Paladin Protocol - The Execution Shield Between Signal And Market
Paladin is the execution shield of the Glavior stack - the protocol that stands between an approved signal and the actual market. Non-custodial, consent-bound, kill-switch-armed, with full pre-trade simulation and post-trade attestation.
Paladin - The Execution Shield
Between the moment a signal is approved and the moment an order touches the market, an entire class of failure exists that no model can fix by being smarter. Wrong venue. Wrong size. Wrong account. Latency. Slippage. Stale state. Mis-authorised key. Phantom fill.
**Paladin** is the protocol that owns that gap. It is the execution shield that stands between an approved Glavior signal and the actual exchange order - and it is the only protocol in the stack with the authority to refuse an order that the model itself believes is correct.
Quick Specification
- **Protocol Code:** PAL
- **Role:** Execution shield · Non-custodial routing · Consent enforcement
- **Status:** Live · Production
- **Position In Stack:** Final gate - downstream of Aegis approval, upstream of the venue
- **Outputs:** `ROUTED` · `REFUSED(<reason>)` · `KILL_SWITCH_TRIGGERED` · `ATTESTATION`
Mandate - The Last Line Of Defense
Paladin assumes that everything upstream may have been wrong. Genesis may have emitted a stale state. The model may have approved a signal against a fingerprint that no longer matches. Aegis may have approved sizing under a portfolio snapshot that has since changed.
Paladin re-validates the entire decision chain at the millisecond of routing. If anything in the chain is inconsistent, the order is **refused**, the user is notified, and the event is logged. The model is never given the benefit of the doubt at the execution boundary.
[INSIGHT] The most expensive errors in trading are not bad decisions - they are correct decisions executed against a market state that has already moved on. Paladin's only job is to prevent that class of failure.
Non-Custodial By Architecture
Paladin never holds user funds. It never holds withdrawal permissions. It holds **scoped, time-bound, revocable execution authority** and nothing more.
- **Encrypted API keys.** Stored under user-derived encryption, never decryptable by Glavior staff.
- **Trade-only permissions.** Withdrawal scopes are explicitly forbidden at the key-import step.
- **Per-venue isolation.** A key for one venue cannot be reused to route on another.
- **Auto-expiry.** Consent windows are time-bound and require explicit re-authorisation. There is no perpetual delegation.
If Glavior disappears tomorrow, the user's funds and keys remain with the user, on the venue, untouched. That is a structural property of Paladin, not a marketing claim.
The Consent Contract
Every order routed by Paladin requires an active, scoped consent grant. The grant is explicit about what is being authorised:
- **Venue** (e.g. Binance, Bybit).
- **Asset universe** (specific symbols only, never a wildcard).
- **Direction set** (long, short, or both).
- **Max notional** per trade and per window.
- **Window** (e.g. 24 hours, 7 days, until revoked).
- **Kill-switch behaviour** (default: any abnormal event collapses the consent).
The grant is a signed object stored under the user's account. Revoking the grant is a single action that immediately halts all in-flight Paladin routing for that scope.
The Six Refusal Conditions
Paladin will refuse to route an otherwise-approved order under any of the following conditions:
1. **Stale Genesis fingerprint** - the perception object the signal was built on has been superseded. 2. **Consent mismatch** - the order falls outside the active grant (venue, symbol, direction, notional, or window). 3. **Venue health degradation** - the target venue is showing abnormal latency, spread widening, or rejected-order rate above the doctrine threshold. 4. **Portfolio reconciliation failure** - the live account state does not match the snapshot Aegis approved against. 5. **Slippage envelope breach** - expected slippage exceeds the published envelope for the symbol and size. 6. **Kill-switch armed** - the user, or the protocol itself, has armed the kill switch in the current window.
Every refusal emits a structured event with a reason code. There are no silent skips.
The Kill Switch - A First-Class Primitive
The kill switch is not an emergency button hidden in a settings page. It is a first-class primitive in Paladin's contract. It can be armed by the user, by Aegis, or by Paladin itself in response to a venue or portfolio anomaly.
When armed:
- All in-flight orders are cancelled if cancel-on-disconnect is supported by the venue.
- All new routing is refused.
- All open positions remain owned by the user - Paladin never closes positions unilaterally without explicit grant.
- The event is published to the ledger with the trigger source and the time-of-arm.
[MISTAKE] Treating the kill switch as a panic feature. The kill switch is a normal operating mode. Markets that don't deserve a position get one - armed.
Pre-Trade Simulation
Every order Paladin routes is simulated against the live order book first. The simulation produces:
- Expected fill price and slippage.
- Expected execution latency under current venue conditions.
- Expected impact on portfolio-level exposure.
If the simulated outcome breaches any envelope, the order is refused before a single byte hits the venue API.
Post-Trade Attestation
Every routed order produces a Paladin attestation written to the ledger:
```json { "protocol": "PAL", "trade_id": "<uuid>", "event": "ROUTED", "venue": "BINANCE", "symbol": "BTCUSDT", "side": "BUY", "qty": 0.184, "expected_price": 64210.5, "filled_price": 64212.1, "slippage_bps": 0.25, "latency_ms": 38, "genesis_fingerprint": "<sha256>", "consent_id": "<uuid>", "emitted_at": "<ISO-8601>" } ```
The attestation is the cryptographic full-stop of the trade. It links the execution back through consent, perception, and approval. Any audit of a Glavior trade starts and ends with the Paladin attestation.
What Paladin Refuses To Be
- **Paladin is not a brokerage.** Glavior never takes custody. Paladin holds execution authority, not assets.
- **Paladin is not optional.** Every order routed by the platform passes through Paladin. There is no "raw" path that skips the shield.
- **Paladin is not configurable to be permissive.** The refusal stack cannot be disabled. The kill switch cannot be permanently silenced. The consent grant cannot be made perpetual.
Why This Architecture Is The Floor, Not The Ceiling
The crypto industry has normalised execution layers that are *opaque*, *custodial*, and *permissive*. Paladin is the opposite of all three by contract. It is the minimum bar a serious execution layer should clear in 2026 - and the bar most platforms still don't.
[AI] A model's intelligence is irrelevant if the execution layer can betray it. Paladin exists so the model's intelligence is never the bottleneck on integrity.
The Bottom Line
Paladin is the protocol that makes Glavior safe to use against real capital on real venues. Non-custodial by architecture, consent-bound by contract, kill-switch-armed by default, and post-trade attested on a public ledger. Every order is either a Paladin-attested order or it does not exist.