Introducing Kosu

An experimental decentralized liquidity aggregation network.

Paradigm Labs is excited to formally announce Kosu. Kosu is an experimental decentralized liquidity aggregation network built on Ethereum and Tendermint.

Initially conceived over a year ago as the Paradigm Protocol, Kosu gets its new name from the Japanese word “Kosu (濾す),” meaning “filter” which we equate to the mechanisms it introduces for aggregating and filtering liquidity.

Kosu aims to provide a piece of critical liquidity infrastructure for building access-prioritizing decentralized exchanges that use non-custodial settlement systems such as 0x.

What is Kosu?

Kosu can be thought of as a decentralized relayer: a blockchain-based network that provides incentives both for high-quality liquidity and high-quality network operators.

For those not familiar with decentralized exchanges (DEXs) and the problem space from which Kosu emerges, its one-sentence description as a liquidity aggregation network likely does little to communicate its purpose, construction, or intended users.

To understand Kosu, one must first become familiar with a few important concepts. This section will attempt to explain Kosu, assuming only basic knowledge of Ethereum, Ethereum-based assets/applications, and Tendermint (a proof-of-stake BFT consensus protocol and framework for building blockchains).

The world of decentralized exchange

“Decentralized Exchanges (sometimes referred to as ‘non-custodial exchanges’) allow for the trading of crypto assets without the need for a trusted central authority.” (EthHub)

In a broad sense, all types of decentralized exchanges serve the the same fundamental purpose: provide settlement functionality for digital assets through smart-contracts. Such exchanges contrast sharply with conventional off-chain asset settlement systems which require (often many) central operators and third-parties that increase transaction costs and add custodial risk for traders.

Within the relatively new world of decentralized exchanges, multiple design patterns have emerged. For simplicity, here we will only discuss developments within the Ethereum DEX space, which is by far the most mature with regards to asset availability, liquidity, and DEX design experimentation.

In today’s DEX ecosystem, the vast majority of trading volume takes place on exchanges that fit into two categories: on-chain (Uniswap, Kyber, etc.) and “hybrid” (primarily 0x and forks), where hybrid means settlement occurs on-chain in smart-contracts, while order messages from makers are broadcast and discovered off-chain.

Both architectures make design trade-offs and generally offer advantages to distinct types of traders. On-chain exchanges tend to leverage liquidity pools and/or automated market makers, thus excelling at providing constant liquidity, at the expense of high-slippage for large trades and limited price-responsiveness. Hybrid decentralized exchanges that leverage systems like 0x for settlement open the door for more flexibility in market structure, and can provide a more traditional experience for market makers who are familiar with maker/taker markets and limit order books, concepts which are still highly relevant in the 0x protocol.

Even within the 0x ecosystem, there are multiple types of market constructions. Most traders within the 0x ecosystem use an entity called a “relayer” to trade. The relayer provides a venue for takers to find and fill orders that have been signed and submitted by makers.

Kosu can be thought of as a decentralized relayer: a blockchain-based network that provides incentives both for high-quality liquidity and high-quality network operators.

Kosu’s role in the liquidity layer

Kosu is specifically designed for building decentralized exchanges that leverage this hybrid model, with on-chain settlement and off-chain order message relay. It is designed to work with the 0x settlement system, and provides a venue for makers to broadcast signed order messages, and for takers to find them. Kosu enforces a strict access control model and proof-of-stake consensus model provided by Tendermint.

Kosu’s liquidity network (the “Kosu network”) uses a blockchain-based architecture supported by a dynamic proof-of-stake validator set. Orders are broadcast as transactions to the network by parties who have bonded tokens (that are not subject to slashing) within the Kosu contract system. Kosu validators maintain a simple access control ruleset, granting network bandwidth for order messages to individuals proportionally, based on the number of tokens they have bonded (locked) in the Kosu PosterRegistry contract at a given time.

What amounts to a decentralized order book is provided by Kosu as its core functionality. Kosu’s order book and relay network is designed to prioritize the following two characteristics.

1. Consistency — the ability of all parties to see the same order messages at the same time (subject to network latency). Validators are, by design, granted an advantage in this regard. This presents a core incentive for validation in a mature network setting.
2. Access — the ability of all parties to guarantee the ability to widely broadcast an order message (for some finite opportunity cost). In addition to read access to the network being unconditionally public, the simple access control and sybil tolerance mechanism for write access to the Kosu order book ensures that at any time, there is some reasonable cost of posting one order (per rebalance period).

Kosu ensures consistency by ensuring strict ordering to order messages (that are organized in blocks by validators) and access (via a token-based bandwidth model enforced at the consensus layer). These design choices sacrifice comparatively higher speeds and throughput offered by alternative network architectures by using a consensus layer.

We believe different market characteristics (provided by their underlying infrastructure) are desirable for certain market and trader types. Kosu favors markets and market participants that prioritize access and decentralization over price and the ability to participate in high-speed trading. Additionally, the token bond-based access control mechanism implicitly incentivizes the contribution of “high-quality” liquidity, by forcing market participants to be exposed to price movements of KOSU while they contribute to the network.

Kosu ensures that all network participants see the same orders at (roughly) the same time, and offer stricter guarantees about what percentage of the network will see a given order. These characteristics complement advantages provided by other decentralized liquidity networks, such as 0x Mesh, that may afford traders higher speeds, but offer less strict guarantees about who will see the order or when.

In short, Kosu will perform best for traders and markets that prioritize access over price (including markets for uncommon financial instruments or assets). Alternative market and network designs will offer contrasting advantages for different market and trader types.

We believe Kosu’s unique advantages will allow it to play a distinct and important role in the diverse and evolving decentralized liquidity layer.

Read a more in-depth and technical introduction to Kosu here.

Experimental liquidity network

Several novel and experimental mechanisms are introduced in Kosu’s design, such as a continuous token-distribution model with an Ether-backed network access token, and a network validator selection mechanism where token-holding voters determine the active validator set at any given time.

Continuous liquidity bonding curve

Kosu uses an ERC-20 token (KOSU) to economically coordinate the network’s stakeholders, and to provide governance (validation curation) and access control functionality.

Instead of distributing KOSU through an ICO (initial coin offering) or other type of public/private sale, the token’s contract will provide the ability to buy and sell KOSU with Ether (ETH), by interacting with the deployed contract directly.

The contract will be deployed alongside the rest of Kosu’s core contract system, at which point anyone will be able to send ETH to the contract to buy KOSU. The price is deterministically calculated with a bonding curve, based on parameters such as the amount of ETH collateral in the contract, and the outstanding supply of KOSU.

Validator token-curated registry

A challenge for networks designed to use proof-of-stake based consensus mechanisms over proof-of-work mechanisms is the added requirement to select and manage a validator set. There are several functioning or planned solutions to this problem, such as mechanisms used by Ethereum 2.0, Cosmos, and others.

Kosu introduces an alternative and experimental mechanism to curate a set of validators on a Tendermint BFT network through an Ethereum-based token-curated registry (TCR). The mechanism described below allows Kosu to have a dynamic validator set, a market-driven reward schedule for validators, ultimately allowing token-holding voters to determine the network-wide inflation rate.

The TCR used in Kosu, called the ValidatorRegistry allows anyone to submit a proposal — an application to join the validator set. To do so, the applicant submits an Ethereum transaction, including parameters such as the number of tokens at stake, their reward rate (denominated in ETH, but paid in inflationary-minted KOSU via the bonding curve), and their desired voting power on the network.

Other token holders are tasked with judging the applicant based on the parameters of their listing: how much they wish to inflate the KOSU supply for their services, the amount of power they will receive on the network, and other social proofs (websites, announcements, etc.) linked through metadata included in the application.

If a token holder deems an application to be fraudulent, malicious, or otherwise undesirable (requiring a fee that is too high, requesting too much power, etc.), they may challenge the applicant within a period of time prior to the applicant becoming a validator.

The challenge results in an open vote in which any token holder may participate by committing and revealing token-weighted votes. The challenge resolves in favor of either the listing owner (applicant) or the challenger, based on simple majority-rules and the loser’s staked tokens are distributed to the winning challenger and voters.

Read a more in-depth and technical overview of Kosu’s validator selection mechanics here.

Ethereum peg-zone

Kosu’s validator-selection mechanism takes place on Ethereum, a sovereign blockchain distinct from the one maintained by the validators selected in the registry. To enable such a construct, Kosu introduces a “peg-zone” mechanism that is responsible for securely applying state changes from Kosu’s Ethereum contract system to the Tendermint network’s state.

Such a mechanism was initially described and specified by core team members of Cosmos and Tendermint, who described a two-way peg-zone mechanism called Peggy, which leveraged Tendermint’s strict finality guarantees over Ethereum’s probabilistic proof-of-work finality (re-orgs become less likely as distance from the chain head increases) to provide token transfers between an ERC-20 token and a representation on a distinct Tendermint-based chain.

Kosu adapts and simplifies this mechanism to create a one-way peg zone between Kosu’s Ethereum contract system, and the Tendermint-based network. This peg-zone does not allow KOSU to be transacted on the Tendermint network, instead allowing Kosu validators to maintain up-to-date representations of relevant components of the contract system’s state, such as the balances of bonded posters (submitting orders to the network) or the list of current validators.

In simplest terms, the Kosu peg-zone works by requiring active validators to submit special “attestation” messages — signed transactions that attest to a specific event log occurring at a specific Ethereum block height. Since all validators see the same state from the Ethereum contract system, all non-byzantine validators will be able to submit attestations to the same state changes. When sufficient validating vote power has attested to a given contract sate change (new validator, removed validator, etc.), the counterpart sate modification can be made to the network’s state.

This process happens on a delay called the “finality threshold,” a number of Ethereum blocks that must be mined “over” an event before it’s state change can be applied on Kosu. In other words, Ethereum transactions that affect change to the Kosu network must be sufficiently old to ensure they will not be reverted or introduced in a different order due to a block reorganization of the Ethereum blockchain.

More information about his process can be found in the Kosu whitepaper, and at the following links:

• A description of the foundational role Ethereum plays in Kosu.
• A GitHub issue regarding the power-weighted confirmation threshold.
• Another issue regarding attestation functionality in the Go network client.

Current status

Kosu is a stable beta, but not yet ready for a main-network launch.

First and foremost, it is important to emphasize the experimental nature of Kosu. Kosu introduces several untested mechanisms that must be viewed as experiments that may work to produce an extremely useful system, but may also fail due to any number of reasons when tested in battle-like conditions of a main-network.

Kosu is a stable beta, but not yet ready for a main-network launch. It is ready for public examination and testing; we want to orient people with Kosu, and help demonstrate what it can be used to build.

In the last year, we have built and written:

• A stable contract system in Solidity
• A feature-complete network client in Go (with light-client functionality)
• A set of constantly maturing TypeScript libraries and contract wrappers
• A library and CLI for performing decentralized Kosu network launches
• Documentation for everything

We have also built a suite of user-facing web-interfaces for interacting with the network and contract system (currently only on Ropsten), a lower-level web-interface for developers, and several other utility packages.

Next steps

Prior to a main-network launch, Kosu’s contract system will undergo an external audit and Paradigm Labs will organize a public test-network.

Information about the public test network and the contract audit will be published in later announcements over the coming months.

For now we encourage anyone interested to learn more about Kosu to ask questions and get involved in its development.

Paradigm Labs

Paradigm Labs is the company leading the open-source development of Kosu.

Our mission is to create open and efficient global markets. Kosu is one of our projects aimed at laying a small part of the foundation for this ultimate vision. Read more here.

Follow us here on Medium and on Twitter for more updates about Kosu, as well as other project announcements from Paradigm Labs.

Learn more

• Read technical documentation on the Kosu docs site.
• Read the Kosu whitepaper.
• Check out the code (contracts, client, libraries, etc.) on GitHub.
• View the live test-network.
• Join the discussion on Discord.
• Follow Paradigm Labs on Twitter.
• View Paradigm Lab’s website.
• Reach out to the team directly.