The financial engineering team at UMA has been thinking about BitDEX and Priceless Financial Contracts for a few months and published a research paper with more details on the underlying concepts. There are a few notable features worth pointing out:

  1. Centralization Tradeoffs as Features vs. Bugs
  2. Privacy Enabled by Pseudonymity
  3. Extension to Fiat-based Trading Platforms
  4. “Slow Oracles” vs. “Fast Oracles”
  5. Capital Management for Liquidity Providers

Centralization Tradeoffs as Features vs. Bugs

As the research paper states, centralized operators like BitMEX perform some or all of the following useful functions for counterparties: 

  1. Aggregating liquidity among counterparties
  2. Custodying margin on behalf of trading counterparties
  3. Moving margin between counterparties (“clearing trades”)
  4. Ensuring that each counterparty has enough margin to pay for potential losses
  5. Settling and closing counterparties’ trades

In order to perform these functions, they also:

  1. Curate lists of counterparties who can participate
  2. Collect personal information for all prospective and existing counterparties
    1. This information may be used to conduct KYC/AML verification and/or shared with regulators. 
  3. Confidentially record counterparty identities, positioning, and margin balances
  4. Source a price feed for each market they service.
    1. This price feed is used to determine each counterparty’s current leverage and conduct margin calls (accomplishing #4 above). 
    2. This price feed is also used to calculate each counterparty’s “mark to market” or PnL (used to accomplish #3 and #5 above). 
  5. (Optional) Institute loss socialization measures (e.g. a dedicated “insurance fund” to pay out counterparties in the event of an exchange hack or counterparty defaults or insolvency).

Rather than “tradeoffs”, these centralized features of operators are often perceived by counterparties and regulators as a brand of safety. Regulators may bless the operations of certain operators (e.g. CME, CBOE), further attracting counterparties and aggregating liquidity. For cryptocurrency exposure, some counterparties also prefer trading on centralized, if less regulated, platforms (e.g. BitMEX, Deribit) that have instituted loss socialization mechanisms and cultivated their own reputations. Counterparties value the economic security of knowing that the system is solvent and the privacy of keeping their positioning hidden from other market participants.

Privacy Enabled by Pseudonymity

BitDEX uses blockchains’ pseudonymity to make counterparties’ positioning and margining information publicly available without revealing real-world identities. This transparency enables a leveraged trading platform where counterparties to set and enforce their own rules of engagement.

A single real-life counterparty can control multiple addresses that each have one unit of risk in BitDEX (long or short). For example, if Alice traded with a centralized operator, she would have to divulge her identity to the operator, who would record how large a position she was taking and how much margin she had deposited. In BitDEX, if Alice wanted 3 units of long risk, she would create or obtain ownership of 3 addresses and then record in the smart contract that those 3 addresses are each associated with 1 unit of long risk.

For each position of 1 unit of risk, BitDEX records an associated address. For a real-life counterparty to own more than 1 unit of risk, they can control multiple addresses. Only the information in the blue box is recorded on the blockchain.

Extension to Fiat-based Trading Platforms

The concept of “Priceless Financial Contracts” is powerful and extensible. It is generic enough to run on Ethereum as a decentralized leveraged CFD provider or any other Layer 2 scaling solution that has the concept of an exit game or challenge period (Plasma, state channels, etc.)

Interestingly, it can also be applied to any trading platform that allows for off-platform coordination among counterparties (for example, a fiat-based platform vs. a blockchain-based platform). A fiat implementation would have all information about counterparty positioning and margining in a publicly viewable place (e.g. a spreadsheet), allow counterparties to pseudonymously and automatically dispute each other’s positions (e.g. via a messaging system connected to an automated dispute resolution mechanism), and set the margin currency to be USD (or other fiat currency). The automated dispute resolution mechanism could be a centralized entity (e.g. Bloomberg) that all counterparties agree to (e.g. via a DAO).

Furthermore, an operator could use some features of BitDEX, but not all. For example, an operator could maintain a pool of margin in a smart contract on the blockchain, but interact only with addresses that it has KYC’d, serve as (or choose) the dispute resolution mechanism, and serve as the sole entity permitted to conduct margin calls on-chain (rather than allowing counterparties to do it themselves). Services like Axoni could build specialized blockchain solutions to migrate the trading activity of existing operators (like the CME?) onto such a platform.

“Slow Oracles” vs. “Fast Oracles”

Freeing financial contracts from on-chain price feeds and oracles opens the possibility for decentralized finance to incorporate slower or asynchronous oracle designs. Many financial contract designs rely on “fast oracles”, where once they receive a price from a “fast oracle”, they take some action. To safeguard against incorrect prices being fed into these contracts, “fast oracles” like the Maker oracle still include a small delay (~1 hour) before bringing a real-world price on-chain. For example, the 10am price of an asset is brought on-chain at 11am, to give people a chance to verify the price. Another design could put the delay at the contract level rather than the oracle level, but regardless, some delay is needed to give “human judgment” a chance to opine on whether the next action is correct.

Priceless financial contracts do something similar – but by only calling for an oracle or “human judgment” when a dispute arrises, it is compatible with “slow oracles”, such as UMA’s DVM, that take a relatively long time to return an answer (24-48 hours). If many financial contracts end up using the “priceless” framework, these provide a practical application and use case for research that others are conducting to design “slow oracles”.

Capital Management for Liquidity Providers

One of the ways in which I find the BitDEX’s design very elegant is in how it is fairly capital-light for someone to close a position. A liquidity provider might care about this because they’d like to open and close positions fairly quickly. (They might be acting as “keepers” to dispute positions they do not yet have offsetting risk for.) Retail users should also care about this because they typically do not have large balance sheets. Let’s walk through a more basic example of someone who is long, looking to exit their position by taking on a new short position.

Let’s say the NPV function = Price – 10,000 and the Margin Requirement function = 10% * Price. Since the BitDEX smart contract was deployed, the price has moved significantly, say, to 15,000.

Alice (long) entered a trade with Bob (short) at a price of 10,000 a long time ago. Alice and Bob each initially deposited 2,000 in BitDEX, so they each always had enough margin to meet the margin requirement. Over time, Alice withdrew a total of 5,000 to account for the 5,000 increase in price, which Bob paid for by depositing 5,000. So Alice’s net deposits are now 2,000 – 5,000 = -3,000 and Bob’s net deposits are 2,000 + 5,000 = 7,000. Only 4,000 is custodied by BitDEX.

Now, if Alice wants to close her position, she needs to submit a “sell” order to find someone else willing to go long. Say Charlie has an order out there to buy a position at 15,000.

Alice and Charlie now see that they should deposit at least 1,500 each into BitDEX to make sure they cover the margin requirement, but seeing that Alice and Bob currently each have 2,000 of excess margin, Alice and Charlie agree to each deposit 2,250. Since Alice and Bob are currently viewed as solvent, if Alice and Charlie add more excess margin than Alice and Bob, they’ll inherit Alice and Bob’s implied solvency.

Alice and Charlie also have to cover the 5,000 NPV value in their “net deposit” values, so they agree to split the 4,500 they’ve deposited into BitDEX in the following way:

Alice can now close her long position with Bob against her short position with him and immediately withdraw 4,250 from the system. This corresponds to the 2,000 of excess margin she kept against Bob and 2,250 of excess margin she kept against Charlie. She already received all the profits of the 5,000 change in NPV by withdrawing from BitDEX before she opened the trade with Charlie, so Alice can now cleanly walk away from the trade.

Charlie is now left facing Bob, and each are securely margined.

The process of Alice closing out her trade only required her to, very temporarily, double the amount of excess margin she had deposited in BitDEX. She was able to immediately withdraw this (with no challenge period required) after closing out her trade. A liquidity provider therefore is looking at fairly low levels of capital required to act as “‘keeper” and “flip” positions.

Separately: If BitDEX allowed Charlie to close out his trade directly with Bob by somehow transferring Bob’s position to Charlie, Charlie would have to “buy out” Bob by paying him 2,000. This is because when Charlie collapses his trade with Bob, he’ll receive 4,250, but only deserves the 2,250 he was maintaining as excess margin. Bob should receive back the 2,000 he was maintaining as excess margin. Charlie and Bob can coordinate this payment off-chain, after which BitDEX could collapse Charlie and Bob’s positions.