Using Bondline
Verification
Know exactly what your completion rule proves—and what it does not.
Updated October 14, 2026
On this page
Circle evidence review · available
Peer review supports outcomes that friends can reasonably judge, such as a run log, a study summary, or a published project. This is human judgment, not independent proof of every claim. Choose reviewers you trust and agree on evidence in advance.
On-chain balance · available
Bondline checks the creator’s available native MON balance against a target stored at creation. Anyone can trigger the check before the deadline. A failed check does not by itself forfeit the commitment; the creator can reach the target and retry before the deadline.
The stake has already left the available balance. This method does not lock savings, distinguish borrowed funds, verify income, or measure how long a balance has been held.
GitHub · available with the operating verifier
Choose a public repository, GitHub username and commit target in the app. The CRE workflow checks unique matching commits on the default branch within the immutable activity window. The current service runs official CRE CLI simulation on an operator’s Mac and uses an authorized signer for settlement. It does not prove ownership of the GitHub account or work quality.
Check progress queues a verification request; the worker also discovers and rechecks supported active goals. Progress below the target leaves the goal active. Success must settle on-chain before the deadline. The app disables new external commitments when its verifier is unavailable or lacks the readiness fee balance. An API error does not establish success.
Onchain activity · direct contract call
Configure a contract on Monad testnet and submit the transaction hash when checking progress. One successful, finalized direct call from the commitment account to that contract must occur inside the commitment window. Reverted transactions, internal calls and calls from another account do not qualify. This uses the same operator-backed CRE CLI service as GitHub verification.
Planned categories
- Fitness providers: no wearable or fitness API integration is live.
- Learning providers: no course platform integration is live.
- Custom external signals: the attestation contract path exists; provider integrations need implementation and explicit trust review.
- Live Chainlink DON deployment remains unavailable for this account. The production forwarder receiver is prepared for that future mode. The current app instead uses official CRE CLI simulation plus authorized EOA settlement; the older standalone Node verifier is a separate integration.
What if a provider fails?
Do not create provider-verified goals unless the required worker is operating. External success must be submitted before the deadline. Contract expiry rules still apply if a worker does not attest; there is no promise of a manual operator override or compensation. Inspect the configured rule before staking.