# DAMAGE Token: Utility, Supply Policy and Accounting

DAMAGE execution-credit utility, 8-decimal units, the 42 million supply policy, owner mint capability and separate Lightning payment flows.

Canonical HTML: <https://damagebdd.com/tokenomics.html>



<a id="utility-and-policy"></a>

## Utility and policy

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.


<a id="contract-capability-is-distinct-from-policy"></a>

## Contract capability is distinct from policy

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.


<a id="execution-accounting"></a>

## Execution accounting

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:

```text
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.


<a id="lightning-top-ups"></a>

## Lightning top-ups

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

```text
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](pricing.md).


<a id="reserves-and-custody"></a>

## Reserves and custody

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](payments.md) distinguishes top-ups, execution
spend, contractor compensation and conditional jobs. No transfer of BTC is
implied by a token-denominated execution charge.


<a id="related-references"></a>

## Related references

-   [Platform and token FAQ](faq.md)
-   [Platform architecture and roadmap](whitepaper.md)
-   [Token terms](token_tos.md)
-   [Execution evidence and source references](articles/damagebdd_evidence_workflows.md)
-   [Implementation repository](https://github.com/DamageBDD/DamageBDD.git)

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.