Core Concepts: Router & Primitives

This page gives you a mental model for the core building blocks you use when building or connecting to the Router:

• The Router as an application orchestration layer
• Global identities for Routers, Investors, Assets and SuperApps
• Primitives: models, intent types and orchestration plans

It’s meant for SuperApp developers.
For protocol / infra / custody deep dives, see the links at the end of this page.

1. The Router in one paragraph

The Ownera Router is an application orchestration layer for institutional finance.

It:

• Connects financial institutions, ledgers and applications
• Exposes a unified API surface:
  • REST – transactional actions (create investors/assets, submit intents, manage configuration)
  • GraphQL – reads (portfolios, positions, balances, workflows, events)
• Executes orchestration plans:
  • Multi-step workflows that coordinate participants across Routers, ledgers and Utility services

From a SuperApp’s perspective:

You talk to one Router API.
The Router talks to other Routers, ledgers and Utility SuperApps for you.

Under the hood (optional reading):
→ The Router Fundamentals – how Routers actually communicate, route and execute workflows.

2. Global identities

Everything you do on the Router is expressed over global identities:

1. Router identity

   • Represents a specific Router instance operated by an institution (or by Ownera on its behalf).
   • Has a cryptographic identity and address so other Routers can route messages and trust its signatures.

2. Investor identity

   • Represents an investor or client (individual or institution).
   • Links to:
     • Cryptographic keys / accounts
     • Custodians or wallet providers
     • Regulatory / KYC / segmentation data (via models and metadata)

3. Asset identity

   • Represents a financial asset or instrument.
   • Has:
     • A physical identity / location (link to the asset location in the real world)
     • A financial identity (how it is represented as a financial instrument)
   • Linked to on-chain or off-chain representations via models and adapters.

4. SuperApp identity

   • Represents a specific application or service (Business or Utility SuperApp).
   • Used for:
     • Authentication and permissions
     • Routing intents and callbacks
     • Auditing which applications participated in which flows

You usually don’t manage cryptography directly; you work with IDs returned by the Router and include them in your calls.

Under the hood (optional reading):
→ Custody and the Investor Identity – how investor identities, keys, custody routing and FinID actually work.

3. Primitives: models, intent types, orchestration plans

On top of global identities, the Router provides primitives that describe and drive business flows.

3.1 Models

Models are structured representations of entities and states, for example:

• Investor profiles
• Assets and their attributes
• Positions and balances
• Contracts, orders, trades, events

They define:

• What fields exist (e.g. currency, quantity, issuer, maturityDate)
• How entities relate to each other (e.g. positions belong to investors and reference assets)

As a SuperApp developer, you:

• Map your internal domain objects → Router models
• Use Router models in:
  • REST payloads (for actions)
  • GraphQL queries (for reads)

3.2 Intent types

An intent is a business action expressed over global identities and models.

Examples (illustrative):

• SUBSCRIBE – invest into a fund / product
• REDEEM – exit a fund / product
• TRANSFER – move positions between accounts or investors
• LOAN – initiate a financing / repo-style flow
• PRIVATE_OFFER – private trade offer
• BUY / SELL - bulletin board style offers

Each intent type has:

• A name (SUBSCRIBE, OPEN_FINANCING, etc.)
• A schema:
  • Required parameters (e.g. investorId, assetId, amount)
  • Constraints (e.g. allowed ranges, currencies, date formats)
• Rules about who can initiate it and under which conditions (via Domain Protocols and Router config)

As a SuperApp developer, you:

• Choose which intent types your app needs
• Build payloads that follow their schemas
• Submit intents via REST to the Router

3.3 Orchestration plans

An orchestration plan is a distributed template for a multi-step workflow that runs when an intent is submitted.

It encodes:

• The sequence of steps (validate, route, reserve collateral, move cash, finalize, etc.)
• Which Routers and Utility SuperApps are involved at each step (execute or approve)
• Dependencies and branching (e.g. “if validation fails, abort and compensate; if it passes, continue to allocation”)
• Settlement and lifecycle guarantees

When you submit an intent:

1. The Router picks an appropriate orchestration plan configuration (based on domain protocols, configuration, counterparties, etc.)
2. It executes that plan across:
   • Your Router
   • Counterparties’ Routers
   • Utility SuperApps (connectivity, data, collateral, cash, etc.)
3. It updates an orchestration instance whose state you can query (status, steps, events).

As a SuperApp developer, you usually:

• Don’t author orchestration plans yourself (at least initially)
• Just:
  • Submit intents
  • Track orchestration state via REST / GraphQL
  • React in your app (update UI, workflow, downstream systems)

Under the hood (optional reading):
→ Intent-Based Orchestration (Orchestration Plan Capabilities) – how orcs are defined, chosen and executed.