Executive Summary
Compliance policy for a token is usually either hard-coded into that token's own contract logic, requiring a redeploy to change, or enforced entirely off-chain and disconnected from the token's actual on-chain lifecycle. JIL Sovereign's token factory takes a third approach: at creation time, a token is bound to a declarative compliance configuration - a structured payload describing jurisdiction and rule context - which is then compiled at evaluation time by a shared compliance engine into an allow/deny decision for every subsequent state-changing action against that token.
Because the enforcement logic itself lives once, centrally, in the compliance engine, and only the token-specific policy varies as data, two tokens created through the same factory can carry entirely different jurisdiction and rule bindings without any contract redeployment or code branch. Every bid against a token re-triggers an independent compliance evaluation - not just the initial creation - and the entire path is fail-closed: if the compliance engine cannot be reached, the action is blocked rather than allowed by default.
Problem Statement
Hard-coding jurisdictional or transfer-restriction logic directly into a token's smart contract means every policy change - a new jurisdiction, an updated rule - requires redeploying that specific token's code, which is slow, expensive to audit repeatedly, and impossible to apply retroactively to tokens already issued under the old logic. Enforcing compliance purely off-chain, meanwhile, leaves no cryptographic guarantee that a given transfer was actually checked at all.
Why Common Alternatives Fall Short
- Hard-coded per-token contract logic: A jurisdiction or rule change requires a full redeploy and re-audit of that specific token's contract, and cannot apply to tokens already live under the old logic.
- Off-chain-only enforcement: Nothing on-chain proves a given transfer was actually evaluated against current policy, or evaluated at all.
- Creation-time-only checks: Verifying compliance once at token creation says nothing about whether a specific bidder, later, is still eligible to transact.
Technical Architecture
Compliance Binding Lifecycle
| Stage | Trigger | Check Performed |
|---|---|---|
| Token creation | POST to the token-factory endpoint with a declarative compliance configuration payload | Compliance engine evaluated against the requested jurisdiction zone before the token record is persisted |
| Every bid | Any bid submitted against an already-created token | Independent compliance re-evaluation against the token's bound configuration, before the bid is even quoted |
| Engine unreachable | Compliance service timeout or error at either stage | Fail-closed - the action is blocked, not defaulted to allow |
Configuration as Data, Not Code
The compliance configuration bound to a token at creation is a structured payload - jurisdiction zone, compliance context, and rule references - not executable logic specific to that token. The same shared compliance engine compiles that payload into an enforcement decision at evaluation time, so adding support for a new jurisdiction or rule set is a change to the engine's rule catalog, applied uniformly across every token that references it, rather than a per-token contract change.
No-Exception Enforcement
Every token-creation and bid code path in the factory routes through the same compliance-check function before the corresponding state change is persisted; there is no code path that mints or transfers a factory-issued token without first invoking this check.
Prior Art Differentiation
| Approach | Policy Representation | Change Requires Redeploy? | Re-Checked Per Transfer? |
|---|---|---|---|
| Hard-coded per-token restriction logic | Contract code | Yes | Only whatever is coded in |
| Off-chain-only KYC/compliance gate | External system, no on-chain binding | No, but unverifiable on-chain | Depends on integration |
| JIL Sovereign | Declarative config bound at creation | No - shared engine | Yes - every bid, fail-closed |