Trust
Security & trust model
Concrete guarantees, explicit trust boundaries, and known risks.
Updated October 14, 2026
On this page
Contract security
The deployed v2 contracts have not undergone an independent security audit. The repository includes lifecycle, access-control, accounting, and reentrancy tests, but tests are not an audit. Smart-contract bugs, validator or infrastructure failures, and loss of signing access remain possible.
Commitment escrow is held by BondlineCore. Each Circle has a separate Pot contract. Contract accounting reserves failed stakes for rewards; arbitrary payout voting cannot consume those reserved funds. Fund-moving paths use reentrancy protection and finalize accounting before external transfers.
Account security
Mera’s WebAuthn PRF output derives the same secp256k1 account when the same passkey is used. Bondline stores credential metadata, not a persistent signing key, in browser storage. Derived buffers are cleared where possible and the short-lived signing session ends after use. JavaScript memory clearing is not a formal guarantee against a compromised device or browser.
There is no Bondline-operated key recovery or custody service. Passkey sync and recovery depend on your provider. Losing the credential can lose access to funds. A different origin or relying-party configuration may prevent use of an existing passkey; use the stable production domain.
Private app features
The server verifies a signed nonce challenge before issuing a seven-day HttpOnly session cookie. Chat requests check current on-chain Circle membership. Profile and Circle changes are authorized server-side; database administrator keys are not sent to the browser.
Chat is access-controlled, not end-to-end encrypted. Project operators and database infrastructure can access stored messages. Display images, profiles, and Circle metadata are public. Do not upload sensitive content. The separate private journal encrypts notes on your device using Mera’s PRF vault; its plaintext is not sent to chat or the database.
Verification and operations
Circle-reviewed outcomes depend on peers. External verification depends on the configured attestor and its data source. The administrator controls the external-verifier registry. The indexer and website improve access to information but do not replace contract authority.
Expired commitments may need a transaction to settle. The indexer’s scheduled job is not a universal settlement or verifier scheduler.
Reporting a problem
Use Contact for the configured support channel. Public GitHub issues are suitable for general bugs, but never publish an exploitable vulnerability, private key, provider secret, or private conversation there. If no private reporting address is configured, first ask the maintainers for a private channel without disclosing details.