The Vilna Platform API monitors addresses, wallets and incoming payments and returns normalized data through a REST API and event notifications. It uses public chain data. See Networks for supported mainnets and testnets; Solana supports address registration and the token catalog only.
Non-custodial by design One API, 9 networks Open standards No cut of your funds
The Platform API provides normalized public-chain data for your application. Depending on the network, it registers addresses, reads balances and transactions, tracks confirmations and sends notifications at your selected trigger. Check the network matrix for the available capabilities.
Because it only ever reads chain data, the Platform API works exclusively with public information: blockchain addresses and extended public keys. It never asks for, holds, or stores private keys or seed phrases, and it cannot sign or broadcast a transaction. Your keys and funds stay exactly where they are.
These monitoring principles describe Platform API. VKS is a separate signing workflow; see APIs for different tasks.
Platform monitoring uses public chain data: addresses and public keys, never private keys or seed phrases. It cannot move your funds.
Because Platform monitoring never touches your money, it never takes a percentage of any payment or transaction it observes.
Open specifications throughout: CAIP ids for chains and assets, BIP-32/44 derivation, RFC 7807 errors. No proprietary formats.
One REST API and one response shape across every network. Adding a chain doesn't change your integration.
Each service has its own credential and scope. Create the workspace and keys in the Dashboard, then use the documented public operations:
Monitor addresses and wallets, read balances and transactions, reconcile incoming payments, and get notified on activity.
Talk to blockchain nodes directly across every supported network through a single endpoint and one key, with no infrastructure to run.
Use published workspace, project and member operations; credential bootstrap and some key actions require the Dashboard.
VKS coordinates account setup, signer approvals and signing; a complete signed transaction can optionally be sent to a node through VKS. Node acceptance is not blockchain confirmation.
New to the underlying ideas - addresses, keys and HD derivation? Start with Blockchain basics.
For Platform API events, whatever chain an event comes from, the response shape is the same, so your code is written once, not once per network.
- Amounts. Many transaction and balance fields carry
base(an integer string in the token's smallest unit) andformatted(display text). Authenticated invoiceamount,received_amountandconfirmed_amountare plain base-unit strings; the public invoice view instead hasbaseand optionalformatted. Follow each field's schema. UseBigIntor an exact decimal library for calculations, and the exact token's metadata decimals for display. See the invoice formatter. - Resolved references. Responses include a
referencesobject with the related tokens, chains and addresses, so you can render a result without extra lookups. - Stable identifiers. Chains, accounts and assets are named with CAIP ids, one identifier shape everywhere.
See the Platform API for the full resource reference and Standards for the identifier formats.