Skip to content

Latest commit

 

History

History
150 lines (120 loc) · 11.3 KB

README.md

File metadata and controls

150 lines (120 loc) · 11.3 KB

zkRamp

A trustless P2P fiat onramp powered by ZK proofs on Starknet 🎟️

The concept was initially conceived and developed by ZKP2P for EVM chains, and zkRamp is making it accessible on Starknet by implementing it in Cairo.

Roadmap

Milestone 1 - Liquidity mgmt

Implements onchain logic to manage liquidity and allow ramping.

Tasks:

  • Offchain account registration
  • Defining the architecture
  • Liquidity addition
  • Liquidity retrieval
  • Liquidity withdrawal
  • Full unit test coverage
  • Full integration test coverage

Milestone 2 - Backend

Index onchain events and build API to find the best quotes when a user ask to onramp.

Tasks:

  • Defining database architecture
  • Infra setup
  • Liquidity indexing
  • Registration indexing
  • Quote computation
  • Registration API
  • full test coverage

Milestone 3 - Frontend

Design and build frontend without plugging it to the backend.

Tasks:

  • Layout (mockup)
  • Layout
  • Buying flow (mockup)
  • Buying flow
  • Selling flow (mockup)
  • Selling flow
  • Registration flow (mockup)
  • Registration flow
  • Proof generation flow (mockup)
  • Proof generation flow

Milestone 4 - TLS Proxy

Implements TLS Proxy to generate proofs from an “attestor”, gather them in the frontend and verify them onchain.

Tasks: TBD

Flowchart 🎡

Contracts

For each platform (e.g. Venmo, Revolut, etc.) a smart contract called a "Ramp" is deployed.

Each Ramp is divided into 2 main parts.

  • Account manager responsible for the mapping between Starknet accounts and the user ID of the supported platform.
  • Funds manager which serves as an escrow for offrampers and sends funds to onrampers.

These parts each use a processor, a component responsible for verifying ZK-SNARKs generated by the notary.

The account manager's processor is responsible for verifying that a Starknet account requesting to be linked to a Revolut user ID, for example, provides a validated ZK-SNARK signed by the notary attesting to its ownership of the Revolut account.

As for the funds manager's processor, it verifies that an onramper has actually transferred the fiat funds to an offramper before releasing the equivalent in tokens to them.

Next steps 🔎

In the flowchart above, the notary is a centralized entity running on a server. Therefore, it can generate false attestations and thus steal the money deposited in the contracts. The next major step will therefore be to decentralize the notarization process.

Contributors ✨

Thanks goes to these wonderful people. Follow the contributors guide if you'd like to take part.

Chqrles
Chqrles

💻
Uğur Eren
Uğur Eren

💻
Lindsay Morales
Lindsay Morales

💻
Charlotte
Charlotte

💻
Abdulhakeem Abdulazeez Ayodeji
Abdulhakeem Abdulazeez Ayodeji

💻
Luiz Vasconcelos Júnior
Luiz Vasconcelos Júnior

💻
lanaivina
lanaivina

💻
Bryan
Bryan

💻
Yusuf Habib
Yusuf Habib

💻
Mubarak Muhammad Aminu
Mubarak Muhammad Aminu

💻
Gerson
Gerson

💻
BlackStarkGoku
BlackStarkGoku

💻
Ikem
Ikem

💻
Jemiiah
Jemiiah

💻
Add your contributions

This project follows the all-contributors specification. Contributions of any kind welcome!