Arkena is four moving pieces. Three of them you talk to directly from a dApp; the fourth you only ever talk to through the others.
The four parts
The wallet (Chrome extension). Generates and holds the user's keys.
Shows transaction summaries, signs locally. Exposes window.arkena to
any browser tab.
The dApp (your code, or arkena.io). Talks to the wallet via the
provider, talks to the backend over HTTP. Doesn't see keys; doesn't see
the ledger directly.
The backend (Spring Boot). Indexes the ledger into a fast read store, exposes a REST API for reads, builds prepare-payloads for every state change, submits signed transactions to Canton, runs the swap matching engine.
Canton (the ledger). The shared source of truth. Holds contracts that encode ownership, listings, swap intents, and LP quotes. Settles atomic transactions when the right signatures are present.
How they fit
What your dApp actually talks to
Two endpoints:
- The Arkena wallet provider at
window.arkena. For connecting, signing, and listening to wallet state. - The Arkena backend at
https://api.arkena.io(or the local proxy if you're usingarkena.ioitself). For reads and for the prepare / execute halves of every state change.
You do not talk to Canton directly from a dApp. You don't talk to the extension's storage, its background worker, or its content script. The provider surface is the entire wallet API.
Why prepare/execute, not eth_sendTransaction
Canton transactions are explicit about which parties co-sign. The backend pre-builds the transaction (a Canton concept called interactive submission), the wallet signs the resulting hash, the backend submits.
This is described in detail in The signing model. The short version: the backend has to be involved in transaction construction because it has the indexed view of the ledger needed to fill in current contract IDs and counterparty inputs.
What lives where
| dApp | Wallet | Backend | Canton | |
|---|---|---|---|---|
| User's private keys | ✓ | |||
| User's public party ID | ✓ | ✓ | ✓ | ✓ |
| NFT metadata, listings, balances (read) | ✓ (PQS) | ✓ (canonical) | ||
| Active swap intents and LP quotes | ✓ (cache) | ✓ (canonical) | ||
| Transaction signatures | (produces) | (relays) | (verifies) | |
| Settlement | ✓ |
PQS (the Participant Query Store) is the backend's read-side index over the ledger. It exists so reads are fast — querying the ledger directly for, say, "every NFT owned by party X" would be slow.
What's next
- The signing model — the deep explanation of prepare/execute.
- Sign-In with Canton — authentication for the backend reads.
- Detect the Arkena provider — start writing code.