Skip to content

Latest commit

 

History

History
198 lines (125 loc) · 12.5 KB

README.md

File metadata and controls

198 lines (125 loc) · 12.5 KB
title description author discussions-to status type created category requires
Non-Custody Cross-Chain Protocol (Non-CCCP)
A trustless cross-chain protocol using auction-based resolvers for competitive pricing and extensible to new blockchains without central authority.
Anton Bukov (@k06a), Slavik Baranov (@SlavikBaranov)
TBD
Draft
Standards Track
2024-09-10
ERC
SLIP-0044

Abstract

This standard defines a secure and modular solution for cross-chain asset exchange without intermediaries, enabling permissionless integration with new networks. The security of the solution is ensured through atomic swaps (Tier Nolan, "Alt chains and atomic transfers", Bitcoin Forum, May 2013), which guarantee atomicity—either both parties successfully exchange assets, or the entire swap is canceled—allowing users to retain full control over their assets throughout the process. The solution is designed to be modular, allowing for the permissionless addition of support for new blockchains.

Motivation

Current cross-chain solutions often rely on custodial models, such as Proof-of-Authority (PoA) or Proof-of-Stake (PoS), which introduce centralization and trust concerns. This standard proposes a self-custodial approach to cross-chain asset exchange, removing the need for trusted intermediaries. The modular design of the solution also allows for seamless integration with new blockchains, empowering independent developers to extend the protocol without needing permission, thus fostering broader decentralization.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Entities definition:

  1. Trader - the party initiating the cross-chain asset exchange.
  2. Resolver - the party accepting the cross-chain asset exchange.
  3. Operator - the party that facilitates the use of protocol by providing neccesssary on-chain and off-chain services to both traders and resolvers.
  4. Source chain - The blockchain where the trader's assets are initially located and locked during the exchange process before being unlocked for the resolver.
  5. Destination chain - The blockchain where the resolver's assets are initially located and locked during the exchange process before being unlocked for the trader.
  6. Trade - the process of exchange of Trader's funds on the Source chain to Resolver's funds on the Destination chain.
  7. Order - an offchain structure with a digital signature, confirming Trader's intent to exchange source asset to destination asset that includes dutch auction setup.
  8. HLTC (escrow) - Hashed Timelock Contract, a smart contract that locks assets until a specific condition is met.
  9. Intent Protocol - a protocol that relies on Order and Trader's signature to lock it's assets in a HLTC.

Phases of protocol

Creation of an off-chain order

All parameters of the trade are defined in an off-chain order data structure to let the operator define specific constrains of the trade.

Order data structure should contain:

  1. Source token address
  2. Destination token address
  3. Source chain id
  4. Destination chain id
  5. Trader address on destination chain
  6. Source token amount
  7. Destination token amount (decreasing by dutch auction)
  8. Hash of one or multiple secrets generated by the trader

TODO: Serialization of order structure

The order undergoes serialization and hashing, with the trader providing a digital signature to authorize the Limit Order Protocol. This process also ensures that the trader’s funds are securely escrowed upon order fulfillment.

Pre-auction

By implementing a pre-auction phase coupled with an off-chain prioritization of resolvers, the protocol effectively mitigates gas wars, turning competitive pressure into trader profits.

Dutch auction

This phase maximizes the benefits of resolver competition, channeling them directly into traders’ profits. The support for partial fills also enables even idle liquidity in market makers’ wallets to be effectively utilized.

Escrowing trader's funds

TODO: Don't forget about finality (source chain reorg protection)

Escrowing resolver's funds

TODO: Don't forget about finality (destination chain reorg protection)

Any Order-based restrictions Intent protocol SHOULD provide order-based traits like fees or resolver set restriction or any other.

Order data should include following fields:

  1. Trader wallet address
  2. List of allowed resolvers

Data representation agreements:

  1. Implementation MUST use SLIP-0044 for "ChainID" specification

Process agreements:

  1. Protocol RECOMMENDED to use intent- and resolver-driven settlement protocol to deliver user funds in HLTC, subject for availability.

Process:

  1. Trader assets are being locked in HLTC escrow in source blockchain with SECRET and TIMELOCK_A params
  2. Resolver assets are being locked in HLTC escrow in destination blockchain with same SECRET and TIMELOCK_B params

Rationale

Trustless

Atomic swaps are a fundamental component of the protocol, providing a mechanism for asset exchange that eliminates the need for trust between parties. The key benefits of atomic swaps include:

  • Security: Atomic swaps ensure that either both parties successfully exchange assets or the entire swap is canceled. This guarantees that no party can lose their assets without receiving the agreed-upon assets in return, thus removing the need to trust the counterparty.
  • Decentralization: By eliminating the need for intermediaries, atomic swaps maintain the decentralized nature of blockchain technology, allowing users to retain full control over their assets without relying on trusted third parties.
  • Transparency: The process is fully transparent and verifiable on the blockchain, reducing the risk of fraud and increasing trust in the system itself rather than in individual participants.
  • Efficiency: Atomic swaps can be executed directly between parties without the need for a centralized exchange or a trusted oracle, reducing transaction costs and time, and further minimizing reliance on trusted entities.

Modular and Extensible Design

The protocol's modular design is a key feature that allows for seamless integration with new blockchains without requiring permission from a central authority. The benefits of this approach include:

  • Flexibility: The modular architecture enables developers to add support for new blockchains or features independently, allowing the protocol to adapt quickly to technological advancements and market demands.
  • Innovation: By removing barriers to entry, the protocol encourages innovation and experimentation, as developers can implement and test new ideas without needing approval from a governing body.
  • Scalability: The ability to integrate new blockchains and features without disrupting existing functionality ensures that the protocol can scale efficiently as the blockchain ecosystem grows.
  • Decentralization: This approach aligns with the core principles of decentralization by empowering individual developers and communities to contribute to the protocol's evolution, reducing reliance on centralized decision-making.

Competitive Pricing

The protocol leverages a Dutch auction mechanism to ensure competitive pricing for cross-chain asset exchanges. This approach offers several advantages:

  • Market-Driven Pricing: By utilizing a Dutch auction, the protocol allows the price to be determined by market demand. Resolvers compete to fulfill orders by offering the best possible rates, which naturally drives prices down to the most competitive level.

  • Incentivized Participation: The auction format incentivizes resolvers to participate actively, as they have the opportunity to secure trades by offering attractive prices. This competition among resolvers benefits traders by providing them with better exchange rates.

  • Dynamic Adjustments: The Dutch auction mechanism dynamically adjusts prices based on real-time market conditions. This ensures that the pricing remains fair and reflective of the current market environment, reducing the risk of overpricing or underpricing.

  • Partial Fills: The protocol supports partial fills, allowing resolvers to fulfill portions of an order. This feature enables even smaller liquidity providers to participate in the auction, increasing the overall liquidity and competitiveness of the market.

By implementing these strategies, the protocol ensures that traders receive the most favorable pricing available, enhancing the overall efficiency and attractiveness of the cross-chain asset exchange process.

Backwards Compatibility

No backward compatibility issues found.

Reference Implementation

Security Considerations

Needs discussion.

Copyright

Copyright and related rights waived via CC0.