Expose wrapped-token backing ratio on-chain, and consider a mint cap relative to treasury reserves #1208

New issue

Open

opened 2026-09-06 09:15:03 +00:00 by LeonardoLUNC · 2 comments

LeonardoLUNC commented

2026-09-06 09:15:03 +00:00

Because the cw20 minter can issue wrapped tokens without a corresponding wrap_deposit, total_supply can move independently of reserves within a single block range, and a holder has no on-chain way to observe this other than polling two unrelated endpoints. Redemption appears to be first-come-first-served against the reserve, so the ratio is material to anyone holding the wrapped asset.

Requests, in order of preference:

Add a {"backing":{}} query to the treasury or mapper returning native_reserve, wrapped_supply and the derived ratio per wrapped denom.
Emit an event on mint paths that bypass wrap_deposit, so indexers can distinguish issuance from wrapping.
Consider a governance-configurable cap on total_supply relative to reserves, or a documented policy statement if unbacked issuance is intentional for liquidity bootstrapping.

Item 2 alone would be a large improvement — it makes "wrapped supply" usable as an adoption metric, which it currently is not.

The wrap mapper and treasury contracts do not expose the ratio between a wrapped token's total_supply and the native reserve held against it. Integrators must derive it by querying token_info on the cw20 and the bank balance of the treasury separately, and there is no event or query that signals when the ratio changes. Because the cw20 minter can issue wrapped tokens without a corresponding wrap_deposit, total_supply can move independently of reserves within a single block range, and a holder has no on-chain way to observe this other than polling two unrelated endpoints. Redemption appears to be first-come-first-served against the reserve, so the ratio is material to anyone holding the wrapped asset. Requests, in order of preference: 1. Add a `{"backing":{}}` query to the treasury or mapper returning native_reserve, wrapped_supply and the derived ratio per wrapped denom. 2. Emit an event on mint paths that bypass wrap_deposit, so indexers can distinguish issuance from wrapping. 3. Consider a governance-configurable cap on total_supply relative to reserves, or a documented policy statement if unbacked issuance is intentional for liquidity bootstrapping. Item 2 alone would be a large improvement — it makes "wrapped supply" usable as an adoption metric, which it currently is not.

LeonardoLUNC commented

2026-09-09 09:26:42 +00:00

Author

Adding a data point for the mint-cap half of this issue. Over the last 24 hours the cLUNC treasury's native reserve fell roughly 45%, including a single ~60% step inside one 90-minute window, taking the backing ratio from about 8% to about 4.6% against an unchanged supply profile. An integrator holding wrapped balances has no on-chain way to observe either the reserve or the ratio — both have to be reconstructed by querying the treasury's bank balance and dividing by cw20 total_supply, which is not something a contract can do on behalf of its users. A backing_ratio query on the wrap contract, and a mint path that cannot take the ratio below a configured floor, would let integrators set their own risk limits instead of discovering a move like this after the fact.

LeonardoLUNC commented

2026-09-12 11:39:26 +00:00

Author

The point stands and is sharpened by the recovery: with no on-chain backing query, an integrator cannot distinguish "reserve grew 11x" from "supply grew faster than reserve" without reconstructing mint events by hand. A read-only backing {} returning {reserve, supply, ratio} would make this a one-call check. A mint cap expressed relative to reserves would make it unnecessary.

Follow-up data point on this request, 6 days on. The treasury reserve backing the wrapped LUNC token has now moved 4.56M → 21.78M → 52.08M over three days, while reported backing sits near 10% of wrapped supply, because supply includes a large admin-minted tranche that was never deposit-backed. The point stands and is sharpened by the recovery: with no on-chain backing query, an integrator cannot distinguish "reserve grew 11x" from "supply grew faster than reserve" without reconstructing mint events by hand. A read-only `backing {}` returning {reserve, supply, ratio} would make this a one-call check. A mint cap expressed relative to reserves would make it unnecessary.