About Signers

How cryptographic identity works on the ledger — every operation is signed, every signature is verifiable, and every participant controls their own keys.

Audience: Technical Leaders, Security Engineers · Read time: 6 min

Every action on the Minka ledger requires a signature. Not a username and password, not an API token that grants broad access — a cryptographic signature tied to a specific key pair that the ledger can verify independently, without trusting any central authority. Signers are how the ledger knows who is doing what, and how it can prove it later.

What a signer is

A signer is an Ed25519 key pair. The private key stays on the participant's machine, encrypted in the local CLI configuration at ~/.minka/. The public key is registered on the ledger. Every API request carries a signature computed by the private key, and the ledger verifies that signature against the registered public key before it processes anything.

This design means the ledger never sees your private key. It doesn't need to. It only needs the public key — a piece of information that is safe to share widely — to confirm that a request came from someone in possession of the corresponding private key. The cryptographic guarantee is unambiguous: only the holder of the private key could have produced that signature.

When you run minka signer create, the CLI generates a fresh Ed25519 key pair. It stores the private key locally, encrypted with a passphrase you control. It prints the public key so you can register it on the ledger. From that point on, any request signed with that private key is recognized as yours — and any attempt to forge or tamper with that request will fail verification.

Signer versus user

It helps to keep two concepts separate: a signer is a cryptographic key, not a person or system. A user — whether human or automated — holds one or more signers and uses them to authorize operations.

A bank deploying Minka might have a treasury team that submits large interbank transfers, a customer service team that can query balances and reverse transactions, and an automated settlement system that runs overnight without human involvement. These are distinct operational contexts with different permissions and different accountability requirements. Rather than trying to capture this through role-based access on a shared credential, the bank creates separate signers for each context. Each signer has its own key pair, its own registered permissions, and its own audit trail.

The separation matters for security and for accountability. If the automated settlement system's key is compromised, the treasury team's key is unaffected. If an audit needs to trace who authorized a specific transaction, the signature identifies exactly which signer — and therefore which operational context — was responsible.

How signers are registered

Creating a signer and registering it on the ledger are two related but distinct steps. The CLI's minka signer create command handles the first step: generating the key pair and storing the private key locally. The public key that the command prints is what you bring to the ledger.

When you create a ledger with minka ledger create, the CLI registers the signer you specify as the ledger's first administrator. That signer's public key is written to the ledger, and from that point on the ledger recognizes signatures from that key as administrator operations. Additional signers — for operators, for read-only access, for automated systems — are registered by an authorized administrator who creates the appropriate records and assigns them to the right circles and policies.

Other participants on the ledger can verify your signatures using your public key at any time, without access to your private key and without going through a central trust authority. The verification is self-contained: the ledger holds the public keys, and the cryptographic math makes forgery computationally infeasible.

What signers can do

A signer's capabilities on the ledger come from the circles and policies it belongs to, not from anything inherent in the key itself. A freshly created signer with no assigned permissions can authenticate to the ledger but cannot do anything meaningful. Permissions are granted explicitly.

A ledger administrator signer can create and configure wallets, symbols, and policies. It can register new participants and assign them to circles. It can change the rules that govern how balances move. These are high-privilege operations, and the key used for them deserves proportionally careful handling.

An operator signer might have narrower permissions: the ability to submit intents and query transaction status, but not to modify ledger configuration. An automated settlement system might have even narrower permissions still — enough to execute a specific class of interbank transfers, nothing more. A reporting signer might be able to read balances and transaction history but not authorize any movement of funds.

The ledger enforces these boundaries on every request. A request signed by an operator signer attempting an administrator action will be rejected at the policy level, regardless of how the request is constructed. The permissions are not advisory — they are enforced.

Working with multiple signers

Participants typically accumulate several signers as they build out their ledger integration. The CLI stores all of them encrypted in the local configuration directory. You can list them, inspect their public keys, and select which one to use for a given operation.

Maintaining separate signers for separate roles is a discipline worth establishing early. The temptation is to use one signer for everything during development — it's simpler. But a single key that can do anything is a single point of failure. If it's compromised, everything is compromised. If it's misused, the audit trail doesn't tell you which function the misuse was associated with.

A more robust pattern is to create an administrator signer that you use only for ledger configuration, an operator signer for day-to-day payment operations, and read-only or limited signers for integrations that only need to query data. This matches how teams actually work, and it means that routine automation never runs with the ability to change ledger configuration.

When switching between tasks — configuring the ledger in the morning, then submitting test payments — you change which signer the CLI uses for that session. Each operation then carries the appropriate signature for its authorization level.

Why signing matters

The signing requirement is not primarily a security feature, though it provides strong security. It's a design choice about accountability and verifiability.

Every transaction on the ledger carries the signature of the signer that authorized it. If a payment is disputed, the ledger can produce the signed record and prove exactly which key authorized it and when. This proof is not contingent on log files that someone could alter, or on a central authority's word. The cryptographic signature is the proof — anyone with the public key can verify it independently.

This property makes the ledger suitable for environments where multiple institutions need to coordinate without fully trusting each other. No participant can claim they didn't authorize something that carries their signature. No participant can alter a record they didn't sign. The audit trail is built into the protocol itself, not bolted on afterward.

For institutions building payment infrastructure, this changes what audit and compliance look like. Instead of maintaining separate logging systems and hoping they weren't tampered with, the evidence is inherent in every record the ledger holds. The burden of proof is cryptographic.

Key rotation

Signers should be rotated when a team member leaves the organization, when a key may have been compromised, or as part of a regular security policy (e.g., annual rotation).

The rotation process follows four steps:

Create a new signer. Generate a fresh Ed25519 key pair using minka signer create. The new private key is stored locally, encrypted with your passphrase.

Register the new signer on the ledger. The new public key must be registered and granted the same permissions (circles, policies) as the signer it replaces.

Update all systems that use the old signer. Any bridge configuration, backend service, or automated process that signs requests with the old key must be updated to use the new key pair. This is the most operationally sensitive step — coordinate the cutover to avoid a window where neither key is active.

Deactivate the old signer. Remove the old signer's permissions on the ledger. The old signer's public key remains on the ledger as a historical record — any past signatures made with that key are still independently verifiable for audit purposes. Deactivation prevents new operations, but the cryptographic audit trail of past operations remains intact.

Never delete a signer record from the ledger. Deactivate it instead. Deleting a signer would break the verifiability of every historical record it signed — the cryptographic chain of custody depends on the public key remaining available for verification.

To create your first signer and connect it to a ledger, see How to Connect to a Ledger. For background on the coordination layer that signers operate on, see About Ledgers.