TokenCount
Ask AI
Command
gnokey query vm/qeval -remote "https://rpc.onyx.testnets.gno.land" -data "gno.land/r/nym-mnsrehearsal001/nsskin/v1.TokenCount()"
Result
Community realm. Read the code first. Community realm, deployed by its author. Read the code before you interact or send coins.
Package nsskin holds purchasable card art — the skins — as tokens of their own, and binds them to names.
WHY THIS IS ITS OWN REALM AND NOT PART OF nsdata. SKINS.md §8 listed it as undecided; it is decided here, because the reasoning turned out to be one-sided rather than balanced.
1nsdata IS PERMANENT. It cannot be replaced, ever. A second kind of
2token in it means every mistake in the skin model is permanent too,
3and the skin model is the newest and least settled thing here.
4
5nsdata.OwnerOf DELIBERATELY PANICS FOR EXPIRED TOKENS so a lapsed
6name cannot be listed anywhere. Skins do not expire. That machinery
7is exactly wrong for them, and a conditional on token kind inside
8the one realm that can never be fixed is the worst place for it.
9
10A NEW REALM CAN BE REPLACED while it holds a handful of tokens. The
11vault cannot, at any point, for any reason.
So being wrong here costs a migration nobody notices. Being wrong inside nsdata costs forever.
1A DEFINITION is the artwork: a name, a sprite, an optional extension
2lock, and the artist to pay. One per design, stored once — a
3thousand holders of one design cost one sprite, not a thousand.
4
5A TOKEN is somebody's copy. Editions are unlimited, because SKINS.md
6is explicit that a cap is a floor price with extra steps and resale
7value is never part of the pitch.
This reverses an earlier recommendation of mine, and the new answer is better. I had argued for keeping them separate — a pointer from the name, reverting on sale — because names expire and skins should not. The objection to bundling was that a buyer sees a skinned card on a marketplace and receives an unskinned name.
Binding solves that rather than working around it. The skin genuinely comes with the name, so the card is not misleading, and the small disclosure line the old model needed inside the artwork disappears. And a skin still does not die with a name: when the name goes, the skin comes back.
The worry: a name listed on a marketplace that takes CUSTODY. If the skin lived in the seller's wallet, a custodial listing would hold the name while the skin sat somewhere else, and untangling that on expiry would need cooperation we cannot compel.
So attaching moves the token to THIS REALM'S OWN ADDRESS. While attached it is in nobody's wallet: it cannot be listed, cannot be sold out from under the name, and a marketplace escrowing the NAME never touches it. The question of freeing a skin from somebody else's custody does not arise, because it was never in it.
Taking it out again is one rule with one fallback:
1WHILE THE NAME EXISTS, its CURRENT OWNER may claim the skin. That is
2what makes it travel: buy the name, claim the skin.
3
4IF THE NAME RECORD IS GONE — lapsed and reclaimed — whoever attached
5it may take it back, which is the "it returns to your wallet" case.
One limitation, stated rather than hidden: buy a name with a skin, never claim it, and let that name lapse completely, and the skin returns to whoever attached it. Claiming on purchase avoids it entirely, and the site prompts for exactly that.
gnokey query vm/qeval -remote "https://rpc.onyx.testnets.gno.land" -data "gno.land/r/nym-mnsrehearsal001/nsskin/v1.TokenCount()"