Dual-chain anchoring
Status: live. Today, sealed records are anchored on Robinhood Chain, which is live. A second anchor chain for resilience is planned to be added later, so no single chain becomes a point of failure. Until it ships, anchoring runs on Robinhood Chain alone.
The design writes every batch of sealed decisions to Robinhood Chain. The Merkle root goes on-chain, so a single anchor’s cost stays gas-independent. A second resilience chain, planned for later, will give the proof a second, independent home. The reason is deliberate: a track record anyone can verify should not depend on any one chain staying alive.
Anchored event for a batch is emitted on Robinhood Chain. Under the planned design, the identical root value will also be emitted for the same batch on a second resilience chain. Verify →Why two chains
A proof anchored to a single chain inherits that chain’s single points of failure: downtime, reorgs, deprecation, or access being blocked in a given jurisdiction. A second resilience chain, planned for later, removes that dependency. Each chain also brings something the other does not, so the pair is complementary rather than redundant.
Robinhood Chain: ecosystem home
Robinhood Chain is where BLEEEP lives natively. It is designed to hold:
$BLEP: the planned ecosystem token. Supply and allocation are provisional; utility is TBA while the model is being revised. See /token.- Agent reputation: sealed track records and NO-GO archives written to the ERC-8004 reputation registry.
- Verification services: the surface other agents and funds call to check a claim.
Robinhood Chain offers low gas and native attestation support (EAS), which makes frequent anchoring and structured attestations practical. It is the hub for ecosystem integration described in /architecture.
Distribution and settlement reach
Robinhood Chain also brings reach beyond the crypto-native audience:
- Broad distribution: a surface that extends past on-chain-native users.
- RWA-grade settlement rails: settlement infrastructure oriented toward regulated, real-world-asset use.
The intent is that a proof is not just verifiable in principle but reachable in practice by an audience that does not already live in DeFi.
The same root, written twice
The proof layer batches sealed records, computes one Merkle root per batch, and submits that root to an identical minimal anchor contract. On Robinhood Chain today that is one transaction per batch; under the planned design the same root is submitted to a matching contract on each chain. Because the root is a single hash, a batch of 1 record and a batch of 1,000 both anchor in one transaction per chain.
| Property | How it is enforced |
|---|---|
| Same root on both chains | The batcher submits one identical (batchId, root) pair to each target. |
| No duplicate/overwrite | Each batchId is idempotent per chain: a re-submit of the same id is rejected. |
| Survives partial failure | If one chain’s submission fails, it goes to a retry queue; the proof is valid as long as at least one chain succeeded. |
Anchoring keys and gas are operator-managed, held in secrets, and separated per chain: the anchoring wallet is never the trading wallet, and neither lives in code.
What “cross-anchored” gives a verifier
A reader checking a revealed decision runs the same three tests described in /proof-of-provenance/merkle-anchoring:
keccak256(record ‖ salt)equals the committed leaf.- That leaf’s Merkle proof resolves to an anchored root.
- The anchor timestamp precedes the outcome.
The difference the planned design adds is at step 2: the root may be matched against either chain’s copy. If Robinhood Chain is unreachable, the second resilience chain’s root answers; if one chain’s history is disputed, the other corroborates it. Today, with Robinhood Chain live, step 2 matches against the Robinhood Chain root. No single operator sits between the record and its verification.
This is the same principle stated in the project’s design rules: prove with on-chain hashes, and do not let a proof rest on one point of failure.
Next, follow a full check end to end on the /verify page.