Skip to content

Execution & Strategy Layer

Every platform-signed transaction — a rebalance, a bridge, a settlement step — passes through one execution stack built as layered defenses: nothing is signed that was not first policy-verified and simulated, nothing executes outside the vault's declared permissions, and everything leaves an audit trail. On top of that stack sits the strategy layer: subscriptions, attested signals, and keepers.

The execution pipeline

strategy / operator intent
        │
        ▼
build          action expressed through the DeFi SDK's uniform
        │      action model; calldata assembled per protocol
        ▼
policy check   every call verified against the vault's Merkle
        │      allowlist — off-chain pre-flight AND on-chain proof
        ▼
simulate       dry-run with gas, balance, and revert-reason checks;
        │      failures decoded into actionable diagnostics
        ▼
sign           cloud KMS/HSM signing — key material never leaves
        │      the module; relay layer owns nonces, retries, and an
        │      allowlist of permitted action types
        ▼
submit         idempotent submission (deterministic external ids —
        │      a retried step can never double-send)
        ▼
record         transaction row: action, resource, signer identity,
               simulation results, status through confirmation

Building actions

Strategy operations are expressed as intents against the internal DeFi SDK's action registry rather than hand-built calldata. Fund movements follow an escrow-sandwich pattern: assets are withdrawn from pool escrow only for the duration of the verified call sequence and deposited back at the end, so value never rests in an intermediate account (see escrow sweeping).

Policy gating (Merkle allowlists)

Each vault carries an on-chain strategist policy: a Merkle root committing to the exact set of calls strategy execution may make — per-protocol actions with their permitted contract addresses, token approvals bound to specific (token, spender) pairs, and escrow operations bound to specific assets.

  • On-chain enforcement. The vault's proof-verifying manager contract executes a call only when accompanied by a valid Merkle proof against the active root. Dedicated decoder contracts extract the address parameters from calldata so the proof binds to what the call actually touches, not just its function selector.
  • Off-chain pre-flight. Before signing, the platform independently verifies every call in the batch against the policy leaves and their proofs. This is the enforcement point; catalog-level policy matching used by configuration UIs is advisory only.
  • Auditable policy construction. Policies are built from explicit action selections, previewable before being set, and setting or changing a root on-chain is itself a role-gated, EIP-712-signed operation.

The result, combined with the custody model: even a compromised operator credential cannot direct vault assets to an arbitrary address — the contract will not execute a call outside the committed allowlist.

Simulation first

Every transaction supports three modes — build-only (returns an unsigned transaction for external signing), simulate-only, and execute. Execution paths simulate before signing; reverts are decoded through a known-error table into one-line diagnoses rather than opaque failures.

Signing, idempotency, audit

Signing happens inside cloud KMS HSMs (see Custody & Key Management); the relay layer that fronts them manages nonces, retries, and receipt tracking, and enforces its own allowlist of permitted action types per deployment — a new action class cannot execute until it is explicitly enabled there. Submissions carry deterministic idempotency identifiers derived from the operation and step, so a retried orchestration step deduplicates instead of double-sending. Every transaction is recorded end-to-end (pending → simulated → submitted → confirmed/reverted) with action and resource labels and the initiating signer, alongside the platform's immutable audit log.

The strategy layer

Catalog & subscriptions

The platform maintains a strategy catalog merging what SignalForge publishes with what has been vetted as subscribable, surfaced with attestation status in the partner portal. A vault subscribes to a strategy; subscription gates (versioning, single-driver rules, parameter bounds) are enforced at subscription time, and per-vault enablement additionally requires the share class's master automation switch and an active policy that carries the strategy's required permission leaves — a strategy cannot be enabled onto a vault whose policy could not execute it.

The keeper's work-list of active subscriptions is fetched fresh; if the source is unreachable the last-known list is served only within a bounded staleness window, after which the keeper stops trading rather than act on a possibly revoked subscription.

Signals: attestation & provenance

Strategy inputs come from SignalForge, operated by Arkonix Capital Management — a deliberate corporate and system boundary between signal generation and execution.

Chain of trust for signals

Every ingested signal is verified before it can influence execution: the signed envelope is checked against pinned attestation keys (with on-chain key-registry resolution), validated against its contract, and stored verbatim. Rejected signals are retained with their rejection reason and never reach keepers. A daily job independently recomputes each recent envelope's hash against an on-chain anchor; a mismatch is a hard stop — the signal is retroactively rejected and every consumer stops using it. Intraday marks are verified the same way and chain-checked back to the accepted signal, but are monitor-grade only: they never feed NAV, fees, or settlement.

A read-only attestation passport exposes the full provenance of any signal — the verbatim envelope, verification outcome, key-pinning state, anchor coordinates, and a recipe to re-verify independently. It states only what was cryptographically checked.

The keeper model

A scheduled keeper evaluates every active subscription every few minutes:

tick ─▶ gates ─▶ read state ─▶ compute targets ─▶ plan ─▶ execute / simulate
         │            │              │                        │
         │            │              │                        └─ policy-gated
         │            │              │                           pipeline above
         │            │              └─ from the attested signal
         │            └─ chain state always wins over cached state
         └─ enablement, signal freshness, sanity checks
  • Every tick is recorded — including no-ops — into a unified run index with status, decision, and detail, which backs the execution-health views in the partner portal.
  • Dry-run mode. Strategies run in a simulate-everything mode before being switched live; dry-run ticks are recorded as simulated runs with the full decision trail.
  • Idempotency and forensics. Runs are keyed so a completed run is never repeated; a pending marker is committed before any on-chain action, so a mid-run crash leaves evidence that blocks re-execution until an operator verifies chain state.
  • Layered kill switches. Environment-level master gates, per-strategy emergency switches, and per-vault database enablement stack on top of each other; automation is opt-in per environment and every layer can stop it independently. Writes to external trading venues pass an additional venue-level write gate with a per-pool allowlist.

Strategy families

The quantitative indices these strategies track (DGI, JRRT, BYI, APYC, ATLAS) are published by SignalForge and documented in the index catalog; the families below describe how the execution layer runs them:

  • Sentinel Carry — delta-neutral funding capture on a perpetuals venue (long spot, short perp). One decision per tick with a strict priority order in which unwinding and buffer top-ups always outrank position-adding actions. Stored position state is treated as a cache: the chain is re-read each tick and material drift is adopted with a warning, while sign violations or unexpected exposure auto-pause the strategy. Consecutive failed ticks also auto-pause with an alert.
  • Haven — a capital-protection wrapper around an index strategy: a protection floor accretes toward maturity, the risky allocation is sized from the cushion above that floor, and de-risking is always allowed — drift gates and frozen states can block risk-adding trades but never a move toward safety. Directives are attestation-verified each tick; an invalid directive freezes new risk while de-risking stays alive.
  • Index-tracking rebalancers (e.g. the DGI and JRRT indices) — daily corrective trades toward attested target weights, with day-level idempotency, weight-change and price-drift sanity gates, dust and per-trade size caps, and no-drift days recorded as skips.
  • Leveraged carry loop (APYC) — maintains a leveraged fixed-yield position at the loan-to-value tier published by its signal. Position risk is priced by the same oracle the lending market liquidates on; de-levering is always allowed while re-levering is liquidity-capped (a starved re-lever holds rather than errors); and live execution is blocked unless a full preflight — policy, prices, market, an end-to-end simulation — has passed recently.
  • Rotate-to-safety — the failsafe posture: a risk-engine-initiated forced de-risk that swaps risky holdings into a safe asset, each leg sized independently so partial progress is still progress.

Risk controls & execution health

  • Circuit breakers. The independent risk engine can pause vaults, force a rotate-to-safety, or trigger position unwinds through an internal, non-public control surface; pausing a vault halts both on-chain deposits and the automation acting on it.
  • Sanity guards. NAV freshness, notional caps, margin ceilings, funding staleness bounds, and per-asset price plausibility checks gate every execution path; guard failures skip the tick rather than trade on bad data.
  • Execution health. Run history, per-run decisions, preflight results, and attestation status are visible to authorized operators and partner admins, and operational alerts fire on failures, pauses, and parked operations.

See Vault Lifecycle & NAV for the settlement flows these strategies operate within, and Data, Indexing & Workers for the run records and audit trail behind them.