Bridges: Mina, EVM, and Midnight

dregg connects to external chains via proof translation -- not consensus bridging. Each bridge converts a dregg STARK proof into a format the target chain can verify natively. No trusted relayers, no multisigs, no committee attestations. The target chain verifies the math directly.

Trust Levels

EVM Bridge (Ethereum, Base)

Architecture

1. Generate STARK proof (off-chain): The Effect VM proves your state transition.
2. SP1 wrapping (off-chain): Succinct's SP1 zkVM verifies the STARK inside a RISC-V guest program, producing a Groth16 proof.
3. On-chain verification (EVM): The Groth16 proof is verified by the SP1 Verifier Gateway contract (~200K gas).
4. State update (EVM): The dregg bridge contract records the new state commitment on-chain.

Depositing (EVM to dregg)

# Step 1: Deposit ETH/tokens to the Dregg bridge contract
# (uses commit-reveal to prevent frontrunning)

# Step 2: The deposit appears as a note commitment in Dregg's note tree
# (federation includes it in the next epoch)

# Step 3: Claim the deposit in Dregg
dregg cclerk claim-deposit --tx-hash 0xabc123...

Withdrawing (dregg to EVM)

# Step 1: Generate a STARK proof of your note ownership
dregg proof generate --backend plonky3 --turn $SPEND_TURN

# Step 2: Wrap in Groth16 via SP1
dregg proof wrap-sp1 --input $STARK_PROOF --output evm-proof.bin

# Step 3: Submit the Groth16 proof to the bridge contract
# (calls verifyAndWithdraw on-chain)

Sovereign Cells On-Chain

A sovereign cell can exist as an on-chain entity with its 32-byte commitment stored in the bridge contract. This enables:

• Other smart contracts to verify dregg state transitions on-chain.
• EVM DeFi protocols to interact with dregg cells (e.g., collateral proofs).
• Cross-chain atomic swaps between EVM tokens and dregg notes.

Contract Addresses (Base Sepolia)

DreggBridge:       0x... (deployed via Foundry)
SP1VerifierGateway: 0x... (Succinct's deployed verifier)
VKRegistry:        0x... (governance-managed VK updates)

Mina Bridge

Architecture

Mina natively supports Pickles recursive proofs over the Pasta curve cycle (Pallas/Vesta). dregg's Kimchi backend produces proofs over these same curves, enabling zero-cost verification on Mina.

1. STARK generation (dregg): BabyBear/FRI proof of the state transition (~24 KiB).
2. Kimchi wrapping (dregg): Verify the STARK inside a Kimchi circuit (~30K gates).
3. Pickles recursion (dregg): Accumulate into a constant-size Pickles proof (~10 KiB).
4. Mina verification (Mina): Pickles proof is natively verifiable by Mina validators and zkApps.

Using the Mina Bridge

# Generate a Kimchi proof of your state transition
dregg proof generate --backend kimchi --turn $TURN_HASH

# Wrap in Pickles for Mina
dregg proof wrap-pickles --input $KIMCHI_PROOF --output mina-proof.bin

# The mina-proof.bin can be submitted to any Mina zkApp that
# includes a Dragon's Egg verifier contract

# Verify a Mina proof locally (for testing)
dregg proof verify --input mina-proof.bin --backend pickles

What You Can Do

• zkApp verification: Mina smart contracts can verify dregg state transitions natively.
• Cross-chain credentials: Prove you hold a dregg capability to a Mina zkApp (without revealing the capability).
• State anchoring: Anchor dregg federation roots on Mina for trustless freshness verification.
• Recursive accumulation: Chain multiple dregg proofs into a single Pickles proof for batch verification.

Timeline

Assisted recursion is operational (STARK-in-Pickles pipeline works). Full production deployment requires approximately 8 weeks of Kimchi gate optimization and Mina zkApp contract development.

Midnight/Cardano Bridge

Architecture (Level 1.5: Optimistic + Dispute)

The Midnight bridge operates optimistically: state transitions are accepted with a bond and a dispute window. During the window, any party can challenge by requesting a full STARK proof.

How It Works

1. Submit transition: Post a dregg state transition to Midnight with a bond.
2. Dispute window: 24 hours (configurable). Anyone can challenge.
3. If challenged: Submitter must produce a full STARK proof within the response window.
4. If unchallenged: Transition is accepted; bond is returned.

Level 1 (Attestation -- Operational Now)

dregg state roots are attested on Midnight as observation-based data, following the same pattern as Midnight's Cardano bridge. This provides:

• Proof that a dregg state existed at a given height.
• Freshness anchoring for offline verification.
• No proof verification required (observation only).

Level 2 (Future: Native ZKIR Verification)

The DSL's ZKIR v3 backend compiles dregg constraint programs directly into Midnight-compatible contracts. This will enable Midnight validators to verify dregg proofs natively -- eliminating the dispute window entirely. Awaiting ZKIR v3 stabilization.

Using the Midnight Bridge

# Attest a state root on Midnight (Level 1)
dregg bridge midnight attest --root $FEDERATION_ROOT

# Submit with optimistic acceptance (Level 1.5)
dregg bridge midnight submit --turn $TURN_HASH --bond 50000

# Check dispute status
dregg bridge midnight status --submission $SUBMISSION_ID

# Respond to a challenge (produces full STARK proof)
dregg bridge midnight respond --challenge $CHALLENGE_ID

Choosing a Bridge

SDK Bridge Operations

use dregg_sdk::AgentCipherclerk;
use dregg_chain::{EvmBridge, MinaBridge};

let cclerk = AgentCipherclerk::new();

// EVM: wrap and submit
let stark_proof = cclerk.generate_proof(turn, Backend::Plonky3)?;
let groth16 = EvmBridge::wrap_sp1(&stark_proof)?;
let tx_hash = EvmBridge::submit_to_base_sepolia(&groth16).await?;

// Mina: wrap in Pickles
let kimchi_proof = cclerk.generate_proof(turn, Backend::Kimchi)?;
let pickles_proof = MinaBridge::wrap_pickles(&kimchi_proof)?;
// Submit to Mina zkApp...

Next Steps

• Operating a Bridge Node -- Cross-federation relay setup
• Storage -- State availability for bridge operations
• Cryptography -- Proof system details