Q: What can I use Proof of Control for?

Sign-in and two-factor. Login, 2FA, account recovery and confirming a sensitive settings change. The user sends a message from Telegram, WhatsApp or SMS, so no code is sent out to be stolen. Passwordless login. A phone proof from Telegram, WhatsApp or SMS becomes the credential through the Sessions API, with no password to store or leak. Onboarding businesses. Check a merchant’s domain, business phone number or Telegram bot during know-your-business checks. Due diligence without screenshots. A company proves its domain to a bank or partner with a signed proof the other side can check offline. Trust between two parties. Before a deal, ask the other side to prove they control the domain they claim. Returning users. A signed-in user who already holds a valid proof confirms with one click instead of repeating the challenge. Public profiles. Show verified assets on a shareable page or badge.

Q: What can I use Proof of Action for?

A person before an irreversible step. An AI agent, script or pipeline stops before a payment, a deploy, a message or a deletion until a named person says yes. The request is end-to-end encrypted, and the decision is made on the approver’s own device. Human oversight. A person able to step in before the system acts — the oversight the EU AI Act (Article 14) and GDPR (Article 22) call for in high-risk systems and significant automated decisions, which Proof Holdings is designed to support. An audit trail. A signed record of what was decided and when, bound to the encrypted request, with the approver recorded on the confirmation — evidence that oversight happened. Sign-off you can prove. It replaces “OK, send it” in a chat thread, which is hard to prove afterwards. Agents. AI agents request approvals directly through our MCP server, which has 167 tools.

Q: What can I use Proof of Delegation for?

For a publisher. State, from your own domain, which npm and PyPI packages, MCP servers, endpoints and agents you authorized, and pause or withdraw any of them. For an installer or an agent. Before installing a package or connecting to a server, check that the domain you expect authorized it — from the MCP tool, the verifier library, the HTTP endpoint or one terminal command. Protection without anyone checking. A publisher that installs our self-refusal package in its MCP server has that server refuse its own tools once the delegation is withdrawn, so callers are cut off without checking anything. Supply-chain duties. It supports the supply-chain security duty in NIS2 Article 21(2)(d). Watching your name. Lookalike Watch alerts you when a new package or server name on npm, PyPI or the MCP registry could pass for your brand.

Q: What can I use Proof of Me for?

Fake-executive requests. A colleague gets an urgent payment request from someone claiming to be the CEO. They check with one tap, and the real CEO confirms or denies — on a different messenger from the one the suspicious contact used, when both Telegram and WhatsApp are connected. Family scams. Relatives get a “new number” message or a call from someone pretending to be you. Clients and partners. People outside the company check that a message claiming to come from you is real. No more code words. It replaces code words and call-back rituals that get skipped under pressure.

Question 1

What does proof.holdings do?

Accepted Answer

proof.holdings is a verification API. It answers questions a business or an AI agent cannot settle on its own, and returns a signed proof token for each completed check or decision. 4 proofs are live today (Proof of Control, Proof of Delegation, Proof of Action, Proof of Me): that a user controls a phone number, an email address or a domain; that a domain authorized a package or an MCP server to act within stated scopes; that a person approved a risky step before software took it; and that the person contacting someone really is who they claim to be. We verify what someone controls and what they decided — never who they are.

Question 2

How is this different from KYC / identity verification?

Accepted Answer

KYC verifies who someone is (name, ID, address). We verify what someone controls. We never collect identity documents, and we are not an identity provider — we don't store passwords, manage login sessions, or have access to your users' accounts. Our proof tokens demonstrate control without exposing the underlying asset to third parties. You own your user base; we just verify what they control.

Question 3

Where does the check run?

Accepted Answer

The check runs on our side, not in your application. No code is sent to your user for you to handle; the user proves control through our flow and you receive a signed proof token. The only credentials you pass us are ones you choose to: a DNS provider key for Auto-DNS, or a bot token to verify a Telegram bot. We don't store your users' passwords or control their accounts — proof tokens are cryptographic receipts of control, not session keys or access grants.

Question 4

What are sub-accounts and public profiles?

Accepted Answer

Every account can create sub-accounts — separate workspaces that each get their own public verification profile page showcasing the verified assets you assign to it. Each profile has a shareable URL (/p/ by ID or /u/ by username) with granular privacy controls — choose which assets to display and how much to reveal (full, partial, or hidden masking). Businesses can customize branding and add custom links. Verified assets, quota, and billing stay account-wide. Free accounts can create up to 10 sub-accounts; paid plans are unlimited.

Question 5

What can I use Proof of Control for?

Accepted Answer

Sign-in and two-factor. Login, 2FA, account recovery and confirming a sensitive settings change. The user sends a message from Telegram, WhatsApp or SMS, so no code is sent out to be stolen.
Passwordless login. A phone proof from Telegram, WhatsApp or SMS becomes the credential through the Sessions API, with no password to store or leak.
Onboarding businesses. Check a merchant’s domain, business phone number or Telegram bot during know-your-business checks.
Due diligence without screenshots. A company proves its domain to a bank or partner with a signed proof the other side can check offline.
Trust between two parties. Before a deal, ask the other side to prove they control the domain they claim.
Returning users. A signed-in user who already holds a valid proof confirms with one click instead of repeating the challenge.
Public profiles. Show verified assets on a shareable page or badge.

Question 6

What can I use Proof of Action for?

Accepted Answer

A person before an irreversible step. An AI agent, script or pipeline stops before a payment, a deploy, a message or a deletion until a named person says yes. The request is end-to-end encrypted, and the decision is made on the approver’s own device.
Human oversight. A person able to step in before the system acts — the oversight the EU AI Act (Article 14) and GDPR (Article 22) call for in high-risk systems and significant automated decisions, which Proof Holdings is designed to support.
An audit trail. A signed record of what was decided and when, bound to the encrypted request, with the approver recorded on the confirmation — evidence that oversight happened.
Sign-off you can prove. It replaces “OK, send it” in a chat thread, which is hard to prove afterwards.
Agents. AI agents request approvals directly through our MCP server, which has 167 tools.

Question 7

What can I use Proof of Delegation for?

Accepted Answer

For a publisher. State, from your own domain, which npm and PyPI packages, MCP servers, endpoints and agents you authorized, and pause or withdraw any of them.
For an installer or an agent. Before installing a package or connecting to a server, check that the domain you expect authorized it — from the MCP tool, the verifier library, the HTTP endpoint or one terminal command.
Protection without anyone checking. A publisher that installs our self-refusal package in its MCP server has that server refuse its own tools once the delegation is withdrawn, so callers are cut off without checking anything.
Supply-chain duties. It supports the supply-chain security duty in NIS2 Article 21(2)(d).
Watching your name. Lookalike Watch alerts you when a new package or server name on npm, PyPI or the MCP registry could pass for your brand.

Question 8

What can I use Proof of Me for?

Accepted Answer

Fake-executive requests. A colleague gets an urgent payment request from someone claiming to be the CEO. They check with one tap, and the real CEO confirms or denies — on a different messenger from the one the suspicious contact used, when both Telegram and WhatsApp are connected.
Family scams. Relatives get a “new number” message or a call from someone pretending to be you.
Clients and partners. People outside the company check that a message claiming to come from you is real.
No more code words. It replaces code words and call-back rituals that get skipped under pressure.

Question 9

What can I verify?

Accepted Answer

Phone numbers (Telegram, SMS, WhatsApp), email addresses (Magic Link or OTP), domains (DNS TXT, HTTP File, Auto-Verify with 54 Providers, Email), and Telegram Bots. Social accounts and crypto wallets are coming soon.

Question 10

Can I use proof.holdings for two-factor authentication (2FA)?

Accepted Answer

Yes. Create a verification with POST /api/v1/verifications, the user sends the code via their preferred channel, then poll GET /api/v1/verifications/:id to confirm completion and retrieve the proof token. Our SDKs handle polling automatically. For returning users, a hosted verification request can reuse a proof the user already holds, if it is newer than the validity you set.

Question 11

Can I build passwordless login with proof.holdings?

Accepted Answer

Yes. We provide a dedicated Sessions API for phone-first authentication flows. Create a session, the user verifies their phone number via Telegram, WhatsApp or SMS, and you receive a signed proof token to use as your auth credential. No passwords to store, hash, leak, or reset. For email (magic link or code), create a regular verification with POST /api/v1/verifications, which returns the same signed proof. You own the session logic; we handle the verification.

Question 12

How is this different from Twilio, Vonage, or Auth0?

Accepted Answer

Different category, not different price. Twilio and Vonage are messaging APIs — they deliver SMS and you build verification logic on top. Auth0 is an identity provider — it handles who users are. proof.holdings is a verification API — it proves asset control and returns a cryptographic proof token. One API call, works across phone, email, and domain, phone channels are user-initiated with no outbound messaging cost, and proof tokens are offline-verifiable via standard JWKS. You only pay for successful proofs, not for messages. You don't replace these tools; you remove the need for them in asset verification flows.

Question 13

What is multi-surface proof of control?

Accepted Answer

One API, multiple verification surfaces. Phone numbers (Telegram, SMS, WhatsApp), Email addresses, Domains (DNS, HTTP, Auto-DNS), and Telegram Bots — all through a single unified verification flow. Social accounts and Crypto wallets are coming soon. Each verified asset generates a cryptographic proof token.

Question 14

How does domain verification work?

Accepted Answer

4 methods: DNS (add a TXT record to prove control); HTTP (place a file at /.well-known/); Email (a code sent to an admin address at the domain, such as admin@ or webmaster@); Auto-DNS (we add the record automatically via your DNS provider API — 54 Providers including Cloudflare, AWS Route 53, GoDaddy, Namecheap, and more). Each completed domain verification counts as one proof.

Question 15

How does SMS verification work?

Accepted Answer

SMS uses the same user-initiated model as WhatsApp and Telegram. The user sends an inbound SMS containing their verification code to our number. On SMS and WhatsApp the user sends the displayed code; on Telegram they open our bot and share their number. We never send a code out — on WhatsApp and Telegram the only message we send is a reply in the chat the user opened.

Question 16

What is Reverse OTP?

Accepted Answer

Traditional verification sends an SMS or email to the user — you pay for every outbound message. Reverse OTP flips the direction: we show the user a short code and they send it to us by SMS or WhatsApp, where a link can open the app with the code already typed; on Telegram they tap Start in our bot and share their number. The user initiates, and no code is ever sent out to them. This is not just a cost optimization; it is a fundamentally different model where phone verification scales without per-message cost.

Question 17

Why does user-initiated verification matter?

Accepted Answer

Traditional outbound verification ties your cost directly to your user count. Every login, every 2FA check, every confirmation is an outbound message you pay for. At scale — millions of users, AI agents triggering automated workflows, bots performing continuous re-verification — outbound messaging becomes an unbounded cost liability. User-initiated verification decouples your infrastructure cost from your user count. The user's own messaging app is the delivery mechanism. And you only pay for successful proofs — not for attempts, not for messages sent. Your verification cost is predictable, not a per-message bill that grows with traffic.

Question 18

Is Reverse OTP secure?

Accepted Answer

Yes. Codes come from a cryptographic random source and expire after 10 minutes. A code sent by message is accepted only from the number being verified, and codes typed into a page are compared in constant time. Because the user initiates the message from their own device, no code ever travels to the user: there is nothing to intercept in the network, read by malware, or type into a fake page. On Telegram and WhatsApp the proof comes from the messaging account, so a SIM swap alone is not enough — the attacker would also have to take over that account, which two-step verification blocks when the user has turned it on. On plain SMS, whoever holds the SIM can send the message, so a proof attests control at the moment it was made.

Question 19

What is Human-in-the-Loop (HITL)?

Accepted Answer

HITL lets AI agents, scripts and pipelines ask a person before taking an action. The person gets the request on Telegram or WhatsApp, opens the approval link, decrypts the request and approves or denies it in their browser, and the decision is cryptographically signed as a proof token — just like a verification proof.

Question 20

How do HITL approvals work?

Accepted Answer

Three steps: (1) Create an approval setup with your Telegram or WhatsApp channel. (2) Your agent or pipeline calls POST /api/v1/confirmations — the request text is encrypted in your process first, so we store ciphertext and never the wording; the JavaScript SDK’s createAndWait does that for you when you approve your own requests; for other approvers, build a multi-recipient (v2) envelope. (3) The human decrypts and approves or denies in their browser, and you get a signed proof token of their decision.

Question 21

What channels support HITL approvals?

Accepted Answer

Telegram and WhatsApp carry the request; the decision is made in the browser. The message in the messenger holds a one-time approval link. The approver opens it, enters the password that unlocks their key, reads the request and approves or denies it, with an optional comment. The request is encrypted end to end, so neither the messenger nor we ever see its wording — which is why there is no approve button inside the chat itself. What an approval proves beside an email “yes”, and a model contract clause, are on /approvals-vs-email.

Question 22

What happens if the human doesn't respond?

Accepted Answer

Each approval setup has a timeout (default 1 hour, from 1 minute to 24 hours). If nobody answers in time, the system denies it: the status becomes "denied" with response.channel "system" and no proof token, so your agent can tell a timeout from an approver's refusal and handle the fallback — retry, escalate, or proceed with a default action.

Question 23

Do HITL confirmations count toward my proof quota?

Accepted Answer

Yes. A proof is every signed answer we mint: a verification, an approval or a denial, an approver’s consent to receive requests, a Proof of Me answer, a delegation. So an approved or denied confirmation counts as 1 proof, priced like a verification. Proofs for your own account count like any other: each phone, email or domain you add, and each domain renewal. Signing in or a 2FA step-up reuses your proof for that phone and channel until it is about six months old, so it is re-issued, and counted again, at most about twice a year.

Question 24

Can I use HITL with AI agents?

Accepted Answer

Yes. proof.holdings ships an MCP server with 167 tools, including create_confirmation, get_confirmation and list_confirmations. Any MCP-compatible client can use it: connect to the hosted server at https://api.proof.holdings/mcp, or run it locally with npx -y @proof-holdings/mcp-server.

Question 25

How is this different from gotoHuman or HITL Relay?

Accepted Answer

proof.holdings delivers the request where the approver already is — Telegram or WhatsApp — and takes the decision on an end-to-end encrypted approval page, with a web dashboard for monitoring and management. Every decision produces a cryptographic proof token (ES256 JWT) you can verify offline, not just a status flag. And proof.holdings combines verification, delegation and approvals in one platform with 167 MCP tools and 4 SDKs, vs single-purpose approval tools.

Question 26

What is Proof of Delegation?

Accepted Answer

Anyone can publish a package or an MCP server under your company’s name, and nothing inside it can prove who stands behind it — every field in an artifact was written by whoever published it. Proof of Delegation puts the statement where the artifact cannot write it: the holder of a domain proves control of that domain, then issues a signed delegation naming the package or endpoint, the scopes it may act within and an expiry. A verified delegation tells you that the domain you expected authorized this artifact for these scopes and has not withdrawn that. It does not say the artifact is safe, well written, or the only one that domain authorized — and it only answers a question you already have, because you need to know which domain to expect before the answer means anything.

Question 27

How do I issue a delegation?

Accepted Answer

First verify your domain (DNS, HTTP, Auto-DNS or an admin email address), which gives you a control proof with a public handle (ph_ctl_…). Then call POST /api/v1/delegations with that handle, the artifact — a package such as pkg:npm/your-package or pkg:pypi/your-package, or an endpoint URL such as https://api.example.com/mcp — the scopes, and a lifetime. The response carries the signed token and a public handle (ph_dlg_…). A delegation can never outlive the domain proof underneath it. All four SDKs and the MCP server expose the same operation, and the dashboard issues one without code.

Question 28

Where does the delegation go, so a verifier can find it?

Accepted Answer

The token travels with the artifact. For an MCP server it goes in the server card’s _meta under the holdings.proof/delegation key (the MCP registry stores the same object under its publisher-provided metadata); for an A2A agent it goes in capabilities.extensions, identified by the uri https://proof.holdings/delegation; and when you control the domain but not the artifact’s card, a DNS TXT record at _mcp under your domain points at a card that holds it. The @proof-holdings/delegation-verifier package reads both card carriers from a card you hand it and parses the DNS pointer; looking the record up and fetching the card it names is the caller’s job. The token’s claims must match the canonicalized artifact identity exactly, so read a hand-built card back with the verifier before you publish it.

Question 29

How does an agent or a developer check a delegation?

Accepted Answer

Four ways, none of which needs an account. An agent with an MCP client calls the verify_delegation tool on our MCP server. A program installs @proof-holdings/delegation-verifier — zero runtime dependencies and no default trust list, so you pass the issuers you trust on every call. Anything that can make an HTTP request sends the token to POST /api/v1/proofs/validate. From a terminal, npx @proof-holdings/proof-check pkg:npm/your-package finds the published tokens and verifies each one locally. In every case, pass the artifact identity you resolved yourself — the package you are about to install, the endpoint you are about to call — never a name read out of a file inside the artifact, because that is the artifact describing itself.

Question 30

How do I withdraw a delegation?

Accepted Answer

POST /api/v1/delegations/:id/revoke, which is not reversible. To pause rather than end it, use the proof surface on its handle: POST /api/v1/proofs/:id/suspend and POST /api/v1/proofs/:id/unsuspend, also available from the dashboard. Withdrawal reaches verifiers through the public validation endpoint (POST /api/v1/proofs/validate), the revocation list and the status list, and through @proof-holdings/delegation-self-refusal, which a publisher installs in its own MCP server so that the server’s own tools refuse by themselves once the delegation is revoked, suspended or expired — the caller does not have to check anything. It works for a publisher who keeps it installed; a fake copy carries no delegation at all, which is what checking before you install catches. What withdrawal cannot do is reach into a card someone already published: the token stays wherever it was put until that carrier removes it, so the dashboard reports, per delegation, where its token might still be visible. There is no token rotation: to replace a token, revoke, issue a new one and republish it in every carrier that held the old one.

Question 31

What is Lookalike Watch?

Accepted Answer

An opt-in monitor for the other side of the problem: artifacts that resemble your name without any delegation from you. It reads the new entries at npm, PyPI and the MCP registry since its last pass and alerts you when a package or server name could be taken for your brand — including typosquats and look-alike characters — listing where it looked, with a monthly report of what each period could and could not cover. An alert is an observation about a name, not a verdict about whoever published it, and the sweep reads what the registries’ feeds serve rather than everything ever published. It needs a verified domain and an active delegation, and is included on the €29, €79 and Custom plans.

Question 32

What is Proof of Me?

Accepted Answer

Anti-impersonation, in reverse. Instead of proving your own identity, you let the people around you check that someone claiming to be you really is. You enroll trusted contacts — colleagues, family, clients — as members of a Circle; each one joins by tapping an invite link in Telegram or WhatsApp, which binds their messenger account to your Circle. It answers the fake-CEO wire request, the “new number” message and the call that sounds like you, without code words that get skipped when it matters.

Question 33

How does a Proof of Me check work?

Accepted Answer

When someone contacts a member claiming to be you, the member taps once in their messenger. You receive a confirmation request on a different channel than the one the suspicious contact used when both Telegram and WhatsApp are connected, and you approve or deny it; the member is told the result, and the answer is signed as a proof token. A member who no longer wants to take part can opt out at any time. Circles and their members are managed from the dashboard or any SDK over /api/v1/circles; a check is started by the member in their messenger, or programmatically with POST /api/v1/identity-challenges from any SDK.

Question 34

How do I get started?

Accepted Answer

Three steps: sign up and generate an API key, install one of our SDKs (JavaScript, Python, Go, or PHP), and call verifications.create() with the asset type, channel and identifier. The SDK handles polling, retries, and error handling. Full API reference, OpenAPI 3.1 spec, and test vectors are available in our docs. You can also initiate verifications directly from the dashboard without writing any code.

Question 35

How does authentication work?

Accepted Answer

API key authentication via the Authorization header: Authorization: Bearer followed by your key. Keys use the format pk_live_* for production and pk_test_* for test mode. Keys are bcrypt-hashed at rest — we never store them in plaintext.

Question 36

Do you support webhooks?

Accepted Answer

Yes. Set a callback_url on a verification request to be notified when it completes or expires; your account webhook URL receives approval, authorization, proof-status and account events. Payloads are signed with HMAC-SHA256 so you can verify authenticity. Failed deliveries retry automatically with exponential backoff, and the webhook-deliveries API lists every delivery with its status and lets you retry one by hand (GET /api/v1/webhook-deliveries, POST /api/v1/webhook-deliveries/:id/retry). Webhooks fire in test mode too, so you can test your integration end-to-end without burning credits.

Question 37

What SDKs are available?

Accepted Answer

JavaScript/TypeScript, Python, Go, and PHP. All four SDKs cover the same API surface: verifications, proofs, sessions, verification requests, delegations, and webhook deliveries. Each includes type definitions (fully typed signatures in TypeScript), automatic retries with exponential backoff, and typed error classes. The Go SDK has a single dependency, golang.org/x/crypto.

Question 38

Can I verify proofs offline?

Accepted Answer

Yes. Proof tokens are ES256-signed JWTs. Validate any proof locally against our public keys from the JWKS endpoint (/.well-known/jwks.json). All four SDKs include built-in offline verification; by default they also read our public status list to catch revoked proofs, which you can turn off for fully offline checks. This is useful for edge computing, air-gapped environments, or simply reducing API dependency in your verification flow.

Question 39

Is there an OpenAPI spec?

Accepted Answer

Yes. A machine-readable OpenAPI 3.1 specification is available at /api/openapi.json and in our public docs repository. This enables automated SDK generation, API client scaffolding, contract testing in CI, and integration by AI coding assistants that can parse the spec directly.

Question 40

How does test mode work?

Accepted Answer

Use a pk_test_* API key. In test mode, direct verifications send no email and skip the DNS and HTTP checks — complete them with the test-verify endpoint — and request and approval webhooks still fire, so you can test your integration end-to-end without burning credits. Approval messages and verification-request emails are still delivered for real.

Question 41

Can I auto-complete test verifications?

Accepted Answer

Yes. The test-verify endpoint (POST /api/v1/verifications/:id/test-verify) instantly completes a verification and generates a proof token. Only works with test API keys — returns 403 for production keys.

Question 42

Do test verifications count toward my quota?

Accepted Answer

No. Test verifications are tracked separately and excluded from billing and production usage limits.

Question 43

Is there a free tier?

Accepted Answer

Yes. The Pay as you go plan includes 300 free proofs every month with full API access, all verification channels, and webhook support. No credit card required. Additional proofs are €0.03 each.

Question 44

What plans are available?

Accepted Answer

Pay as you go (300 free proofs/mo, then €0.03 each), €9/month (1,000 proofs), €29/month (3,000 proofs), €79/month (10,000 proofs), and Custom (custom pricing for 100,000+ proofs, with dedicated infrastructure and BYOC on request).

Question 45

What is BYOC?

Accepted Answer

BYOC (Bring Your Own Channels) is available on request on the Custom plan: verification messages can come from your own Telegram bot, WhatsApp Business number and email sender instead of our shared ones.

Question 46

What happens when I pass my included proofs?

Accepted Answer

Proofs beyond your included amount are deducted from the prepaid balance you top up in the dashboard, at your plan’s rate — on Pay as you go €0.03 each, and on a paid plan that plan’s overage rate (€9: €0.03, €29: €0.025, €79: €0.02). While the balance lasts nothing stops; when it runs out, new proof requests pause until you top it up, and proofs already issued keep working. A Pay as you go account with no card on file gets a short grace beyond its included proofs before it pauses. The dashboard shows your current usage and tells you when a different plan would cost you less at your current volume.

Question 47

How am I billed?

Accepted Answer

Paid plans are charged in advance for each billing period. Proofs beyond what your plan includes are deducted from a prepaid balance you top up in the dashboard, at your plan’s rate; when the balance runs out, new proofs pause until you top it up. Post-paid invoicing is available under a separate agreement, enabled for your account on request. Prices exclude VAT where it applies; the full terms are in the Terms of Service.

Question 48

What data do you collect?

Accepted Answer

Only what the service needs, and the Privacy Policy (/privacy) lists all of it. For a verification: the identifier (phone, email, domain), the channel, the messages exchanged, the result and its timestamps. For security: the IP address and browser type when a code is submitted, an authorization is given or a proof is changed; a risk record for SMS verifications; and web-server request logs, deleted after 30 days. We never ask for identity documents, legal names or postal addresses. Identifiers are encrypted at rest with AES-256-GCM and masked in logs, and inside a proof token the identifier appears only as a SHA-256 hash, never in readable form.

Question 49

Are you GDPR compliant?

Accepted Answer

The service is built for it: the operator is an EU company, data is hosted in the EU, and every customer is covered by a published Data Processing Agreement (/dpa) with a subprocessor register (/subprocessors). You can export your data (Article 20) and delete your account (Article 17) from the dashboard; identifiers are encrypted at rest and masked in logs, and delivery records expire automatically. We never ask for identity documents or legal names. The Privacy Policy states the legal basis for each purpose and your right to complain to a supervisory authority.

Question 50

How are proof tokens secured?

Accepted Answer

Proof tokens are signed JWTs using ES256 (asymmetric, P-256) so they can be verified offline. A verification token carries the phone number, email address or domain only as a SHA-256 hash, never in readable form; a delegation token names the domain and the artifact in clear, because that is the statement it makes. Public keys are published at our JWKS endpoint so any party can validate a proof without contacting our API. Tokens support revocation via a published revocation list.

Questions, answered.

What is proof.holdings?

What each proof is for

Proof of Control: what you can verify

Reverse OTP

Proof of Action: human approvals (HITL)

Proof of Delegation

Proof of Me

API & Integration

SDKs & Developer Experience

Test Mode

Pricing

Privacy & Security

Related