Nabu technology
Pelagos and sequencing
- Block time target: \~250–360ms internal blocks, with optional centralized sequencing for specific performance modes.
- Consensus and consumption: validators run full nodes for external chains and confirm blocks/receipts in a Directed Acyclic Graph (DAG)-based consensus; applications consume state diffs and receipts as a stream.
Confidential strategy execution (high level)
- Strategy logic is encrypted to an epoch public key derived from the active validator set (via regular DKG). Strategies are decrypted and executed only inside allowlisted TEEs, and signing of external transactions and requests is performed via threshold protocols. Execution produces outbound transactions/orders without a public linkage between a specific strategy and a specific outbound action.
This allows creators to share performance and terms without exposing proprietary logic, enabling social trading and profit-sharing at scale.
Visibility and trust boundaries
| Artifact / Data | User | TEEs (confidential execution) | Validators (DKG + TSS) | Solvers (optional) | Public chain / mempool | CEX venue |
|---|---|---|---|---|---|---|
| Strategy logic (PSL) | Full | Full (decrypted & executed) | No (only epoch key material, no plaintext) | No (unless user explicitly shares) | No | No |
| Strategy parameters | Full | Full | No | No (unless shared) | No | No |
| Intents (if used) | Full | Produced/consumed (may be internal) | May see authorization-relevant parts only (via approvals), not full logic | May receive intent constraints to compute execution plan | No | No |
| Risk policy (loss cap, slippage, allowlists, kill switch) | Full | Enforced | May see policy-relevant approvals/limits | May see constraints needed for planning | No | No |
| Outbound chain transaction (payload) | Can reconstruct from own strategy + receipts; also visible on explorer | Constructs/sign-request; does not TSS-sign | TSS-signs + broadcasts, not connected to strategies | May generate tx plan (if intents path) | Yes (tx hash, calldata, state changes) | N/A |
| Outbound CEX order request | Visible to user (via receipts) | Final signing with user CEX key occurs here after validator approval | Approves via TSS (returns approval signature), does not submit to CEX | May generate order plan (if intents path) | No | Yes (to that CEX) |
| Sealed receipts (inputs + constraints + outcomes) | Full (private) | Produces / packages | Contributes signatures/approvals referenced by receipts | No by default | No | No |
| Performance metrics (PnL, drawdown, Sharpe, etc.) | Full | Computes/derives | No by default | No by default | Not inherently | Not inherently |
| Public performance envelope (selectively disclosed) | Optional publish | Can produce proof material | Not required (unless attestation scheme) | Not required | Optional (only what user publishes) | Optional |
CEX key model
This section describes how CEX credentials are handled within the trust and visibility boundaries defined in the table defining the visibility and trust boundaries.
- For venues that support key import/compatible models, users import a corresponding public key; signing occurs via distributed threshold signing among TEEs (e.g., GG20/FROST-style flows).
- For other venues, users encrypt their CEX API keys to the Pelagos epoch public key; execution uses enclave-only access and policy-bound usage.
Risk control catalog
Nabu’s policy model implements execution-grade risk controls across multiple layers — strategy, account, and venue — reflecting established best practices in automated trading. The controls listed below present the full policy surface the system is designed to support at v1 for the subset of controls explicitly marked as designated for the MVP launch of Nabu.
Trusted execution environments are relied on for confidentiality, integrity, and attestation, but are treated as fallible components rather than sources of availability guarantees.
- Core exposure limits:
- Max position size per asset; max gross/net exposure; concentration limits.
- Max leverage and margin utilization (derivatives).
- Pre-trade validations:
- Order size caps; notional caps; price collars / price band checks; fat-finger protection.
- Slippage ceilings; minimum liquidity checks; gas/fee ceilings (where applicable).
- Execution throttles and stability:
- Rate limits / order throttles; max open orders; cancel-on-disconnect equivalents.
- Cooldowns after repeated failures or consecutive losses.
- Latency watchdogs, heartbeat requirements, and timeouts.
- Data sanity and manipulation resistance:
- Oracle deviation guards; stale-data checks; cross-source consistency checks
- Venue status checks (halts, degraded mode), circuit breakers
- Operational controls:
- Kill switch (global and per-strategy); venue allowlists/denylists
- Key permission scoping; audit logs/receipts; emergency rotation procedures
These controls track established industry practice for automated trading risk management (pre-trade checks, throttles, kill-switches, and volatility controls).