Skip to content
Last updated

Core concepts

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

How Vilna works

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.

On-chainEvery networkTransactions land across every supported chain.BitcoinEthereumSolanaTRON
reads
PlatformObserves & normalizesTracks confirmations, reorgs and HD derivation, then turns raw chain data into one canonical shape.read-only · non-custodial
delivers
Your appOne API + webhooksClean, chain-agnostic data and signed real-time events.
Platform monitoring reads chain data and delivers it to your app. It does not sign or broadcast transactions. VKS signing is a separate workflow.

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.

Built safely and openly

Core guarantees
Non-custodial

Platform monitoring uses public chain data: addresses and public keys, never private keys or seed phrases. It cannot move your funds.

No cut of your funds

Because Platform monitoring never touches your money, it never takes a percentage of any payment or transaction it observes.

Standards-first

Open specifications throughout: CAIP ids for chains and assets, BIP-32/44 derivation, RFC 7807 errors. No proprietary formats.

Chain-agnostic

One REST API and one response shape across every network. Adding a chain doesn't change your integration.

APIs for different tasks

Each service has its own credential and scope. Create the workspace and keys in the Dashboard, then use the documented public operations:

New to the underlying ideas - addresses, keys and HD derivation? Start with Blockchain basics.

Data you can rely on

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) and formatted (display text). Authenticated invoice amount, received_amount and confirmed_amount are plain base-unit strings; the public invoice view instead has base and optional formatted. Follow each field's schema. Use BigInt or an exact decimal library for calculations, and the exact token's metadata decimals for display. See the invoice formatter.
  • Resolved references. Responses include a references object 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.