SettleMint
Corporate actions

Stock split and reverse split

Change the share count for every holder at a fixed ratio with a paused snapshot plus per-holder mints or burns.

A stock split multiplies every holder's share count by a fixed ratio; a reverse split (consolidation) divides it. The platform has no single re-denomination call today, so you run a split as a controlled composition: pause the asset, snapshot every holder, then mint or burn each holder's delta, and unpause. The pause makes the operation atomic from the market's point of view.

Rendering diagram...

Prerequisites

  • API key for a wallet holding the Supply Management role for the mints and burns, and the governance role for the pause and the cap change.
  • For a forward split on a capped token: raise the cap before minting, since the post-split supply exceeds the old cap by definition.
  • A stated rounding policy for reverse splits, announced with the ratio.

Running the split

Pause the asset

PATCH /api/v2/tokens/{tokenAddress}/pause-state stops transfers so no balance changes between snapshot and execution. Run the split in the announced window; holders see a paused asset, not a half-split one.

Snapshot every holder

With transfers paused, GET /api/v2/tokens/{tokenAddress}/holders is a consistent snapshot. Paginate with limit=200 until you hold the complete set, and record total supply from GET .../stats/total-supply as the reconciliation baseline.

Compute each holder's delta

For a forward split at ratio R, the delta to mint is balance x (R - 1). A 2-for-1 split mints each holder their current balance again. For a reverse split at 1-for-N, the target is floor(balance / N) whole post-split units and the delta to burn is balance - target x N. Token decimals make forward splits exact; reverse splits leave sub-unit remainders that your rounding policy governs, typically burn-to-floor with cash compensation for the burned fraction.

Mint or burn the deltas

For a forward split, mint each holder's delta in groups of up to 100 recipients.

curl -X POST "https://your-platform.example.com/api/v2/tokens/0x9459D52E60edBD3178f00F9055f6C117a21b4220/mints" \
  -H "X-Api-Key: sm_dalp_test_xxxxxxxxxxxxxxxx" \
  -H "Idempotency-Key: split-nwih-2for1-batch-001" \
  -H "Content-Type: application/json" \
  -d '{
    "recipients": ["0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb"],
    "amounts": ["1000000000000000000000"]
  }'

Reverse split, same batching with POST .../burns and addresses/amounts. Burning a holder's delta needs no holder signature; the Supply Management role authorizes it, and the burn pre-check verifies each holder's indexed balance covers the amount. One Idempotency-Key per batch; a retry after a timeout reattaches instead of double-executing.

Adjust the cap, unpause, verify

If the token is capped, set the post-split cap with PATCH .../supply-cap and body { "newCap": "..." }. Unpause with DELETE .../pause-state. Then verify: new total supply must equal the baseline times the ratio (minus recorded reverse-split remainders), and each spot-checked holder must hold old balance x ratio. Update the asset's price feed so the per-share reference price reflects the new count; see publish a feed update.

Operational notes

  • The mints and burns are supply operations, not a re-denomination: on-chain history shows the old balances before the effective date. State the ratio and effective date in the asset's records so downstream consumers interpret history correctly.
  • Batches are atomic per request. Sequence them so a mid-run failure leaves a resumable state: keep the allocation table, mark each batch's transaction hash as it confirms, and resume from the first unconfirmed batch.
  • For reverse splits, pay the announced cash compensation for burned fractions as a cash-token distribution, following the one-off path in the cash dividend guide.

On this page