Control Plane and capability manifests
The configuration an operation runs under, kept versioned so it can be read again later exactly as it was.
What the Control Plane holds
Versioned configuration for:
- tenants;
- networks and chain identifiers;
- assets, their decimals and their canonical form;
- contracts and their code hashes;
- execution mode;
- signing profile;
- providers and RPC endpoints;
- fees and limits;
- authorization policy;
- webhooks and channels;
- finality policy;
- the capability manifest itself.
What a capability manifest is
A manifest identifies the exact combination that is enabled: this network, with these contracts at these addresses, this execution mode, this signing profile, these assets, these limits.
A capability is not "EVM transfers work". It is "EVM transfers on this chain, through this execution mode, with these contracts, under these limits, have been validated". Anything outside that combination is not enabled, and the platform refuses it rather than improvising.
Why the version is recorded on the operation
Every operation records the version of the manifest it ran under.
Configuration changes. Limits are raised, a contract is redeployed, an execution mode is enabled. Without the version stamped on the operation, an audit months later would read today's configuration and conclude that an old operation broke rules that did not exist when it ran — or, worse, that it respected rules that were not in force.
Recording the version makes the question answerable: not "what is allowed" but "what was allowed at that moment, and did this operation stay inside it".
Relationship with execution
The Data Plane executes against an approved configuration version. The separation is what lets configuration change without a deployment, while keeping every past operation explainable.