Monetary and legal constraints are compiled into the settlement engine as invariants it checks before it commits. An over-issuance or a prohibited transfer is not flagged after the fact — it is refused as an impossible state.
The rules that must never be violated are conditions of a valid state transition, checked before anything is written.
A transaction that breaks an invariant never commits. There is no window in which the illegal state exists and is later reversed; the ledger simply advances only through states that satisfy every rule.
Policy checks are bound into the same atomic step as settlement. Either the transfer clears with every rule satisfied, or nothing changes — no partial application, no cleanup path.
Given the same ledger state and the same instruction, the policy engine reaches the same verdict every time. Enforcement does not depend on timing, load, or which node processes it.
The ledger is modeled as a state machine whose only legal transitions are policy-conformant. Illegal outcomes are outside the transition set, so they are unreachable rather than merely undesirable.
Total supply is governed by signed authorizations the engine reconciles against every mint.
Issuance is bounded by a supply authorization the owner signs. A mint that would push circulating supply past the authorized ceiling fails the invariant and is refused.
Every transfer must conserve the total: debits equal credits, and no path creates units except an authorized issuance. Value cannot appear from a rounding gap, a race, or a replayed message.
Each issuance carries the owner's signature and a defined quantity. The engine treats the signed envelope as the hard limit; operator intent or urgency cannot expand it.
There is no overdraft, no negative balance, and no deferred-settlement float. An account cannot spend units it does not hold, closing the door on synthetic supply.
Jurisdictional and legal constraints are encoded as preconditions each transaction must satisfy to commit.
Sanctions status, account standing, and jurisdictional eligibility are evaluated as preconditions. A transfer to or from an ineligible party does not settle, because it never satisfies the precondition.
A delegated key can only authorize transactions within the limits its delegation defines. An instruction outside that scope is refused even if the signature is cryptographically valid.
For delivery-versus-payment, the asset leg and the cash leg are conditioned on each other. Neither moves unless both can, so a legally required simultaneity cannot be broken by failure or timing.
Constraints apply to the specific instruments, corridors, or account classes the policy names. Enforcement is precise to the rule rather than a coarse freeze on unrelated activity.
Hard-coded does not mean vendor-defined; the policy set is authored and changed under the owner's signature.
The parameters — supply ceilings, eligibility lists, corridor rules — are set by the owner and admitted only under the owner's signing authority. Sovex cannot alter a live constraint.
Changing a rule is itself a signed, ledgered transaction subject to the owner's governance quorum. There is no side channel to adjust policy without leaving a record.
Each policy revision is versioned with an effective time, so it is always clear which rule set governed a given settlement. History cannot be quietly rewritten.
The path that authors policy is distinct from the path that operates the system. An operator cannot relax a constraint to unblock a transaction under pressure.
Enforcement is recorded on the same tamper-evident chain as settlement, so compliance can be proven, not asserted.
Accepted transactions and the policy version that governed them are written into the tamper-evident hash chain. Altering a past decision breaks the chain and is detectable.
A refused transaction and the invariant it violated are logged with its reason. Regulators can see not only what settled but what the engine declined and why.
Because evaluation is deterministic, an auditor can replay an instruction against the recorded state and confirm the engine's verdict independently. Enforcement is checkable, not opaque.
Signatures over policy and settlement use ML-DSA-65, so the authenticity of every rule and decision remains verifiable against future cryptographic threats. The audit trail is durable, not perishable.