What is graduated account containment?

A third ledger account state, distinct from normal and frozen, in which the account may only send outbound transfers to destinations on a per-account recipient allowlist, subject to a maximum per-transfer amount and a required memo value, all enforced directly by the ledger's payment-application logic before a transfer is committed.

How is containment different from a frozen account?

A frozen account is a hard stop on every outbound transfer. A contained account can still pay a defined set of allowlisted recipients - such as rent, utilities, or legal counsel - up to a capped amount, as long as the transfer memo matches a required value, without requiring the account to be fully unfrozen.

How does an account leave containment?

Only by presenting a structured, quorum-signed containment-release receipt bound to the account identifier. The release receipt carries its own schema version, an approvals commitment, a quorum descriptor, a timelock, and an activation signature; the ledger validates the receipt before clearing the containment flags.

Where is containment enforced?

Inside the ledger service's own payment-application code path, at the same point that checks account balance and nonce, rather than in an external policy engine or off-chain compliance layer sitting in front of the ledger.

Graduated Containment Account State with Lifeline Allowlist

Executive Summary

Most compliance holds on a digital asset account are binary: an account is either open or frozen. JIL Sovereign's ledger service implements a third state - containment - sitting between the two. A contained account cannot move funds freely, but it is not fully seized either: it may send transfers only to destinations on a per-account recipient allowlist, only up to a capped amount per transfer, and only when the transfer carries a specific required memo value. Every one of those checks runs inside the ledger's own payment-application code, at the same execution point that validates balance and nonce - not in a separate policy service sitting in front of the chain.

The account exits containment only when the ledger receives a structured, quorum-signed release receipt bound to that specific account, carrying its own schema, an approvals commitment, a declared quorum, a timelock, and an activation signature. There is no administrative override that simply flips a flag: release is itself a gated, verifiable event.

Core Innovation: A graduated, capability-restricted account state - enforced in-consensus rather than by an external policy layer - that lets a flagged account keep paying a defined set of essentials while every other outbound path is closed, with exit gated by a quorum-signed release receipt.

Problem Statement

Compliance holds on financial accounts - sanctions screening flags, suspicious-activity investigations, AML holds - are conventionally implemented as a full freeze: every outbound transfer is blocked until the hold is lifted. That is operationally simple, but it produces real hardship for the account holder, who may be unable to pay rent, utilities, or legal counsel while an investigation runs its course, even when the underlying concern has nothing to do with those specific, ordinary payments. Regulators and licensing regimes have pushed back on over-broad freezes for exactly this reason, but most account infrastructure - and essentially all smart-contract "pausable" token designs - offers only the binary choice: fully open, or fully stopped.

Distinct account states enforced at the ledger execution layer

Off-chain policy layers required - enforcement is in-consensus

Fixed memo value required on every lifeline transfer

Why Binary Freeze Models Fall Short

Full account freeze: stops every outbound transfer, including rent, utilities, and counsel retainers unrelated to the underlying compliance concern.
Pausable smart-contract tokens: a single global or per-account pause bit; no concept of a restricted, allowlisted subset of permitted activity.
Off-chain policy engines in front of a ledger: a separate service intercepts and blocks transactions before they reach the chain, which means the restriction is only as strong as that external gate and is not itself part of the ledger's own consensus-enforced state.
Manual bank account restrictions: case-by-case human review to permit specific payments, slow and unauditable at the protocol level.

Technical Architecture

Three Account States

State	Outbound Transfers	Enforcement Point
Normal	Unrestricted, subject to standard balance and nonce checks	Ledger payment-application handler
Containment	Allowed only to allowlisted recipients, capped per transfer, memo must equal a required value	Same handler, three additional guards
Frozen	Hard stop - no outbound transfers of any kind	Same handler, first-checked guard

Containment Transfer Guards

When a transfer originates from a contained account, the ledger evaluates three conditions before allowing the transaction to proceed, in this order: the destination account must be present in the account's lifeline_allowlist; if a lifeline_max_amount is set, the transfer amount must not exceed it; and the transfer's memo field must equal the literal value LIFELINE. Any failure returns a locked-account error and the transaction is rejected before it reaches balance debiting.

Setting and Releasing Containment

Operation	Required Fields	Effect
`set_containment`	account_id, reason, evidence_id, lifeline_allowlist, lifeline_max_amount	Flags the account contained and installs the allowlist/cap for that account
`release_containment`	account_id, a `containment_release_receipt` matching a pinned schema version, with an approvals commitment, quorum descriptor, timelock, and activation signature	Clears the containment flag, reason, evidence pointer, allowlist, and cap in one atomic update

The release receipt's schema is version-pinned (rejecting any receipt that does not declare the expected schema string) and its activation signature is verified before the ledger will clear containment, so the release path is itself an authenticated, auditable event rather than an administrative field write.

Relationship to Full Freeze

Containment and freeze are independently tracked states on the same account record, checked in a fixed order: a frozen account is rejected outright regardless of containment status, so freeze remains available as the harder stop for cases that warrant full seizure (for example, a confirmed compromise requiring an administrative clawback). Containment is reserved for the graduated case - an account under investigation or subject to a lesser hold - where blocking every dollar would be disproportionate to the underlying concern. The two states compose rather than compete: an operator can escalate a contained account directly to frozen without first releasing containment.

Prior Art Differentiation

Approach	Granularity	Enforcement Layer	Auditable Release Gate?
Traditional AML/sanctions freeze	Binary (open/frozen)	Off-chain case-management system	Manual
Pausable smart-contract token	Binary pause bit	Contract-level flag	Admin key, unstructured
Off-chain policy engine in front of a ledger	Configurable, but external to consensus	Separate gateway service	Depends on gateway design
JIL Sovereign graduated containment	Allowlist + amount cap + required memo	Ledger execution layer, in-consensus	Quorum-signed, schema-versioned release receipt

Patent Claim

Independent Claim 45: A computer-implemented ledger system comprising: an execution layer maintaining, for each account, a plurality of account states including at least a normal state, a graduated containment state, and a frozen state; wherein, responsive to an account being placed in the graduated containment state together with an associated recipient allowlist and a maximum per-transfer amount, the execution layer's payment-application logic enforces, prior to committing any outbound transfer originating from that account, that the transfer's designated recipient is present on the recipient allowlist, that the transfer amount does not exceed the maximum per-transfer amount, and that the transfer carries a predetermined memo value; and a release mechanism that returns the account from the graduated containment state to the normal state only upon presentation of a schema-versioned, quorum-signed containment-release receipt cryptographically bound to the account's identifier.