Technical notes
Terms, not trust scores.
A collateral-backed commitment to publish preagreed data onchain before a deadline. USDG collateral on Robinhood Chain. Not insurance.
The mechanism
- Deposit. An operator approves the exact collateral amount and deposits it into Surety. The contract tracks available and reserved bond separately.
- Reserve. The operator fixes the client, request hash, result hash, fee, compensation, payment cutoff and delivery duration. Compensation must cover at least the fee. A separate payment vault is created for this one job.
- Pay. The fixed client pays the exact fee into that job's vault. A standard x402 transfer does not itself activate the commitment.
- Activate. Before the cutoff, anyone can activate a funded vault. Its fee goes to the named operator. The delivery deadline is activation time plus the agreed duration. Compensation remains locked.
- Deliver. The named operator publishes the actual nonempty bytes, at most 4,096, with the agreed keccak256 hash. Delivery at the exact deadline is valid. Successful delivery releases bond to available funds.
- Claim. After the deadline, if matching bytes have not been delivered, anyone can trigger compensation. The destination is always the fixed client, never the caller. A settled job cannot pay twice.
Payment windows: 30 seconds to one day. Delivery windows: 30 seconds to seven days. Deadlines use block timestamps, not browser or HTTP timing.
What is actually verifiable?
The initial condition is public delivery of bytes matching a hash agreed before payment. Both parties must know what resource that hash identifies. A matching digest alone is not delivery: the contract stores and emits the bytes.
This is not suitable for arbitrary, previously unknown AI output. The contract does not prove truth, freshness, licensing, usefulness, confidentiality, offchain uptime or HTTP response latency. Even correctly hashed bytes may be useless. All delivered content is public and persistent onchain. Do not submit private or unlawful content.
x402 and the reserved vault
Surety uses a dedicated pay-to vault for each reservation. The client must verify the chain, product contract, fixed client, operator, asset, fee, compensation, result hash and cutoff before signing or transferring. Do not pay a vault belonging to another client: recoveries go to that fixed client.
Signed EIP-3009 exact payment on the no-value test token has passed a loopback HTTP 402 challenge and public-testnet settlement, including tampered destination and replay rejection. The browser currently offers a direct onchain payment and exports the job's payment requirements. The payment service code is prepared, but no publicly validated relay is configured yet.
The product uses canonical USDG. Real USDG uses a separate Permit2 integration route. Read-only checks confirmed canonical USDG, Permit2 and the proxy. A local mainnet-snapshot simulation passed signed Permit2 settlement, reserved-vault activation, delivery, compensation and refunds. This is not a live facilitator test: public relay hosting and full production settlement still require validation before launch. An initial Permit2 approval may require client gas. A successful test fixture is not proof of mainnet compatibility.
Resources: x402 network and token support; official exact EVM scheme.
Funds, fees and exits
Operators earn service fees paid by clients. Compensation is their own existing collateral, not yield. The current Surety contract charges no protocol fee. Each reservation deploys a vault; creation, approvals, activation, delivery and claims cost gas and can outweigh small service fees.
Available bond can be withdrawn by its operator. Reserved bond cannot. An unactivated reservation may expire after its payment cutoff: collateral is released and the vault's balance is refunded to the fixed client. Excess or late funds in a settled vault can be recovered to that same client by any caller.
There is no owner, upgrade mechanism, discretionary arbitration, oracle or admin withdrawal in the deployed Surety product. That does not eliminate code, token or network risks.
Risks and limitations
- Unaudited contracts may contain vulnerabilities. Tests are not an audit or a guarantee.
- Token issuer controls, transfer restrictions, pauses or blacklisting can prevent payments or claims. Fee-on-transfer and rebasing assets are unsupported. An issuer adding an outgoing transfer fee can reduce the amount actually received. A blocked transfer reverts the operation; retry remains subject to issuer and network availability.
- Network outages, RPC limits, wallet problems and transaction ordering can prevent timely activation, delivery or recovery. No automatic claim service is promised.
- Compensation is limited to reserved collateral. It does not insure downstream losses or guarantee a useful service.
- Data and hashes are public. A hash is a content commitment, not a quality or truth oracle.
- Only the most recent 20 commitments are listed in the app. Older commitments remain available through exact ID lookup; there is no complete historical indexer.
Current deployment
Robinhood Chain mainnet. Collateral asset: canonical USDG. Contract deployment does not certify public payment-service readiness.
- Surety product
- Explorer
- Canonical USDG. 6 decimals
- Explorer
31 local contract tests; payment policy, settlement recovery, HTTP and launcher checks. Public-testnet signed exact payment into an isolated vault, activation, matching-byte delivery, compensation to the fixed client and withdrawal of unused bond. Canonical USDG and Permit2 settlement also passed a local mainnet-snapshot simulation. Independent audit, publicly hosted relay and live production facilitator validation are not complete.