unused/half-broken denoms on mainnet: STOSMO (all-caps), stATOM2

[warner]

While validating the devnet/mainfork test of upgrade16, we noticed some unusual denominations on mainnet. These are probably proposals with typos, or which had problems that prevented them from being completed and required replacement.

One cheap way to get a list of names is to look at the virtual-collection keys in v6-agoricNames. I don't know what collection 10 is, but it certainly seems to have a bunch of expected names, as well as the unexpected/unusual/half-broken ones:

% grep 'v6.vs.vc.10.' b3934000-all-kv.txt
v6.vs.vc.10.sATOM|{"body":"#\"$0.Alleged: ATOM brand\"","slots":["o-122"]}
v6.vs.vc.10.sAUSD|{"body":"#\"$0.Alleged: AUSD brand\"","slots":["o-114"]}
v6.vs.vc.10.sBLD|{"body":"#\"$0.Alleged: BLD brand\"","slots":["o-80"]}
v6.vs.vc.10.sIST|{"body":"#\"$0.Alleged: IST brand\"","slots":["o-81"]}
v6.vs.vc.10.sInvitation|{"body":"#\"$0.Alleged: Zoe Invitation brand\"","slots":["o-52"]}
v6.vs.vc.10.sSTOSMO|{"body":"#\"$0.Alleged: STOSMO brand\"","slots":["o-154"]}
v6.vs.vc.10.sUSDC_axl|{"body":"#\"$0.Alleged: USDC_axl brand\"","slots":["o-106"]}
v6.vs.vc.10.sUSDC_grv|{"body":"#\"$0.Alleged: USDC_grv brand\"","slots":["o-108"]}
v6.vs.vc.10.sUSDT_axl|{"body":"#\"$0.Alleged: USDT_axl brand\"","slots":["o-110"]}
v6.vs.vc.10.sUSDT_grv|{"body":"#\"$0.Alleged: USDT_grv brand\"","slots":["o-112"]}
v6.vs.vc.10.sstATOM2|{"body":"#\"$0.Alleged: stATOM2 brand\"","slots":["o-140"]}
v6.vs.vc.10.sstATOM3|{"body":"#\"$0.Alleged: stATOM3 brand\"","slots":["o-145"]}
v6.vs.vc.10.sstATOM|{"body":"#\"$0.Alleged: stATOM brand\"","slots":["o-135"]}
v6.vs.vc.10.sstOSMO|{"body":"#\"$0.Alleged: stOSMO brand\"","slots":["o-149"]}
v6.vs.vc.10.sstTIA|{"body":"#\"$0.Alleged: stTIA brand\"","slots":["o-162"]}
v6.vs.vc.10.sstkATOM|{"body":"#\"$0.Alleged: stkATOM brand\"","slots":["o-158"]}
v6.vs.vc.10.stimer|{"body":"#\"$0.Alleged: timerBrand\"","slots":["o-50"]}
v6.vs.vc.10.|entryCount|17
v6.vs.vc.10.|nextOrdinal|1
v6.vs.vc.10.|schemata|{"body":"#{\"keyShape\":{\"#tag\":\"match:scalar\",\"payload\":\"#undefined\"},\"label\":\"nameKey\"}","slots":[]}

In a line like v6.vs.vc.10.sBLD| ..., the key is BLD (the s prefix means the key is a string). Or, you can look at the value, where the interface name (Alleged: BLD brand) is easier to read.

If this collection is definitive, the list of denoms that have at least been registered with agoricNames is:

• ATOM
• AUSD
• BLD
• IST
• STOSMO
• USDC_axl
• USDC_grv
• USDT_axl
• USDT_grv
• stATOM2
• stATOM3
• stATOM
• stOSMO
• stTIA
• stkATOM

@Chris-Hibbert and I think that STOSMO is a typo (replaced by stOSMO, with a lowercase st), and that stATOM and stATOM2 somehow failed and it wasn't until stATOM3 that we got it right.

The question is: just how much actually got wired up on these denoms before we stopped trying to make them complete?

• does vaultFactory know about them? will it attempt liquidations?
• are there oracles registered for them? are there price-feeds or scaledPriceAuthority services that are in an error/stale state because they haven't received price updates?
• are there any promise currently waiting for them to be fully wired up? will those promises ever resolve? perhaps when we upgrade some vat in the future?

Our main concern is that nothing weird happen during vat upgrades because these denoms are in an unusual state. We don't have anything like this on emerynet, or our non-mainfork testnets, so it represents an under- tested/simulated/investigated case.

[Chris-Hibbert]

Also Auctions. There's one schedule that drives all the auctions, but each denom does separate work, and looks separately for price updates.

I wonder if we can effectively shut down processing on the unused vaults/auctions to ensure no chain activity connected to these extraneous brands.