DAMAGE Token: Utility, Supply Policy and Accounting

DAMAGE is the Aeternity AEX9-style utility token used in DamageBDD's documented execution-credit and verification-spend path. It is not governance-only. This page reconciles the documented model; it is not a new audit of a deployed contract, wallet balances, exchange liquidity or circulating supply.

Parameter	Documented policy or interface
Token	DAMAGE / Damage Token
Standard	Aeternity AEX9-style fungible token
Decimals	8; 1 DAMAGE = 100,000,000 base units
Supply policy	42,000,000 DAMAGE
Founder / custody allocation	80% = 33,600,000 DAMAGE
Public / market allocation	20% = 8,400,000 DAMAGE
Primary utility	Meter and settle behaviour-verification execution
Payment rail	Lightning purchase/top-up integration, separate from token accounting

Allocation describes policy. It does not establish how much is currently circulating, locked, vested, available for sale or held in any particular wallet.

The documented contract stores its owner, supply, balances, metadata, allowances and swapped balances. Its initializer accepts an initial owner balance. A deployment following the stated supply and decimal policy would initialize that balance to 42,000,000 * 10^8 base units.

The described extensions include allowances, mintable, burnable and swappable. Owner-authorised minting can increase supply; holder burns reduce it. Swap marking burns and records an amount. The 42 million policy is therefore not an immutable contract-level cap. Verify the deployed contract, owner authority and transaction history when checking actual supply.

Calling an operation an administrative or governance action does not establish a token-holder voting system. No deployed voting rights are asserted here.

The documented runner estimates cost through its dry-run path and checks the user's balance before paid execution. The estimate depends on the installed step implementation and repeated/concurrent work. A default one-DAMAGE spend unit in a code path is not a universal tariff for every module.

The documented contract call is:

spend(node_address, amount, feature_hash, report_hash)

This transfers the specified amount from the caller origin to the node/operator and associates execution references. Spend and burn are separate operations. A report hash identifies bytes; it does not itself prove the target's behaviour or confirm a payment on another network.

The documented listener processes paid invoices with labels of the form:

damage:<ae_account>:<amount_damage>:<timestamp>

It transfers DAMAGE from the node/admin account to the target Aeternity account, scaling the amount by 10^8. This describes an integration, not a newly verified production transaction. Confirm the invoice and credited amount separately, including retry and interruption behaviour.

Use the service's quoted rate and invoice. A /rate endpoint or market-rate helper is not proof that a configured deployment provides live market pricing, price parity or automatic redemption. See pricing.

The founder/custody allocation is intended to support development and operations. It is not evidence of segregated customer reserves, a redemption obligation, guaranteed liquidity or any financial return. Public/market allocation does not imply that the whole amount is available on an exchange.

Hosted accounts and external wallets have different key-control arrangements. The payment-flow reference distinguishes top-ups, execution spend, contractor compensation and conditional jobs. No transfer of BTC is implied by a token-denominated execution charge.

• Platform and token FAQ
• Platform architecture and roadmap
• Token terms
• Execution evidence and source references
• Implementation repository

When updating this page from a contract review, record the network, contract address, owner permissions, revision and observation date. Do not substitute the documentation publication date for that evidence.