Trust-Minimised Exchange

ChainRift, an efficient custodial exchange, researches and defines a path to reduce custodial risks in the future. Trust-minimised exchange is a concept that achieves that by reducing the time customers’ funds are exposed to a bare minimum.

ChainRift’s proposed scheme combines auditability, improved user experience for hardware wallet owners, (“trade from your hardware wallet”), and trust equivalent to that provided by non-custodial exchanges, but with the liquidity order matching that only traditional exchange engines are able to pull off. The current iteration of ChainRift’s order matching engine can do sustained 50K transactions per second.

Simplified overview

CEX (Centralised EXchanges)

+ Speed, (high-frequency trading).
+ Funds recovery for lost credentials.
+ Compliance (through KYC) for exchange owners.
+ Easy to add any chain (multichain).

– A central point of failure
– User experience riddled with authentication apps, email notifications, and sometimes even worse (selfies).
– Security risk I — The exchange can never be sure if user credentials were stolen.
– Security risk II — Users can never be sure if their accounts on the exchange aren’t “recovered” to an attacker (stolen).

DEX (Decentralised EXchanges)

+ No central point of failure — usually the centralising functions are being added on top.
+No custody risk, users trade from their account — through hardware wallets preferably.
+ For existing hardware wallet owners- a superb, “just works” user experience.

– Single chain — but still many tokens.
– Slow/expensive— even on fast EOS blockchain, CPU costs can skyrocket.

ChainRift is proposing a hybrid approach, that

• is easy to use like a DEX,
• limits exposure of funds to an absolute minimum, but
• still uses modern matching engines, and
• keeps the ease of adding another blockchain without constant modifications.

Posting a trade

The flow consists of 3 main elements;

• RiftUI, that runs on the user’s PC, authenticates all actions
• Nodes in the middle, which;
  ◆ Backup data
  ◆ Authorization nodes; 2x per each chain provide independent verification.
  ◆ HSM- Hardware Security Module, aka ‘dumb signer’ that only takes orders if both nodes sign/attest the command.
• The traditional (fast) order matching engine, that only trust both nodes agreement on the outcome (2x signed attestations).

RiftUI- ‘MetaMask for Bitcoin’

For end-users, RiftUI is the only visible part of this schematics. Whenever the users click to post buy/sell orders, a window opens which either shows a message to either plug in their ledger device (other hardware wallets later) to sign the request, or gives an address + QR code for the authenticated address, after which the users can use any external wallet to transfer funds.

RiftUI acts as a Metamask (or Scatter), but its main focus is Bitcoin and the ability to quickly add new chains (ETH and EOS as well). It’s designed to interact with the exchange and its nodes and not directly with the blockchain networks. That makes it more centralised, but able to. easily add new chains without added network overhead.

In addition to that, RiftUI also offers signups using only hardware keys (no emails, usernames or passwords). It does that by using FIDO authentication (U2F/UAF/WebAuthn) and reuses Ledger (or other hardware key manager devices) ability to recover. Email then becomes an optional communication channel which significantly shrinks phishing attack surface.

Behind the scenes

Technically speaking RiftUI is an open source javascript library that communicates with the exchange’s RiftUI api. It’s hosted from the website (or packaged as an app).

After you press buy order, RiftUI’s job is to:

• Derive “hidden” child address from exchange xpub, using chain-code that is hashed data composed of:
  ◆ Signed challenge; that proves it’s your account.
  ◆ Command; buy order data (trading pair/price), time to live, allow batching? (yes/no)
  ◆ Return blockchain address for the asset you are buying.
  ◆ Random number- to make hide-reveal secure versus brute force guessing.
• Prompt the users to plug in their hardware wallet to sign the transaction, or
• Alternatively, display an address (+ QR code) that the users can pay to from any other wallet.
• Once signed the transaction is pushed to the blockchain and additional encrypted data (ECIES) is sent to the exchange:
  ◆ Backup, offline key (backup purposes, it has to be accessed manually). Encrypted blob stays on the server and on the user device (redundancy)
  ◆ Node 1
  ◆ Node 2

Authorization Nodes in the middle

Backup data

A public key encrypted blob is saved for redundancy purposes. If data needed to reveal the funded addresses is ever lost (bug or attacker deleting it), exchange operators can still import an offline private key and find where your order funds are.

Authorization Nodes

Two independent nodes per blockchain independently decrypt the data and check if Bitcoin (or other currency) is really there. After the verification process, they sign the authorization message (only command and user included). Additionally, a user command (+ data) received from the user gets encrypted with the pubkey provided from the Hardware Security Module (HSM) and stored on a node for later.

HSM

Hardware Security Module provides ECIES encryption pubkey to encrypt data coming from auth nodes. Encrypted data is decrypted on HSM device, but only if both auth nodes provide a valid (signed) request again.

Order Matching Engine

Traditional matching engine checks the signatures of both auth nodes before adding the order to the order-book. If orders match, the trades produced are sent a request back to the auth nodes which then reverse the order of events to push funds back to the user wallet.

Returning the coins

After the trade is executed the process is reversed.

• The trading engine sends an authenticated message back to authorization nodes.
• Nodes verify received messages and request decryption of encrypted user command (+ data) parts from the Hardware Security Module (HSM).
• HSM waits for authorization from both nodes, then decrypts both parts of user commands (+ data) and send them back.
• Now both nodes are ready to check the trade, verify there is enough funds deposited, and prepare transaction for signing.
• The unsigned transaction is sent to HSM for signing
• HSM verifies that both nodes requests are equal and if true it signs the transaction using the valid child private key and transaction back to the node.
• Node publishes the transaction to the blockchain.

After enough on-chain confirmations, the coins are now safe back in the user cold wallet. This can happen overnight and even if the user forgot about it. The money doesn’t accumulate on the exchange and does not provide an ever-growing target to be hacked.

Details

Batching

Posted trades specify if batching is allowed. If disabled, executed order is sent asap, but the on-chain fees might be prohibitive. 12h batching period allows an exchange to accumulate multiple transactions to reduce on-chain fees (and pass that to the user). It also allows the user to issue a new trade with a new command. The commands have the same format, are signed with the same hardware wallet (using FIDO protocol) and communicated over the same channel, but they are not checked against the blockchain. “Withdrawal/deposit” on chain fee is skipped. Bots can “roll” trades without coins touching the chain for a long time.

Partially filled orders

Partially filled orders act the same as batching. Even if a user posted a trade with disabled batching, until the whole trade isn’t filled, they wouldn’t get funds returned (that saves a ton of fees).

Cancelling the trade

You can cancel any trade any time and even disable the batching. It increases the on-chain fee you pay but your coins get on the way immediately.

Manual approval for larger withdraw requests

The automatic withdraws can still be limited based on the size and withdrawal limit (per person and per exchange); if there is an unusual high withdrawal rate, human operators must approve further withdrawals. This would help ensure that even if an attacker was able to bypass some validity checks, the attacker would not be able to drain the whole exchange by repeating the exploit.

Hot/Cold separation of funds

There is still an option to split funds into hot/cold storage in addition to multi-sig style security, manual processing of larger withdrawals, and minimal amount of funds retention within exchange control.

Funds would go into cold storage based on how big orders are and how close to the market price. Huge orders set to counter a “fat finger” accidents (that might never happen) would qualify. Withdrawal of such order would always require manual approval (to batch-approve cold storage withdrawals).

Challenges

EOSIO

In some chains (for instance EOSIO based chains), the creation of a new account for every command is not practical since its too expensive to create ‘one time use’ accounts. To remedy this, a simple contract would be deployed. The contract would check if there is hash commitment present on every deposit (or fail the transaction). It would also check if withdraw actions provided valid data (hash of user commands (+ data)) that authenticates in the previous commitment.

GRIN/BEAM

Some new chains and protocols like mimble-wimble or lightning network don’t allow transfers without the recipient being online. They are building new approaches to re-enable that functionality, but until they deliver a reduced scheme must be used that only uses one always online node, and doesn’t use the commit/reveal approach to achieve multisig style security.

Lightning Network

The lightning network promises fast transactions with zero confirmations by keeping data off the blockchain. We are excited and its speed would fit right into the “posting trades from the user wallet” design that this paper proposes.

LN is in its early stages; there is no hardware wallet, no standardised push payments yet (read more on sphinx to learn what is coming), no clear way to pay more for settlement fees, toxic channel history (both issues are addressed by eltoo), questions about node liquidity,..

LN can be integrated using a reduced security scheme. Unfortunately, the hide/reveal part of a proposed security scheme is still a subject of further research, development, deployment and standardisation before it could be safely adopted.

First Iteration

To reduce the complexity and learn from the system while being built, an iterative process is suggested.

The first iteration of this concept should focus just on the usability of RiftUI (“MetaMask” for Bitcoin) and discard the more complex commit/reveal with 2 authorization nodes + HSM security flow. By keeping data in plain, the backups can be simplified and chain addition gets even simpler.

Instead of integrating a Ledger device, only the generated address (string with magnet link + QR code) is displayed and the user sends to it with their favourite (external) wallet. FIDO based UAF authentication stays as the only authentication factor used — signed challenge is part of the data that derives child address. Order cancellations and issuing new ones while the funds are on the exchange are also authorised with UAF. All hardware wallets and browser support it out of the box.

Conclusion

The ChainRift trust-minimised exchange allows users to bring the “trade from the hardware wallet” experience from Ethereum and EOS to the Bitcoin blockchain. The approach to commit/hide and later reveal data gives an attacker hard time if trying to drain the funds. And the fact that funds not being used are sent back to the user reduce the amount of exposed crypto to a minimum and keeps the attack surface, and consequently any potential damage, very small.

Compatibility with current username+password allows users without hardware wallets to still participate and then slowly migrate after the amount of funds that users keep in the exchange becomes a honeypot. Trades from the “old” (the current ChainRift) portal are posted alongside authenticated ones, so both contribute to liquidity.

An even simpler “Shape-Shift like” portal can be used to further reduce complexity and bring market additional market order currency conversions to provide liquidity to existing orders books.

The proposed solution requires users to authenticate using a FIDO compatible hardware wallet, which reuses the existing KYC for compliance reasons. That’s a compliance requirement, not a technical one; the Trust-Minimised Exchange would technically work the same without user id (each authenticated trade on its own).

Cover picture adapted from Pixabay.