Ledger Key Concepts
Core building blocks of Minka Ledger — what they are and how they work together
The ledger organizes financial operations around a small set of building blocks called records. Each represents a different concern (identity, currency, accounts, movements) and together they form the foundation for building payment systems.
Four core records are used in every ledger interaction: signers, symbols, wallets, and intents.
| Record | Think of it as | Purpose |
|---|---|---|
| Signer | User identity | Proves who is acting |
| Symbol | Currency (e.g. USD, points) | Defines what is being counted |
| Wallet | Bank account | Holds balances |
| Intent | Payment order | Moves balances |
Together, these form the foundation for creating accounts, defining currencies, and processing payments. For example, when Alice pays Bob $50: Alice's signer authorizes the operation by creating an intent that moves 50 of the USD symbol from Alice's wallet to Bob's wallet.
Signer
A signer is a digital identity that holds keys used to authorize ledger operations by signing them. No operation can proceed without a valid signature. In practice, the Ledger SDK handles signing and hashing automatically. Signers can also carry metadata such as security constraints or links to external identity systems. Learn more in About Signers.
Symbol
A symbol identifies a unit of exchange and has a unique handle (e.g. usd, points). Ledger balances are always denominated in a symbol. Symbols can identify currencies, loyalty points, or any other concept that can be counted. Whoever controls a symbol also controls the issuance of that symbol in the ledger.
Wallet
Wallets hold balances. Each wallet has a unique handle that identifies it. This handle is used in intents, balance queries, and any other operations involving a wallet.
The handle is defined by the user, so it is useful to choose a value that is user-friendly and easy to remember. Handles can be phone numbers, emails, bank account numbers, usernames, etc. The format and types of handles mostly depend on the use case that is being built on top of a ledger.
Wallets are used to represent anything that can hold a balance. For example, bank accounts, loyalty point accounts, subscriptions, bills, loans, etc. All of those use cases can be modeled by mapping them to wallets. Learn more in About Wallets.
Intent
An intent is a request to move or modify balances. Most commonly, intents transfer balances between wallets, but they can also issue new balances or perform other operations. Each intent contains one or more claims, the actual balance movements it will execute. Most intents have a single claim, but when multiple movements need to happen together they are grouped in one intent. For example, transferring 100 USD to a recipient while collecting a 2 USD fee into a bank fees wallet would be a single intent with two claims.
All claims in an intent are processed atomically — either every claim succeeds, or none of them do. When an intent fails, the ledger reverses all claims and records the reason. See About Intents for the full lifecycle and the Error Reference for common failure codes.
Each intent must have a unique handle, which prevents duplicate processing if a request is retried (idempotency) and provides a convenient way to look up past operations.
Intents support custom data like all other records. For example, an invoice ID, payment description, or location. Learn more in Custom Fields.
REST API
All records are available through a standard REST API and the CLI. Every API resource follows the same JSON format:
{
"data": { ... },
"meta": { ... },
"hash": "...",
"luid": "$wlt.abc123..."
}| Field | Description |
|---|---|
data | The resource's primary content, including any custom fields an application needs |
meta | System-managed metadata: status, timestamps, and proofs (digital signatures that verify authenticity) |
hash | Cryptographic hash of data, ensuring content has not been altered |
luid | Ledger Unique Identifier with a type prefix (e.g. $wlt. for wallets, $int. for intents) |
See the API Reference for the full list of resource types.
Every resource is independently verifiable by checking its hash and proofs, so any participant can confirm who created it and that nothing has changed.
Beyond the Core
The ledger includes additional records beyond these four:
- Effects trigger notifications when ledger data changes, enabling event-driven integrations like webhooks.
- Bridges connect third-party systems to the ledger, coordinating balance movements so both systems stay in sync.
- Access policies and circles control who can perform operations and under what conditions.
What's next
Ready to try it? Continue to the Quickstart.