Proof-bounded RWA issuance and redemption on Creditcoin.
Open the live application · Judge Evidence: verify V2 · Start issuing · Redeem an asset · Source repository
Resyvr lets an organization issue a branded real-world asset token on Creditcoin without trusting a centralized oracle to report its reserve. The issuer locks test USDC in a canonical Ethereum Sepolia vault. Attestcoin proves that exact deposit to Creditcoin, where Resyvr checks the vault, asset, issuer, recipient, amount, receipt status, and replay identity before minting exactly the proven amount. The reverse flow escrows the token, proves the reserve payout, and burns the redeemed supply.
The result is a reusable issuance rail with one public trail from reserve lock to mint, and from redemption request to payout and burn.
| Hackathon track | RWA |
| Destination chain | Creditcoin CC3 Testnet (102031) |
| Reserve chain | Ethereum Sepolia (11155111) |
| Reserve asset | Circle test USDC, 6 decimals |
| Cross-chain verification | Creditcoin Attestcoin Protocol |
| Issuer commitment | Native CTC activation stake |
| Current status | Live testnet issuance and proof-finalized redemption |
| Contracts | Solidity 0.8.30 and Foundry |
| Application | Dependency-free browser UI with MetaMask |
All newly created assets use the V2 contract path: canonical Sepolia vault provenance, proof-bounded minting, redemption escrow, proven reserve payout, and supply burn. Existing V1 assets remain visible and usable for their original issuance-only flow; they are not silently upgraded or represented as redeemable. This preserves their immutable on-chain configuration while giving new issuers the complete lifecycle.
An inclusion proof answers one narrow question: did this source-chain transaction occur in an attested block? It does not decide whether that transaction should authorize a token mint.
An RWA issuer still needs to prove that:
- the transaction succeeded;
- the funds entered the correct reserve vault;
- the vault belongs to the correct issuer;
- the configured reserve asset moved;
- the amount and recipient match the intended issuance;
- the same transaction or deposit has never been used before;
- supply stays within the reserve that has passed those checks;
- redemption pays the correct holder before escrowed tokens are burned.
Resyvr turns those requirements into reusable contracts, issuer factories, canonical vaults, a guided wallet flow, and a public evidence dashboard.
- Create an isolated controller, ERC-20 token, reserve vault, and CTC stake vault for each asset.
- Choose the token name and symbol while the contracts preserve one immutable reserve boundary.
- Mint additional units of the same token by making a new reserve deposit and proving it; a new token deployment is not required.
- Manage every token created by the connected administrator from an on-chain issuer portfolio.
- Pause issuance or redemption without rewriting the asset configuration.
- Receive the exact token amount named by the verified reserve event.
- Inspect the token, controller, reserve provenance, CTC stake, supply, and proof-accounting coverage through public links.
- Request redemption by escrowing tokens on Creditcoin.
- Receive the exact reserve amount on Sepolia before the proof finalizes the burn on Creditcoin.
- Reuse canonical source-vault and issuer factories rather than rebuilding the full cross-chain authorization boundary.
- Verify every published deployment and state claim with public RPCs.
- Run unit, fuzz, invariant, dashboard, encoding, preflight, and live evidence checks from one command.
- Study explicit failure cases for wrong vaults, beneficiaries, amounts, receipts, payout terms, and replay attempts.
flowchart LR
subgraph Sepolia[Ethereum Sepolia]
USDC[Circle test USDC]
FactoryS[Canonical vault factory]
Vault[Issuer reserve vault]
USDC -->|deposit| Vault
FactoryS -->|CREATE2 deploys| Vault
end
Attestcoin[Attestcoin proof]
subgraph Creditcoin[Creditcoin CC3 Testnet]
FactoryC[Issuer factory]
Controller[Issuer controller]
Token[Issuer ERC-20 token]
Bond[CTC activation stake]
FactoryC --> Controller
FactoryC --> Token
FactoryC --> Bond
Controller -->|mint / escrow / burn| Token
Bond -->|gates issuance| Controller
end
Vault -->|deposit or payout event| Attestcoin
Attestcoin -->|verified transaction + receipt + event| Controller
Creditcoin is the verification and settlement layer. Resyvr calls the CC3 Block Prover precompile through Attestcoin, stores reserve and redemption accounting on Creditcoin, and uses CTC for gas and the issuer activation stake. Without Creditcoin, the demonstrated cross-chain authorization gate and native issuer commitment do not exist.
- Create a canonical reserve vault on Sepolia. The vault is derived from the published factory, reserve asset, issuer ID, and administrator.
- Create the token system on Creditcoin. The issuer factory deploys an isolated controller, branded token, and CTC stake vault.
- Post and activate the CTC stake. Issuance remains disabled until the minimum native CTC commitment is funded and activated.
- Lock reserve USDC on Sepolia. The vault emits a unique deposit ID, issuer ID, beneficiary, depositor, and exact amount.
- Generate the Attestcoin proof. This requires no wallet signature. The proof becomes available after the source block enters Attestcoin coverage.
- Submit the proof on Creditcoin. The controller validates the complete transaction and event semantics, consumes two replay keys, records the reserve, and mints the exact proven amount.
The beneficiary can be the issuer or another wallet. Importing the resulting Creditcoin token address into MetaMask only makes the balance visible; tokens reach a user when a proven deposit names that wallet as beneficiary or when an existing holder transfers tokens to it.
- The holder approves the controller and requests redemption on Creditcoin.
- The controller escrows the exact token amount and creates a redemption ID.
- The issuer pays the named Sepolia recipient from the canonical reserve vault using that redemption ID.
- Attestcoin proves the successful payout transaction to Creditcoin.
- The controller checks the vault, operator, recipient, amount, issuer ID, calldata, event, and replay identities.
- The controller marks the request complete and burns the escrowed tokens.
Redemption is asynchronous because one Creditcoin transaction cannot synchronously execute a Sepolia payout. Anyone may submit the eventual proof, so a relayer can affect timing but cannot change the recipient or amount.
The main dashboard presents the product in the order an issuer needs it:
- understand the reserve-to-token model;
- inspect the live public proof trail;
- issue or reopen an asset;
- complete a guided redeemable issuance flow;
- manage every asset created by the connected wallet.
The redemption flow is embedded in the same dashboard at
#redemption,
immediately before Your issued assets. The fixed navigation keeps issuance,
proofs, and redemption reachable while scrolling. Each wallet action names the
chain, signature count, and effect before MetaMask opens. Confirmed hashes are
saved before receipt polling so a refresh can recover progress without asking
the user to repeat a reserve transfer.
Pending Attestcoin coverage is shown as a normal lifecycle state with a route back to the required proof action. It is not presented as a failed reserve or a missing asset.
The redeemable pilot locked 100,000 base units (0.1 test USDC), minted 0.1 rvUSD2, paid the reserve recipient, finalized the proof, and burned the escrowed supply.
| Component | Network | Address |
|---|---|---|
| Canonical vault factory | Sepolia | 0x97e2…400f |
| Canonical reserve vault | Sepolia | 0xb733…5A1e |
| Issuer factory | Creditcoin | 0x9266…f0d8 |
| Issuer controller | Creditcoin | 0x1349…7834 |
| rvUSD2 token | Creditcoin | 0x5b8b…9ac9 |
| CTC activation stake vault | Creditcoin | 0x488e…9226 |
| Lifecycle action | Network | Transaction |
|---|---|---|
| Create canonical vault | Sepolia | 0x2ef2…9945 |
| Lock reserve | Sepolia | 0x52a6…00c7 |
| Create V2 issuer | Creditcoin | 0x0a5b…cdff |
| Deposit activation stake | Creditcoin | 0xafe4…fd40 |
| Activate issuance | Creditcoin | 0xe6cc…316 |
| Verify deposit and mint | Creditcoin | 0x7d1d…226b |
| Approve redemption escrow | Creditcoin | 0xa80f…6821 |
| Request redemption | Creditcoin | 0x368e…d5d0 |
| Pay reserve recipient | Sepolia | 0x0b9f…45e4 |
| Finalize redemption and burn | Creditcoin | 0xe006…60b0 |
The completed V2 state is:
| State | Base units | Display amount |
|---|---|---|
| Token total supply | 0 |
0 rvUSD2 |
| Pending redemption | 0 |
0 rvUSD2 |
| Net verified reserve | 0 |
0 USDC |
| Total redeemed | 100000 |
0.1 USDC |
| Source vault recognized reserve | 0 |
0 USDC |
This final state demonstrates the complete accounting loop: reserve entered, matching supply was issued, reserve left for the named redemption, and the matching supply was burned.
V1 is preserved as historical issuance evidence and does not support redemption. The original pilot locked 5 test USDC on Sepolia. A genuine Attestcoin proof was accepted on Creditcoin and minted exactly 5 rvUSD to the beneficiary.
| Evidence | Network | Explorer |
|---|---|---|
| Source reserve vault | Sepolia | 0x99d9…B34f |
| 5 test-USDC deposit | Sepolia | 0xbc7b…45b |
| Issuer factory | Creditcoin | 0xd951…323F |
| Issuer controller | Creditcoin | 0x81a5…2948 |
| rvUSD token | Creditcoin | 0xbCb8…5Afa |
| 1 CTC stake vault | Creditcoin | 0x164e…B55f |
| Proof-backed mint | Creditcoin | 0xe5c1…4ddb |
The V1 source vault currently contains 6 test USDC because a later 1-USDC deposit has not been submitted as an accepted proof. The controller therefore reports 5 verified USDC and the token supply remains 5 rvUSD. This is the intended boundary: an unproven source deposit cannot authorize minting.
Attestcoin supplies cryptographic inclusion evidence. Resyvr supplies the application-level authorization rules. A proof can mint or finalize redemption only after all relevant rules pass.
- The proof must use the configured source-chain key.
- The transaction receipt must report success.
- The transaction target must be the canonical vault or the configured MetaMask transaction executor with the expected routed call.
- The log emitter, event signature, issuer ID, reserve asset, depositor, beneficiary, and amount must match immutable configuration and calldata.
- Both the Attestcoin query ID and source deposit ID can be consumed once.
- Minting uses the beneficiary and amount from the verified event.
- Supply cannot exceed net proof-accounted reserve after decimal normalization.
- An active and sufficiently funded CTC stake is required before minting.
- Tokens enter controller escrow before a request becomes pending.
- The source payout must come from the canonical vault and authorized payout operator.
- Calldata and the
ReservePaidOutevent must agree on redemption ID, recipient, and amount. - The payout query and redemption ID can each be consumed once.
- Accounting updates and escrow burning occur atomically on Creditcoin.
- The CTC stake cannot be withdrawn while token supply or pending redemption liability remains.
The suite also covers failed receipts, duplicate and ambiguous events,
arbitrary source vaults, unauthorized operators, mismatched payout terms,
fee-on-transfer behavior, pause controls, and replay attempts. See
docs/security-invariants.md for the detailed
evidence map.
- The system is deployed on testnets and has not been independently audited.
- Circle test USDC has no financial value.
- Attestcoin proves what happened on the supported source chain; it does not guarantee the reserve token issuer itself.
- The displayed ratio is proof-accounting coverage. It compares accepted reserve proofs with Creditcoin token supply; it is not a general real-time solvency rating.
- The CTC vault holds an activation stake. There is no slashing mechanism, insurance policy, dollar conversion, or automatic holder compensation.
- Redemption requires the issuer to perform the Sepolia payout. Anyone can submit its proof afterward, but the protocol still has issuer-liveness risk.
- There is no automatic redemption timeout refund because a payout can be complete while its proof is still pending. Refunding tokens in that interval could pay the holder twice.
These boundaries are part of the design and visible in the product. Resyvr does not present itself as an audited stablecoin or claim that CTC is dollar-stable.
resyvr/
├── contracts/
│ ├── src/ # V1 issuance and V2 redemption contracts
│ ├── test/ # unit, fuzz, and stateful invariant tests
│ └── script/ # Foundry deployment scripts
├── dashboard/ # public proof dashboard and guided wallet flows
├── config/ # networks, bytecode, deployments, and evidence
├── docs/ # architecture, security, operations, and submission
├── scripts/ # preflight, deployment, and evidence verification
├── src/ # TypeScript proof generation and validation modules
└── test/ # TypeScript tests
- Node.js 22.12 or newer
- npm
- Foundry (
forge) - MetaMask for interactive testnet transactions
Install dependencies and start the static application:
npm install
npm run dashboardOpen http://127.0.0.1:8000/dashboard/.
The public dashboard and evidence commands use configured public RPCs and do not need a private key. Interactive issuance needs a wallet funded with:
- Sepolia ETH for source-chain gas;
- Circle test USDC for the reserve;
- testnet CTC for Creditcoin gas and the activation stake.
Optional RPC overrides can be placed in .env using .env.example as the
template. Never commit private keys or wallet seed phrases.
Run the complete validation pipeline:
npm run checkIt currently covers:
- TypeScript typechecking and module tests;
- browser JavaScript syntax, DOM contract, and proof encoding checks;
- submission completeness checks;
- 55 Foundry tests, including fuzz and stateful invariant campaigns;
- Attestcoin protocol and network preflight checks;
- 79 live V1 evidence checks across Sepolia and Creditcoin;
- 93 live V2 lifecycle checks covering every receipt, deployed bytecode, both Attestcoin proofs, source and destination events, replay state, and the final zero-supply/zero-reserve accounting state.
Useful focused commands:
npm run contracts:check # format, build, and test Solidity
npm run dashboard:check # validate the browser application
npm run preflight # verify Attestcoin/network assumptions
npm run evidence:verify # reproduce the V1 live evidence
npm run evidence:v2:verify # verify both canonical V2 factories
npm run evidence:v2:pilot # reproduce the complete live V2 round tripRead-only verification needs no wallet signature, API key, or private key.
- Architecture and trust boundaries
- V2 redemption protocol
- Security invariant evidence
- Live deployment and failure evidence
- RWA submission copy
- Live Judge Evidence page
- Three-minute demo script
- Submission checklist
- Competitive landscape
Resyvr connects off-chain economic value represented by a source-chain reserve with a transparent Creditcoin asset. The core product is infrastructure for organizations to create, capitalize, issue, inspect, and redeem tokenized claims while cryptographic cross-chain evidence controls supply changes.
The project does not claim that cross-chain proofs or lock-to-mint are new. Its contribution is the issuer control plane around those primitives: canonical vault provenance, multi-issuer isolation, branded tokens, exact proof-bound accounting, liability-aware CTC stakes, redemption escrow, replay protection, and public evidence.
Completed for the hackathon build:
- live V1 reserve deposit, genuine Attestcoin proof, and exact Creditcoin mint;
- live V2 canonical vault, issuance, redemption payout, proof finalization, and supply burn;
- verified V2 source and destination factories;
- self-service wallet flows, multi-issuer portfolio, public proof trail, and recoverable transaction state;
- unit, fuzz, invariant, browser, preflight, and reproducible live-evidence checks.
The next production milestones are an independent contract audit, broader source-chain and reserve-asset support, decentralized payout operations, objective stake-slashing rules, and a formally designed redemption recovery protocol. Those milestones are future work and are not presented as features of the testnet build.
MIT