Three sovereignties.

Capital, audit, and inference — each held by the Principal, never delegated to the operator. Together they form the floor beneath everything else.

Each sovereignty is architectural — a property of how Pascal was built, not a feature that can be toggled. Removing any one would require rebuilding the system.

The vault.

Your capital sits in your own exchange account, always. Pascal has never had custody and never will.

When the Principal funds a Pascal deployment, the capital is deposited into the Principal's own exchange account — created by them, held by them, withdrawable by them. The operator (Pascal) is never named as a counterparty on the deposit. The account is not in Pascal's name. The keys are not in Pascal's hands.

Withdrawals are something the Principal does directly, from their own exchange. Pascal is never in the loop for deposits or withdrawals. Pascal just trades. If Pascal disappeared tomorrow, the capital would remain exactly where it is — in the Principal's account, accessible by their normal exchange login.

The API key.

One key. One permission scope. Trading on. Withdrawal off. Always.

Pascal connects to the Principal's exchange through a single API key generated by the Principal during onboarding. The key authorises one thing — placing and managing trades. Withdrawal permission is refused at the connection stage. A key that carries withdrawal authority cannot be used; Pascal does not need the permission and refuses to operate with one that has it.

The key is encrypted on receipt; nobody in the workshop ever sees the raw key. Rotation is the Principal's action, on the Principal's schedule — log into the exchange, delete the old key pair, generate a new one (trade-only scope), paste it into Pascal. Revocation is one click on the exchange side; the moment the key is deleted, Pascal's access ends. No process inside Pascal can refuse a revocation.

The Treasury.

The Treasury is not a bank account. It is a capital-allocation engine that operates on rules, not judgement.

Inside the engine, Tier 3 (Risk & Capital) governs how much capital can be deployed at any moment. The rules are deterministic — same conditions, same response — which removes the single most common failure mode in discretionary trading: emotional decision-making under stress.

• Position size cap — min(intended, available × 40%). A single position can never exceed forty percent of available capital, regardless of conviction.
• Position floor — $50 minimum. Below the floor, the trade is not worth the cycle.
• Cash reserve floor — 5% architectural. The reserve never enters trades. The Principal may raise the floor through Settings; the system will never lower it.
• Cooldown mode — three consecutive losses puts the Treasury into COOLDOWN: 50% allocation, throttled deployment, until conditions confirm.
• Performance floor — trailing six-month thresholds for profit factor, expectancy, and Sharpe. All three must hold for normal operation.
• TREASURY_UPDATE bus event — every state change emits a record to Alexandria with timestamp, mode, balance, allocation, and reserve.

When the rules say reduce exposure, exposure reduces. When the rules say increase allocation, allocation increases. The Treasury does not have an opinion about whether to deploy. It has a rule about when.

Cold storage handoff.

Above a defined profit threshold, gains route to a destination controlled exclusively by the Principal — their own cold wallet, created and held by them.

Profit sweep is the protocol that moves realised gains off the trading exchange and into long-term storage. The destination is not Pascal's. The destination is the Principal's own cold wallet, whitelisted on the exchange before the first trade.

The rules:

• Whitelist first. The Principal whitelists their cold-wallet address on the exchange — not on Pascal. The exchange enforces it.
• Threshold defined upfront. The profit threshold above which sweep is permitted is set during onboarding and recorded in the Principal's settings.
• Architect approval per disbursement. Any threshold-crossing transfer requires explicit Architect-level approval, filed to Alexandria with the rationale and amount.
• Destination is exclusively the Principal's. Pascal cannot route to an address that is not the Principal's own — the whitelist sees to that, structurally.

The cold wallet is not Pascal's infrastructure. It is the Principal's own — hardware wallet, signed by their keys, stored where they store it. Pascal observes the sweep. Pascal does not control the destination.

Three layers of security.

Each layer is a separate refusal. For Pascal to misappropriate capital, all three would have to fail in concert — and they were designed not to.

Each layer is independent. Each layer refuses on its own. Together they form a defence-in-depth posture: no single component, on its own, can release the Principal's capital.

Pascal is not that.

The custody model is the foundation of what Pascal is. It is also the foundation of what Pascal refuses to be.

• Not a managed fund. Pascal does not pool capital across Principals. Each Principal's capital trades alone, in their own account, against their own balance.
• Not a custodian. Pascal does not hold balances on behalf of users. The operator's books do not carry a customer-deposit line.
• Not a signal service. Pascal does not publish ideas and ask users to execute them. Execution is part of the system; reasoning, sizing, and stop discipline are filed alongside.
• Not a copy-trading platform. Pascal does not mirror a master account into follower accounts. Each Principal's deployment is its own configuration, its own decisions, its own record.
• Not a market-making book. Pascal does not run inventory on its own balance sheet. There is no operator balance sheet to run inventory against.

The refusals are not posture — they are consequences of the custody model. An operator that never holds customer capital cannot become any of those things, by construction.