zkUSD Feasibility Study: Paving the Way for a Private Stablecoin on Mina Protocol
Proposal Overview
The zkUSD project aims to explore the feasibility of developing a private, algorithmic stablecoin on the Mina Protocol. By drawing inspiration from MakerDAO’s DAI and utilizing Mina’s zero-knowledge proofs, zkUSD intends to offer a stable, private medium of exchange within the Mina ecosystem. This initial research grant focuses on validating critical assumptions and laying the groundwork for the full development of zkUSD.
Problem
The Mina ecosystem currently lacks a native stablecoin, which is essential for DeFi applications such as lending platforms, DEXs, and synthetic assets. The absence of a stable, private medium of exchange hampers innovation and adoption, putting Mina at a competitive disadvantage compared to other blockchain networks that offer comprehensive DeFi solutions.
Solution
This research grant proposes a focused feasibility study over 1.5 months to validate key assumptions critical to developing zkUSD:
Minting/Burning Logic Management: Investigate the ability to manage the supply of zkUSD through Collateralized Debt Positions (CDPs) via an orchestrator contract based on user actions.
Computational Feasibility: Assess whether all necessary calculations and assertions (e.g., health factors, liquidation conditions) can be performed within o1js smart contract constraints to provide a full end-to-end stablecoin solution.
Optimal Architecture Analysis: Determine the best architecture for building zkUSD (L1 zkApp vs. L2 App-Chain), including trade-offs related to scalability, security, and decentralization.
Staking Mechanism Exploration: Research the feasibility of staking locked MINA on behalf of users to provide staking rewards, enhancing the stablecoin’s value proposition.
Proof of Concept Development: Integrate the above components to create a local minimal viable product (MVP) demonstrating the core functionality of zkUSD.
Impact
Validating these assumptions will pave the way for developing zkUSD, filling a critical gap in the Mina ecosystem. A successful feasibility study will:
- Enable the creation of a private, stable medium of exchange.
- Encourage developers to build DeFi applications on Mina.
- Differentiate Mina as a leading privacy-focused blockchain with innovative financial tools.
Audience
- Developers interested in building DeFi applications on Mina.
- Mina Community Members seeking enhanced ecosystem capabilities.
- Stakeholders and Investors evaluating the potential of Mina’s DeFi landscape.
Architecture & Design
Link to diagram: https://hackmd.io/_uploads/BkIDV1P11e.png
Overview
zkUSD will consist of several key components that work together to provide the functionality required for a private, algorithmic stablecoin.
Key Components:
- Proving Layer with zkPrograms
Each type of interaction (creating CDP/ depositing collateral etc.) with zkUSD will have an associated zkProgram governed by application rules that determine whether users can update the state.
When a user performs an action, they generate a proof using the appropriate zkProgram. This proof is then submitted to the zkApp, which updates the state accordingly.
- zkApp for State Management
The zkApp serves as the orchestrator, managing state updates and interacting with the zkUSD token contract.
Based on user actions and proofs submitted, the zkApp will handle the minting and burning of zkUSD tokens, ensuring that supply adjustments are accurately reflected.
- Pricefeed
An accurate price feed is crucial for the functionality of an algorithmic stablecoin like zkUSD. For the purpose of this PoC, the price feed will be centralized. The on-chain state will store the public key of our designated price feed source. We will maintain an API that periodically updates the MINA/USD price and signs this data with our private key.
When users perform actions that require price data—such as minting zkUSD or initiating liquidations—they will supply the latest price data along with the corresponding signature from our price feed. The zkApp will then verify the signature against the stored public key during computation to ensure the price data is authentic and untampered.
This mechanism allows the protocol to securely incorporate external price information while we work towards integrating a decentralized oracle solution in the future.
Creating a Collateralized Debt Position (CDP)
- Initialisation: When a user creates a CDP, they initialise an empty CDP in an off-chain Merkle Tree Map. The root hash of this tree is stored on-chain for verification purposes.
- Ownership Secret: The user provides a secret that is used to track ownership of the CDP within a separate Merkle Tree called the CDP Ownership Tree.
- Public Visibility: Upon creation, an event is fired containing all public data of the CDP. This data is transparent so that other users can track CDP values against current prices to identify undercollateralized positions eligible for liquidation.
Managing a CDP
- User Actions: The CDP owner can interact with their CDP by depositing additional collateral, minting more zkUSD, or redeeming collateral to repay debt.
- Event Emissions: Updated states trigger events that publish the latest CDP data. This ensures the network remains informed about all positions, which is crucial for maintaining system stability through timely liquidations.
Liquidating a CDP
- Liquidation Threshold: If a CDP falls below the collateralization ratio threshold of 150%, it becomes eligible for liquidation.
- Liquidation Process:
Any user can initiate liquidation by providing proof that the CDP is undercollateralized. The liquidator burns an amount of zkUSD equal to the debt of the undercollateralized CDP. In return, the liquidator receives the MINA tokens stored as collateral in the CDP.
The original CDP owner retains the zkUSD they minted but loses their collateralized MINA tokens.
Privacy Features
- Decoupling Ownership: By using ownership secrets and hashing mechanisms, the system decouples the key that created the CDP from its ownership, enhancing privacy.
- Minting: When debt is issued, it can be minted to a hidden public key, meaning that the stablecoin system is essentially private
Research Objectives within Architecture
- Minting/Burning Logic Management: Validate that the zkApp can effectively manage minting and burning of zkUSD through orchestrated actions based on user-submitted proofs.
- Computational Feasibility: Ensure that calculations for health factors, collateral ratios, and liquidation conditions can be performed within Mina’s circuit constraints.
- Optimal Architecture Analysis: Assess whether the current design as an L1 zkApp is optimal or if transitioning to an L2 App-Chain model would offer better scalability or security.
- Staking Mechanism Exploration: Investigate integrating a staking mechanism where locked MINA collateral can be staked to earn rewards, providing additional incentives for users.
Vision:
The successful completion of this feasibility study will lay the foundation for developing zkUSD as a cornerstone of the Mina DeFi ecosystem. By validating critical components, we aim to proceed confidently toward building a full-fledged, private stablecoin.
Budget & milestones
Deliverables
- Report on optimal architecture with recommendations
- Working MVP demonstrating core zkUSD functionality
- Final presentation and detailed report summarising findings
Midpoint Milestones (1 Month)
- Core zkOrchestrator functionality proven - CDP creation/management with minting/burning managed by the zkApp
- Full test coverage of developed functionality
Stretch goals
-
Price Feed Investigation: Research and explore the best approach for implementing a reliable price feed for zkUSD. We will investigate whether there are existing decentralized oracle solutions within the Mina ecosystem that can be integrated into zkUSD, or if we need to develop our own price feed system. This research will also evaluate the trade-offs between these solutions in terms of security, decentralization, and scalability.
-
Data Availability and Synchronization: Explore the data availability and synchronization challenges inherent to maintaining a shared Merkle Tree Map for zkUSD. This stretch goal will involve researching the various options available with our chosen architecture.
Project Timeline
2 Months
Budget Requested
50,000 MINA
Budget Breakdown:
Research and Development (25,000 MINA)
- Minting/Burning Logic Prototyping
- Computational Feasibility Testing
- Architecture Analysis and Documentation
- Staking Mechanism Exploration
Proof of Concept Development (25,000 MINA)
- Integration of Components into MVP
- Full test coverage of application functionality
- Testing and Validation of MVP Functionality
Wallet Address
B62qnfDpwYS9u2uEcgdfcuWRqB5MmPQSeNdrVXMWF6cJXipzcGaMejM
Team Info
Proposer Github:
Charlie Mack
Education:
Self taught programmer, professional history as Scrum Master/Agile coach in large financial institutions
Experience:
Spent the last 3 years building full stack web3 projects including:
Nanobyte - browser wallet / payment processor for Nano
Notifly - AI powered personalised newsfeeds for crypto projects
Omnipus - LayerZero multi-chain defi memecoin project
Relevant Projects:
Chainmail - A ZK Email marketplace
Foundry-Stablecoin - A working implementation of DAI in Solidity
Achievements
ETHDam 2024 (Finalist) - BlockLock - on-chain password manager
ETH Berlin (Runner up) Chainmail - as above
Team Members
Team member:
Fedor Panafidin
Education:
Currently doing a masters degree in computer science (artificial intelligence) @ KU Leuven
Work experience:
- EnergyVille IoT internship (2023)
- Freelancing in web3 since 2022
- Grant from the Oasis Blockchain for BlockchainOfThings project
- Launched/managed/developed memecoins & NFT projects on Ethereum, Base and Pulsechain.
Achievements:
- ETH Brussels 2023 (3rd place)
- 6th CASSINI Hackathon (2nd place)
- ETHDam 2024 (finalist)
- ETH Berlin 04 2024 (Runner up)
- ETH Global Brussels 2024 (won web3auth, worldcoin, filecoin bounties)
- DAGI hackathon
X: @choddor
Telegram: @vysotapolyota
Risks & Mitigations
Circuit Size Limitations
- Risk: Exceeding o1js circuit size limits due to complex calculations.
- Mitigation: Modularize applications, optimise calculations, and utilise recursive proof verifications to manage circuit sizes.
Account Update Constraints
- Risk: Hitting the maximum of 9 account updates per transaction. This can be more of an issue when the orchestrator is managing the token contract.
- Mitigation: To be researched
Ordering of Liquidations and Withdrawals
- Risk: Potential MEV opportunities and transaction ordering issues affecting fairness.
- Mitigation: Plan to research and address during architecture development.
Application Security
- Risk: Vulnerabilities could lead to fund loss or exploitation.
- Mitigation: Implement best security practices and engage in community reviews to identify and fix vulnerabilities.
