moultest/v0 package

Package moultest issues `moultest`, a NATIVE coin, and gives it away.

Native here means the chain's own bank holds it, exactly as it holds GNOT. It is not a GRC20: there is no ledger in this realm's storage, no balance map, no Transfer function, no allowance. A realm with the right banker calls IssueCoin once and from that moment the coin is a first-class chain object, and this realm has no further say in who holds it.

What that buys, and what it costs

The interesting half is what disappears. Moving moultest needs no code here at all: a plain bank send does it, from any wallet, with no realm call and no approval dance, because the transfer is a tm2 bank message rather than a function call. It can also RIDE a transaction: the `-send` envelope of a call carries it into the realm being called, which is the one thing no GRC20 can do, and Tip exists to show it. The account page of any explorer lists it beside GNOT with nothing registered anywhere.

The half that is worse is the authority. A GRC20's mint and burn live behind a PrivateLedger this realm chooses to guard; a native coin's live in a banker minted from a realm handle, and banker.RemoveCoin takes an ARBITRARY address. Nothing in the chain stops the issuing realm from deleting anybody's balance at any time. This realm does not expose that (see Burn, which is scoped to the caller and to nobody else), but "does not expose it" is the only protection there is, and it lasts exactly as long as the deployed code. That is the real asymmetry against a GRC20, not the ergonomics.

There is no decimals field either, nor a name, nor a symbol: a native denom is a string and nothing else. 1000 moultest is a thousand moultest.

Why it is capped

Free money with no ceiling is a spam vector rather than a faucet, so Claim is bounded four ways, and the caps are the point of the experiment as much as the coin is:

• ClaimAmount per call, to the CALLER only, never to an address the caller names, so nobody can dust a stranger with it.
• ClaimEvery blocks of cooldown between two claims by one account.
• MaxPerAccount over that account's lifetime.
• MaxSupply over the realm's lifetime.

Burn does not give any of it back. Issuance is counted monotonically, so claim-burn-claim cannot walk around the per-account cap; what burning moves is the circulating supply, which is why the two numbers are reported separately.

It is a private realm

gnomod.toml declares private = true, so this path can be redeployed with corrected code instead of being abandoned for a v1. The price is measured elsewhere in this repo and applies here too: the coins survive a redeploy (they are bank state, held at their owners' addresses, and the denom embeds the package path, which does not move), and everything on this page does not. Claim history, caps consumed and the tip board all return to their init values, which would hand every account a fresh MaxPerAccount. For a coin that is worthless by construction that is an acceptable trade; it would not be for one that is not.