A confidential alternative to transparent Proof of Reserve. Reserve balances flow from the custodian's private API directly into a Chainlink CRE workflow via ConfidentialHTTP. They never touch a public feed. The CRE workflow verifies solvency off-chain and publishes only a boolean attestation onchain. When undercollateralization is detected, an AI agent autonomously recovers, whether via direct Uniswap swaps for small deficits or confidential dark pool execution with Chainlink Private Token Transfers for large ones. No human intervention required.
Live Demo | Built for Chainlink Convergence Hackathon 2026
Proof-of-reserve systems today are transparent by design. That's good for trust, but dangerous during a crisis:
- A reserve dips to 98%. Chainlink PoR reports this publicly
- Arbitrageurs front-run the rebalancing trade, driving up costs
- The market interprets the deficit as distress. Panic begins before any recovery can execute
- Large rebalancing orders on DEXs signal the exact deficit size. MEV bots extract value
The reserve manager is stuck: they need to fix the problem, but the act of fixing it makes it worse.
Existing Chainlink Proof of Reserve feeds publish exact reserve ratios on a public chain. Under normal conditions, this transparency builds trust. But during a crisis, it becomes the attack surface.
When a reserve drops below 100%, the exact shortfall is immediately visible. Competitors see the deficit. Traders front-run the recovery. MEV bots extract value from every rebalancing swap. The market reads the ratio as a distress signal and panic selling begins, all before the reserve manager can fix the problem.
This project proposes an alternative architecture for Proof of Reserve, designed for assets where crisis resilience matters more than public ratio granularity. In production, the custodian's reserve API feeds directly into the CRE workflow via ConfidentialHTTP. No public feed is ever involved. The live demo uses real Chainlink wBTC PoR data as a realistic simulation anchor, but in a production deployment, that data path would be entirely private.
The tradeoff is explicit: less granularity for the public (boolean instead of ratio), but the same trustless verification (CRE attestation with DON consensus), with dramatically better crisis resilience.
Self-Healing Reserve keeps reserve balances confidential while still providing trustless onchain proof of solvency.
Custodian API ──▶ CRE Workflow (off-chain) ──▶ Onchain: isSolvent = true/false
│ │
│ Balances NEVER leave │ Agent watches
│ the CRE workflow │ this event
│ ▼
│ Recovery Agent
│ (autonomous wallet)
│ │
▼ ▼
Only a boolean Selects recovery mechanism
reaches the blockchain based on deficit size
The key insight: No sensitive data ever reaches the public chain. Reserve balances stay inside the CRE workflow during verification. Dark pool order amounts, counterparties, and fill prices stay inside the CCC enclave during recovery. Token transfers use CCC private token transfers during settlement. The only public artifacts are a boolean solvency attestation and an encrypted balance hash.
Without CRE and CCC, proof-of-reserve is a tradeoff between transparency and stability. With them:
- Verification is trustless. The CRE workflow with DON consensus ensures the comparison is honest, even though the inputs are hidden
- Recovery is private. No one knows how much is being rebalanced, or through which venue
- Settlement is confidential. CCC private token transfers mean the actual wBTC movements are encrypted onchain, not just the computation
- Market impact is zero. Competitors, traders, and MEV bots can't front-run what they can't see
- Confidence is maintained. The public sees "solvent" or "insolvent" without the noise of partial ratios
The agent intelligently selects the optimal recovery method based on deficit size:
| Mechanism | When | How | Visibility |
|---|---|---|---|
| Direct Wallet Swap | Small deficits (<$50M) | Agent swaps USDC → wBTC on Uniswap | Public onchain txs |
| Chainlink Confidential Compute Dark Pool | Large deficits (>$50M) | CCC threshold-encrypted matching + private token settlement | Only boolean result + encrypted hash public |
A $500K deficit can be swapped on Uniswap without moving the market, so just do it fast. But a $50M+ deficit on a DEX would crater the price, signal distress, and attract MEV. For large deficits, the dark pool matches with institutional market makers inside a CCC compute enclave. No one sees the order size, the counterparties, or the fill price. Token transfers happen via CCC private token transfers where balances are stored encrypted and updated inside the enclave. Only an encrypted balance hash and a boolean success flag reach the chain.
Agent encrypts deficit amount with CCC master public key (threshold encryption)
│
▼
CREDarkPool.sol receives encrypted request
│
▼
Vault DON re-encrypts inputs for assigned compute enclave
│
▼
CCC Compute Enclave
├── Decrypts order amount + market maker balances
├── Matches with market makers privately
├── Applies transfers to encrypted balance table
├── Re-encrypts updated state
└── Produces attestation over result
│
▼
Onchain: encrypted balance hash + boolean success + CCC attestation
PUBLIC: "Recovery executed successfully" + encrypted state hash
PRIVATE: How much, from whom, at what price, which balances changed
Key difference from the previous architecture: the encryption uses CCC threshold encryption via the Vault DON, not a single TEE public key. The master decryption key is secret-shared across decryption nodes. No single node can ever decrypt alone. This means even if a single enclave or node is compromised, the private data remains secure.
The dark pool only works if there's liquidity sitting on the other side of the trade when a crisis hits. This doesn't happen by accident. Institutional market makers pre-commit capital into the CREDarkPool contract ahead of time:
-
Market makers deposit wBTC (or USDC) into the dark pool. These are institutional desks (OTC firms, large funds, custodians) who earn a premium for providing standby liquidity. Think of it like an insurance float: capital sits idle most of the time, but earns yield for being available.
-
Commitments are encrypted and private. Thanks to CCC threshold encryption, no market maker knows the total pool depth, and no one outside the CCC enclave knows who has committed or how much. This prevents front-running of the pool itself.
-
When a deficit occurs, the CCC enclave pairs the recovery order against committed liquidity and fills the order across multiple market makers, splitting the size so no single counterparty sees the full deficit. Each fill is at a fair price (TWAP ± basis points), verified inside the enclave. Token transfers are applied to the encrypted balance table and re-encrypted before leaving the enclave.
-
Market makers are incentivized. They earn a spread on every fill (negotiated at commitment time), plus they get priority access to large OTC flow they'd never see on public DEXs. For institutional desks, this is attractive deal flow, not charity.
-
If liquidity is insufficient, the dark pool fails gracefully. The CCC enclave times out, and the system reports the failure without revealing the order size or the pool's capacity. The reserve stays undercollateralized until manual intervention or a retry with different parameters. This is demonstrated in the "Dark Pool Failure" simulation.
The key tradeoff: the dark pool requires pre-positioned capital, which means ongoing relationships with institutional liquidity providers. In exchange, when a crisis hits, recovery executes in seconds with zero market visibility: no front-running, no panic, no MEV extraction.
| Direct Wallet Swap | Chainlink Confidential Compute Dark Pool | |
|---|---|---|
| Use Case | Deficits < $50M | Deficits > $50M |
| Execution Venue | Uniswap (Public DEX) | CCC Compute Enclave |
| Transaction Visibility | Fully Public | Boolean + Encrypted Hash |
| Market Impact | Moderate Slippage | Zero |
| MEV Protection | None | Full (CCC + Threshold Encryption) |
| Amount Privacy | Exposed Onchain | CCC Threshold Encrypted |
| Token Transfer Privacy | None (Public ERC-20 Transfers) | Full (CCC Private Token Transfer) |
| Speed | ~300ms | ~2.2s |
| Complexity | Low (3 steps) | High (4 steps + CCC), fully automated |
The live demo dashboard uses real Chainlink wBTC Proof of Reserve data from Ethereum mainnet as a simulation anchor. In production, this data would flow from the custodian's private API directly into the CRE workflow via ConfidentialHTTP, never via a public feed.
Three simulation scenarios demonstrate the system end-to-end:
- Small Deficit → Direct Swap: Reserve drops to 99.9%. Agent swaps USDC → wBTC via Uniswap, restores to 100%. Remaining 5% buffer replenished via scheduled OTC.
- Large Deficit → CCC Dark Pool: Reserve drops to 95%. Agent routes through Chainlink Confidential Compute dark pool with threshold-encrypted order, CCC enclave matching, private token settlement. Restored to 105%.
- Dark Pool Failure: CCC enclave matching times out. System stays undercollateralized until manual intervention. Demonstrates graceful failure handling.
Each scenario shows a live step-by-step execution panel with timing, status, and a comparison of what's public vs what stays private.
npm run setup # Install dependencies
npm run demo # Full end-to-end demo
The demo starts a local Hardhat node, deploys contracts, and runs the dashboard with live Chainlink data at http://localhost:3002.
ReserveAttestation.sol: Onchain boolean attestation. The CRE workflow calls onReport() to write isSolvent. The agent monitors ReserveStatusUpdated(bool, uint256) events.
CREDarkPool.sol: Confidential dark pool with CCC private token settlement. requestCollateral() accepts orders encrypted with the CCC master public key (threshold encryption). confidentialFill() settles with a CCC-attested encrypted balance table update. No plaintext amounts ever touch the chain. Runs in simulation mode pending full CCC General Access availability.
workflow/main.ts follows the CRE SDK typescriptConfHTTP pattern:
ConfidentialHTTPClientfetches reserve data from the custodian's private API (encrypted end-to-end)- Compares reserves vs liabilities off-chain within the CRE workflow
consensusIdenticalAggregationacross DON nodes- Returns only
{isSolvent: boolean}. Balances never leave the CRE workflow
The dark pool settlement uses Chainlink Confidential Compute for end-to-end private token transfers:
- Agent encrypts deficit amount with CCC master public key (threshold encryption via Vault DON)
- CREDarkPool.sol receives the encrypted request
- Vault DON re-encrypts inputs for the assigned CCC compute enclave
- Enclave decrypts order + market maker balances, matches fills, applies transfers
- Enclave re-encrypts updated balance table, returns encrypted state + boolean + attestation
- Onchain: only the encrypted balance hash, boolean success, and CCC attestation are stored
In simulation mode, the CCC operations are simulated with the correct interfaces and data flows. The workflow is designed to be a drop-in upgrade when CCC General Access launches.
Monitors ReserveStatusUpdated events and selects recovery mechanism:
- Small deficits: Check wallet balance → Swap USDC → wBTC on Uniswap → Send to reserve
- Large deficits: Encrypt order with CCC master public key → Submit to dark pool → CCC enclave matching → Private token settlement → Encrypted state onchain
Uses an MPC wallet (no raw private keys exposed to the agent). Dry-run mode by default.
See SECURITY.md for the full security architecture, including what runs inside the CRE workflow and CCC enclave in production vs what is simulated in the demo.
| Data | Visibility |
|---|---|
isSolvent boolean |
Public onchain |
| Reserve amounts | Never onchain (CRE workflow only) |
| Dark pool order amount | Never onchain (CCC threshold encrypted) |
| Market maker identities | Never onchain (CCC enclave only) |
| Fill prices | Never onchain (CCC enclave only) |
| Token transfer amounts | Never onchain (CCC private token transfer) |
| Updated balance table | Onchain as encrypted hash only |
| Recovery succeeded | Public onchain (boolean) |
| CCC attestation | Public onchain (proves computation was correct) |
The demo uses real Chainlink wBTC PoR data as a simulation anchor and simulates CCC operations with the correct interfaces. In production:
- Reserve data flows from the custodian's private API into the CRE workflow via ConfidentialHTTP, never via a public PoR feed
- CCC threshold encryption replaces simulated encryption. The Vault DON manages the master key
- Dark pool settlement uses real CCC private token transfers with encrypted balance tables and enclave attestation
- CCC attestation proves settlement was computed correctly inside the enclave
- Chainlink CRE: Chainlink Runtime Environment (off-chain workflow orchestration)
- Chainlink Confidential Compute (CCC): Threshold encryption + private token transfers for dark pool settlement
- Chainlink Proof of Reserve: Live wBTC PoR feed on Ethereum mainnet (simulation anchor)
- MPC wallet: Autonomous agent wallet (no raw private keys)
- Solidity 0.8.19: ReserveAttestation + CREDarkPool contracts
- TypeScript + viem: All runtime code, Ethereum client
- Express: Dashboard backend + mock API
- Hardhat: Local EVM for demo