Allow CL8Y to upload CosmWasm code

Proposals
1

TL;DR

This proposal asks governance to allow one 2-of-3 multisig wallet, controlled by CL8Y, to upload CosmWasm code directly:

terra1zlmv2xydxcusurtr6rl78wsvytdc6mfex6hep7

  • Project: CL8Y runs a DEX and a cross-chain bridge, and its CL8Y token gives holders reduced DEX fees.
  • Why upload rights are needed: To deploy pending token security upgrades and to keep maintaining the project’s contracts.
  • Scope: This vote covers this wallet only. Every other project is voted on separately.

Feedback is requested before this goes to an on-chain vote.

Background

Since the restriction of CosmWasm code upload, new contract code can only be added with governance approval. That proposal left room for the community to authorize specific deployers later. This thread asks validators and the community to decide on this project on its own merits.

About the project
Project CL8Y (Ceramic Liberty)
Website https://cl8y.com/
DEX https://dex.cl8y.com/
Official X account @CeramicToken (user ID: 1887160758963748864)
X account created February 2025
Telegram t.me/ceramictoken
Source code cl8y-dex-terraclassic, cw20-mintable

CL8Y DEX is an automated market maker on Terra Classic with CW20 token support, multi-hop routing and customizable fee hooks. Holding the CL8Y token reduces trading fees by tier. The project also runs CL8Y Bridge, which moves tokens across supported chains.

The factory, router and 22 trading pairs listed below are live on Terra Classic. The project’s website lists the DEX and bridge as its two live products.

Ownership proof

This proof links the wallet above to the project’s official X account.
Wallet terra1zlmv2xydxcusurtr6rl78wsvytdc6mfex6hep7
Memo classic-wl:ceramictoken:r1
Proof transaction 6597D9AE78CE4A9EFF809AAC5A39ED1EC3AEC121F70666C12DC193E670BE8AC8
X post CeramicToken on X: "Our multisig is terra1zlmv2xydxcusurtr6rl78wsvytdc6mfex6hep7 For whitelisting deployment verification, see: 6597D9AE78CE4A9EFF809AAC5A39ED1EC3AEC121F70666C12DC193E670BE8AC8" / X

Anyone can check that:

  1. The transaction was signed by the wallet above, by 2 of its 3 keys, on 2026-11-01 at 01:06:26 UTC. It contains a single direct send of 1 uluna (0.000001 LUNC) to terra1sk06e3dyexuq4shw77y3dsv480xv42mq73anxu, the burn module account.
  2. The memo names the X account above.
  3. The X post names the same wallet and transaction hash, and was published after the transaction, at 01:07:03 UTC.

The project’s public documentation also names this wallet as its production governance, contract admin and upgrade address.

On-chain history
Code uploaded None by this wallet
Contracts instantiated None by this wallet

This wallet has not uploaded code because the project has used a separate wallet for that: terra1hu4zggf3f8yw6jw3rxrjxn2drwad675gq5k2lv uploaded 65 codes, from 10181 to 11729. This wallet is the admin of the contracts below and migrated 26 of them between 7 and 17 October 2026. All of them run code from the upload wallet.

Contract Address Current code
cl8y-dex-factory terra1ejpgvv7g3hj0u6fpcnxhflqp84g0w3cnaskqkg5733ygwlmf963sfchsea 11711
cl8y-dex-router terra1e7s0h9ftxakwca5gxspyt4haeuaqxds6swr08ul3tsepq7el924sprrsrw 11712
cl8y-dex-fee-discount terra1wcczsdk7jwj99n3my6wx8wr4ee0hn6yaapgd792lgx5elrdtrn2scfnecz 11581
cl8y-community-token-launcher terra126pr5323xkhwas7y03azv48sqr2fy3fxxg0sxu8xhmjdxr8v5tzqahzwze 11632
USTR CMM Treasury terra16j5u6ey7a84g40sr3gd94nzg5w5fm45046k9s2347qhfpwm5fr6sem3lr2 11728
cmm-wrap-mapper terra1xuuuhpmyd5t29ry7mydg7ra2q2phrwhx7j28nx7x9sjw6zznkumsz0nmd2 11729
22 DEX trading pairs 11715

The wallet is also the admin of the CL8Y token, terra16wtml2q66g82fdkx66tap0qjkahqwp4lwq3ngtygacg5q0kzycgqvhpax3, which runs code 10184.

Who can upgrade them: Migrating these contracts requires 2 of the wallet’s 3 keys. The project’s registry lists other contracts, including ust1-window and ust1-oracle, that are still controlled by a single-key wallet. The project keeps its signer identities private.

Why this project needs upload rights

  • What will be deployed: Security upgrades for the project’s CW20 tokens, which cw20-mintable issue #16 tracks. Additionally, new versions and security relevant fixes of the project’s other contracts. In the team’s words: The upload rights are needed improve its “ability to mitigate & respond to […] incidents in the future”.
  • Expected timeline: The migration tooling is prepared, and the upload is waiting for this approval.
  • Expected upload frequency: No fixed schedule. The upload wallet has stored 65 codes so far.
  • Why per-upload governance proposals don’t work for this project: A 7-day governance vote for each upload would delay security upgrades and incident responses.

What this vote does

If it passes:

  • The wallet above can upload CosmWasm code without a separate governance vote for each upload.
  • Governance can remove the wallet at any time with a later vote.

It does not:

  • Allow any other wallet to upload code.
  • Change any existing contract.
  • Endorse the project or its token, or vouch for the safety of its contracts.

Discussion questions

  1. Does the evidence above convince you that this wallet belongs to this project?
  2. Does the project have a clear need for its own upload rights?

Please share feedback here before this is submitted on-chain.

1 Like
2

Thanks Frag for opening this proposal. It is critical for us to conduct security upgrades in light of both what has happened to our community members, other terraclassic defi, and the broader tech ecosystem due to recent advancements in AI offensive cyber capabilities. We are planning to deploy a series of upgrades to our CW20Mintable contracts to improve our pausing infrastructure, provide rate limiting services, blacklist known bad actors, and conduct asset recovery efforst in a secure & transparent manner. To see the publicly visible planned upgrades, check out #16 - Prepare later-run migration script; deployment blocked pending Terra Classic whitelist - code/cw20-mintable - Forgejo: Beyond coding. We forge. .

Also, I want to confirm that the hep7 wallet is our ecosystem multisig. Because whitelisting requires a governance vote, we are switching our deployment from the deployer EOA to the multisig as we usually rotate our EOAs periodically.

Heres our x post followup supporting this proposal from the official CeramicToken (@CeramicToken) / X cl8y account, which is linked from cl8y.com: CeramicToken on X: "Please support the proposal: https://t.co/Q8jDxH0nmT Usually we rotate our EOAs at least once a year, which is why the whitelisting is for multisig instead of our usual EOA deployer." / X

1 Like
3

From my end No free CosmWasm whitelist unless the ask clearly serves the chain, not just one project’s deploy pipeline. If they need a security fix, they can still go through governance per upload, or bring a narrower ask (time-limited whitelist, named audit of the next code, public signer set). Convenience for CL8Y is not a chain benefit. Also this can be accomplished through changes to their own smart contracts.

4

Calling this a matter of convenience misses the point entirely.

CL8Y operates a live DEX, bridge and growing DeFi infrastructure. Protecting that infrastructure and its users is absolutely a benefit to Terra Classic.

A seven-day governance vote for every code upload is simply not a practical response to an emerging security threat.

And suggesting CL8Y can just modify its existing smart contracts overlooks the technical problem. If new security functionality requires new contract code, that code must first be uploaded. That’s precisely what the restriction prevents.

This isn’t unrestricted access. It’s permission for one verified 2-of-3 multisig, revocable through governance.

I’m all for accountability, transparency and appropriate security audits. But safeguards shouldn’t make it impossible to respond quickly when something goes wrong.

Having recently suffered a substantial loss through compromised keys, I know firsthand that speed can be the difference between losing something and losing everything.

We need to encourage developers building real utility on Terra Classic, not introduce unnecessary obstacles to maintaining and securing it.

So my question is simple: what alternative are you proposing that provides the same ability to respond to an active threat without waiting seven days?

5

After further discussion with Frag, we will support this proposal.

6

  1. Does the evidence above convince you that this wallet belongs to this project?

    I’m not convinced. Given the chain security reason for moving to permissioned CosmWasm code uploads, this undermines that strong protection as there will be no way to audit and control the impact of potentially insecure contracts, on a case by case basis, that could have a detrimental impact on the chain once an ongoing authorisation is in place.

  2. Does the project have a clear need for its own upload rights?

    The reason given - the need to provide contract security updates at short notice, applies to pretty much any project that operates smart contracts, so if we accept this reason as valid for CL8Y, we have to accept it as valid for all projects as far as I can see.

    I’m not convinced this demonstrates a unique reason as to why this project in particular should have its own ongoing upload rights.