Auto-Execution - Non-Custodial Trade Routing Under Glavior Control
How Glavior routes approved signals into live exchanges without ever holding user funds. Wallet-bound consent, kill-switch enforcement, slippage caps, partial-fill safety, and a fully attested post-trade record.
Auto-Execution - Non-Custodial Trade Routing Under Glavior Control
Auto-Execution is the optional layer that takes an approved Glavior signal and routes it to a live exchange on the user's behalf. It exists for one reason: to remove the latency, hesitation, and discretionary drift that destroys most retail edges.
It is not custodial. It is not silent. It is not automatic in the sense most users assume - it runs only inside a strict consent envelope the user has explicitly armed.
What Auto-Execution Actually Does
When a signal passes every protocol gate (Genesis perception, Aegis risk, Zenith profit, Paladin execution), the Auto-Execution layer:
1. Confirms the user's standing consent for that venue, instrument, and risk envelope. 2. Resolves the working order plan (entry, size, stop, target ladder). 3. Submits the order through the user's own exchange credentials or wallet. 4. Watches fills in real time and posts the attested outcome to the public ledger.
If any of these steps fails its precondition, the order is never placed. The model never overrides the user's envelope.
Non-Custodial By Architecture
Glavior never holds user funds. Auto-Execution operates through:
- **Exchange API keys** scoped to trading-only (no withdrawal permission).
- **On-chain wallets** connected by the user with per-transaction consent.
There is no Glavior-controlled custody, no internal balance, and no off-exchange settlement. If Glavior disappeared tomorrow, the user's funds would be exactly where they are today.
The Consent Envelope
Auto-Execution does not run on a single click. The user arms an envelope that defines:
- **Venues** allowed (Hyperliquid, Bybit, Binance, etc.).
- **Instruments** allowed (spot, perps, specific symbols).
- **Max position size** per signal and per day.
- **Max drawdown** before the kill switch trips.
- **Slippage cap** per fill.
If a signal would breach any limit, the order is silently skipped and logged. No automation is allowed to silently expand its own authority.
Kill Switch, Always Armed
A single user action halts every working order across every venue. The kill switch is the highest-priority instruction in the entire stack - it bypasses queueing, retries, and pending fills. When tripped, Auto-Execution withdraws every resting order and refuses to submit new ones until the user re-arms the envelope.
Slippage And Partial-Fill Safety
Every order carries a hard slippage cap. If the venue cannot fill inside that cap, the order is cancelled rather than chased. Partial fills are accepted only when they match the planned ladder; out-of-plan fills trigger a corrective close.
Post-Trade Attestation
Every Auto-Executed trade is appended to the public ledger with:
- Originating signal hash.
- Venue, instrument, side, size, fills.
- Realised slippage versus expected.
- Final outcome (TP-hit, SL-hit) - the only valid terminal states.
This makes the entire automation surface auditable from outside the platform. The record is the proof.
What Auto-Execution Is Not
- It is not custodial. Glavior never controls user funds.
- It is not opaque. Every order is signal-attributed and ledger-attested.
- It is not unbounded. Every order lives inside an explicit user-armed envelope.
- It is not a guarantee. Markets can gap; venues can fail; the kill switch and slippage cap exist precisely because execution is never riskless.
The Bottom Line
Auto-Execution is the bridge between Glavior's decision stack and the user's capital - built so the user keeps control of the keys, the envelope, and the off-switch at all times. The model decides. The user consents. The venue executes. The ledger records. Nothing in that chain is hidden, custodial, or reversible inside Glavior.