[Proposal setup] Proposal title
Please provide your proposal title
Anvil - Scale the Chain: Universal Merkle Bridge POC for L2s
[Proposal Summary] Budget Information
Enter the amount of funding you are requesting in ADA
95000
[Proposal Summary] Time
Please specify how many months you expect your project to last
6
[Proposal Summary] Translation Information
Please indicate if your proposal has been auto-translated
No
Original Language
en
[Proposal Summary] Problem Statement
What is the problem you want to solve?
Cardano eUTxO limits complex state throughput; no standard to anchor off‑chain compute to L1, forcing fragile, duplicated bridges. Teams need a reusable, audited state‑commitment + settlement pattern.
[Proposal Summary] Supporting Documentation
Supporting links
[Proposal Summary] Project Dependencies
Does your project have any dependencies on other organizations, technical or otherwise?
No
Describe any dependencies or write 'No dependencies'
No dependenies
[Proposal Summary] Project Open Source
Will your project's outputs be fully open source?
Yes
License and Additional Information
Open source (Apache-2.0)
[Theme Selection] Theme
Please choose the most relevant theme and tag related to the outcomes of your proposal
Developer Tools
[Campaign Category] Category Questions
Mention your open source license and describe your open source license rationale.
License: Open source (Apache-2.0)
Anvil has selected the Apache-2.0 license for its open-source protocol to maximize adoption and long-term sustainability. Apache-2.0 is a permissive license that allows developers and enterprises to freely use, modify, and integrate the protocol. It provides explicit patent protection and contributor safeguards, reducing legal risks. Lower barrier to adoption while ensuring legal clarity, Apache-2.0 creates the optimal balance between openness and enterprise readiness, helping Anvil’s protocol scale as a foundational standard within the Cardano ecosystem.
How do you make sure your source code is accessible to the public from project start, and people are informed?
Github and Social Media
We plan on building in the open, on Github, from Milestone 1 of the proposal. A repository will be created as part of our initial milestones, and we will start to socialize that through Catalyst and our official Social Media accounts.
How will you provide high quality documentation?
Anvil has references cleary illustrating the quality of our documentation and the lengths we go to to provide examples that developers from all skill levels can navigate and understand.
Our first open sourced project Weld is commonly cited as being easy to use and well documented. https://github.com/Cardano-Forge/weld
We have several positive messages about ease of use of our documentation for our Anvil API https://dev.ada-anvil.io/
[Your Project and Solution] Solution
Please describe your proposed solution and how it addresses the problem
Solution Overview
We propose a generic bridge pattern:
- Off-chain execution aggregates many user intents into state transitions.
- On each update, a new Merkle root is committed to Cardano L1 by spending the Merkle Tree NFT and re-creating the state UTxO with an updated datum.
- Users deposit and withdraw ADA/native tokens via on-chain contracts using Merkle proofs and signed statements.
- A reference demo (L2 batch swap) showcases high-throughput execution with L1 settlement.
Scope & Non-Goals
- Scope: A self-hosted developer playground with open-source validators (Treasury + Merkle Tree), aggregator, SDK/CLI, and docs. Teams deploy their own instances and manage their own keys.
- Non-Goals: Operating a managed SaaS bridge, custodying user funds beyond demo/testnet scenarios, shipping production token economics or governance.
Technical Approach
- On-chain (Plutus V3):
- Merkle Tree validator controls a single-state NFT; spending it produces the next UTxO with an updated root in the datum (one root per transaction).
- Treasury validator holds deposits and processes withdrawals using Merkle proofs against the latest root.
- Treasury requires a reference input to the current Merkle Tree NFT UTxO to read the latest root during withdrawals and validate signatures.
- Datum/UTxO layout optimized for compact state, low fees, and auditability.
- Off-chain aggregator:
- Consumes user intents, executes transitions, builds Merkle trees, and signs state assertions.
- Produces proofs for deposits/withdrawals and prepares root-update transactions that spend the Merkle Tree NFT.
- Reference implementation for local/testnet use (self-hosted, not SaaS) with documentation to deploy your own.
- Integrates wallet signData (CIP-8) or aggregator-key signatures as configured.
- SDK/CLI:
- Create/verify Merkle trees and proofs; generate/verify signed statements.
- Deploy validators, mint the Merkle Tree NFT, and construct root-update, deposit, and withdrawal transactions.
- Dev-friendly local/testnet scripts and reproducible demos.
- Demo dApp (L2 batch swap):
- Simulates high-frequency swaps off-chain.
- Commits a new root on each update (NFT spend); publishes metrics and dashboards.
- Security & assumptions:
- Honest-majority or committee model for the aggregator (configurable).
- No epoch gating; each new root is committed by spending the Merkle Tree NFT. Anti-reorg and liveness assumptions documented.
- Compact proofs, bounded sizes, and replay protection.
- Clear fraud/economic assumptions documented; optional multi-sig/committee path.
Terminology & Data Model
- Merkle Tree State UTxO: Unique NFT anchors the state; datum includes root, version, timestamp (optional), and policy parameters.
- Treasury UTxO: Holds user funds; validator checks Merkle proofs against the latest root via reference input to the State UTxO.
- Proofs: Inclusion proofs (leaf → root) for withdrawals; deposit intents recorded in aggregator state and reflected in next root.
- Keys & Signatures: Aggregator signs state assertions; optionally uses wallet signData (CIP‑8) for user intents when appropriate.
- Out of scope: Zero-knowledge proofs, fraud proofs, or economic games beyond documented assumptions (POC scope).
How this differs from Hydra
Hydra is an isomorphic state-channel/head protocol for low-latency, multi-party off-chain transactions; this POC is a rollup-like Merkle-bridge pattern with proof-based exits and a configurable aggregator.
- Architectural model: This POC provides a rollup-style bridge with an off-chain aggregator that commits Merkle roots to L1. Hydra creates a temporary off-chain ledger (a "Head") for a fixed set of participants.
- State anchoring: We update L1 by spending the Merkle Tree NFT and recreating the state UTxO with a new root per update. Hydra Heads run an off-chain mini-ledger and only touch L1 on open/close and during disputes in the contestation period.
- Exit path: Users can unilaterally withdraw using a Merkle proof against the latest root on L1. Hydra exits depend on head closure and participant interaction during the contestation period.
- Trust/coordination: Configurable aggregator or committee signs state assertions; not a peer-to-peer channel among all users as in Hydra.
- Composability: Our L1 validators are always on-chain and globally composable; Hydra funds are isolated in a Head UTxO until the head closes.
- Deployment focus: Self-hosted, per-dApp playground enabling one-to-many user interactions; Hydra is best for small groups needing sub-second coordination.
- Non-goal: We are not operating a managed Hydra head; we provide proof-based bridging and settlement primitives.
See Hydra docs: https://docs.cardano.org/developer-resources/scalability-solutions/hydra
[Your Project and Solution] Impact
Please define the positive impact your project will have on the wider Cardano community
This proposal brings more necessary development tooling to the Cardano community in the form of open-source L2 bridges. We do not have the patience to wait any longer - we need this tooling to offer enterprise solutions near instant finality options, through the plethora of Layer 2 protocols building on Cardano. This is a tool for all, that we want to build for the community.
Ecosystem Alignment & Interoperability
- Aligns with CIP‑30 for UI wallet compatibility and CIP‑8 signData where applicable.
- Works with common indexers (Blockfrost; optional Koios) and CSL-based tooling.
- Complements Hydra (not a head): always-on L1 validators with proof-based exits; see “How this differs from Hydra.”
Ecosystem Value Alignment
- Establishes a reusable pattern for rollup-like architectures on Cardano.
- Reduces duplicated effort and risk for teams needing throughput and better UX.
- Accelerates developer experimentation while preserving L1 settlement guarantees.
[Your Project and Solution] Capabilities & Feasibility
What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?
Year after year, we increase our visibility, and notareiety, in the Cardano develoment space. At Anvil, we have set out to be trailblazers, and diminish the gap between web2 and web3. We create our solutions with every developer in mind and we pride ourselves in the work we do under these community grants. We know our approach is feasible because we have internal consensus as a team.
We believe that this work doesn't just impact Anvil and what weant, but rather the entire Cardano Community, it's truly a tool for all.
Additionally:
- Serviced over 300 projects in the Cardano space.
- Minted over a million native assets.
- 1 successfully completed open source project
- 4 years of service
- Infastructure
- dApps
- Cusom Contracts
- API
We work on a little bit of everything and learn the ins and outs so you don't have to. We want to build on behalf of the Community. We know we can.
[Milestones] Project Milestones
Milestone Title
Spec, Threat model, Contract scaffolding, Repo creation, and Test harness.
Milestone Outputs
During this milestone we will begin the development of the merkle bridge, starting with the following items:
- Public Spec and threat model
- Initial Plutus Contract scaffolding
- Github Repository
- CI Test harness
Acceptance Criteria
- CI Test harness completed and capable of completing tests
- Initial Plutus Contract scaffholding completed
- Deterministic script hashes from reproducible build documented
- Github Repository Created
Evidence of Completion
- Link to Video Recording of CI tests completed
- Link to build Documentation
- Link to Github Repository
Delivery Month
1
Cost
30000
Progress
30 %
Milestone Title
Deposit/withdraw flows and proof verification; signData integration.
Milestone Outputs
For Milestone 2 we will be preparing the contracts and proofs
- Contracts with deposit/withdraw
- Merkle proof verification
- CIP-8 signData path
- NFT-chaine root updates (spend and recreate state UTXO with new root)
Acceptance Criteria
- Passing tests for end-to-end deposit→proof→withdraw in harness, including reference-input read of current root and successful root-update transactions
- Negative tests (invalid proof, stale root, replay) fail as expected
- Preliminary execution-cost profiles captured.
Evidence of Completion
- Link to Video of passing tests that show deposit actions; as well as, preliminary execution-cost profiles being captured
- Link to Documents/Evidence of Negative Tests
Delivery Month
3
Cost
30000
Progress
60 %
Milestone Title
Aggregator prototype + SDK/CLI; end-to-end local demo.
Milestone Outputs
In this milestone we will complete the following outputs towards our merkle bridge:
- Deliver aggregator
- Deliver SDK/CLI
- Completed Local demo wiring everything together
- Updated GitHub Repository
Acceptance Criteria
- Demo runs locally, producing roots/proofs and exercising contracts
- CLI supports deterministic builds and verification commands
- Execution budgets documented under mainnet limits for typical flows.
- GitHub repository has been updated to reflect current progress
Evidence of Completion
- Link to Video Evidence of the demonstration showing roots/proofs and CLI commands functioning
- Link to Execution budget documentation
- Link to Updated GitHub Repository
Delivery Month
4
Cost
15000
Progress
70 %
Milestone Title
Delivery and Close Out Video
Milestone Outputs
As part of our final milestone, we will be doing final testing, documentation, and walkthroughs:
- Testnet contracts
- Mainnet Deployment
- Public Demonstration/Tutorials
- Completed Documentation
- Final GitHub Repository Update
In addition we will be producing:
Acceptance Criteria
- Testnet contracts completed and deployed
- Contracts successfuly tested and deploted on mainnet
- Documentation fully completed
- GitHub Updated
- Public Demo/Tutorial video showing completion and how product works
- Will be posted in GitHub and on X
- Completed Close out Report/Video
Evidence of Completion
- Link to Testnet contracts/video showing completion
- Link to Mainnet contracts/video showing completion
- Link to updated Documentation
- Link to updated GitHub
- Link to Demo Video as well as X post
- Link to Completed Close out Report/Video
Delivery Month
6
Cost
25000
Progress
100 %
[Final Pitch] Budget & Costs
Please provide a cost breakdown of the proposed work and resources
Core Development (75,000 ADA)
- Plutus contracts, reviews, and QA: 41,000 ADA
- Merkle Tree and Treasury validator development (25,000 ADA)
- Security reviews and audit preparation (10,000 ADA)
- Comprehensive testing and QA (6,000 ADA)
- Aggregator + SDK/CLI: 34,000 ADA
- Off-chain aggregator implementation (20,000 ADA)
- SDK/CLI tooling and developer experience (14,000 ADA)
Ecosystem & Community (20,000 ADA)
- Demo, documentation, testnet ops, and community support: 20,000 ADA
- L2 batch swap demo development (8,000 ADA)
- Comprehensive documentation and tutorials (6,000 ADA)
- Testnet deployment and operations (3,000 ADA)
- Community support and developer onboarding (3,000 ADA)
[Final Pitch] Value for Money
How does the cost of the project represent value for the Cardano ecosystem?
This proposal provides a plethora of different value propositions for the Cardano ecosystem. Not only are we solving a looming problem, we also do it at a fair market value. This proposal is lean and efficient, and we plan on keeping it that way.
Additionally, this proposal delivers open-source infrastructure that addresses one of Cardano’s biggest challenges: scaling throughput and improving UX without compromising L1 security. By building a generic, trust-minimized Merkle bridge, it establishes a reusable foundation for rollup-like architectures that any team can adopt. Instead of each project reinventing fragile bridges, developers gain audited contracts, an SDK/CLI, and a demo dApp to accelerate experimentation.
The solution complements Hydra by filling a different niche: Always-on, proof-based settlement with unilateral exits that broaden Cardano’s scalability toolkit. With permissive licensing (Apache-2.0), clear docs, and testnet demos - this project lowers barriers of development and reduces ecosystem fragmentation. The result will be a standard pattern that strengthens Cardano’s competitiveness across DeFi, gaming, and payments systems.
A product that everyone will need, and everyone will have.
[Required Acknowledgements] Consent & Confirmation
Terms and Conditions:
Yes