Chrysalis v1 Architecture

Architecture notes for Chrysalis v1 route resolution, wallet handling, bridge selection, settlement tracking, and dependency boundaries across CCIP, CCTP, and Axelar ITS.

Wallet connects (Wagmi/ConnectKit for EVM, Crossmark for XRPL)
                │
                ▼
     Network -> protocol lookup (config-driven, no inference)
                │
        ┌───────┼────────┐
        ▼       ▼        ▼
      CCIP    CCTP    Axelar ITS
        │       │        │
        └───────┼────────┘
                ▼
     Protocol-specific status manager polls settlement
     (CCIP explorer / Circle Iris attestations / Axelar transfer status)
                │
                ▼
     Destination staking state fetched (Ethereum Sepolia) -> Dashboard
                │
                ▼
     (Ripple route only) XRPL NFT staking receipt minted

Frontend stack

React 18 with TypeScript on Vite, styled with Tailwind CSS and animated with Framer Motion. Wallet and chain state run through Wagmi and ConnectKit for EVM, with TanStack Query handling data fetching and caching and Zustand holding client-side app state.

Staking orchestration hook

A single staking hook is the control point for the whole flow: it reads token balances and allowances for the connected wallet, resolves which contract path applies for the active protocol, submits the cross-chain stake transaction, subscribes to status updates from the relevant protocol's status manager, and persists transaction metadata once the flow starts.

Network and protocol configuration

A single config module is the source of truth for every supported chain: chain IDs, RPC and explorer URLs, the network-to-protocol matrix, token decimals, and the contract addresses used per route. Because the UI reads this config rather than trying to infer support, a network only ever offers the protocol it's actually wired for.

Cross-chain status tracking

Each bridge protocol reports settlement differently, so each has its own status manager:

• CCIP routes poll Chainlink's CCIP explorer/API for message and transaction status.
• CCTP routes poll Circle's Iris attestation API for burn confirmation and mint attestation status.
• Axelar ITS routes poll Axelar's transfer status endpoints, then hand off to the XRPL minting flow once the transfer settles.

XRPL staking receipt NFTs

Ripple-originated stakes mint a compact XRPL NFT as a staking receipt once the Axelar ITS transfer settles - staker address, amount, token symbol, route name, reference APY, stake timestamp, and the resulting stETH amount, kept deliberately small since XRPL NFT URI payloads are size-limited.

Transaction history persistence

Transaction history is cached locally in the browser first, with optional remote persistence to a Redis-backed history store so history can survive a device switch. If the remote store isn't configured, the app simply falls back to local history - nothing about the staking flow itself depends on it.