Midgard L2: Battleship Game on Cardano - via Commit‑Reveal

[Proposal setup] Proposal title

Please provide your proposal title

Midgard L2: Battleship Game on Cardano - via Commit‑Reveal

[Proposal Summary] Budget Information

Enter the amount of funding you are requesting in ADA

29000

[Proposal Summary] Time

Please specify how many months you expect your project to last

12

[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?

With Midgard L2 arriving, Cardano needs engaging, repeat‑use dApps that exploit its low fees and high throughput—turning capacity into daily active users, on‑chain activity, and ecosystem growth.

[Proposal Summary] Supporting Documentation

Supporting links

• https://en.wikipedia.org/wiki/Battleship_(game)
,
• https://www.raffleize.art
,
• https://cexplorer.io/article/a-high-level-overview-of-midgard

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

Yes

Describe any dependencies or write 'No dependencies'

Midgard L2 availability (preprod/testnet → mainnet). If mainnet lags, we ship a feature-complete testnet release plus an L1 fallback mode for private games.

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

License and Additional Information

License: Apache‑2.0 (contracts, UI, indexer, devops).

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal.

GameFi

[Campaign Category] Category Questions

Describe what makes your idea innovative compared to what has been previously funded (whether by you or others).

• L2‑native from day one: Purpose‑built for Midgard to turn low fees + high throughput into move‑per‑transaction gameplay and scalable tournaments (not a later L2 port).
• Granular, verifiable fairness: Merkle board commitments with per‑cell openings reveal only what’s necessary, proving honesty without leaking the rest of the board.
• On‑chain proof‑of‑win receipts: Shareable links that anyone can verify on chain—driving organic virality and community‑run tournaments.

Describe what your prototype or MVP will demonstrate, and where it can be accessed.

Feasibility of the pattern: Demonstrates that turn‑based games on Cardano can be implemented efficiently using commit‑reveal schemes on EUTxO.

L2 advantages in action: Smooth, low‑fee, fast‑confirm move‑per‑transaction play on Midgard; minimal on‑chain data per move.

Describe realistic measures of success, ideally with on-chain metrics.

Adoption KPIs (first 90 days post‑launch):

• 1,000+ unique wallets open the dApp; 300 complete at least one game.
• ≥3,000 L2 transactions (games, shots, openings).
• Day‑7 retention ≥ 15% for new players;

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

Why Battleship?

It’s globally recognized, easy to learn, and perfect for commit‑reveal: players must place ships in secret, then gradually reveal single cells as hits occur. That makes it a striking demo of verifiable fairness—a uniquely blockchain‑native advantage vs. Web2 games.

Architecture (high level)

• Commit Phase: Each player commits their 10×10 board as a Merkle root of 100 salted cell hashes (ship / water). The root and a deposit are locked into a game UTxO.
• Turn Loop: Players submit shots (coordinates). When a shot “hits,” the defender reveals only that cell (coordinate + salt) proving consistency with the committed root. Sinks require revealing the full ship path, not the entire board.
• Reveal / Settle: When the game ends (all ships sunk or resign), both players reveal remaining necessary cells (or prove sinks) and the contract settles stakes.
• Anti‑griefing: Timeouts and forfeiture rules: if a player doesn’t act within N blocks, the opponent can win by timeout; partial refunds follow clear rules.
• Disputes/fraud‑proofs: Any inconsistent reveal against the committed root fails on‑chain; repeated invalid reveals are slashed.
• Data footprint: Only minimal data is published per move (coordinate, hit/miss, optional opening), keeping fees tiny on L2 and acceptable on L1 fallback.

Midgard L2 Integration

• Why Midgard: Optimistic rollup style L2 for Cardano offering low fees, fast “pre‑confirmations,” and L1 security. Ideal for move‑per‑tx games and tournaments.
• Deployment: We will deliver a Midgard‑native contract package and front‑end that connects to Midgard nodes; tournament mode and leaderboards will highlight low‑fee play.

[Your Project and Solution] Impact

Please define the positive impact your project will have on the wider Cardano community

Why this matters to Cardano

• Onboards new users with a recognizable game and smooth, low‑fee UX.
• Proves cryptographic fairness (commit‑reveal) to the mainstream in an accessible format.
• Drives transactions on Cardano through L2 gameplay and L1 settlement.
• Leaves reusable code other builders can adopt for chess, connect‑four, word games, sealed‑bid auctions, quizzing dApps, and more.

[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?

Track Record: Live, proven commit‑reveal scheme (CRS) game prototype already deployed on Cardano Preview: https://raffleize.art/ .Learnings from this prototype directly inform the Battleship implementation and reduce delivery risk.

[Milestones] Project Milestones

Milestone Title

Architecture and Design (Month 1–3)

Milestone Outputs

1. Protocol Specifications: Merkle commitment format, timeout rules
2. DApp Design - UML diagrams: Visuals depicting the DApp’s functional behaviour and structure.
   1. Component Diagrams: Highlighting the organization and dependencies among components. This include smart contracts, web frontends, backend servers, external APIs, etc.
   2. Use Case Diagrams: These help in identifying the different actors (users, other systems, or DApps) and their interactions with the DApp.
   3. State Machine Diagrams: Very relevant for smart contracts to depict the different states a contract can be in (e.g., open, closed, funded) and the transitions between these states, triggered by transactions or events.
   4. Class Diagrams: Useful for representing the structure of the datums of smart contracts.
   5. Sequence Diagrams: These can depict the interactions over time between users, the DApp, external systems, and the underlying blockchain. This might show the sequence of calls to a smart contract function, how events are emitted, or how off-chain components interact with the blockchain.

Acceptance Criteria

The Functional Specification must encompass all potential DApp user interactions and all potential actors interacting with the DApp.

The Battleship Game should be described with UML diagrams depicting the it's structure and dynamics.

Evidence of Completion

A repository link showcasing the smart contracts.

Test logs or reports illustrating the success of all tests.

Delivery Month

3

Cost

10000

Progress

30 %

Milestone Title

Core Implementation

Milestone Outputs

Smart Contracts (Validators and Minting Policies): Customized contracts facilitating the game

On-Chain Logic Test Suites: A combination of unit tests and property-based tests testing the code used in the validators and minting policies.

Acceptance Criteria

Smart contracts must be deployable and functional on the Cardano testnet.

Unit and property-based tests must execute without errors.

Documentation should be detailed, covering all facets of the smart contracts.

Smart contracts deployment - description of the deployment transactions and automated deployment scripts.

Test results for each transaction including transaction fee and resources (memory, cpu and size).

Evidence of Completion

A public github repository link showcasing

• the implemented smart contracts (validators and minting policies).
• the onchain documentation
• the updated UML diagrams
• Test logs or reports illustrating the success of all tests.

Delivery Month

6

Cost

11000

Progress

80 %

Milestone Title

Website, E2E Integration and Project Closeout

Milestone Outputs

Implementation of Battleship Website ;

Deployed contracts to Midgard preprod/testnet;

Off-Chain implementation for Transaction Building for both L1 and L2;

E2E Integration of the front-end with backend;

Final close-out report;

Final closeout video;

Acceptance Criteria

The website must be deployed and live in Midgard Testnet.

The Battleship Game should be playable on testnet.

The final closeout report should be publicly available

The final closeout video should be publicly available

Evidence of Completion

Github public repository containing all the code and the updated documentation;

Link to final closeout report;

Link to final closeout video;

Delivery Month

12

Cost

8000

Progress

100 %

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

This budget reflects only the development costs required to implement this project. All other costs for operation will be supported by me.

• Architecture and Design - ₳10,000
• Core Implementation - ₳11,000
• Website and E2E Integration - ₳8,000

[Final Pitch] Value for Money

How does the cost of the project represent value for the Cardano ecosystem?

For the cost of a small community event, you get a playable, open‑source game on Midgard L2 that others can copy and extend.

Why this is great value for the ecosystem

• Onboards newcomers with a familiar game that’s cheap to play—perfect for meetups and social sharing.
• Kick‑starts Midgard usage: many low‑fee moves = lots of on‑chain activity and data.
• Lower delivery risk: we already shipped a live CRS prototype on Cardano Preview (raffleize.art).

[Required Acknowledgements] Consent & Confirmation

Terms and Conditions:

Yes