About Domains

Audience: Technical Leaders, Developers · Read time: 7 min

Every wallet address on the ledger ends with a domain. In svgs:4242@bank.co, the domain is bank.co. In store1@starbucks.com, it is starbucks.com. The domain is not decorative — it is the mechanism that tells the ledger who owns a resource, how to group related resources together, and how to resolve a payment when no exact match exists.

What a domain is

A domain is the institutional namespace that scopes every resource on the ledger. Wallets, anchors, and signers all carry a domain, and that domain tells you who is responsible for them.

treasury@bank.co belongs to the bank. main@starbucks.com belongs to Starbucks. qr0000001@starbucks.com is an anchor that belongs to Starbucks as well. The domain is the shared identifier that groups all of these together under one institutional roof — even though they are different kinds of resources with different purposes.

This is a deliberate design choice. Financial systems have historically used short codes and abbreviations to identify participants — a three-letter bank code, a numeric institution identifier, a proprietary network label. These work inside a single network but break down the moment you try to route payments across networks or countries. Two banks in different countries can share the same three-letter code with no way to distinguish them. Domains, being globally unique by design, eliminate this ambiguity. bank.co and bank.us can coexist on the same ledger without any naming conflict, and every resource under each domain is unambiguously owned by the institution that controls it.

How domains scope resources

Everything at @starbucks.com belongs to Starbucks. This scoping is both a logical grouping and a structural boundary. When you query wallets or anchors in a domain, you see only that participant's resources. When access control is configured, policies on the domain apply to all resources underneath it. When a bridge is linked to a wallet in the domain, it handles operations for that participant.

The namespace property has a practical benefit for address collision. Two different merchants can each have a store1@ wallet — one at store1@starbucks.com and another at store1@dunkindonuts.com — because the domain makes them distinct. The ledger treats them as completely separate resources. There is no registry of short names or unique prefixes required because the domain carries all the uniqueness the ledger needs.

The same scoping applies to anchors. A QR code anchor like qr0000001@starbucks.com lives in the Starbucks domain alongside the merchant wallet it points to. When the bridge processes an inbound QR payment, it resolves the anchor within the domain, finds the store wallet, and walks the domain hierarchy for the fields the store wallet doesn't define on its own.

Signers are domain-scoped in the same way. A signer registered under @bank.co is an authorized operator within that institution. The domain establishes the boundary of authority — a signer in one domain cannot act on behalf of a wallet in another unless the ledger's access control explicitly permits it.

Domain hierarchy and inheritance

Domains do more than group resources — they establish a parent-child relationship that bridges use when resolving payment data.

Consider a merchant with multiple locations. Starbucks onboards once, creating main@starbucks.com with the full business profile: name, city, tax ID, category, country, tax regime, acquirer, and settlement account. Each physical store then gets its own wallet — store1@starbucks.com, store2@starbucks.com — carrying only the fields specific to that location: name, city, and postal code.

When a payment arrives at a store and the bridge needs to generate the network payload, it does not stop at the store wallet. It reads store1@starbucks.com, finds that tax ID and settlement account are absent, and looks up main@starbucks.com in the same domain to fill them in. The convention is that main@ in a given domain is the parent entity that stores inherit from. The bridge resolves the complete profile by combining the store's specific fields with the merchant's shared fields.

This hierarchy has a concrete operational effect. When Starbucks changes its settlement account — moves its money to a different bank — they update one wallet: main@starbucks.com. Every store wallet inherits the change automatically. There is no need to update hundreds of store wallets or re-run an onboarding flow. The domain hierarchy makes the merchant wallet the single source of truth for everything the stores share.

The same principle applies at the institution level. A bank may have a hierarchy of wallets — an institution wallet that holds regulatory and correspondent information, settlement wallets that represent external bank accounts, and individual account wallets for each customer. When the ledger routes a payment and encounters an address it has no exact record for, it walks up the hierarchy to find a wallet that can handle it. chk:10500029@bank.co resolves to that specific checking account if it exists; if not, the ledger tries chk@bank.co, then bank.co. A single institution-level wallet can receive all payments addressed to accounts at that bank until individual account wallets are created.

Cross-domain operations

Most payments cross domain boundaries. An intent from treasury@bank.co to svgs:4242@starbucks.co moves money between two institutions — two different domains, each with its own wallets, its own bridge, and its own external system.

The ledger coordinates this through two-phase commit. When the intent is created, the ledger identifies the source domain's bridge and the target domain's bridge. The source bridge handles the debit — it communicates with the bank's core system to confirm the funds are available and reserve them. The target bridge handles the credit — it communicates with Starbucks's bank to confirm it can receive the funds. Only when both sides agree does the ledger commit the transaction. If either side fails, both sides roll back.

From the perspective of the intent, the domain boundary is transparent. The payment sender addresses svgs:4242@starbucks.co and the ledger handles the rest. The routing logic, bridge selection, and two-phase coordination are all driven by the domain portions of the addresses involved. The ledger knows that @bank.co maps to one bridge and @starbucks.co maps to another because each wallet in each domain carries a bridge reference. Domains are how the ledger knows which external system to talk to and in what order.

Cross-domain payments are also how the ledger enables interoperability between participants that have no direct connection to each other. Two merchants on different acquiring banks can settle payments between them because the ledger coordinates both sides — each party sees only their own domain, and the ledger manages the handoff.

Domain naming conventions

Banks use their institution domain. Merchants use their business domain. Government agencies, fintechs, and payment operators each use their own. The convention throughout Minka's documentation uses familiar examples — bank.co for a bank, starbucks.com for a merchant — because real domain names are easier to reason about than invented codes.

Domains on the ledger are ledger constructs. They do not resolve to DNS records or require the participant to control the domain name in any technical sense. starbucks.com on the ledger is an identifier agreed upon during participant registration — the ledger uses it as a namespace, not as a network address. That said, using real domain names is strongly encouraged because it eliminates naming collisions, makes integrations self-documenting, and simplifies audits. When you read an intent log and see @bank.co, you know immediately which institution is involved.

The choice of domain also signals the level of the hierarchy. Top-level domains (bank.co, starbucks.com) represent the institutions themselves. Subdomains can represent divisions or regional entities — a bank's subsidiary might operate under subsidiary.bank.co, with its own namespace while remaining legibly connected to the parent. This flexibility lets the ledger model complex institutional structures without inventing a proprietary hierarchy format.

Relationship to the addressing scheme

The full wallet address is schema:number@domain. The schema describes the account type — svgs for savings, chk for checking, tel for a phone-linked account. The number is the specific identifier — an account number, phone number, or generated handle. The domain scopes the address to an institution.

Together, the three parts give the ledger everything it needs to route a payment. The schema tells it what kind of account this is. The number tells it which specific account. The domain tells it which institution owns it and which bridge to use. A payment to svgs:4242@bank.co carries all three pieces of routing information in a single string — no lookup tables, no routing codes, no separate address registry required.

The domain is the piece that connects the human-readable identifier to the ledger's internal infrastructure. Change the domain, and the same account number at a different institution is a completely different wallet. Keep the domain and change the schema or number, and you stay within the same institution but address a different kind of account. The address is composable, and the domain is the anchor that makes the composition meaningful.

For a closer look at how wallets use domain-based addresses, see About Wallets. To see domain hierarchy in practice — including the full merchant onboarding flow — see How to Onboard a Merchant.