Mints

Mints Identity

Identity for every principal in your organization.

W3C decentralized identifiers with human-rooted lineage. FROST threshold signing that requires no single trusted keyholder. Hardware-backed WebAuthn for humans, verifiable DIDs for agents — one identity layer for every principal.

DIDs · FROST / MPC · WebAuthn · multi-chain keys

Lineage — humans and agents, one root

Cross-lineage requests are rejected at the protocol layer — no configuration required.

3

Principal kinds — human, organization, agent

m/n

FROST threshold — no single point of key compromise

1

Human root per lineage — every agent traces here

Who is a principal?

Three kinds. One lineage model.

Every entity Mints recognizes — human, organization, or agent — gets a W3C DID. Every DID traces to a human root through a cryptographically-signed lineage chain.

Human

did:oas:…:hmr

Human member root. The accountability anchor for every lineage.

Organization

did:oas:…:enr

Entity node root. Groups agents under one human-rooted lineage.

Agent

did:oas:…:agent

Autonomous actor. Provably traces to a human root — always.

Lineage isolation

Every agent traces to a human root.

Cross-lineage access fails closed at the protocol layer. There is no ACL to misconfigure, no permission to grant and forget. One organization cannot fund, view, or direct another organization's agents.

Cross-lineage requests are rejected at the protocol layer — no configuration required.

01

Lineage is cryptographic, not configurable

The proof that an agent belongs to your organization is derived from signed key material, not from a database row. Tampering breaks the signature — there is nothing to mis-set.

02

Accountability always traces to a human

Any action an agent takes — payment, escrow, credential request — is traceable to the human root who owns that lineage. There are no anonymous autonomous actors in Mints.

Threshold key management

m-of-n signing. No single point of compromise.

FROST threshold signatures split key material across multiple keyholders. A quorum must cooperate to produce a valid signature — but no keyholder ever assembles the full key.

FROST threshold ceremony

3 / 3 required
admin-aliceshard contributed
board-bobshard contributed
cfo-carolshard contributed
agent-vaultpending
guardian-davepending

No single keyholder holds a complete key. Shards combine only at signing time, never stored together.

illustrative threshold — quorum you define
3/5
01

No single point of key compromise

Individual key shards are mathematically insufficient. An attacker would need to compromise multiple independent keyholders simultaneously.

02

Shards never stored together

Threshold parties store their shards independently. Mints coordinates the ceremony — it never holds a shard, and the full key is never reconstructed in one place.

03

One DID, threshold-backed

The threshold key is bound to a single DID. Counterparties verify the DID — they need not know how many keyholders underpin it.

A quorum that must cooperate is safer than a secret that must be kept.

— Mints key management model

Asking 'who is this agent?' should have a provable answer — not a policy lookup.

— Mints Identity design principle

Human authentication

WebAuthn. Hardware-bound. Phish-proof.

Human operators in Mints authenticate with modern multi-factor methods — including hardware security keys and platform authenticators. Passwords are not in the model.

Mints Identity

Hardware-bound, phish-proof, verifiable

Password-based auth

Replayable, breachable, unverifiable

Phishing-resistant by design
Credential stored on hardware key
Works without a shared secret on the server
Biometric or PIN local unlock
Cryptographically bound to origin
Breach exposes nothing reusable
WebAuthn / FIDO2 vs username + password

Method 01

Hardware security keys

FIDO2-compliant hardware keys (YubiKey, Titan, etc.) store credential private keys in tamper-resistant silicon. The key never leaves the device.

Method 02

Platform authenticators

Touch ID, Face ID, and Windows Hello backed by the Secure Enclave or TPM. Fast, biometric, hardware-bound.

Method 03

TOTP as a second factor

Time-based one-time passwords available as a second factor where hardware authenticators are not practical. Phishing-resistant methods are always preferred.

Key lifecycle

Generate, bind, attest, sign, rotate.

Every key material lifecycle is audited. Generation is local, attestation is hardware-backed, rotation produces an immutable event — nothing is hidden or undocumented.

Generate

Ed25519 key material generated on-device via a CSPRNG. Never leaves the hardware boundary.

Bind to DID

The public key is registered to the principal's W3C DID document. The binding is signed and timestamped.

Attest

Hardware attestation (FIDO2 / Secure Enclave) proves the key was generated on genuine hardware.

Sign

Operations are signed locally. Mints verifies the signature; it never sees the private key.

Rotate

Key rotation appends a new binding to the DID document. The old key is revoked with an immutable event.

Multi-chain key management

One identity layer, every chain your treasury touches.

Mints Identity manages key material across chains without fragmenting your identity model. The same DID binds the same principal regardless of which chain an operation settles on.

01

Chain-agnostic DID

The OAS DID is chain-agnostic. The same identity works on Ethereum, Solana, or any other chain Mints supports — no chain-specific identity silos.

02

HKDF key derivation

Chain-specific key material is derived from a master key using HKDF-SHA256, so your key hierarchy is auditable and deterministic.

03

BIP-44 / SLIP-0010 paths

Hierarchical key derivation follows standard paths. You can independently verify key derivation — no proprietary black box.

04

Unified audit trail

Every key derivation, rotation, and signing event across all chains appears in the same immutable event log — one audit for every chain.

05

Threshold on any chain

FROST threshold signing is chain-agnostic at the cryptographic layer. Treasury quorums work identically regardless of settlement chain.

06

Guardian recovery across chains

Guardian-based key recovery works across your entire key hierarchy — losing a device does not mean losing your multi-chain treasury.

Related service

Mints Custody

Identity binds the keys. Custody decides who can use them for treasury operations. m-of-n quorums, guardian recovery, and policy-gated signing — built on the same lineage model.

API documentation

Identity API reference

DID resolution, session management, WebAuthn credential registration, threshold ceremony coordination, and key rotation — all documented in the API reference.

Every principal deserves a verifiable identity.

Mints Identity is in early access. Bring your agent fleet — or just yourself.