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. Each institution picks and chooses which counterparties, apps and data providers its Router connects to, and which products it surfaces to its own customers.
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.
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.
Need-to-know privacy applied to the primary sale above: only the parties to a trade see the trade. Each Router receives the instructions and proofs it needs, and nothing more.
| Party | What it sees | What it does not see |
|---|---|---|
| Investor's Router | The whole plan it authored, every receipt and proof | The issuer's or payment provider's internal systems |
| Issuer's Router | The sale, its own token instruction, the proofs it needs | The investor's other positions and trades |
| Payment provider's Router | The cash leg it holds and releases | Anything beyond the instructions and proofs it needs |
| Every other Router | Nothing | The trade exists at all |
| The chain | The settlement, hidden by its own privacy feature | The business logic, which never goes on-chain |
Our reading of Ownera's documentation and its privacy paper. More on the privacy page, including privacy by chain.
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 |
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.