Counterstake: A Truly Decentralized Cross-Chain Bridge

Today we are launching a bridge that will connect Obyte with other networks and enrich Obyte’s trading environment with a huge number of tokens imported from other chains.

Unlike other cross-chain bridges, the Counterstake bridge is truly decentralized and universal at the same time. Decentralization means that user funds are protected from theft by hackers and insiders, the bridge cannot be shutdown or restricted, and any tokens can be transferred over the bridge in a permissionless manner.

Initially, the bridge connects 3 networks: Obyte, Ethereum, and Binance Smart Chain, but can be implemented for other programmable chains as well. EVM-based chains can be added with minimal effort.

Interoperability is on the rise

It is certain that there will be many different chains optimized for different use cases and the value needs to be transferred between them in a safe and easy way.

There is already proven and rapidly growing demand for interoperability solutions. The amount of tokens transferred over the Binance Bridge alone is currently over $13b (source) while on Jan 1, 2021 it was about $0.5b — roughly 25x growth.

However the existing solutions are either overly centralized or support a rather small subset of chains.

Counterstake: decentralized and universal

This is how Counterstake is positioned against other interoperability solutions:

Counterstake is absolutely decentralized and is one of the most universal cross-chain bridges.

Decentralization

Centralized vs decentralized is not a black-or-white choice, there are varying degrees of decentralization offered by other protocols. For example, a group of custodians bound by a multisignature scheme (including similar technologies such as threshold signatures and MPC) would be more decentralized than a single custodian. A larger group would be more decentralized than a smaller group. A group that is free to join would be more decentralized than a closed group. Absence of any groups at all is the gold standard of decentralization, which Counterstake meets, as it will be clear from the protocol description below.

We care about decentralization not for the sake of decentralization but because it allows us to reduce risks of theft (by hackers or insiders), shut-down, censorship, or regulatory takeover. The protocols that are more decentralized:

• better protect the funds of their users,
• are harder to stop,
• are more open to new and small-cap coins,
• are less likely to censor specific transfers, users, or coins,
• and are less vulnerable to regulatory interference such as requirement of KYC and other requirements that might cause friction or infringe on privacy.

Universality

Counterstake supports all tokens on all supported chains without any approvals or whitelistings. That’s thousands of tokens. Implementations currently exist for Obyte tokens and ERC20 tokens on EVM-based chains (Ethereum, BSC, etc). Other chains that support programmable agents (autonomous agents, smart contracts, chaincode) can be easily added along with their respective tokens.

Some other protocols require custom implementations for each direction of transfer, thus making it N² amount of work to support N chains. Counterstake requires only a one-time implementation on each supported chain to be connected to all existing and future chains.

We care about universality because it allows us to easily reuse knowledge and experience among various tokens and networks. For developers, universality means that the same APIs work across many tokens and networks.

Three types of cross-chain bridges

All existing cross-chain bridges can be roughly classified into 3 classes:

1. clique based: cross-chain transfers are to be approved by a small group of custodians, signers, multi-sig participants, threshold signature members, or participants of multi-party computation (MPC). This includes the case when the clique consists of a single signer/custodian.
2. light client based: they attempt to implement a light client of the foreign chain in order to verify the transactions happening on the foreign chain.
3. based on economic incentives, or in simpler words, greed-based: they offer economic incentives for the correct behavior while transferring coins from one chain to another, and punish for misbehavior. In spirit, these designs are the closest to how the cryptocurrency ledgers themselves are designed (such as mining on the longest chain is expected to be more profitable than mining a double-spend).

Clique-based bridges

All clique-based bridges are invariably centralized and the degree of centralization depends on the size of the clique.

Binance Bridge is an example of a bridge with a single custodian who has outsized control over everything and is a single point of failure. All the funds transferred to foreign chains are stored on an account on the home chain controlled by the central custodian. Imported coins on the foreign chains are again issued by a single account. Any compromise of these accounts (including that by insiders) would be disastrous for the health of the bridge: funds stored on the home chain could be stolen, or the account on the foreign chain could issue an unlimited number of unbacked tokens.

Various multisig schemes (including threshold signatures and MPC) mitigate the risks. Anyswap, ChainBridge, Wrapped BTC, and Liquid are examples of such bridges controlled by several trusted parties. However, collusion or compromise of a majority of signers is still a possibility when large amounts of money are at stake.

Another important factor is that by transferring money from account to account, the bridge operators (clique members) become a money services business (MSB), and this kind of activity is heavily regulated in many jurisdictions. They might fly under the radar for now, but the threat of regulatory interference exists, and it is easy to identify those who control the bridge.

Clique-based bridges are technically the most universal as they don’t require the connected chains to have any features apart from the basic money transfer function. However, in practice, the bridge operators only support the chains and tokens they want to support, and adding a new chain or token requires their approval, similar to listing on centralized exchanges. Such bridges are definitely not open, not permissionless.

Light client based bridges

Light client based bridges verify the transfers initiated from the other chain by implementing a light client of that chain on the destination chain. For example, when you transfer 100 units of token T from chain A to chain B, you have to submit a proof that the transfer did take place on chain A. You submit the proof to a programmable agent on the destination chain B who verifies the proof and issues 100 units of TB — the token’s representation on chain B. The proof is the same proof that light clients use to verify that a transaction was actually included in the ledger of chain A. Therefore, such bridges work with light client security.

There are no central parties in such bridges. There might be central parties in the participating chains, e.g. miners / block producers when the chains are blockchains, but the bridge doesn’t weaken the security assumptions of the member chains.

However, an implementation of a light client of a source chain using the programming language of the destination chain is in many cases challenging. It often involves non-trivial logic and sometimes requires re-implementation of cryptography that is not natively supported on the destination chain. For this reason, light client based bridges between some networks become either impossible or cost-prohibitive.

In addition, a custom implementation is required for each pair of chains, for each direction, which makes it N² amount of work to support N chains. Therefore, this approach is difficult to scale.

Cosmos and Polkadot use such bridges to connect the chains that were specifically developed to work within their interchain infrastructure. PolyBridge connects heterogeneous networks but to address the scalability problem, they do so through a central relay chain, which reintroduces the risks found in clique-based bridges.

Light client based bridges certainly cannot support Bitcoin and other older chains with poor programming capabilities. Hybrid solutions that include elements of clique based bridges address this problem — at the expense of greater centralization and the risks it introduces.

Bridges based on economic incentives

Bridges based on economic incentives ensure the security of cross-chain transfers by rewarding the correct behavior and punishing fraudulent activity. Some participants need to lock their money and they stand to lose this money if they attempt to execute a transfer that didn’t exist, or if they attempt to steal users’ funds.

XClaim is one such protocol, and Interlay implemented it to connect Polkadot and BTC (PolkaBTC). The protocol is decentralized but requires vault-keepers to deposit collateral in excess of all the BTC stored in vaults and transferred to Polkadot. The collateral needs to stay there all the time while BTC lives on the foreign chain (such as 1.5 BTC worth of DOT collateral for 1 BTC traveling in Polkadot). If a vault-keeper tries to steal BTC from their vault, the collateral would be confiscated, and they would lose more than they gain.

However, the high collateral requirements might make the vault-keepers charge high fees to get an adequate return on their capital, and the protocol is unlikely to stay competitive without a subsidy.

TBTC is another bridge based on economic incentives. It imports BTC to Ethereum and also requires 150% overcollateralization of all BTC circulating in Ethereum. Again, capital efficiency is an issue that hurts the bridge’s competitiveness.

Counterstake bridge

Counterstake is a decentralized and universal bridge based on economic incentives. However it is much more capital efficient than other bridges based on economic incentives.

Let’s say we want to transfer some amount of token T from its home chain A to a foreign chain B, e.g. we want to transfer 1 ETH from Ethereum to Obyte.

As the first step, we send the tokens to a programmable agent on chain A to lock them there. Programmable agents are known by different names on different chains: autonomous agents on Obyte, smart contracts on Ethereum, chaincode on Hyperledger Fabric. That’s the only requirement to the supported chains: they should support programmable agents — programmable entities that have their own agency independent of their creators and can hold coins, governed by code.

Next, we claim the token’s representation on chain B by requesting another programmable agent, this time an agent on chain B, to issue the imported tokens TB for us. To prove that our claim is legitimate, we also put up a stake in chain B’s native tokens. The stake’s value is equal to the value of the imported tokens according to the current exchange rate. We’ll get our stake back if our claim is legitimate indeed, or will lose it if the claim proves to be fraudulent.

This claim starts a challenging period. During this period, anyone can challenge our claim by counter-staking 1.5 times (or another configured factor) the amount of the original stake if they think that the claim is fraudulent. The challengers are staking on the “No” outcome of the claim. If they are right and the original claim was fraudulent indeed, they stand to win the original stake from us — a 66.7% ROI. The counterstakes can come from many users while each user’s contribution can be small, only the total needs to be 1.5 times larger than the original stake.

The counterstake, if it happens, starts another challenging period, which is longer than the first one. During this period, anyone can support our original claim with their counterstakes if they believe that it was legitimate and the first challenge was fraudulent. As soon as the total staked in favor of “Yes” reaches 1.5 times the total staked in favor of “No”, “Yes” becomes the current outcome again and another challenging period starts.

This pendulum can continue for several periods until a challenging period expires without the opposing side overturning the current outcome. Then, all the staked money is distributed among those who staked on the winning outcome. If the winning outcome is “Yes”, we also get our imported tokens, which are issued for us on the foreign chain.

In practice however, most claims will end after one period because there is objective truth that anyone who follows both the home and foreign chains can easily see. The truthful outcome is also the Schelling point, and the community will quickly converge on the true outcome because everyone expects everyone else to stake on the true outcome. Even if a whale tries to repeatedly stake on the false outcome, the increasing length of the challenging periods will give the community ample time to mobilize and outweigh the whale’s stake with the sum of many honest counterstakes.

This process of exporting tokens from their home chain and getting the same amount of newly issued imported tokens on the foreign chain is called expatriation. The imported token, such as GBYTE on Ethereum or ETH on Obyte, naturally represents the original token on the foreign chain. After using the imported tokens on the foreign chain, the same or another user can repatriate them back to the home chain by following a similar procedure:

1. burning the imported tokens on the foreign chain by sending them back to the programmable agent they were issued from,
2. claiming the burned amount on the home chain using the programmable agent where the original tokens were locked,
3. unlocking the previously locked tokens on the home chain if the claim succeeds.

As long as the protocol works correctly and its watchdogs successfully challenge all fraudulent claims, the total amount of the imported tokens issued on the foreign chain exactly matches the total amount of the exported tokens locked on its home chain. Its total circulating supply stays the same, just part of the coins “travel” in foreign chains.

Assistants

The described process might take rather long time as the sending user has to wait for at least one challenging period, and the period has to be long enough to give the challengers enough time to counterstake on fraudulent claims. The first challenging period is 3 days by default.

However, assistants can accelerate the process for users by claiming the transfers for them and immediately paying the claimed coins to the user, less a reward to the assistant. The assistant will then wait for the challenging period to expire, defend the claim if necessary, and withdraw the claimed coins with profit. When sending a transfer, users indicate the reward they are prepared to pay to an assistant who picks their transfer. The reward should be large enough to cover the network fees on the destination chain and make a profit for the assistant that is adequate to the risk the assistant takes and the capital they lock in claims. What the assistants are doing is lending tokens to users for the duration of the challenging period, the loan being collateralized by the ongoing transfer.

Assistants can be either solo assistants or pooled ones that pool the capital from several investors and are operated by a manager who earns a management fee and a success fee from generated profits. Pooled assistants are more likely to process large transfers. Assistants usually double as watchdogs and can challenge fraudulent claims as well as help users accelerate their transfers.

Governance

All parameters mentioned above are just examples and they can be adjusted by governance. For example, the governance can:

• change the stake growth factor for the consecutive challenging periods from 1.5 to any other value (above 1, of course, as the target stake should grow between challenging periods).
• change the value of the initial stake from being exactly equal to the claimed amount to 1.2x claimed amount, or 0.8x, or whatever they like.
• change the challenging periods for both regular and large transfers. By default, for regular transfers, the first challenging period is 3 days, the second is 7 days, then 30 days, and 60 days. For large transfers, above some threshold, the first challenging period is 7 days to give the watchdogs more time to collect the amount required to challenge a large transfer.
• change the threshold above which a transfer is deemed large.
• change the minimum stake.
• change the price oracle used when the transferred and staked currency are not the same.
• change the minimum price accepted from the oracle.

There are two programmable agents on each bridge:

• export agent on the home chain: it is responsible for
  - locking funds during expatriation
  - claims to unlock funds during repatriation;
• import agent on the foreign chain: it is responsible for
  - claims for issue during expatriation
  - burning during repatriation;

Both agents have their own governance modules. To govern the parameters of the export agent, all holders of the token being exported can vote. To govern the parameters of the import agent, all holders of the staking token (which is by default the native token of the foreign chain) can vote.

We use challenger voting, the same as in bonded stablecoins, it doesn’t require any quorums and allows the active participants to make decisions quickly.

Capital efficiency and costs

Counterstake is much more capital efficient than earlier protocols based on economic incentives. The funds need to be locked only during transfer for 3 days (the challenging period) while in protocols like XClaim, collateral needs to be held for the full amount of tokens traveling in a foreign chain.

Higher capital efficiency means that the fees for transfers are lower.

However, compared with clique-based and light-client-based bridges, Counterstake requires locking capital for the duration of the challenging period, and therefore is less capital efficient. Because of time value of money, this means higher cost of transfers. That’s the price we have to pay for better security and permissionlessness guarantees compared with click-based bridges and better universality compared with light-client-based bridges.

The risks and security analysis

It follows from the above description that protocol participants have selfish economic interest in ensuring the correct operation of the protocol, i.e. supporting legitimate claims and attacking fraudulent ones.

Since the protocol is decentralized, all the major risks — that come from centralization — are eliminated. That is, the protocol cannot be stopped, cannot be restricted, transfers cannot be censored, and user funds cannot be stolen.

However there are other risks users should be aware of.

Bugs

As usual for programmable money, bugs in the programmable agents are possible, and should they be discovered, they are hard to recover since the agents are fully autonomous. However, we did our best to keep the implementation as simple as possible in order to minimize the probability of errors.

Price oracle

The only centralized element the protocol relies upon is the oracle that reports the price between the transferred token and the token used for stakes — if the tokens are not the same, which is the case for expatriations but not repatriations. The worst that can happen is that the oracle reports zero (or very low) price, and the required stake will therefore become also zero (or very low) and make counterstaking unprofitable. The risk is mitigated in 3 ways:

• governance can change the oracle if there are doubts about reliability of the current one or simply a better one is available. Governance can also choose an oracle that programmatically aggregates data from several oracles (like Chainlink does), so it can fail only when a majority of them collude. Governance can also choose a decentralized oracle based on Counterstake protocol for oracles (see below). A Counterstake-based oracle would be slow but we don’t really need real-time accurate rates. The bridge would be still safe even if the oracle price is off by 50% — you still need to put up a stake with every claim and you’ll lose it if the claim is fraudulent. The exact amount of the stake is not important, its loss in case of fraud should be certain and large enough in order to ward off fraud.
• governance can set a minimum price, and if the oracle reports a lower price, the minimum price will be used to determine the stake size. As the price between tokens changes, the governance can adjust the minimum price. This needs to be done only occasionally if the minimum price is set sufficiently low just to prevent obvious manipulation.
• governance can set a minimum stake size. This will also prevent the claims that are so small that a potential profit from counterstaking would be less than the gas cost.

Spam

Another risk is that an attacker submits a fraudulent claim and immediately after that tries to spam the network during the entire challenging period in order to prevent any counterstakes from coming through. That’s why the challenging period should be long enough to make it harder and more expensive for the attacker to keep spamming and give time to the network’s community to counter the attack. Depending on the network’s design, a counterstake submitted during the spam attack may still come with a timestamp when it was submitted, i.e. will still work against the fraudulent claim.

The mob

There is also a risk that a transfer made by a widely unpopular individual or organization can be attacked by the mob (similar to the recent GameStop story) even if it is otherwise legitimate. Pseudonymity of cryptocurrency addresses helps to mitigate the risks by using the addresses that are not known to be linked to the individual or organization.

Malicious whale

As mentioned above, a whale can try to attack a legitimate claim in order to seize the stake submitted with it. Progressively increasing challenging periods give the honest community time to mobilize their counterstakes against the whale. It’s important that the total stake in favor of Yes or No can grow only 1.5x relative to the previous period. Therefore, the malicious whale cannot throw their entire weight against the legitimate claim in the first challenging period. They can only counterstake a relatively small amount in the first period, which triggers a longer second period when the community responds, then the whale can top up their stake in the 3rd period, which triggers an even longer 4th period for the community to respond, and so on. The whale can win the game if they hold 40% of the total circulating supply of the token used for staking (assuming 1.5x growth of stake in subsequent challenging periods), but this token must be already in bad shape if it is the case, and the whale’s actions are likely to further destroy its value.

User error

One more factor that can be considered a risk is that the protocol is very strict and not tolerant to user error. When claiming a transfer, the claiming transaction should accurately cite the parameters of the original transfer. Any mistake will result in the claim being challenged and losing one’s stake. One potential source of errors is the fact that tokens of home and foreign chains can have different precision, i.e. different numbers of decimals. For example, ETH on Ethereum has 18 decimals but its imported token on Obyte might have only 8 decimals for example (amounts in Obyte can have only up to 16 digits). The claim must indicate the same amount in ETH, not wei. Therefore, a transfer with excessive precision, e.g. 0.200000001 ETH cannot be claimed in Obyte as this number cannot be exactly represented with 8 decimal places accuracy, and such transfer, if sent, will be lost.

Reorgs

The last risk that ought to be mentioned is the risk of chain reorganization that removes (or changes some important parameters of) the original transfer. The risk exists for rewritable blockchains, i.e. those without deterministic finality. If this happens, the claim becomes invalid as it no longer exactly matches the original transfer, and can be successfully challenged. To mitigate the risk, users (usually assistants) need to wait long enough to ensure that the risk of reorg is minimal, and send a claim only after that.

Counterstake protocol for decentralized oracles

In fact, we developed the Counterstake protocol for decentralized oracles first, before applying it to cross-chain bridges now. There is a website for setting up and submitting data to decentralized oracles that we developed but haven’t launched yet.

The main working principle is the same: anyone can submit a value that they want the oracle to post, they also put up a stake to back their claim that the value is true. This starts a challenging period during which anybody can challenge the claim and put up a counterstake that exceeds the original stake by a factor of 1.5 (or another configurable factor). The counterstake, if it happens, starts another challenging period, and so on. The process stops when any period expires without overturning the current outcome. All stakes are split among the winners, and if the outcome is Yes, the oracle posts the proposed value.

The decentralized oracle protocol was largely inspired by Augur’s similar protocol.

We didn’t launch the protocol for oracles but decided to switch to its application for cross-chain bridges as interoperability seems like a more pressing issue now.

Transferring of data

So far, we discussed transfer of tokens only, fungible tokens to be exact. However, the Counterstake protocol also allows transferring arbitrary data along with a token. The data just needs to be indicated in the claiming transaction and exactly match the data sent in the original transfer.

The data can be anything, and it will be passed along to the recipient on the destination chain. If the recipient is a programmable agent (autonomous agent on Obyte, smart contract on Ethereum, chaincode on Hyperledger Fabric), it can act upon this data. Thus, one can send money to a programmable agent on the destination chain, the agent will be called, and the call will be parameterized with data.

This means that one can send tokens for example from Obyte to Uniswap on Ethereum, and have Uniswap swap the tokens and send the output tokens somewhere else. It can send them, for example, to another bridge (created for the transfer of the output tokens) that would then forward the tokens back to Obyte, to the original sending address. Thus, one can use Uniswap on Ethereum from Obyte, without having an account on Ethereum. The same works in the reverse direction: one can use Oswap on Obyte from Ethereum without having an account on Obyte.

What’s important, assistants can help to process transfers with data the same way they work with transfers without data, therefore such cross-chain calls can be reasonably fast. The delays are only due to confirmation times on both chains.

One can also transfer data without any amounts, or transfer non-fungible tokens, but one needs to modify the protocol slightly to assign a monetary value to the data being transferred and choose a token to be used for staking.

For example, if one assigns a $100 value to each data point posted by an oracle, then oracle data can be transferred chain-to-chain, and the initial stake when trying to receive that data on the destination chain will be $100. If there is a group of NFTs, each valued between $100 and $1000, an initial stake of $500 will do the job. It is ok that the initial stake is smaller than the item’s real value — if the claim is fraudulent and the value is large enough, it will be challenged and the total stake amount can grow in several challenging periods.

For non-fungibles, assistants cannot help as no second token exists that could be used to pay to the recipient immediately after claiming. The recipient has to wait a full challenging period.

Counterstake token

The protocol doesn’t require any new token to operate. However, to enable investors to bet on the success of the protocol, we are going to launch a token whose price will depend on the protocol’s adoption. The token will work without interfering with the protocol, without causing any friction for the protocol’s users.

The token’s supply will automatically decrease as the total dollar amount of all tokens traveling in foreign chains increases, the supply will decrease faster as more tokens travel. The exact details of the token design will be decided upon in the coming months. Subscribe to the project’s newsletter on the CS token page to get updates about the token.

Launch

The bridge is already online at counterstake.org. Initially, it supports Obyte, Ethereum, and Binance Smart Chain and their respective fungible tokens: native tokens on Obyte, ERC20 on Ethereum, and BEP20 on BSC. Bridges for GBYTE, ETH, BNB, OUSDV2, USDC, BUSD, and WBTC are already up. One assistant is online and charged with some coins.

Next, to ensure frictionless movement of coins between chains, we definitely need competition among assistants and more capital in assistants. The code for assistant bots and instructions are published on our github.

The UI will initially set the assistant reward to 1% of the transferred amount. If that’s not enough to attract more assistant bots, we’ll increase the reward. As soon as we have enough competition among assistants, we’ll decrease the reward to make it more attractive to users, while making sure that the assistant ROI stays high enough so that they continue running.

With the bridge, we hope to achieve several goals:

• enrich the trading environment on Obyte by making the existing tokens easily tradable against other well-known tokens. In particular, the existing stablecoins will become tradable against other stablecoins imported from Ethereum, such as USDC or WBTC, and tokens they are pegged to, such as ETH. This will create more arbitrage opportunities as all these coins constantly move against each other in multiple pairings, and will make Obyte more interesting for traders.
• create more connections between GBYTE and the outside world in addition to those we already have through centralized exchanges. It will become easier to enter and exit the ecosystem through Ethereum and BSC by:
  - transferring the most popular coins on these networks to Obyte and trading them here, e.g. on Oswap. In particular, trading pairs GBYTE/WBTC and GBYTE/USDC will be easy to arbitrage against centralized exchanges, and low fees encourage frequent trading (hence high volumes and more fees for liquidity providers).
  - transferring GBYTE and other Obyte tokens to Ethereum and BSC, and trading them on Uniswap, PancakeSwap, and other decentralized exchanges on these networks. This makes the tokens easily available to more traders, who might want to transfer them back to Obyte, e.g. to take advantage of the staking feature of v2 bonded stablecoins. GBYTE/WBTC and GBYTE/USDC pairs will also be easy to arbitrage against centralized exchanges.

To bootstrap liquidity in the most important trading pairs, we’ll add them to the existing liquidity mining program with 300% weights. The eligible pools will be:

• GBYTE-USDC
• GBYTE-WBTC
• GBYTE-ETH
• OUSDV2-USDC
• OBITV2-WBTC
• OETHV2-ETH

Now, head to counterstake.org and try out your first cross-chain transfer through Counterstake protocol. Remember, this is a new thing and you are likely to encounter various bugs, so start with small amounts. To get updates about the future CS token release, subscribe to the protocol’s newsletter at counterstake.org/cs-token.