Data, Indexing & Workers¶
The backend's data layer follows one principle: on-chain events are the source of truth; the database is a read-model plus orchestration state. This page covers what gets indexed, what the read-model contains, and the background processing that keeps both moving.
Event indexing¶
A dedicated indexing pipeline watches vault contracts across every supported network and materializes their events into the queryable state the APIs serve:
- Deposit and redemption flow events — requests, approvals, claimable notifications, claims, and cancellations. These drive both user-visible transaction history and the settlement workers' discovery of pending depositors (which is additionally verified against live on-chain state before any epoch acts on it).
- Share-price publications — the on-chain NAV series the public API exposes as share-price history, block numbers and transaction hashes included.
- Asset lifecycle events — asset registrations and cross-chain price notifications, synchronized into the platform's asset registry.
The indexer is a read-model
Nothing settles, prices, or pays out from indexed data alone. Settlement workers reconcile indexed events against live contract state before acting, and the indexed state can be rebuilt from the chain. If indexing degrades, reads degrade gracefully — funds and settlement correctness do not depend on it.
Protocol & registry sync¶
The Discovery API's catalog of chains, protocols, and actions is backed by synchronization from the internal DeFi SDK's action registry: protocols and their supported actions are discovered from the SDK, verified, and materialized into the database. What the API advertises therefore reflects what execution can actually do. Supported-chain configuration and contract addresses come from static, reviewed configuration — never from mutable database rows.
The domain read-model¶
At concept level, the read-model contains:
| Entity | What it holds |
|---|---|
| Partners | Tenant organizations, members and roles, invitations, API credentials |
| Pools | A partner's on-chain pool: hub chain, per-chain state and escrow/manager addresses, epoch configuration, status |
| Share classes | The product unit: strategy and fee configuration, epoch and automation settings, denomination, cached metrics and published-price state |
| Vaults | Deployed instances per share class per chain: address, type (async / sync-deposit), deposit assets, deployment status |
| Assets & protocols | Pricing configuration per token (method, sources, sanity bounds) and the synced protocol/action/market catalog |
| Transactions | Every platform-signed on-chain transaction with its full status lifecycle, action/resource labels, simulation results, and initiating signer |
| Audit records | An immutable, financial-grade audit log (long-retention) of authentication events, custody operations, and administrative actions |
| Fee records | Per-settlement accrued management/performance amounts, transaction references, recipient, and settler |
| Strategy records | Ingested signals with attestation status, a unified per-tick run index, and per-strategy execution detail |
| Pricing history & snapshots | The fine-grained share-price audit series and validated daily snapshots backing APY |
The resource hierarchy (partner → pool → share class → vault) scopes every query — see Backend overview.
Background processing¶
Automation runs in two modes — continuous workers and scheduled jobs — each independently deployable and health-checked. By responsibility:
| Responsibility | Cadence class | What it does |
|---|---|---|
| Settlement watchers | Continuous (seconds) | Watch approval events and settle issuance/redemptions, reconciling against on-chain state; cursors rewind on failure so nothing is dropped |
| Epoch monitoring | Every few minutes | Detect due epochs (schedule/threshold), prepare approval-workflow executions, detect redemption shortfalls, and kick off deposit routing |
| Orchestration advancers | Continuous (seconds to a minute) | Advance the durable state machines: vault-to-vault flows, redemption sourcing, deposit routing, bridge transfers, rotate-to-safety |
| Strategy keepers | Every few minutes | Evaluate subscriptions and dispatch strategy executions (keeper model) |
| Signal ingestion | Hourly | Poll, attestation-verify, and store signals; catch-up re-invokes strategies whose day was blocked only by a late signal |
| Signal anchor check | Daily | Recompute recent signal hashes against the on-chain anchor; a mismatch retroactively rejects the signal (hard stop) |
| Price publication | Several times per hour | Compute cross-chain NAV and push share prices on-chain — the sole writer of the published price |
| Snapshots & APY | Daily | Record integrity-validated snapshots and refresh cached APY figures |
| Reconciliation & confirmation | Continuous (seconds to minutes) | Resolve submitted venue operations to confirmed/rejected, ingest funding data, verify pending cross-chain deployments |
Cross-cutting properties:
- Idempotent tasks. Background tasks claim a per-invocation idempotency key; completed work returns its cached result, stale in-flight claims are taken over atomically, and the same task can never run twice concurrently for the same inputs.
- Opt-in automation. Every scheduled automation is gated behind explicit per-environment switches, off by default — nothing trades because a deployment happened to include it.
- Operational alerting. Workers alert on failures and threshold breaches, with status-transition deduplication so a persistent condition pages once, not every tick.
Orchestration state machines¶
Multi-step operations — vault deployment, share-class setup and spoke notification, vault-to-vault deposits and unwinds, redemption sourcing, deposit routing, bridge transfers, leveraged-loop unwinds, rotate-to-safety — are executed as durable state machines: a database row advanced one step per worker tick.
Shared guarantees:
- Resumable and idempotent. Every step re-reads on-chain state before acting and short-circuits if its work is already done; submissions carry deterministic idempotency identifiers, so a crash, restart, or retry never double-sends a transaction.
- Bounded retries, no silent failure. Failed steps retry a bounded number of times, then the operation parks for operator review with an alert — flows never end in a silent failed state, and parked operations expose an explicit, role-gated resume path.
- Single active flow per scope. Partial unique constraints enforce that at most one sourcing run, routing run, or unwind is active per vault or share class — concurrent conflicting flows are structurally impossible.
- Per-step audit. Each step records its transaction hashes and intermediate results, so any operation can be reconstructed after the fact.
For the flows themselves see Vault Lifecycle & NAV; for how each step's transaction is authorized and signed see the Execution & Strategy Layer.