StealthTradeDAO

The cumulative trading volume of perpetual contracts since 2020 has surpassed $60 trillion, which is much higher than the trading volume of the underlying cryptocurrencies and conventional futures contracts Read More. For A primer on how perpetual contracts work and what is option trading please look into this

The Problems Open Order Books: Challenges in Perpetual Markets Perpetual markets with open order books provide transparency, but they also come with significant challenges:

Front Running: Traders can exploit the visibility of pending orders, executing trades before others, taking advantage of transaction ordering.

Copy Trading Exploitation: Similarly, the visibility of trades allows competitors to duplicate strategies and profit unfairly.

Lack of Privacy: Open order books expose traders’ strategies and positions, allowing market analysis to be exploited by competitors.

Market Manipulation: Open order books can be gamed by actors who use this transparency to manipulate markets and liquidity.

Private Order Books: A Double-Edged Sword Private order books come with their own set of problems:

Trust Deficit: Users cannot verify the platform’s financial solvency, leading to doubts about whether enough assets back the open positions.

Hidden Liquidity: With no visibility into the market depth, traders face uncertainty about whether their orders will be executed, or at what price.

Manipulation Risk: The platform or privileged users can manipulate the market without detection, undermining the integrity of the system.

User Trust: Lack of transparency can cause users to question the platform’s stability, especially during volatile periods, driving away both new and existing users.

How we solve the Problem We address these issues by adopting a private order book system enhanced with access proofs and proof of solvency to foster user trust. While part of the market data remains public to prevent a “gambling-like” environment, the core of the system ensures that transparency and trust are maintained in a decentralized manner.

Our approach is powered by a Chain Abstracted DAO, enabling users to propose and vote on changes to the perpetual contracts and platform structure. This cross-chain voting architecture ensures that all stakeholders have a say in the platform's evolution, adding further trust and transparency to the ecosystem.

It is made with help of mina's protokit for the core peprpetaul contracts logic. The circuits like proof of solvency were written in a truly scalable way with help of recursive zk snarks

Chain Signatures-Based Cross-Chain Voting Architecture

high Level Architecture This architecture is designed to support a cross-chain flow where transactions are signed on Bitcoin, NEAR, and Ethereum using Chain Signatures. It allows seamless interaction between these networks for decentralized voting within a DAO that exists primarily on Ethereum. The architecture aims to offer secure and efficient transaction management for a multi-chain DAO by integrating BTC -> NEAR -> EVM flow.

How the DAO works Key Components: MPC Contract:

Contract Address: v1.signer-dev.testnet

Purpose: Used to sign both NEAR and Ethereum transactions.

Main Contract (lib.rs):

This contract handles the promises and logic for cross-chain transactions.

It calls the MPC contract to sign NEAR and Ethereum transactions.

NEAR Transaction:

A simple token transfer on the NEAR blockchain, initiated after a BTC transaction is signed.

Ethereum Transaction:

A voting transaction for a DAO on Ethereum, signed and broadcasted using the MPC contract.

DAO on Ethereum:

Main contract for the DAO resides on Ethereum. It tracks votes, stablecoins, and each member's account, including a token that represents the identity of the member. The Ethereum transaction settles here after NEAR and Bitcoin interactions.

Architecture Flow BTC -> NEAR Transaction:

A Bitcoin transaction is signed using Chain Signatures.

The flow triggers a NEAR transaction via the MPC contract, which uses the FunctionCall parameter to sign the NEAR transaction (e.g., token transfer).

The NEAR transaction is signed and one promise is returned for the signed NEAR transaction.

NEAR -> Ethereum Transaction:

After the NEAR transaction is signed, the same flow continues to trigger an Ethereum transaction.

The Ethereum transaction payload (raw-coded for now) is derived and passed to the MPC contract for signing.

The second promise is returned for the signed Ethereum transaction.

Broadcast:

Both signed NEAR and Ethereum transactions are broadcasted to their respective networks.

Once the Ethereum transaction is completed, it triggers voting in the DAO on Ethereum, where the member's identity and vote are recorded.

Limitations Serialization Issues:

While calling the MPC contract directly for FunctionCall transactions, Borsh serialization faces inconsistencies, especially with incorrect argument types. Spelling discrepancies for parameters (like FunctionCall) have caused issues during the serialization process.

Direct Function Calls:

Direct calls to the MPC contract’s sign function often fail due to type mismatches in the arguments (e.g., number not being recognized correctly).

Raw-Coding of Ethereum Payload:

The Ethereum transaction payload is currently hardcoded. This could lead to inflexibility and might require frequent updates when Ethereum transaction formats change.

Keyversion and Path Derivation:

The derivation of Keyversion and path has been complex, and ensuring consistent behavior across NEAR and Ethereum has been challenging.

Dual Promise Handling:

Managing two promises (one for NEAR and one for Ethereum) requires a robust handling mechanism to ensure that transactions are broadcasted correctly, even if one fails or is delayed.