Corporate Actions

A corporate action is a structured change to an issued token: a split, a redemption, an additional issuance, and so on. XKOVA runs each one through a lifecycle engine that opens the action, freezes transfers, executes the on-chain legs one at a time, reconciles the cap table, and unfreezes. The action is the unit of record, so each step is auditable and resumable.

The kinds

A corporate action is opened with a kind, plus the parameters that kind needs. The supported kinds are:

Kind	What it does
`split`	Multiplies each holder's balance by a ratio. A 2:1 split is numerator 2, denominator 1; each new balance is floor(old times numerator over denominator).
`consolidation`	The reverse of a split, applying a ratio that reduces balances (a reverse split).
`redemption`	Prices out holders at a per-unit price in a payout token, settling the cash leg through the payments chokepoint.
`additional_issuance`	Mints new units to one or more named recipients, as mint-only legs through the same lifecycle engine. Works on any token standard; the recipient shape is standard-specific (a fungible amount, an NFT instance id, or both for a multi-token).
`capital_call`	Collects a per-unit obligation from holders. Not yet available: opening one is rejected with a clear error, because collecting from holders requires a holder-authorized payment flow.
`mandatory_conversion`	Converts holdings into a target token. Not yet available: opening one is rejected with a clear error.

Opening an action validates and freezes the kind-specific parameters, then lands the action in draft. No chain leg fires at open time. You drive it forward with a separate advance step. For the exact parameter fields per kind, see the interactive reference.

The money-moving kind that executes today (a redemption price-out) settles through the same payments chokepoint every other value movement uses. It references an ERC-20 or stablecoin payout token and a funded issuer wallet to draw on.

Token standard constraints

The balance-rewriting kinds (split, consolidation, redemption) apply only to fungible ERC20X tokens, and the token must have an access registry attached (allowlist or denylist access control, chosen at deploy): the mechanism that claws back and re-issues holder balances requires both. Opening one of these kinds on an ERC721X or ERC1155X collection, or on a token without a registry, is rejected up front with a clear error rather than freezing a token the action cannot execute on. NFT corporate actions are a planned capability.

additional_issuance carries no standard or registry constraint: it mints to named recipients on any standard, with the recipient shape validated per standard up front (a fungible amount for ERC20X, a unique token id for an ERC721X instance, an id and amount for ERC1155X). capital_call and mandatory_conversion are not yet available: opening either is rejected at draft with a clear error, so an action that cannot execute is never opened.

The lifecycle engine

Advancing an action drives a re-entrant state machine one step forward. Re-entrant means you can call advance again after a transient failure to resume from where it stopped, rather than restarting. The states run in order:

draft: parameters are frozen; nothing has executed.
frozen: the transfer freeze commits before any on-chain leg fires, so positions cannot move underneath the action while it runs.
executing_on_chain: the on-chain legs run one at a time. Each leg rides the shared tokenization build, sign, relay, and confirm lifecycle.
reconciling: the cap-table replay confirms the new positions against the chain.
completed: the freeze is lifted and the action is closed.

There are two failure outcomes. If the relayer or RPC layer fails transiently and the transaction never landed, or an on-chain leg reverts without diverging supply, the action lands failed_resumable: calling advance re-enters the machine from the failed step. The one terminal failure is reverted, a supply divergence where a mint reverts after its paired burn already confirmed, so balances were clawed back but not re-issued; it needs operator reconciliation. A reverted on-chain transaction is never treated as success.

flowchart TD
  D[draft] --> F[frozen: transfers locked]
  F --> E[executing_on_chain: legs run one at a time]
  E --> R[reconciling: cap table checked against chain]
  R --> C[completed: freeze lifted]
  E -- mint reverts after a confirmed burn --> V[reverted, terminal: supply divergence]
  E -- transient relayer or RPC failure, or a non-divergent revert --> FR[failed_resumable]
  FR -- advance --> E

Reading state and progress

Reading an action returns its current state, the frozen parameters, the snapshot block and freeze timestamp, and the ordered legs, each linked to its tokenization operation id. This is the auditable record of what the action did and how far it has progressed. Opening and advancing require a step-up authenticated session and the token admin role, and both are audited.

Constraints to know

The recover-orchestration kinds (those that rebuild balances on-chain) apply to the fungible ERC20X share class and require an access registry on the token; without one the open is rejected.
Corporate actions are gated by the real-world-asset entitlement. A tenant without it is rejected before any work happens.

Cap Tables and Distributions: how positions are read and how a pro-rata payout works.
Holder Eligibility and Transfers: the transfer freeze and the eligibility door that gate movements.
Token Standards: the ERC20X, ERC721X, and ERC1155X models the legs act on.
Provenance and Transparency: the append-only record behind each change.

For the open, advance, and read operations, see the operations list or try them in the interactive reference.

Was this helpful?