TC x Projects Opium & Celer

TC x Projects Opium & Celer

Hey everyone! :relaxed:

Project Opium and Celer made a collaboration proposal, which consists of two points: the Project Opium Vault (1) and the Celer Asset Bridge (2).
Within a week, I will setup a snapshot for the community to decide whether or not they want to use the multisig fund for that collaboration.

1. Project Opium Vault

What is Opium Protocol?

The Opium protocol is a smart escrow that enables two parties to make a trustless contract and holds an asset on their behalf until contract terms are fully or partially fulfilled. It is used when two parties are in the process of completing a transaction, and there is uncertainty over whether one party will be able to fulfill their obligations or when the transaction depends on an outcome of a future event.


They are proposing to add TORN token to a DeFi Option Vault (DOV), owned by Opium, where the token has the potential to yield returns of about 10-15%.

Opium can set up a vault for TORN using Binance Smart Chain (BSC). However, BSC would need to have enough TORN available for this transaction. The BSC network already has a Binance-Peg TORN token, but it lacks liquidity. Binance team is willing to help with that. They can accept TORN tokens from the TC community treasury multisig and transfer the equivalent of this amount to the BSC.

How does it work

The Opium owners will create a vault where TORN holders can stake their tokens. From there, the assets will be deployed into Options strategies (which before DOV were only available to accredited investors through OTC trading or via self-execution).

Once in the vault, the token owners can set a threshold and a commitment clause whereby the owner commits to selling the right for the token to be purchased by another party if at a predefined time and day (e.g., each Friday at 8am UTC) the TORN price reaches said threshold (e.g., 15% price hike in value).

Market makers compete to buy these options from the vault; they pay the premium for these options upfront and thus provide the high base yield – hence the percent APR. Users just need to be prepared to sell their token once the price hike reaches a set threshold.

2. Celer Asset Bridge (cBridge)

What is cBridge?

cBridge is a decentralized and non-custodial asset bridge that supports more than 40 different tokens across 21 different blockchains and layer-2 rollups. It has processed more than $4b cross-chain asset transfers volume for more than 100K unique users.


The project is ready to launch, the only remaining component is the offer of liquidity: that is, circulating TORN tokens on both sides of the bridge (on Ethereum mainnet and BSC) so that users can bridge TORN token cross-chain to BSC and vice versa. Once moved into the BSC Network, TORN can also be deposited into the Opium vault by any users who hold the token.

Why is this proposal good for the TORN?

This proposal is good for the TORN token because TORN can enter the Options market -> increased popularity with market makers -> the TORN volume grows -> the coin becomes more stable -> increased visibility -> expansion to BSC and TORN’s own vault in Opium.

Why a Snapshot vote is needed?

A Snapshot is needed to unlock ~25k TORN (suggestion) so that it can be transferred to BSC. Deposit a portion of this amount into the Opium vault (to attract the market makers so that this instrument can be utilized) and another portion - towards the cross-chain bridge, which in effect will enable users to bridge assets from Ethereum to BSC via a dApp called Celer, a multi-blockchain asset bridge.

What needs to be determined here?

Prior to the snapshot vote, we need to determine :

  1. TORN amount to unlock from the multisig fund (suggested: 25k TORN),
  2. Distribution percentage across 2 destinations: cBridge (Celer) and Vault (Opium),
  3. Designate a small TORN allocation for Chainlink Price Feed, which will enable the smart contract to retrieve TORN’s latest price in a single call (~75$ per month is needed in order to maintain the Opium vault).


TORN amount to unlock
  • 25,000 TORN
  • 20,000 TORN
  • 15,000 TORN

0 voters

Distribution percentage across 2 destinations
  • 50% Celer/50% Opium
  • 40% Celer/60% Opium
  • 60% Celer/40% Opium

0 voters

TORN allocation for Chainlink Price Feed
  • 30
  • 25
  • 20

0 voters

Within 1 week, I will setup a snapshot for the community to decide whether or not they want to use the multisig fund for that collaboration.

Some readings

Reference to an article for DeFi Option Vaults (DOV), explained:

Reference to an article about Celer bridge:

1 Like

Could you elaborate on the risk of this scheme ?

Cross chain bridges are always more or less custodial, bridged assets redeemability is usually guaranteed by a multisig.

Second, I am unfamiliar with these protocols. Do they have a good track of record? Any audit ? How much TVL? Anon founders? Do they have an admin multisig that can rug the protocol?

Last, it is unclear to me when will the community multisig get its TORN back ? (Or are they gone forever ?) If we can get them back, is there any price risk like an impermanent loss ? Is there an unlock period ?

Since it is proposed to commit a significant share of the funds of the community multisig, we have to ensure that these funds are safe.

Also, is there really demand for TORN options ?


I sincerely appreciate your enthusiasm for building relationships with other protocols and projects @bt11ba. However, I’m not sure this is a meaningful pursuit. At least not for me

I would like to respectfully submit a “rejection” vote to each of the above 3 polls. If you add “reject” as an option, I’ll include my vote accordingly

1 Like

Opium Protocol is controlled by Opium DAO, which is controlled by $OPIUM governance tokens in a decentralized manner through Snapshot and Reality mechanisms. Read more here:

Opium Team is a non-anon team of Core Contributors to Opium DAO, which originally founded the project and continues to develop and contribute to the ecosystem.

Opium is live since 2019 and has 8M$ TVL Opium: TVL and stats - DefiLlama

The protocol has one of the best investors in the industry: Alameda, Rockaway, Galaxy Digital, QSN, CMS, QCP, etc.

Opium products were already in collaboration with other reputable projects as 1inch, AAVE, UMA, etc. (see Medium and Twitter)

Opium Protocol v1 was audited by SmartDec (2020) and MixBytes (2021)

Opium Protocol v2 was audited by Pessimistic (2022) and Igor Gulamov (2022)

Opium DeFi Option Vaults were audited by Pessimistic (2020) and MixBytes (2021)

Opium DeFi Option Vaults have good track records which could be seen via analytics on


Opium DeFi Option Vaults are non-custodial. There are emergency mechanisms with timelock, that can be accessed by DAO. There is an advisory role, which can securely suggest derivative params, but is restricted to manipulate with the vaults in any other way.

Opium DeFi Option Vaults also have alternative community owned-frontend hosted on IPFS:

The community-owned frontend is currently under additional development funded by Opium DAO grant to 3rd party team which performs the development.

Funds staked into DeFi Option Vaults can be withdrawn in the rebalancing phase (every Friday), so whenever the Tornado Cash community decides to exit the pool, it’s possible and completely permissionless.


To answer your first question, our technical overview and security model can be found here. From a high level, Inter-chain dApps built on top of Celer, including cBridge, which is the one that will be used for Tornado Cash bridging, can choose two different security models with different tradeoffs on delay.

By default, inter-chain dApps rely on the security of the State Guardian Network by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC-based solutions.

Even under the extreme case of 100% of the guardians behaving maliciously, inter-chain dApps can maintain full security with an optimistic-style delay buffer. Instead of instantly processing a message routed by the SGN, an inter-chain dApp can inject a mandatory delay buffer and run an independent watchtower service to double-validate the message on the source chain. If the watchtower service detects any inconsistency, it can prevent the message being processed before the delay expires.

In cBridge, both of these models co-exists with a adjustable threshold: if any single TORN cross-chain transfer is larger than a certain size, it will be using the 2 phase commit model. For more details about Celer cBridge’s security model, please see this blog.

Now, in terms of track record. You can see Celer cBridge’s stats here. cBridge has processed $5.1b cross-chain transactions for 120K users cross 27 chains safely with $484M TVL. Not anon founders, no admin multisig. Check out our website at

There is no IL risk for adding TORN in the liquidity pool bridge model and they can be withdrawn anytime.

1 Like

@rezan :
I made both team answers to your questions above. Regarding the demand for TORN options, I think that the community will make it clear thanks to the Snapshot vote.

@ethdev :
Unfortunately we can’t edit forum post after some time.

You will be able to vote “ACCEPT” or “REJECT” directly during the Snapshot.

For the next proposals which need to have a “pre-vote” to define some variables, I will directly add a poll with a “REJECT” option, that is a really good idea. :blush:

Thank you Celer and Opium team for your answers.

I am still uncertain if it’s the role of the community multisig to provide TORN option liquidity (I am still wondering who needs these btw).

Also, we are speaking about pledging half of the funds of the multisig. After that, we wouldn’t have enough funds to pay for a critical Immunefi bounty if it were to happen.

Anyway, the community vote will decide…


Ho, last thing. Would be good to talk about a timeline for how long to provide these liquidity. When do we withdraw the TORN back.

Exactly, regarding the Immunefi bounty, as I told you earlier, we must ensure that we have enough funds. This is one of our role as multisig signers. That is why I will soon make a Governance proposal post asking for another Sablier allocation for 2022.

For sure. Then let’s brainstorm :

What do you suggests ?

While integrations can be good for a closed economy, they can also be risk inducing such is the basis of this proposition. However, it does spark conversation on the topics of asset interoperability and assessing the need to integrate economic tooling such as lending markets.

I’d like to thank both projects for their clear and concise documentation, which helped me become familiarised with the mechanism design of each.

Let’s take a moment to scope how agile tornado as an organisation is to engage in profiteering past protocol primitives - the answer is it lacks such nature, while the community multisig acts as a resolver or subsidy of the governance demographic. It was not formed as the basis for signers to act independently relative to consensus in the organisation. Such as co-ordinating liquidity provisioning in an options protocol, which is not a passive strategy. It often involves quick thinking and decision making to stay profitable and is susceptible to manipulation by any such co-ordinator if the underlying liquidity is not inherently theirs. Especially with protocol intricacies that some may say are “safeguards” but are in reality can add further risk to the product acting as intended. Firstly let’s address the failure to mention the potential risks of such a proposal.

  • As a derivative liquidity provider, there is a risk of a large proportion of the capital being lost or depreciated from a competitive disadvantage. As quoted in Opium’s article; “option strategies are a great way to amplify the yield on your market positioning, but not a passive return instrument” - meaning it is a competitive mechanism and requires constant occurring assessments in rebalancing accordingly to stay afloat.

  • Opium at its core, does not comply with the standard of open organisations as it merely conforms to coordinated multisig operated by core figures. That is used to execute signals of consensus orchestrated from the retrospective snapshot space, using a GnosisDAO module to automate such verification of off-chain activities, on-chain. Although, signers could still purposely act against any proposals even if the veto safeguard was triggered, as seen in the core multisig contract. If it was actually governed by tokenholders, only the module would be able to execute transactions (see execTransaction function).

  • Opium by design is conflictual with the decision of implementing individual proxies for major components of the protocol. While this adds the ability of adaptability it also adds an attack vector with the introduced behaviour, by adding more room for error in configuration or malicious behaviour resulting in loss of funds. The ProxyAdmin component is owned by the core multisig, meaning that all current core implementations of the protocol could be changed without consensus.

I am not against accelerating asset integrations for either realised or unrealised economic efforts. Just I feel the requirement of externally seeking other protocols treasuries resources to bootstrap such mechanisms is not in good faith. If a protocol wants individual pools to be catalysed it can put incentive mechanisms in place to accelerate provisioning. This would add an actual reason for external parties to do so and perhaps creates synergy. Although it still wouldn’t suffice to satisfy such a proposal between tornado in my opinion. I think the two protocols contrast in terms of their virtues and management. Let alone the fact that tornado’s governance demographic is quite young, and that there is already a derivatives market on OKEX for TORN. Which some argue can be an accelerant to governance attacks and even volatility.

In regards to asset interoperability and the Celer bridge, I think their security model at face value is much more impressive than the standardised model. Although, I see no individual reason for seeding such resources to be bridged when there is no necessary reason to. I certainly think it’s a subject matter to be conscious of depending on how tornado evolves in its multi-chain narrative going forward and the potential utility of the protocol’s token in relation to.

Furthermore, as specified by @Rezan this would be deducted from the community resources that are currently allocated to a bug bounty program. This would require the community multisig to seek more funding from the treasury and orchestrate additional planning of future expenditures. When the majority of the subsidies’ current resources have not been fully explored in fulfilling the needs of the organisation.

I will be voting against these proposals for the reasons specified above.


Snapshot link :

I’ve added a 6 months duration and 3 choices for “Accept”:

  • 25k torn,
  • 20k torn,
  • 15k torn.

After discussions with the multisig team, we think that a 25,000 quorum would be more suitable to that kind of proposals, since it involved a large amount of TORN and that it is coming from external parties. If someone disagree with this, please answer here.

As we took this decision AFTER the launching of the snapshot, if it is needed we could reorganize this snapshot if it reach the mentionned quorum (15k) but do not reach the 25k quorum.

As of today, we never discussed this publicly, I think it’s time to do so and define a rule regarding the snapshot quorum. I’ll let @xgozzy take care of that so we can make a forum post and a Snapshot vote to make the community decide on this policy.

1 Like