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

## Abstract

<!--
The Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.

TODO: Remove this comment before submitting
-->

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)](https://bitcointalk.org/index.php?topic=193281.0), 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

<!--
This section is optional.

The motivation section should include a description of any nontrivial problems the EIP solves. It should not describe how the EIP solves those problems, unless it is not immediately obvious. It should not describe why the EIP should be made into a standard, unless it is not immediately obvious.

With a few exceptions, external links are not allowed. If you feel that a particular resource would demonstrate a compelling case for your EIP, then save it as a printer-friendly PDF, put it in the assets folder, and link to that copy.

TODO: Remove this comment before submitting
-->

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 Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).

It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.

TODO: Remove this comment before submitting
-->

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.
1. **Resolver** - the party accepting the cross-chain asset exchange.
1. **Operator** - the party that facilitates the use of protocol by providing neccesssary on-chain and off-chain services to both traders and resolvers.
1. **Source chain** - (trader's funds) **TODO**
1. **Destination chain** - (resolver's funds) **TODO**
1. **Trade** - the process of exchange of **Trader's** funds on the **Source chain** to **Resolver's** funds on the **Destination chain**.
1. **Order** - an offchain structure with a digital signature, confirming **Trader**'s intent to exchange source asset to destination asset that includes dutch auction setup.
1. **HLTC (escrow)** - Hashed Timelock Contract, a smart contract that locks assets until a specific condition is met.
1. **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
3.

#### Data representation agreements:
1. Implementation MUST use [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) 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

<!--
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.

The current placeholder is acceptable for a draft.

TODO: Remove this comment before submitting
-->

### Trustless (self-custody?)

Atomic swaps were chosen as the underlying mechanism due to their ultimate security and trustless nature. Atomicity allows ensuring that either both parties successfully exchange assets or the entire swap is canceled, atomic swaps eliminate the need for trusted intermediaries and provide users with full control over their assets throughout the process.

### Permissionlessly extensible

The modular design of the solution was selected to enable permissionless integration with new blockchains, allowing independent developers to extend the protocol without requiring permission. This approach fosters decentralization and innovation within the cross-chain ecosystem.

### Competitive pricing

TODO

## Backwards Compatibility

<!--

This section is optional.

All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.

The current placeholder is acceptable for a draft.

TODO: Remove this comment before submitting
-->

No backward compatibility issues found.

## Reference Implementation

<!--
This section is optional.

The Reference Implementation section should include a minimal implementation that assists in understanding or implementing this specification. It should not include project build files. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
If the reference implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed.

TODO: Remove this comment before submitting
-->

## Security Considerations

<!--
All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

The current placeholder is acceptable for a draft.

TODO: Remove this comment before submitting
-->

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).