Architecture

Minerva Bridge is a liquidity-backed bridge between the existing fixed-supply Ethereum MRV token and native MRV on Minerva. The system does not mint or wrap Ethereum MRV.

V1 Model

V1 uses the pure liquidity pool model. Ethereum MRV holders deposit real MRV into MRVBridgeLiquidityVault. When native MRV users bridge to Ethereum, the Ethereum vault releases MRV from deposited liquidity. When users bridge Ethereum MRV to Minerva, MRV returns to the vault and native MRV is released on Minerva.

LP principal can become unavailable while bridge demand consumes Ethereum-side liquidity. ETH epoch rewards, dynamic fees, caps, finality checks, and pause controls compensate and constrain this risk.

Components

• Ethereum contracts: vault, ETH rewards, message registry, guardian manager, fee collector.
• Sepolia deposit adapter: SepoliaMRVBridgeDepositAdapter emits user bridge deposits for Sepolia MRV -> Minerva native MRV; existing LP deposits remain LP-only.
• Minerva side: MinervaNativeBridgeVault, MinervaBridgeMessageRegistry, and MinervaBridgeGuardianVerifier handle native MRV locks, releases, nonce tracking, replay protection, refunds, and guardian checks.
• Relayer: observes finalized events on both chains, constructs bridge messages, gathers attestations, submits executions.
• Indexer/API: exposes bridge liquidity, user positions, message status, reward epochs, and health.
• Monitor/finalizer: tracks bridge risk surfaces and finalizes reward epochs.
• Web app: bridge, liquidity, rewards, history, status, and admin console.

Message Safety

Bridge messages must include source chain, destination chain, source asset, destination asset, sender, recipient, amount, fee, nonce, deadline, source transaction hash, and domain separator.

Messages execute once. Expired, wrong-chain, duplicate, or insufficient-liquidity messages must not execute.

Both vaults verify releases on-chain: full message, guardian threshold, unexpired deadline. After deadline + expiryMargin anyone can record an inbound message as Expired on the destination, which makes it unexecutable there forever. Guardians then attest the cancellation (a hash over the message hash and destination chain ID) and the source-side lock or deposit becomes refundable by its sender. No timer ever refunds on its own. Executed transfers are settled on the source chain by the relayer (confirmOutboundExecuted, confirmDepositExecuted) and cannot be cancelled afterwards.

The canonical native-MRV bridge asset identifier is 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE. The canonical message domain is keccak256("MINERVA_BRIDGE_MESSAGE_V1"), matching the deployed Sepolia registry domain.

Minerva PoW Finality

Minerva is treated as a sovereign PoW L1. Relayers must wait MINERVA_CONFIRMATIONS before executing a Sepolia release from a Minerva lock event, then re-check that the event still exists before submitting the destination transaction. The default for this milestone is 50 Minerva confirmations and 32 Sepolia confirmations.