Optimistic cross-chain token exchange

Delight is a protocol designed to facilitate secure and efficient cross-chain token exchange. The protocol consists of three core modules:

Trading: A fast and secure way for users to acquire their desired tokens from a merchant.

Conflict Resolution: An efficient and integrated refund, dispute and arbitrage process.

Settlement: An easy and safe way for merchants to settle the exchange and get paid out.

📎

To illustrate how the protocol works, we will explain it with a simple use case: Lisa wants to buy a NFT on Cronos with FIRA tokens, but all her funds are in her wallet on the Binance Smart Chain (BSC). Gordon, a merchant, is specialized on trading Cronos tokens and can make a profit by selling FIRA tokens to Lisa.

Module 1: Trading

In the Delight protocol, the customer, Lisa, will purchase FIRA tokens offered by Gordon, the token merchant. While Gordon’s actions will in practice be automated by software the best way to understand the protocol is to understand its very basic functions first.

These basic functions are:

Gordon creating an offer for FIRA tokens

Lisa ordering FIRA tokens with BNB

Gordon fulfilling the exchange claiming his settlement tokens

Gordon offers tokens for sale

The process begins with Gordon creating an offer in form of a sale limit order on the source chain for any token on a supported destination chain. In our example, this means creating an offer on the BSC Chain for FIRA tokens on Cronos.

Gordon sets the terms for his offer. He specifies a minimum and maximum amount of FIRA tokens he would like to sell. Optionally, he can set a fixed token amount which allows him to offer packages (e.g: 20 FIRA tokens for $5.99), making his offers easy to understand and accept for customers with no trading experience like Lisa. Then Gordon sets the exchange rate for FIRA/BNB as a fixed value.

🚧

In the first versions, Delight works with a fixed exchange rate between tokens. However, at the center of the protocol lies what we label a persistent, dynamic pricing. It’s the ability for merchants to define and calculate exchange rates in realtime, using data from any on and off-chain system and set them immutably for any trade.

Finally Gordon sets a timeout period that defines how fast he will execute and deliver the purchased tokens to Lisa’s wallet. This duration he specifies may, for example, depend on the technology he uses as a bot or on the checks he wishes to carry out before paying. If the timeout period passes and Gordon did not complete the transaction, Lisa will receive an automatic refund in the form of the tokens she originally deposited.

🚧

In future versions, instead of receiving a refund, Lisa will be able to receive credit in the protocol’s token. This will reduce unnecessary gas cost and provide Lisa with additional convenience for executing another exchange swiftly.

When Lisa now searches for FIRA offers, the system displays all active offers including Gordons. Lisa can now select an offer that matches the amount she intends to deposit on the source chain. Lisa can then decide to purchase a packaged offer or choose to exchange a custom amount of tokens and place her order by depositing the corresponding BNB amount. Lisa’s deposit will be locked in the source chain smart contract used for later settlement with Gordon as covered in Module 3 of this documentation.

Lisa can choose between simple shopping and more customized trading.

🚧

To allow users to exchange with non-EVM chains and make payments on their behalf, users will be able to specify and optional a recipient wallet for their order. In combination with account abstraction this will enable entirely new types of payment experiences for Lisa. For example, Lisa will be able to directly receive a NFT in a single transaction. Read more in our .

When the transaction of the deposit has completed, Gordon can detect this new order and fulfill it on the destination chain, sending the FIRA tokens to Lisa’s wallet. This transaction is recorded on the destination chains smart contract to facilitate future validation and eventual conflict resolution.

Module 2: Conflict Resolution

The Delight Protocol is based on an “optimistic approach”, meaning it assumes that all actors behave honestly. In the case of this protocol, this translates to a simple assumption: as long as Lisa does not fill a refund during the validation period Gordon will be able to settle the transaction and claim his funds.

📌

This optimistic approach has important benefits. It avoid the use of complex algorithms as well as the need for intermediaries, traditional bridges watchers or validators. It decreases execution cost, protocol deployment time while keeping security entirely on-chain, significantly reducing vectors of attack.

The protocol has theoretically four instances of conflict resolution.

Timeout period: An order is not fulfilled on-time by the merchant.

Refund request: The customer, Lisa, is “not satisfied” with the fulfillment.

Dispute resolution: The merchant, Gordon, rejects the refund request.

Arbitrage: Triggered from dispute resolution as last instance.

The timeout period has already been covered in Module 1. This process is not included in the conflict resolution procedure, as it serves as a safeguard against possible technical malfunctions and unavoidable network delays. The merchant cannot be held responsible for such delays at all times.

Refund request

The refund process allows Lisa and Gordon to solve any issues that arose from their trade easily and swiftly between them, without help or intervention of any third party. If Lisa believes that the transaction was not completed according to the agreed terms or not completed at all, she can initiate the refund process. The only requirement is that Lisa requests the refund process within the validation period and after the time out period has expired.

🚧

Initially, the validation period is set to a fixed (e.g: 30min). However, future version allows to take transaction amount as well as reputation of the buyer and seller into account. This dynamic validation period further reduces settlement time while maintaining maximum security for all parties and with that overcoming challenges typically associated to optimistic protocols.

While the entire conflict resolution process starts with Lisa taking the first step by asking for a refund, it is de facto Gordon, the merchant, providing the foundation. All merchants need to stake tokens in the source chain contract to be able ~~to punish malicious behavior and make sure the merchant can - if necessary -~~ cover the cost of the incurred refund, dispute and arbitrage. As we will see, Lisa’s deposit serves on the other side the same purpose.

Lisa files a refund request associated to a specific order and makes a deposit.

Gordon can choose to:

Accept the request and execute one transaction restarting the validation period.
Reject the refund or letting it expire in both cases initiating the dispute process on behalf of Lisa.

Lisa is presented subsequently with the following choices:

She is satisfied with Gordon’s transaction and simply lets the validation period expire.
She is not satisfied and triggers the dispute process.

🚧

It will be possible to provide Lisa with a credit in the systems stable, settlement currency instead of issuing a refund. This not only allows to reduce unnecessary gas cost but also to remove volatility during the refund and possible dispute and arbitrage period.

Again, the refund process together with time out period of Module 1 are designed to account and resolve for all conflicts arising from human, machine and network behavior with no malicious intention.

Dispute Resolution

The previous processes of time out period and refunds are the primary means of dispute resolution. The herby described process of dispute resolution in combination with the last instance of arbitrage ultimately just provides a fail safe deterrent for malicious behavior.

In this dispute resolution procedure, Lisa and Gordon take turns depositing larger amounts of liquidities to confirm their positions and increase the dispute bonding. The goal is to create a pool of funds that will be used to reward the honest party who participated in the dispute. The other party will be penalized heavily, and the penalty amount increases with each round of dispute because the bidding also increases each time. Additionally, backers who are interested in the potential financial gain can also participate in the dispute by depositing increasing amounts of money.

📌

This dispute resolution process within the optimistic protocol is based on the pioneering work of systems such as Reality.eth Beamer protocol or even UMA Oracle. Indeed, it secure systems of different types, based on financial incentives and punishment in a social and democratic way.

More specifically:

Each time a participant responds to the challenge, the duration of the challenge and underlying claim is extended to allow the other party to respond.

At the end of the challenge period, the participant with the highest stake, who is also the last non-contested participant, wins the challenge.

If Gordon wins the challenge, his claim will be seen as valid and he will be able to withdraw his GST on BSC.

However, the winning participant, regardless of who it is, will receive the deposit of the losing side as a reward. Potential backers can also take part of the rewards depending on the impact of their participation.

Arbitrage

Furthermore, the system has an arbitration capability, but it is an expensive option and is usually requested only after parties have posted bonds. When the bond amount reaches a level where the fee for arbitration is less than the bond amount that could be gained, the arbitrage is called. The participants in the arbitration are the holders of the stable settlement currency. They have acquired a reputation for making the protocol completely decentralized and are responsible for settling critical disputes by casting their final vote to decide the outcome of the dispute.

Module 3: Settlement

In the final part of the protocol, Gordon can claim and withdraw tokens received from the trade. Gordon can claim tokens that meets any of the following conditions:

Tokens from trades where the validation period has expired

Tokens from trades with settled refunds and expired validation period

Tokens from trades with resolved disputes and arbitrage

Tokens resulting from winning in the dispute and arbitrage

Any token not withdrawn are automatically added to the stake of merchant which can be withdrawn under the same same conditions at anytime. This means the stake must be high enough to cover any transactions in process, refund, dispute and arbitrage surplus to cover gas and transaction fees for these processes.

A unified settlement currency

At its foundation, Delight is an order book exchange. One of the shortcomings of these types of exchanges is the trade frequency, arising from the exponential amount of token tuples needed simultaneously to allow for a successful match. Delight overcomes this challenge with three strategies:

Delight allows end users to exchange only a few selected tokens (primary tokens on dominant source chains) into tokens on other chains. This significantly reduces the amount of tuples.

Delight allows merchants to incorporate existing DeFi and CeFi systems on the fly when trading. This enables them to offer and trade tokens without having actual liquidity in them.

Delight introduces a single, stable settlement currency for merchants that is always settled on the source chain. This removes required tuples to the absolute minimum while removing volatility risk for the merchant.

It is this last of the three strategies implemented in the protocol itself that makes the biggest difference and sets Delight apart from other cross-chain protocols and DEXs.

The stability of this currency is achieved by over collateralization of this token with stable coins like BUSD and USDC.

🚧

In its first mainnet version, Delight will accept only BUSD or USDC from Lisa to avoid the cost, time and complexity of exchanging volatile tokens into stable coins. Future version can provide for more sophisticated stabilization and collateralization strategies of the treasury.

🚧

As Delight’s stable token is native on every source and destination chain and it’s minting and burning can be uniquely controlled by the protocols. This opens additional opportunities for secure native bridging and the use of the stable coin across its network of supported chains.

Protocol Tokens

Additional to the settlement token described above the protocol has a native token. This token is exclusively a governance token. This ensures decentralization of the protocol by delegating power to the community. Token holders will be able to exercise their voting rights by locking the token and voting on governance proposals or submitting new ones. Besides voting, holders also have ownership over the protocols treasury and have the power to enact a protocol-wide fee switches.

The protocol also features fee switches that allow token holders to receive income based on the fees generated by the protocol. For example, a future version could have a fee switch that would set transactions fees to 0.3%. The protocol would give the the fee to token holders if the switch was enabled.

Reputation

Our system collects a significant amount of data regarding the source and destination chains, which enables us to create reputation indicators and scores. These measures are inspired by P2P marketplaces and could be maintained entirely through decentralized systems such as The Graph. Reputation plays a crucial role in our system, as it helps establish trust between participants and enhances the overall security and reliability of our platform. Through our reputation measures, we aim to provide a transparent and trustworthy environment for our users to conduct their transactions.

Delight Blockchain

In order to fully realize the vision of the protocol two aspects present significant opportunities. The first is the persistent, dynamic pricing we hinted at in Module 1. The second one is the decentralization of the merchant automation. We are still in early phases of research but we believe that bringing these feature on its own blockchain - no matter if L1, L2 or L(x) - is the future of the Delight protocol.

Below you find an outlook and preliminary strategies to achieve this.

Persistent, dynamic pricing

In Module 1, we introduced a fixed exchange rate set by merchants that had limitations but worked for some scenarios, such as testnet tokens. However, the next version of our system will allow for a persistent, dynamic pricing that can use formulas and functions that point to on-chain data. This enables the use Oracle price feed technologies like Chainlink to provide real-time, verified data to merchants in their offers. To achieve this, merchants need to identify a request for off-chain data and write it on-chain before Lisa accepts the offer and makes a deposit. The first version of this pricing engine can be implemented by writing the value off-chain in persistent storage like IPFS while allowing merchant automation to be either centralized (e.g., Zapier) or decentralized (e.g., Gelato). However, implementing the entire process on a single system (e.g., a dedicated layer 1 blockchain) would enhance simplicity, security, and performance as this blockchain could pull and validate off-chain data in its runtime.

Merchant Automation

In Module 1, we discussed how merchants can use any centralized or decentralized technology to execute trades. This provides significant autonomy and the ability to incorporate CEFi and DeFi systems into their trades. This advantage can lead to lower prices for end users like Lisa. However, the downside is that these merchant systems are largely centralized and exposed to inherent shortcomings. With the introduction of a persistent, dynamic pricing engine, there is now the possibility of not only storing trading data like exchange rates on-chain but also using smart contracts to define the actual trading processes. This development emphasizes the need for a blockchain that can pull and validate off-chain data in its runtime to enable secure and reliable trading processes.

Hybrid Smart Contracts

The strategies outlined above for persistent dynamic pricing and merchant automation lead to the creation of a blockchain capable of running hybrid smart contracts. These smart contracts incorporate off-chain data, as detailed in Chainlink's vision. Grindery has spent the last 18 months working on automation, messaging, and oracle technology, resulting in the first publicly available product via Zapier. This technology not only breaks new ground by allowing users to connect Apps and dApps without code but also lays the foundation for a cheaper oracle system that can be incorporated into a blockchain's runtime. The current Gateway product can transition from running on centralized systems like Zapier to decentralized systems on its own blockchain, opening the gates for a new generation of multichain systems.