Onchain Iceberg Orders — A Decentralised Zero Knowledge Framework

TL;DR

• Onchain Iceberg Orders involve breaking large trades into smaller transactions in DeFi for anonymity and market impact reduction.
• Centralized intermediaries pose privacy risks and allow front-running, hindering secure execution of onchain iceberg orders.
• Utilising private mempools with cryptographic encryption ensures secure, private, and decentralized execution of iceberg orders.
• Elektrik uses Fairblock’s SDK, eliminating centralized intermediaries for iceberg orders, combining block numbers and public keys for encryption which ensures transaction security.

Introduction

With the maturation of financial markets, the demand for more comprehensive and complex financial instruments has resulted in the creation of a myriad of different order types, from limit orders to TWAPs. Recently, the blockchain domain and its decentralised financial (DeFi) realm has presented a new arena for financial markets, prompting the development of decentralised analogues for these order types. However, given the significant differences between the underlying infrastructure, in some cases adapting these order types to DeFi has proven difficult.

One such order type that has presented significant challenges in transitioning from TradFi to DeFi is the iceberg order. These orders, which involve making a large trade via several smaller transactions, are indispensable for large volume traders. By only showing the ‘tip of the iceberg’ through these smaller trades, traders can hide the larger order and avoid incurring significant financial losses. Therefore, the development of an on-chain analogue for the iceberg order is indispensable for the advancement of DeFi markets. Recognising this need, our decentralised exchange (DEX), Elektrik, is looking to create an effective decentralised system for initiating and executing iceberg orders.

The Problem with On-Chain Iceberg Orders

The term ‘iceberg order’ refers to a single, larger transaction that is broken down into a number of smaller limit orders. Typically implemented via automated algorithms, iceberg orders are used to mask the true magnitude of substantial trades, thus minimising their market impact. Hence the name; much like the tip of an iceberg that’s visible above the water, only a fragment of the actual order is displayed in the market, concealing the bulk of it beneath.

But why the subterfuge? The answer lies in the nuances of market dynamics. When substantial orders are placed in the open market, they have the potential to drastically sway market sentiment and cause slippage among other problems. For instance, a large sell order can inadvertently hint at a lack of confidence in a stock or commodity, influencing other traders to adopt a similar stance. Additionally, a larger order may encounter insufficient liquidity at a particular price, necessitating the trade to be executed at the next best available price, hence slippage. By splitting these orders, traders can sidestep unintended market consequences.

In the context of blockchain wherein orders are placed into a mempool for execution, iceberg orders provide traders with additional protections. By decentralising the process of making an order and concealing the true size of transactions, these on-chain strategies prevent malicious actors from preemptively acting on large forthcoming trades to extract harmful MEV via frontrunning, sandwich attacks or other mechanisms. This ensures that traders can execute larger orders without inadvertently providing cues to potential market manipulators.

The Problem: Centralised Infrastructure

Presently, the execution of on-chain iceberg orders is tethered to centralised intermediaries. These intermediaries, be it brokers or centralised exchanges (CEXs), function as the gatekeepers, curating and channelling iceberg orders based on individual traders’ specifications. Parameters such as price impact, total amount, average amount, and limit price are typically entrusted to these entities, mapping out the trajectory of the iceberg order’s split and execution.

However, this centralised framework harbours inherent drawbacks, namely the trust factor. Entrusting sensitive order details to centralised parties inadvertently opens up vulnerabilities. For one, these orders become susceptible to front-running by those operating the exchanges. As these intermediaries hold prior knowledge of order details, unscrupulous entities can exploit this information, executing trades to their advantage before the original order is completed. Moreover, the centralised nature inherently opposes the core tenets of decentralisation and trustlessness that are inherent to blockchain technology.

Such challenges underscore the pressing need to rethink the prevailing infrastructure. If the essence of iceberg orders is discretion and strategic manoeuvring, then shouldn’t the platforms facilitating them resonate with the same principles? As the global financial landscape evolves and decentralised systems gain prominence, the spotlight should inevitably shift toward solutions that mitigate the vulnerabilities inherent in centralised architectures.

Addressing Market Demands Beyond Open Exchanges

Aside from the openly accessible exchanges, there exists a substantial volume of trading that transpires within dark pools and amongst private investors. These avenues are used to execute large trades with less risk and minimal market impact, gleaning the same benefits as afforded by iceberg orders. Dark pools, being private exchanges or forums for trading securities, are not accessible by the public investor. They cater primarily to institutional investors who aim to trade in large volumes without significantly affecting the market price. Similarly, private investors, who constitute a significant portion of the market, often engage in trades off-exchange to minimise market impact. Therefore, the use of these alternative trading avenues by traders demonstrates the need for effective onchain solutions such as iceberg solutions.

Decentralising Iceberg Orders with Private Mempools

When placing an order on a blockchain network such as Ethereum, the transaction is held in a mempool before execution. Mempools, short for memory pools, are a holding area that allows for transactions to be grouped together and eventually added to a new block by a miner or validator. These mempools essentially act as a waiting room, ensuring transactions are orderly processed and recorded onto the blockchain. However, traditional mempools are public, meaning anyone can access and observe the transactions taking place.

Recently, private mempools have begun to emerge. They present a viable alternative to the traditional hegemony of centralised intermediaries used for iceberg orders. As the name suggests, these mempools provide a secure, private environment that is also decentralised in nature. Private mempools achieve this using cryptographic technology, notably multi-party computation schemes, that ensure each transaction is completely private and encrypted. Each fragment of an iceberg order, in a private mempool, is completely private until the moment of execution and can be executed in a trustless manner.

Using private mempools, DEXs can maintain the integrity and security of user’s transactions while also upholding the core tenet of decentralisation. An integral aspect of this new approach is the introduction of local execution conditions. These conditions are rules used to dictate the execution of orders within the mempool, ensuring a structured and strategic flow. This is especially pertinent for iceberg orders as each order fragment must be primed for execution only upon the successful culmination of its predecessor. Therefore, these local execution conditions must be built into the private mempool in order to properly facilitate iceberg orders.

Elektrik’s Approach Using Fairblocks

Aiming to solve the centralisation problem associated with iceberg orders in DeFi, Elektrik is making use of a private mempool software development kit (SDK). This mempool has been developed by Fairblock, a company focusing on applied cryptography with a particular emphasis on enabling pre-execution privacy in blockchain applications. Underpinning Fairblock’s infrastructure is its unique method of generating a distributed public key, enabled through the Secret Sharing Scheme (SSS). This process involves a consortium of validators collaborating to create a distinct and secure public key that forms the cornerstone of Fairblock’s encrypted transactional architecture.

Beyond just the public key generation, Fairblock makes use of the concept of Identity Based Encryption (IBE). Instead of relying on generated and distributed public keys for each transaction, block numbers are used as identities. Users looking to execute iceberg orders, for example, can encrypt their transactions using the public key in tandem with the block number via IBE. This binds each transaction to a specific block number, providing an added layer of cryptographic security. Decryption happens at specific block heights, where key shares are combined to decrypt the transactions. This use of IBE, along with the (presumed) SSS, forms the core cryptographic foundation to ensure the privacy of iceberg orders.

The Execution Process

To explore the process via which an iceberg order is executed within the Fairblock mempool, consider the following example:

1. Initialisation — A trader on Elektrik decides to place an iceberg order.

2. Fragmentation — The larger iceberg order is broken down into smaller limit orders with sizes drawn from a random distribution to prevent statistical inference attacks on extended orders. Each limit order specifies a definite price and a random amount, with the sum of all limit orders equaling the total amount. These orders are then sent to the private mempool.

3. Determining Execution Time — Select the timescale for the complete execution of the order. Divide the number of orders by the timescale to calculate the execution time of each limit order. The user can change their preferred timestamps.

4. Block Number Assignment — The block number for each limit order is calculated based on its execution time using the formula:

Note — blockNumber can be assigned manually to each limit order without affecting the execution.

5. Encryption — Each limit order is encrypted using the designated public key and the block number as the identity for each order.

6. Mempool — The encrypted transactions, tethered to a designated future block height, are dispatched to the Fairblock mempool.

7. Execution — When the blockheight is reached, Fairblock decrypts the transactions exclusive to that block. Said transactions are sent to a settlement contract where certain preconditions are verified. These preconditions may include price limits, with the option for stateless or stateful preconditions, depending on the desired level of security. Now in the open and visible, these transactions stand ready for execution, maintaining the iceberg strategy’s fidelity.

In the future, the Elektrik team is looking to implement conditional decryption keys for iceberg orders on their platform. These orders could be set to execute only when certain pre-defined criteria or conditions are met, enabling traders to seamlessly manoeuvre and readjust in response to market events.

Conclusion

By bringing true decentralisation and security to on-chain iceberg orders, Elektrik is enabling their traders to exercise greater control over their trading. It represents another step taken toward DeFi achieving true equivalency with TradFi. Unbound from centralised intermediaries, these traders will be able to execute iceberg orders within a system that embodies the core tenets of blockchain technology without sacrificing their user experience. Integrating these tools will only serve to open the door for even more sophisticated and seamless trading experiences in the future.