The commitment
A provider promises to deliver a signed financial data packet within a defined deadline — capital is committed before that promise is accepted
The first proposed use case is delivery timeliness for financial data — it does not establish whether an asset valuation or market price is economically correct
Production guarantee contracts and deposit service are not deployed
- Provider — reserves the bond and delivers the packet
- Beneficiary — agrees the terms and separately funds the service fee
- Verifier and resolver — check agreed evidence and handle conflicting submissions under explicit rules
From terms to settlement
Define
Specify the service identifier, authorized signer, deadline, liability limit, evidence format and challenge window — liability cannot exceed the reserved provider bond
Bond
Reserve the provider capital and beneficiary-funded fee — terms become fixed for this commitment
Verify
Record the packet, signature and delivery timestamp — retain funds for the full challenge window and resolve conflicting evidence before release
Settle
When the commitment is fulfilled, release the provider bond and pay the service fee — when the agreed failure condition is upheld, apply the bounded penalty and return the unearned fee
What evidence can establish
| Condition | Required evidence | Scope |
|---|---|---|
| Packet origin | Signature from the agreed authorized signer | Origin of a packet |
| Delivery time | Commitment-bound receipt and defined timestamp source | Delivery before a deadline |
| Packet conformity | Agreed schema and service identifier | Conformity with agreed terms |
| Price correctness | Separate source policy and verification design | Outside this initial model |
A production implementation still needs replay protection, signature verification, timestamp semantics, dispute resolution, operator permissions and failure-mode testing — the website does not implement these as an onchain service
Every unit has a destination
The example bond and fee are independently funded — a failed commitment returns the fee because it was not earned
Provider = bond + fee
Beneficiary = 0
Upheld failure
Provider = bond − liability
Beneficiary = liability + fee
For the default example, a 2,500 USDG bond and 25 USDG fee produce a total funded amount of 2,525 USDG — a 500 USDG penalty returns 2,000 to the provider and 525 to the beneficiary
USDG units are illustrative accounting inputs — the example does not assume a market exchange rate, source real balances or promise a dollar value
Robinhood Chain and launch
The official network documentation supports EVM contract deployment on Robinhood Chain mainnet with chain ID 4663 and ETH for gas
Deployment of an ERC-20, provision of market liquidity and listing in the Robinhood App are distinct processes — chain deployment does not imply App availability or Robinhood endorsement
The proposed token is a coordination asset — collateral and liability must remain explicitly defined for each commitment
Read the token thesisOfficial sources
Research checked on 26 October 2026 — these sources describe the reference mechanisms and network, rather than a live SURETY deployment
- Eigen Labs — introducing slashing
- EigenLayer — allocation and operator commitments
- Robinhood Chain — network configuration
- Robinhood Chain — contract deployment
- Robinhood — supported coin availability