Atomic Swaps with XBOM- Smart Accounts for DeFi

By: David Beberman, CTO and Michael Holdmann, CEO

The underlying concept of the atomic swap and the Uniswap concept is the ability to control separate smart contracts from another smart contract. This enables a single transaction to encompass swapping different tokens. We should view this as proof of the underlying concept of asset swaps of any kind encompassing any type of assets not just tokens[i]. To do this, we need to design the fundamental models of exchanging arbitrary objects, which can be overridden with security functions in subclasses.

Let’s start with the basics of transferring an object between two accounts[ii]. Accounts are represented by objects and are container type objects. To transfer an object between any two accounts, we need to implement both a push function and a pull function.

To push an object: A message would include the object to be pushed to another account, and the Ledger Object ID (LOID) of the target account. This message would be sent to the first account. The first account simply deletes the object from its contained list and sends an insert message to the second account. If there is a failure of any kind, the transaction returns an error. That is all that is necessary because a failed transaction does not update the ledger state database at all.

To pull an Object: The account to pull from, and the object to pull are designated in the message to the receiver account. The receiver account sends a remove message to the sender account and inserts the object in its list.

To make this a 3-way: That is an independent 3rd party account that causes a transfer between two accounts — the 3rd account is the source of the push or pull message.

To implement the foundation for this, the Class XBOM Container needs to support the messages: insert, remove, list. The Class Account needs to support the messages transferto, transferfrom Class Account also needs to support create — which creates a new object of a class. This doesn’t create a full sales cycle — which needs the ability to make offer-to-sell and offer-to-buy capability[i]. For that, we will create a subclass of ClassAccount that has specialized lists of objects in its containment lists.

To do the marketplace concept we need the listener capability to listen for new accounts, and for new objects that are offers-to-sell.

The next question to consider is how to do the equivalent of liquidity pools — We can do a liquidity pool of any type of object to any other type of object. What we can do is design classes to show how things can be done similar to individual smart contracts, but cleaner and faster with the XBOM approach.

For the liquidity pool concept, we create a liquidity pool account class — each liquidity pool is its own account. What we can do is enable accounts to be referenced from other accounts. Thus, there can be a master list of liquidity pool accounts, we would want that type of design so that individual liquidity pools can run on separate shards. The protocol design enables the liquidity pool object to inform the “swappers” they can do the swap, but that the actual swap is a separate direct transaction, not part of the liquidity pool transaction itself, this would enable better shading.

To do this, we would also need the ability to guarantee the swap occurred. The concept of a liquidity pool forces that each transaction for each pool requires the swappers and the liquidity pool which forces all 3 to be on a single shard for any transaction and serializes on the liquidity pool object which solves for that.

So, a liquidity pool concept — which is essentially bartering, forces a 3-way transaction which forces serialization on the specific liquidity pool, but all pools are independent. Of course, Uniswap is similar in that all liquidity pools are separate smart contracts. Uniswap introduced the idea of chained swaps, which ties the liquidity pools together for a specific swap, which is the same as assigning the liquidity pools on to a single shard for the specific transaction on DataGrid Blockchain. This shows that we can generalize to assets not just “dumb” tokens ad that is the fundamental point of using the XBOM.

Up until atomic swaps we didn’t have anything similar to point to on other blockchains, thus the discussion on multisided marketplaces[iii]. We can use the liquidity pool constant model to show the ratio between any two assets. We can use a single account that contains a list of all liquidity accounts so that it’s easy to find the entire list of them at any time.

This will be a very interesting example of our infrastructure project within the DeFi vertical and the enablement capabilities of XBOM. We look forward to engaging with both DEX’s and Centralized Exchanges to develop Class Trees for instantiation of accounts and assets while we continue development of the DataGrid Blockchain.

[i] https://medium.com/@michael_11858/anatomy-of-asset-and-value-transfers-with-the-extensible-blockchain-object-model-and-extensible-565d2c0f5e51?source=friends_link&sk=8d82c0caf4bb212083e7c2cff7d73a12

[ii] https://medium.com/datadriveninvestor/rethinking-the-blockchain-account-concept-e974382e291f?source=friends_link&sk=1c6078ad04b1b0caa1ab4176e29a396a

[iii] https://medium.com/@michael_11858/amazon-ebay-nasdaq-on-a-blockchain-ed56383c0626?source=friends_link&sk=a8614e427c68a6a98370e1cc4c0f458d.