Website | Telegram | Documentation

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 01 - E2E flow without data verification

Tasks:

• extension mockup
• client mockup
• extension UI
• client swap page UI
• client wallet mgmt UI
• client registation page UI
• relevant data detection from extension
• extension/client connection
• onchain registration
• onchain escrow

Milestone 02 - Offchain notarization and SNARK generation

Tasks:

• Notary mgmt UI in extension
• 2PC-TLS with notary mgmt
• Prover commitment generation
• generation of the verification zk-SNARK

Milestone 03 - Onchain verification

Tasks:

• zk-SNARK (groth16) verification with Garaga
• escrow assertions based on previous verification

Milestone 04 - Liquidity mgmt improved

Tasks:

• Liquidity lock/unlock implementation to avoid onramp collusions
• Allow better granularity
• Liquidity mgmt UI in client
• Onchain Liquidity mgmt implementation

Milestone 05 - Notaries decentralisation

DVM could be an interesting solution to achieve this goal

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 💻	Uğur Eren 💻	Lindsay Morales 💻	Charlotte 💻	Abdulhakeem Abdulazeez Ayodeji 💻	Luiz Vasconcelos Júnior 💻	lanaivina 💻
Bryan 💻
Add your contributions

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