Proposals 1957 and 1959 requested over 9,000 USDT—an amount that clearly exceeds the 1,000 DOT limit. What’s alarming is that Proposal 1957 was actually approved; could this be a bug that is being exploited?
Not a bug in the track check, it’s the conversion rate the check uses. treasury.spend converts a USDT amount to DOT with the rate stored in pallet-asset-rate and compares the result to the track’s max. On Asset Hub the stored rate for USDT (asset 1984) is 1000 as a FixedU128. With 6 decimals on USDT and 10 on DOT, that’s 1 USDT = 0.1 DOT, so the chain prices DOT at $10.
At that rate 9,796.08 USDT counts as 979.6 DOT and 9,000 USDT as 900 DOT, both under 1,000. With DOT around $1.08 today, Big Tipper is worth about $1,080 for a DOT spend and about $10,000 for a USDT or USDC spend (USDC is stored at the same rate). Every spend track has the same gap, roughly 9x.
The rate is set by governance, not read from a price feed, so the fix is updating it, or agreeing how often it gets reviewed. Anyone can check it under assetRate.conversionRateToNative on Asset Hub.
Thank you very much for the clear and precise explanation. It seems there are still some issues worth addressing.
First, when DOT is used as the reference for spending limits, should the conversion rates for payments made in other assets be updated dynamically to reflect market prices?
Second, what would be an appropriate long-term maintenance mechanism to ensure that these rates remain reasonably accurate and that any significant discrepancies are detected and addressed in a timely manner?
I think this is also an important consideration for the upcoming practical use of dotUSD.
I’d be careful with a live market feed here. The rate only feeds the limit check, so whoever can move the feed moves the ceiling of every track for stablecoin spends. If it stays a stored rate, the safer error is one that prices DOT a bit below market, since then the limits get tighter, not looser. Today’s error goes the other way.
On keeping it current: updating it already takes a Root or Treasurer referendum (assetRate.update), so the missing piece is noticing. A public check that compares the stored rate with the market and flags any drift past, say, 20%, plus a fixed review date, would catch this early. For dotUSD and the other stablecoins, a limit set in the asset’s own units would take the DOT price out of that check entirely, though that needs a runtime change.