# Decrease of capital

Source: https://docs.settlemint.com/docs/developers/corporate-actions/capital-decrease
Reduce issued capital with batch burns, an optional supply-cap reduction, and an optional cash return to holders.



A decrease of capital retires issued units, either pro-rata across all holders or from specific positions such as a treasury account after a buyback. You execute the reduction itself as a burn: the Supply Management role removes units from holder addresses directly, no holder signature required. A cap change and a cash return complete the reduction when the terms include them.

<Mermaid
  chart="flowchart TD
  Approve[&#x22;Approve the reduction<br/>(scope, ratio or amounts, cash return)&#x22;] --> Scope{&#x22;Pro-rata across holders<br/>or specific positions?&#x22;}
  Scope -->|Pro-rata| Snapshot[&#x22;Snapshot holders<br/>GET /tokens/{token}/holders&#x22;]
  Snapshot --> Compute[&#x22;Compute burn per holder<br/>balance x reduction ratio&#x22;]
  Scope -->|Specific| Positions[&#x22;List the positions to retire<br/>(e.g. treasury after buyback)&#x22;]
  Compute --> Burn[&#x22;Batch burn<br/>POST /tokens/{token}/burns&#x22;]
  Positions --> Burn
  Burn --> Cap[&#x22;Lower the supply cap if capped<br/>PATCH /tokens/{token}/supply-cap&#x22;]
  Cap --> Return{&#x22;Cash return<br/>to holders?&#x22;}
  Return -->|Yes| Pay[&#x22;Batch transfer the cash token<br/>POST /tokens/{cashToken}/transfers&#x22;]
  Return -->|No| Verify[&#x22;Verify supply and report&#x22;]
  Pay --> Verify"
/>

## Prerequisites [#prerequisites]

* API key for a wallet with the Supply Management role on the asset, plus the governance role when the cap changes.
* For a pro-rata reduction: a consistent holder snapshot, which means pausing the asset or running in a quiet window.
* For a cash return: a funded distribution wallet holding the cash token.

## Running the reduction [#running-the-reduction]

<Steps>
  <Step>
    ### Fix the scope and the numbers [#fix-the-scope-and-the-numbers]

    A pro-rata reduction burns `balance x reduction ratio` from every holder, rounded down; snapshot the holder set first with `GET /api/v2/tokens/{tokenAddress}/holders` (paused) or the [record-date snapshot](/docs/developers/corporate-actions#record-date-snapshot) (past date). A targeted reduction, such as cancelling repurchased shares, burns exact amounts from named positions and needs no snapshot beyond those balances.
  </Step>

  <Step>
    ### Batch burn the retired units [#batch-burn-the-retired-units]

    Burn in groups of up to 100 addresses, one `Idempotency-Key` per request.

    ```bash
    curl -X POST "https://your-platform.example.com/api/v2/tokens/0x9459D52E60edBD3178f00F9055f6C117a21b4220/burns" \
      -H "X-Api-Key: sm_dalp_test_xxxxxxxxxxxxxxxx" \
      -H "Idempotency-Key: capdec-nwih-2026-batch-001" \
      -H "Content-Type: application/json" \
      -d '{
        "addresses": [
          "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
          "0x8ba1f109551bD432803012645Ac136ddd64DBA72"
        ],
        "amounts": [
          "100000000000000000000",
          "25000000000000000000"
        ]
      }'
    ```

    The burn pre-check verifies each address's indexed balance covers its amount, counting frozen units, so your reduction can retire frozen positions too. A batch fails whole when one address falls short; correct that address's amount and rerun your batch under a fresh `Idempotency-Key`.
  </Step>

  <Step>
    ### Lower the supply cap [#lower-the-supply-cap]

    When the asset is capped and the reduction is permanent, bring the cap down to the new authorized level. A lowered cap stops a future mint from silently restoring the retired capital.

    ```bash
    curl -X PATCH "https://your-platform.example.com/api/v2/tokens/0x9459D52E60edBD3178f00F9055f6C117a21b4220/supply-cap" \
      -H "X-Api-Key: sm_dalp_test_xxxxxxxxxxxxxxxx" \
      -H "Content-Type: application/json" \
      -d '{ "newCap": "800000000000000000000000" }'
    ```
  </Step>

  <Step>
    ### Return cash to holders when the terms include it [#return-cash-to-holders-when-the-terms-include-it]

    A capital repayment pays each holder the announced amount per retired unit in a cash token. Compute from the same snapshot the burns used and push the payments with `POST /api/v2/tokens/{cashTokenAddress}/transfers` in batches of up to 10,000, following the one-off distribution path in the [cash dividend guide](/docs/developers/corporate-actions/cash-dividend).
  </Step>

  <Step>
    ### Verify and report [#verify-and-report]

    Confirm every transaction, then check `GET /api/v2/tokens/{tokenAddress}/stats/total-supply` against the approved post-reduction supply and reconcile burned amounts per holder against your allocation table. Keep your approval record, your snapshot, the burn payloads, and the transaction hashes together as the audit trail of the reduction.
  </Step>
</Steps>

## Operational notes [#operational-notes]

* Burns are irreversible. Verify your allocation table against the approved reduction before the first batch, not after.
* The platform records the burn, the cap change, and the cash return; the capital-account bookkeeping behind the reduction (share premium, reserves) lives in your corporate records, not on-chain.
* Where local law requires creditor notice periods or court approval before a reduction, complete them before the burn run; the platform does not model those gates.

## Related guides [#related-guides]

* [Stock split and reverse split](/docs/developers/corporate-actions/stock-split) reduces share count without reducing capital.
* [Burn assets](/docs/operators/asset-servicing/burn-assets) covers the burn primitive through the Console.
* [Token holders and transfers API reference](/docs/api-reference/tokens/token-holders-transfers) documents burn pre-checks and freeze interactions in depth.