> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://docs.prividium.com/api/mcp` to find what you need.
>
> **Have feedback?** Use `submit_feedback` on the same MCP server.

The asset instruction service turns business events from your source systems — a brokerage funding, a digital asset
sale — into `mint` and `burn` operations on one on-chain asset. Each instruction is accepted durably, executed strictly
in the order you assign, authorized through the platform's policy engine and human approvals, signed by a dedicated
signer, and stored with its confirmed on-chain evidence.

Applications reach it through the Prividium API at `/api/asset-instructions`. The API authenticates the caller, checks
organization membership and the route's permission, and forwards the request to the zone's deployment.

## Permissions

| Permission                       | Grants                                                    |
| -------------------------------- | --------------------------------------------------------- |
| `org_asset_instructions_submit`  | `POST /operations` — machine-to-machine applications only |
| `org_asset_instructions_correct` | `POST /corrections` — users and applications              |
| `org_asset_instructions_read`    | Every `GET` route                                         |

Every route also requires membership in the deployment's organization; an administrative role is no substitute. An
application or user may only submit or correct for the source systems bound to its ID in the deployment configuration.
One zone serves one deployment: the organization, logical asset and service named in the API's configuration.

## The contract behind a deployment

The service depends only on the `IControlledAsset` interface, so any implementation can sit behind a deployment and keep
its own lifecycle, limits, freezes and holder rules:

| Purpose                | Call                                                                                                                 |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Ordinary mint / burn   | `mint` / `burn(wallet, amount, operationId)`                                                                         |
| Corrective mint / burn | `correctMint` / `correctBurn(wallet, amount, operationId, relatedOperationId)`, gated by the corrector role          |
| Account lookup         | `walletAddress(walletId)`; the zero address means unregistered                                                       |
| Signer check           | `hasRole(role, signer)` for `MINTER_ROLE`, `BURNER_ROLE`, `CORRECTOR_ROLE`                                           |
| Evidence               | `AssetOperationRecorded(operationId, walletId, relatedOperationId, wallet, kind, amount, operator, balance, supply)` |

The ordinary signer must hold exactly `MINTER_ROLE` and `BURNER_ROLE`, the correction signer exactly `CORRECTOR_ROLE`.
Every call is simulated before it is signed, and a completed instruction is stored with the `AssetOperationRecorded`
event from its receipt. `relatedOperationId` is the ordinary operation a correction reverses: a recorded `Burn` for
`correctMint`, a recorded `Mint` for `correctBurn`, or zero for an adjustment that reverses no single operation.

## In this section

1. [Instructions API](/developers/asset-instructions/instructions-api) — submitting, correcting and following
   instructions.
2. [Deploying Asset Instructions](/developers/asset-instructions/deployment) — configuring the API, the service, its
   signers and the instruction profile.
3. [Recovering a Halted Stream](/developers/asset-instructions/recovery) — holding execution, and retrying or closing an
   instruction that holds its sequence.