[Proposal] AttestedSupply — who authorizes a supply change?

[SergeevDmitry]

Summary

§5.2 lists Mintable / Burnable / FixedSupply / BurnOnly as supply behaviors, but none of them says who authorizes a supply change. For RWAs this is arguably the central risk: a token can be fully compliant on transfer and still represent more units than the underlying asset backs. I'd like to propose a supply-side behavior that makes this explicit.

Proposal: AttestedSupply

A token with AttestedSupply changes supply only on a valid attestation from a declared, independent attestor (auditor, custodian, transfer agent), not on the issuer's say-so alone.

Minimal semantics:

• Binding. The attestation is bound to the asset's metadata anchor (§6.4), the exact amount, the destination, a single-use nonce, an expiry, and the specific token/controller and chain, so it cannot be replayed or redirected.
• Separation of duties. The attestor signs; it does not need to submit transactions. The issuer submits; it cannot create supply without a valid attestation.
• Symmetric for burn. De-tokenization (asset sold, matured, or left custody) follows the same rule, so supply can't be silently reduced either.
• Discoverable. The capability manifest (§5.2, see also [Open Question] Conformance profiles and the capability/behavior manifest #14) declares the attestor identity or key and how it is rotated.
• Event. For example SupplyAttested(metadataHash, attestor, amount, nonce), so any indexer can reconcile supply against attested records across rails.

This links two layers that are currently separate in the draft: Asset Metadata provenance (§6.4: who asserted this, signed how) and the supply primitives in §5.2.

Prior implementation (EVM)

We run this pattern in an open-source permissioned RWA stack: every mint requires an EIP-712 auditor signature over (auditor, profileDigest, recordKey, metadataDigest, amount, nonce, validUntil, vault), bound to the chain and controller contract. The auditor signs offline. The issuer's admin broadcasts the mint, and the platform server cannot create supply. Burn uses the same pattern and is limited to unsold inventory. Metadata digests are SHA-256 over RFC 8785 canonical JSON, anchored as CIDv1.

Code and specs: https://github.com/devlab-group/rwa-platform-evm (SupplyController, shared/eip712/types.md)

Open questions

1. Should AttestedSupply be a behavior of its own, or a constraint on Mintable / Burnable declared in the manifest?
2. Single attestor or m-of-n? Our deployment uses one, but custodian-plus-auditor setups seem likely for institutional issuance.
3. How should attestor rotation and revocation be expressed so that a counterparty can verify historical mints against the attestor valid at the time?
4. Does this belong in Flow A/B as a pre-condition, or as a separate reference flow for issuance?

Happy to draft text for §5.2 / §6.4 if there's interest.