One check. Every identity.

Paste anything. Get one signed answer.

A company domain, an API, an MCP server, an A2A agent card, a GitHub account, a Hugging Face model, an npm or PyPI package, an SSH key. A wallet too. MIZAN reads what it is, resolves it to its owner's proof, and signs the answer.

15 kinds of identity link today. Each by proving control.

An identifier joins your subject only when you prove you control it, with the method native to its world: a DNS record for a company, a file for a service, a publish for a package, a signature for a key. Nothing is inferred, and nothing is linked for you.

Landing next: sign-in platforms (Google, Microsoft, LinkedIn, X, Discord, Slack, Okta), work email, passkeys for people, legal entities by LEI, brokerage and exchange accounts through a read-only key, and more chains. The live list is always at GET /api/link/kinds.

Two calls and a signature. No account.

Claim an identity, ask for a challenge, publish its nonce (a DNS record, a file, a package release) or sign it with your key, complete. From then on, check() on that identifier carries your proof, and your stapled receipt binds every identity you linked.

# 1 · an identity, no account
POST /api/agents/claim            → api_key
# 2 · a message to sign
POST /api/link/challenge
     {"identifier": "yourcompany.com"} → nonce
# 3 · add the DNS record, complete
POST /api/link/complete
     {"challenge_id": "…"}
LINKED  · one log leaf, a hash only

# at studio.mizan.market/mcp
claim_identity()
link("https://you.ai/mcp", api_key)
  → serve the nonce
link(api_key=…, challenge_id=…)

# then, anywhere
check("https://you.ai/mcp")  → your proof

Proof of control per world: a passkey (Face ID, Touch ID, Windows Hello, security keys) for people and devices; a DNS TXT record for domains; a /.well-known/mizan-challenge file for sites, APIs, MCP servers and A2A agents; a public gist for GitHub; a MIZAN.txt file for Hugging Face; a published release for npm and PyPI; an SSH signature (ssh-keygen -Y sign) or ed25519 signature for keys and did:key; and for wallets, the signing standard of each chain (EIP-191 plus smart-contract wallets via EIP-1271 and ERC-6492, ed25519, BIP-322 Taproot and BIP-137, ADR-036, Sui, Aptos, Tron, NEP-413, SEP-53). Each challenge is single-use and expires in ten minutes.

Every chain reads it. We deploy nothing.

The same proof, signed for each chain's own verifier: one ecrecover on EVM chains, native ed25519 on Solana, Sui, Aptos, NEAR, Stellar, TON and the rest. Import one library, add one check, and your contract refuses capital to anything unproven. No oracle, no call to MIZAN.

import {MizanProof, MizanGated} from "./MizanProof.sol";

contract Vault is MizanGated {
  function allocate(address agent,
      MizanProof.Receipt calldata r, bytes calldata sig)
    external onlyProven(agent, r, sig) { … }
}

GET /api/staple/0xAgentWallet
→ receipt   (agents verify offline)
→ eip712[]  (contracts verify on-chain)

# same answer, two signatures
# issued only while the owner passes

use mizan_onchain::{verify_with, kind};

// the chain's own ed25519 verifier does the math
verify_with(&receipt, &sig, kind::NEAR, caller.as_bytes(), now,
            |k, m, s| env::ed25519_verify(s, m, k))?;

Libraries (MIT): MizanProof.sol · ProvenPayout.sol · mizan-onchain (Rust). Every chain receipt uses one fixed 86-byte layout (mizan-compact/1), so contracts parse it with no JSON. The signer is published in /.well-known/mizan-keys.json. Receipts last 24 hours, state a fact about an identity, and authorise nothing.

Every one of them. One answer.

Ranked live by DeFi value locked (DefiLlama). For each chain: how a smart contract reads a MIZAN proof, and whether its wallets link today.

Source: GET /api/chains. MIZAN integrates signature curves, not chains: secp256k1 and ed25519 cover every programmable chain on this list. Where a chain has no general smart contracts, agents, wallets and platforms verify the receipt off-chain.

Consent in. Proof out.

Staple your proof · The check · Require it