Skip to content

Backend (Execution Platform)

The execution platform is the service layer between the frontends, the public API, and the on-chain protocol. It serves every API surface, orchestrates the ERC-7540 vault lifecycle end to end, runs the strategy automation, computes and publishes NAV, and executes every platform-signed on-chain transaction through a policy-gated, simulation-first pipeline.

This section is split into three deep dives:

  • Vault Lifecycle & NAV — epoch settlement, redemption sourcing, deposit routing, cross-chain flows, deployment, pricing and NAV publication.
  • Execution & Strategy Layer — the transaction execution stack, Merkle-policy gating, signal provenance, and the strategy keeper model.
  • Data, Indexing & Workers — event indexing, the domain read-model, protocol sync, and background processing.

Responsibilities

Serve the APIs. The public read-only API (vault data, discovery), the authenticated app API behind the Earn app and partner portal, the HMAC-signed Partner API, and the platform administration surface.

Orchestrate the vault lifecycle. Deposits and issuance, epoch execution, redemptions (including automatic multi-source liquidity sourcing), vault-to-vault allocation and unwinds, and cross-chain USDC movement via Circle's CCTP.

Run strategy automation. A keeper layer evaluates subscribed strategies on a fixed cadence, consumes attested signals from SignalForge, and executes through the policy-gated pipeline. Every action is simulated first and every run is recorded.

Compute and publish NAV. Multi-asset, multi-chain portfolio valuation feeding on-chain share-price publication, daily snapshots, and APY series — with integrity checks at every step.

Execute on-chain. All platform-signed transactions flow through one stack: built via the internal DeFi SDK, verified against per-vault Merkle policies, simulated, signed inside cloud KMS/HSM, and recorded in an audit trail. See Custody & Key Management for what those keys can and cannot do.

API tiers

Every surface is matched to an authentication mechanism and a role tier. Authorization is enforced server-side on every request; the frontends only mirror it for UI purposes.

Tier Audience Authentication Scope
Public Anyone None Read-only vault, share-class, and discovery data; liveness check
Authenticated app Earn app & partner portal users JWT bearer tokens (email or wallet login), plus an EIP-712 wallet signature as a second factor on sensitive operations Portfolio views and vault operations, scoped to the caller's memberships and role
Partner API Institutional programmatic integrations HMAC-SHA256 request signing with replay protection Orders and vault management for the partner's own resources — see Partner API
Platform administration Arkonix operators JWT with platform-level roles, plus EIP-712 signed actions Registries, deployments, cross-tenant operations

Internal service-to-service traffic between platform services (risk engine, signal ingestion, indexers, transaction relay) uses separate service credentials on network paths that are never exposed publicly.

Roles

Within the authenticated tiers, a strict role hierarchy gates each operation:

Role Tier Typical rights
Super admin Platform Everything, including registries and partner administration
Platform admin Platform Cross-tenant operations, orchestration recovery
Partner admin Partner Full management of the partner's own pools, vaults, members, and fees
Partner strategist Partner Strategy and trade execution within the partner's policy bounds
Partner investor Partner Read and invest only

Invitations cannot grant a role higher than the inviter's own — vertical privilege escalation through invites is rejected structurally.

Two factors for anything that moves state

Every state-changing operation requires both a role check and an EIP-712 typed-data signature from a signer wallet bound to the account — single-use nonces, short deadlines, and signer verification included. A stolen session token alone cannot trigger execution-class operations. Details on the Authentication page.

Resource hierarchy & multi-tenancy

The platform is multi-tenant. All resources hang off a partner:

Partner (organization)
   └── Pool (on-chain pool, one hub chain)
          └── Share Class (strategy, fees, epochs, NAV — the product unit)
                 └── Vault (deployed instance, one per chain)
  • Partner — the tenant: an institution or curator, with its own members, roles, wallets, and API credentials.
  • Pool — the on-chain pool a partner operates, anchored to a hub chain with per-chain spoke state (see Protocol Layer for the hub-and-spoke model).
  • Share class — the unit users experience as "a vault": strategy configuration, fee terms, epoch settings, denomination, and the published share-price series.
  • Vault — a deployed contract instance of a share class on a specific chain; a share class can expose vaults on several networks simultaneously.

Every authenticated query and mutation is scoped through this hierarchy: a partner-tier caller can only ever reach resources that resolve back to their own partner. Platform-tier roles are required to cross tenant boundaries.

Request path

All traffic enters through an API gateway that terminates TLS, then passes through a fixed processing chain before any handler runs:

client
  │
  ▼
gateway (TLS termination, routing)
  │
  ▼
hardening layer          security headers, input screening,
  │                      request-size caps, per-tenant rate limiting
  ▼
authentication           tier-appropriate credential verification;
  │                      membership and role resolution
  ▼
authorization            role check for the endpoint; EIP-712
  │                      signed-action verification where required
  ▼
handler                  tenant-scoped business logic

Authentication successes and failures are audit-logged, error responses never leak internal details, and interactive API schema browsing is not exposed unauthenticated.

Boundaries

  • The backend cannot move user funds — deposits and withdrawals settle between user wallets and vault contracts; operational keys are limited to strategy execution, settlement, and price publication, and strategy execution is itself constrained by on-chain Merkle policies. See Custody & Key Management.
  • On-chain events are the source of truth; the backend's database is a rebuildable read-model plus orchestration state. See Data, Indexing & Workers.

Technology

Python (fully async) services on Kubernetes, PostgreSQL for the domain read-model, task queues and dedicated workers for background automation, schema migrations applied as a gated pre-deployment step, and cloud KMS/HSM for all transaction signing.