Skip to content

x/issuancepolicy — Issuance Policy module

The x/issuancepolicy module encodes the rules under which new tokens may be minted: schedules, safeguards and policy parameters that staking and identity allocations must respect. The proposed issuance model uses VEID-led 15-token issuance batches: 14 tokens to eligible active verified humans and 1 token to the Foundation-controlled genesis account. All policy lives in chain state and can be changed through consensus.

Because policy is a module, changing issuance rules is a governance act with a public proposal trail, not a quiet parameter edit.

The module holds issuance policy as first-class on-chain state. Policies are created and updated, activated as the active policy, and lifecycle-managed through pause, resume, and deprecation — all as messages rather than off-chain configuration.

Policy is enforced through bounded mechanics: BME mint schedules and staking rewards execute within the policy’s schedules and safeguards. The module also exposes its own accounting — Counters tracks issuance against policy, and ProofMintRecord/ProofMintRecords exposes proof-of-mint records so the issuance trail can be audited. Under the proposed model, VEID-led batches issue 15 tokens: 14 to eligible active verified humans and 1 to the Foundation-controlled genesis account.

Monetary credibility requires that issuance be rule-bound and visible. Separating the policy (what may be minted) from the mechanics (how minting executes) means the rules can be audited and governed independently of the machinery.

ConceptDefinition
Issuance scheduleThe governed timetable and limits under which new supply may be minted.
Max supplyNo fixed maximum or hard cap. Initial supply is zero; new tokens are issued only through verified human identities, with continued issuance as new identities are verified and the human population grows.
  1. Encode — Policy becomes state. Issuance rules live in chain state, auditable by anyone, changeable only through consensus.
  2. Constrain — Mechanics obey bounds. BME mint schedules and staking rewards execute within the policy’s schedules and safeguards.
  3. Propose — Changes go public. New schedules arrive as governance proposals with open debate and stakeholder vote.
  4. Enact — Consensus adopts. Approved policy activates through the normal upgrade path, with the trail preserved on-chain.
MessagePurpose
MsgUpsertPolicyCreates or updates an issuance policy.
MsgSetActivePolicyMakes a policy the active issuance policy.
MsgPausePolicyPauses a policy.
MsgResumePolicyResumes a paused policy.
MsgDeprecatePolicyDeprecates a policy.
MsgPauseIssuancePolicyPauses issuance under policy control.
MsgResumeIssuancePolicyResumes previously paused issuance.
MsgUpdateIssuanceParamsUpdates issuance-specific parameters.
MsgUpdateParamsGovernance-only update of module parameters.
QueryPurpose
Policy / PoliciesOne issuance policy, or all policies.
ActivePolicyThe currently active issuance policy.
CountersRunning counters tracking issuance against policy.
ProofMintRecord / ProofMintRecordsProof-of-mint records, individually and as a list.
ParamsCurrent module parameters.
ModuleHow they interact
x/bmeMint schedules execute within policy bounds.
x/stakingReward issuance is constrained by governed policy.
x/configPolicy parameters are part of governed chain configuration.

The governed timetable and limits under which new supply may be minted — the temporal bounds every minting path must respect.

No fixed maximum or hard cap. Initial supply is zero, and new tokens issue only through verified human identities as the verified population grows. See Tokenomics explained.

So the rules can be audited and governed independently of the minting machinery — monetary credibility requires issuance to be rule-bound and visible. See the x/bme module.