Collateral Passport
The on-chain admission layer for tokenized RWA collateral. Before a lending protocol accepts a tokenized stock or RWA as collateral, Collateral Passport answers one question on-chain — is this asset eligible, attested by a trusted party, fresh, and not already pledged? — and returns a deterministic Allow / Deny / ConditionalAllow. Live on Robinhood Chain testnet.
Videos
Tech Stack
Description
What it is
Collateral Passport is the on-chain admission layer that lets lending protocols safely accept tokenized real-world-asset
(RWA) collateral. It does not produce compliance decisions, originate market data, or score risk — it records what regulated attestors sign and enforces it on chain.
The problem
Tokenized RWA collateral (e.g. xStocks) is arriving on-chain, but lending protocols have no shared way to decide whether a specific asset is eligible, attested, unexpired, unrevoked, and not already pledged elsewhere. Today this is hardcoded allowlists + per-protocol risk params (e.g. Kamino accepting xStocks). That doesn't compose attestations, doesn't survive revocation or corporate actions, and can't see cross-protocol double-pledging.
How it works
An attestor signs a typed claim about an asset (EIP-712, EIP-1271 multisig supported). An integrator binds a per-integrator policy template to its address. When its vault calls checkAdmission(...), the template composes the claims + cross-protocol encumbrance + optional market signals and returns Allow / Deny / ConditionalAllow with a rationale code — deterministically, on chain.
What's live (Robinhood Chain testnet — primary)
- All core contracts deployed and source-verified on Robinhood Chain testnet (46630), mirrored on Arbitrum Sepolia (421614) as a portability proof.
- 7 reproducible demos run end-to-end against the live deployment.
- TypeScript SDK (viem), 3 live sites (landing / docs / demo console), subgraph, 186 passing tests (fuzz + invariants), Slither in CI.
The hero: value-aware admission + a real attestor trust model
- Value-aware policy (StandardAdmissionTemplateV2): a trusted attestor signing eligibility = Rejected is denied on-chain Deny:ClaimValueNotAllowed), not admitted on presence. Proven live demo6).
- Regulated-attestor trust model: the attestor is modeled as an EIP-1271 multisig MultisigAttestor) — a contract requiring multiple signers, like a regulated entity would use — not a single dev key. Proven live demo7): the multisig signs Rejected → deposit is denied on chain.
Why it's different (not just an allowlist)
- vs ERC-3643 / T-REX: those gate at the token (issuer-controlled permissioned token). We gate at the integrator's policy over shared claim + encumbrance state — different lending protocols can apply different policies to the same asset, and encumbrance is tracked across protocols.
- vs Chainlink ACE: ACE does identity/compliance attestation; it doesn't issue the gating decision or track encumbrance. We compose attestations into a decision + encumbrance.