FinP2P is not a blockchain. It is a way for financial institutions to run transactions across many blockchains, custodians and legacy systems without integrating with each other one by one. Every institution runs its own Router inside its own walls. Routers find each other and talk peer to peer. An application only ever talks to its local Router.
1. The shape of the network
Three things sit inside each institution: the business apps people use, the Router, and adapters that translate the Router's instructions into that institution's own ledgers and systems. Only signed instructions and proofs cross the boundary.
Each institution keeps its own Router. Apps above it submit business intents and read state through one API. Adapters below it do the actual work on whichever ledger, custodian or legacy system the institution uses. The green dashed lines are the FinP2P network: Routers talking directly to each other.
Router to Router (FinP2P)inside one institutiondiscovery only
2. One transaction, end to end
The unit of work is a business intent: "buy 10,000 units of this fund, settle in USD." The app never says which chain, contract or custodian. The Router turns the intent into an orchestration plan, a set of instructions spread across every Router involved, and drives it to completion.
A primary sale of a tokenized fund. The investor's Router authors the plan; the issuer's and payment provider's Routers each execute only their own instruction on their own ledger through their own adapter. Nobody hands keys or positions to anyone else. The app polls or subscribes for the plan status and gets receipts when it completes.
3. What the Router works with
Four identities and three primitives cover everything. Developers mostly create profiles, submit intents and watch plans; they rarely touch orchestration plans directly.
Thing
What it is
Example
Router identity
An organization on the network. Cryptographically anchored; other Routers trust it through the registry.
bank-us
Investor identity
A client profile with one or more FinIDs (public keys) across custodians, plus KYC and accreditation certificates.
bank-us:101:<uuid>
Asset identity
One asset profile with representations on each chain it lives on, plus KYA and NAV certificates.
issuer-de:102:<uuid>
App identity
A business app or connector, used for auth, routing and audit.
SuperApp ID
Intent
A business action with a schema: primary sale, secondary buy or sell, transfer, redemption, repo loan.
bank-us:105:<uuid>
Orchestration plan
The distributed workflow the Router generates from an intent and runs across participants.
bank-us:106:<uuid>
Adapter
Code the institution runs beside its Router: ledger, custody, payment or data. Speaks a fixed API; the Router never sees the ledger directly.
EVM adapter, our LunarCrush data adapter
4. Example: where our data utility plugs in
A data provider is just another adapter, on the provider's side rather than the consumer's. It answers pull and subscribe requests and pushes items into a Router's ingest endpoint. That Router can then re-share the feed to peers under an access list, so one adapter serves the whole network.
The Social and Market Data SuperApp is the "Data adapter" box. It never touches a trade. Consumer Routers subscribe to it the same way they subscribe to a price or ratings feed.
Drawn from Ownera's developer documentation (finp2p-docs.ownera.io) and the SuperApps store. Simplified: real plans have more instruction types (hold, release, transfer, issue, await, redeem) and Routers can also be Ownera-hosted or shared through a hub.