Leverj: An Accounts-Based Plasma Implementation for a Non-Custodial, High-Speed DEX

Blockchain Technology 16 min, 8 sec READ

by Martin Banov

Gluon Plasma is an accounts-based sidechain design implemented by Leverj to facilitate a non-custodial decentralized exchange of Ethereum assets.

One of the most notable developments on the Ethereum front this year has been the Plasma side-chain design space (a second layer scaling solution proposed by Buterin and Joseph Poon and described in more detail in a series of previously published articles). Extended side-chains are based on the logic of disengaging the main-chain and utilizing it only as a sort of supreme court for dispute resolution, minimizing the main-chain footprint and just periodically submitting the state of the Plasma side-chain to the Ethereum main chain as a Merkle root (merklized commitment).

Multiple flavors of Plasma exist, however, most specifications have so far been based on the UTXO coin payments (Unspent Transaction Output) model (OmiseGO's Plasma MVP, Plasma Cash, etc.), which is not ideally suited for applications to do with market making and efficient industry-grade exchange. The reasoning in Plasma side-chain designs is such though that each side-chain is modeled to fulfill the desired properties for its concrete use-case and application. 

The Troubles with Centralized and Decentralized Exchanges

Among the most immediate and persistent problems haunting the crypto-assets and crypto-currencies that fuel distributed economies are the fact that market exchange takes place on unregulated, centralized exchanges and the associated problems and risks that carries with it. (This problem goes all the way back to Mt.Gox, which was originally a site for trading Magic: The Gathering cards -- hence the name -- and which had been slapped together as a BTC exchange in PHP almost overnight). This is not to mention, of course, the fact that trading the value of decentralized systems on centralized exchanges with repeatedly proven poor track records largely defeats the intention behind building and populating them in the first place. Yet, despite all this, people continue to use these exchanges because they're fast, responsible, and efficient. 

Decentralized exchanges, on the other hand, are costly, slow, impractical, and much more complicated and less user-friendly than centralized exchanges. While they offer superior security, they are still unable to handle high-volumes of trading and are overall not adequately suitable for supporting profitable trading activity (after all the on-chain fees, unpredictable fluctuations, and uncertainty, etc.). This goes on to yet again illustrate the trade-offs of centralized vs. decentralized system architectures. Centralized structures are extremely fast, efficient, easy to use. They conveniently and quickly deliver a service without much hassle, but are proportionately insecure (in more than one way) and constitute a single point of failure. The more funds a centrally operated exchange holds in its custody, the more the associated risks go up.

Systems running as decentralized monolithic hashchain records massively replicated among all network peers seem to, on the other hand, go to the spectrum of the other extreme and sacrifice almost everything else in favor of cumbersome and heavyweight security (with the recording of transactions sometimes seeming to cause detectable disturbances and interruptions in their surrounding areas, as well as reported cases of interfering with wireless LTE spectrums) - so, a balance between those two obviously unsustainable extremes must be realistically possible. 

Enter Gluon

Gluon is one such new Plasma design implementation specifically built for non-custodial, high-speed, low-latency trading that strikes that balance between decentralizing the security-critical components and maintaining relatively centralized operator control over the elements that make an exchange efficient (i.e., fast and reliable order matching without gas fees for every step on-chain). Unlike previous Plasma specifications, Gluon is an accounts/balances based ledger (not a UTXO/coins one) modelled so as to satisfy a number of important security constraints of how activity gets channeled and coordinated. The recording of events and sequence of how they're ordered and finalized defines a regime of data coordination such that it allows users to exercise direct agency over the custody of their assets, insulating their asset flows within the constraint of their associated account address of provable ownership, clearly defined roles, protocols, and procedures and implementing of zero-knowledge schemes for client-side authentication (among other things). 

The Plasma Design Space

The general outline of the Plasma design so far is such that a child-chain (or side-chain, or an extended tree of side-chains) is anchored to a root chain (via an interfacing on-chain contract). A deposit on the main-chain/root-chain creates a UTXO in the side-chain (a withdrawal pulls it out of circulation from the plasma chain and back into the main chain). State changes in the side-chain are periodically submitted to the root-chain as block headers (Merkle roots) which contain the sufficient information required to prove the correctness of state transitions in a condensed form. Incorrect state transitions are rolled back using fraud-proofs and the order of how exit procedures take place is prioritized by earlier side-chain blocks. A Plasma chain is usually a Proof of Authority chain managed by an operator under specific design constraints.

Most Plasma designs, as already noted, are UTXO-based ledgers - a UTXO is a transaction output that can be legitimately spent as input in a new transaction. A UTXO ledger deals with registering and keeping track only of UTXO units - Plasma MVP checks transaction orderings, rather than state transitions. Plasma Cash, on the other hand, creates a coin on the side-chain with the denomination of what has been deposited - it is non-fungible in that one cannot merge (or split) coins to get a coin of the total value. 

All transactions on the Plasma side-chain are hashed along the Merkle tree and the resulting Merkle root (also known as block header) is submitted on the main chain. The rationale is such that it allows for running specific applications as separate Plasma chains, allowing for much flexibility in how they could be optimized and set up while still inheriting the security properties of the main chain. 

Gluon Plasma: An Accounts-Based Plasma Variant for Non-Custodial Exchanges

Gluon is a Plasma side-chain specification for a hybrid exchange customized for non-custodial, low-latency trade at high speed. Users trading on unregulated centralized exchanges, as said in the beginning, compromise by tolerating significant custodial risks for the benefit of speed and low latency, while at the same time it is obvious that one cannot have an equally efficient, usable decentralized exchange fully on-chain, given the intensity of how these records are secured on a proof-of-work chain, which seems to contradict the second-splitting velocities of cent-scalping trades executed in large numbers that generally characterize the nature of activity taking place on most industrial grade trading platforms. Gluon seems like an important step in advancing Ethereum-based fintech applications that could introduce substantial re-arrangements to how operations have so far been usually carried out in the crypto-currency scene.

Gluon Plasma provides an equally efficient decentralized solution without the associated custodial risks of centralized exchanges, a side-chain specifically geared towards trading rather than UTXO payments which keeps safety and security critical functions (i.e., custody of funds) decentralized while maintaining the high speed of centralized order matching in the hands of the side-chain operator (who runs the order book). This is not unlike the approach taken by another similar fintech/financially oriented undertaking, namely the Waves platform, although the latter is perhaps less successful for the time being due to the fact that it  runs on its own custom-built Scala-based blockchain and, therefore, does not take advantage of the Ethereum network's effects, ecosystem, and large, active community. Instead, Waves has distanced itself as a stand-alone application that is still some distance away from services it doesn't natively support and from executing cross-platform operations.  

Gluon instead applies similar reasoning in the Plasma context and introduces an accounts-based spec capable of dealing with states and state transitions as defined by the data storage and coordination implied in the model and ledger structure. The paper describing the properties of the model lists four defining constraints that need to be satisfied for a system of the sort to provide the necessary degree of trustlessness:

• Segregation: A direct corridor of owner custody (account address) for asset flows (i.e., coins, tokens).

• Agency: Asset possession and ownership can only be altered with the provable and authorized intention (signing and/or counter-signing) of the owner of that asset.

• Solvency: Only legitimately created and previously unspent assets can be spent.

• Integrity: Asset movements should comply with all network consensus rules.

The on-chain plasma contract serves as the anchored interface for assets between the main chain and their entry point into the side-chain cluster. (The external address depositing funds can serve as the account identifier enforcing the Segregation and Agency). Visualized as a graph, asset-holding entities are accounts (nodes) whose possible movements are directed edges (pointing arrows) constrained by the above four criteria.

The contract also accepts fraud-proofs and enforces correctness: any submitted proof of operator misconduct or compromise results in instant automatic suspension of side-chain operation and enables fund withdrawals. Data unavailability is similarly addressed and enforced by the on-chain contract. Asset transfers between users on the side-chain require matching signed orders of the users, counter-signed by the side-chain operator. 

Gluon Ledger Specifics

The side-chain state is maintained on its own ledger with every state change resulting in a new ledger entry, signed by the operator and enforcing the above constraints (of Segregation, Agency, Solvency, and Integrity).

Each Merklized main-chain submission of a set of transactions (committed as an ordered Merkle root) is called a Gluon block (or G-block). The last committed G-block is considered unconfirmed and open to challenges from validators until a newer G-block is committed, after which the prior G-block is deemed confirmed, marking a checkpoint and usable for initiating withdrawals. 

Each recorded state change consists of a ledger entry with the following fields: 

There are six listed ledger types: 

• Origin is the initial state, a special entry that records a universal zero balance.
• Deposit and Withdraw entries are levers to the plasma contract for increasing and decreasing balances.

• Exited entry type represents a permanent cessation of all activity for an (Account, Asset) pair, reducing the balance to zero.

• Trade represents a trade of an asset pair between two accounts. 

• Fee denotes the fees paid to the side-chain operator.

Every state transition has sufficient witness data to prove the correctness of the new entry and a link to the prior entry. Gluon is essentially a design that simplifies transactions and proofs to a compact arrangement that allow for seamlessly coordinating exchange.

Leverj: A Gluon Plasma-Based DEX

Leverj is the first implementation of the Gluon Plasma side-chain specification built as a non-custodial exchange for trading ETH, ERC-20's and crypto-derivatives. It centralizes the order book and matching engine components, with the off-chain matching synchronizing with the interfacing smart contract which pairs the accounts in a transaction. In addition to the Gluon Plasma side-chain and the off-chain components (matching engine and order book), Leverj also makes use of a pair of tokens specific to the workings of its platform.

Provided libraries (Python and Node.js) and the platform functionality exposed through the APIs allow for the programming of a wide range of possible tools, scripts, bots, and automated trading strategies. Username and password login and authentication on the platform is replaced with a login-less zero-knowledge authentication scheme using account ID, and an API key associated with a secret.

Signing up and authentication takes place via MetaMask or similar Ethereum wallet implementation. The API key is generated using a web3 library and mapped to its corresponding account via a Registry Smart Contract tracking key ownership and rights.

The key secret is used to sign and confirm identity but is not transferred or stored server-side. After concluding online registration with the exchange, the ZKA is set up and key/secret pair downloaded. This authentication mechanism avoids using session cookies, eliminating a range of possible associated attack vectors.

Platform Tokenomics: LEV & FEE Token Pair Mechanics

Leverj makes use of a token pair - LEV and FEE. LEV works as a kind of license for using the platform and is fixed supply, while FEE is used as a means of accounting and can fluctuate. That way, value is separated from utility (rather than expressed within a single token) so as not to create tension and conflict between the two. Staking LEV (which can also be staked for voting) enables people to trade for free while the revenue generated from trading activity is converted to FEE tokens which so serve as a stable measure for pricing services and its supply naturally adjusting to reflect activity on the platform. This arrangement is intended as a stability mechanism for the platform's economy.  

Derivatives and a Model for a Decentralized Prediction Market (LevPredict)

In addition, a model for a collateralized approach to implementing an events derivatives (or simply betting on outcomes of real-world events) market for binary (either/or) and multi-category types of outcomes has been proposed alongside Gluon. Most are by now at least somewhat familiar with prediction markets, mainly from Augur (Joey Krug, Augur's co-founder has shown significant interest in the Gluon model). 

As a refresher, the concept of prediction markets is such that it takes raw assets representing probabilities of particular events taking place in the future and assumes they are freely traded on an open market (not unlike other derivatives like binary options, futures, insurance, etc.) Given an efficient market functioning as such, available information about assets (or events) is rapidly priced into the value of that asset, which as such represents a reliable, compact economic signal (an Occam razor of sorts) for the said probability of that outcome taking place. 

The LevPredict model for collateralized prediction markets is such that market participants would send ETH to a smart contract programmed to exchange that ETH for whatever amount of ERC-20 shares in a particular bet of an outcome it buys. After event resolution takes place, the holders of the winning outcome get all the ETH locked in the contract distributed among them in proportion to their tokens. 

Not unlike the implementation of CDPs (Collateralized Debt Positions) in MakerDAO - a smart contract locks ETH and gives out an asset actively adjusted against market forces to the US dollar as a soft peg (by the DAO members who themselves bear the risk of exposure should anything go wrong, as such an event would trigger autonomous emergency feedback mechanisms that quickly balance the peg to the losses of MKR token holders that manage the MakerDAO), essentially functioning as a prediction market for how low the price of ETH wouldn't go (if it does, the collateral gets liquidated, or the borrower returns the amount of borrowed USD pegged tokens to unlock back his ETH).

Generalizing the concept for (binary and categorical) prediction market though has interesting implications, as the ERC-20 shares are guaranteed to be covered by the collateralized ETH locked in the contract that generated them. There is no system risk so exchanges can list them without having to worry about Tether-style toxicity when trading in pairs with other exchangeable assets.

The paper presents this solely as financial engineering/a proposed financial instrument - the issues of correctly resolving event outcomes (via reporting, oracles, etc.) isn't discussed in the scope of that, but it is specified that it relates only to binary outcomes (which are mutually exclusive either/or outcomes and thus the least ambigious), which could also be extended to categorical ones (multiple concrete choices, an either/or/or/or...)

This is also understandable, since blockchain-based systems are deterministically tied to the network-wide consensus they operate on - that means that all participants by design agree to having one, single (canonical) view of the ledger and accept it as the only possible valid account of what has ever taken place. If groups of miners disagree on whether some transaction (or sequence of how some transactions are ordered) are valid, the dispute would lead to the system splitting in two versions of the story no longer replicating the same history between each other.

In addition to the proposed model for collateralized event derivatives, Leverj also includes traditional derivatives contracts encoding the business logic and financial engineering necessary for allowing traders of all types to manage their risk. Combined with the Gluon Plasma custody management, this will allow trading of high speed futures contracts using only cryptocurrency as collateral.

Founders and Team

Co-founded by CEO Bharath Rao and CTO Nirmal Gupta, a developer with over a decade of experience in developing Forex trading software. Bharath is also a trader with over a decade of experience and a degree in computer engineering from Syracuse University. Overall, Leverj cultivates a community pulling within its membership high levels of combined expertise in finance, computer engineering, and trading.

Summary and Conclusion

Cryptocurrency exchanges have consistently proven themselves a major liability, if not a gaping hole of systemic risk (and failures with often long-lingering fallout) in these nascent, emerging markets of distributed crypto-economies and novel class assets. The complete lack of regulation, standardization, and oversight coupled with the inherent security risks and the often questionable behavior and tactics that frequently surface underneath badly maintained appearances should by now be enough evidence of just how urgent the necessity to address this issue has grown. 

This is why developments in working out viable decentralized alternatives to centralized exchanges are critically important and Leverj seems to be making steps forward in that very direction, introducing a model for a decentralized trading platform commensurate with the security properties of the systems actually securing the value of their respective assets, rather than delegating custody to yet another third-party that is often not exactly confidence inspiring. 

Leverj is in its endeavor focused on implementing its comprehensive security measures while ensuring the usable, straightforward UX/UI that trading generally requires. Thorough security audits on the contracts will be performed by independent auditors before mainnet deployment. Meanwhile, both the Gluon Plasma chain and LEV/FEE mechanics are live and observable on testnet.

Links and Additional Resources

An Ethresear.ch thread discussion of the Plasma Gluon specification.

Plasma Gluon (specification) paper and documentation on Github (in development, TeX format).

Leverj Decentralized Custody (protocol specification) paper.

Leverj official site, documentation (APIs, etc.) and blog.

Telegram group and Twitter account.