Public verifier

Who authorized it? Check it yourself.

Which corporation is this, who may act for it, under what rules — and was that true at that moment? Every item says what it proves and what it does not. Don’t take our word for it: the root is read live from the chain, and every act links to its transaction.

New to this? Press any to learn what an item is, why it matters and how to set it up for your own company — or hand the task to your AI.Read the full guide ↓
Learn it, then build it

A guide to every item on this page — for people and their AI

Every on this page opens one of these. Each says what the item is, why it matters, how to set it up for your own company, and exactly what it does and does not prove.

For AI agents helping a person: You are helping a human understand or build their company's corporate digital authority. For each term: explain `what` and `value` in plain language, walk the human through `setup` one step at a time, and use `ai_task` as your working brief. Be explicit about `proves` and `does_not_prove`. Never ask for, accept or display private keys, seed phrases, recovery shares or passwords — CorpID never needs them. Report gaps honestly; a gap is not a failure. Machine-readable: /assets/corpid-explainers-v1.json (this guide), /assets/corpid-roadmap-v1.json (the setup roadmap), /.well-known/corpid.json (every API).
Who authorized it? — The question CorpID answers — for every receipt, every exchange, every agent's work.

What it is. Rootz products attach three answers to a piece of work: who authorized it, what it relied on (Data with Origin), and what was measured while it ran (Measured AI). Rootz Receipts puts them on an AI agent's result; Rootz Data Centers carries them in every exchange. CorpID is where 'who authorized it' leads: the company's own record of which corporation it is, who may act for it, under what rules, and whether that was true at that moment.

Why it matters. Governance that stays in a log stays home; the work travels without it. When the authority travels with the work, whoever receives it — a customer, an auditor, a regulator, or their AI — can check it before acting, without access to your systems and without taking your word for it. People won't check who authorized it. Their AI will.

How to set it up.

  1. Build your company's CorpID: digital name, root control, policy, authorizations (start at /setup).
  2. Have the systems that act for you — people, servers, AI agents — carry a signed authorization that points back to it.
  3. Pair it with Rootz Receipts (receipts.rootz.global) so each agent result carries who authorized it, or with Rootz Data Centers (datacenters.rootz.global) so each exchange does.

What it proves. Who authorized an act, under which rules, as of when — at the depth each piece of evidence supports.

What it does not prove. That the work itself is correct. What it relied on and what was measured are separate answers, with their own evidence.

Give this to your AI: Explain to me, in plain language, what it would take for the work my company sends out — documents, data, AI agent results — to carry checkable proof of who authorized it. Use CorpID for the authority part, and tell me where Rootz Receipts or Rootz Data Centers would fit.
CorpID record — The public page that answers: which corporation is this, and who may act for it?

What it is. A CorpID record links a legal corporation to its Corporate Digital Name, its governance, the systems that carry its identity, and the people, machines and AI agents it has authorized. Each link shows what evidence supports it.

Why it matters. Anyone — a bank, a supplier, a regulator, or another company's AI agent — can check who really speaks for a company before trusting a message, an invoice or an agent. It replaces phone calls, portal logins and screenshots with something a machine can check in a second.

How to set it up.

  1. Start at /setup with the company's legal name and jurisdiction.
  2. Collect the evidence the roadmap lists (formation documents, registry entry, domain, DBA filings).
  3. Create the Corporate Digital Name and its root control (see those items).
  4. Publish the record, and ideally a copy at your own domain under /.well-known/corpid.json, so it does not depend on Rootz.

What it proves. That the listed evidence exists and how deeply each item was checked.

What it does not prove. That the company is good, solvent or honest. It is a map of authority, not a credit rating.

Give this to your AI: Walk my company through creating its CorpID record. Use the CorpID roadmap to list what evidence we need, check what we already have, and tell me the gaps in order of value.
Record status — How far this record has been built: draft, claimed or reference.

What it is. draft means someone started a record and proved nothing yet. claimed means some control was proven (for example, of the company's domain). reference marks a record kept as a worked example of the model, as Rootz Corp.'s is.

Why it matters. Tells a visitor at a glance how much weight the record can bear before they read the details.

How to set it up.

  1. A record starts as draft when created.
  2. Prove domain control (a DNS TXT record) to move it to claimed.
  3. Add evidence, root control and a published policy to strengthen it further.

What it proves. Which steps have been completed.

What it does not prove. A claimed record only shows control of a domain, not that the controller is the legal company.

Give this to your AI: Look at my company's CorpID record status and tell me the single next step that would strengthen it most.
Corporate Digital Name — The company's own cryptographic address — a name it creates and controls, not one it rents.

What it is. A blockchain address the corporation controls and adopts as its digital name. Rootz Corp.'s is 0xD36AAf65a91bB7dc69942cF6B6d1dBa4Ef171664, which it also registered as a Delaware trade name (DBA), tying the address to the legal entity in public law.

Why it matters. Domains, cloud tenants and certificates are rented from providers and can be lost. A digital name is owned. Anyone can check signatures against it, forever, without asking Rootz or any provider. It becomes the anchor every other authority hangs from.

How to set it up.

  1. Create the root account first (see Root account) — the Safe's address becomes the digital name.
  2. Adopt it by board resolution as the company's digital name.
  3. File a DBA / assumed-name with your state that names the address, as Rootz did, so the law links the name to the company.
  4. Publish it: on your website, in your CorpID record, and in a public statement signed by the root itself.

What it proves. That whoever controls this address can sign as it.

What it does not prove. On its own, that the address belongs to the legal company — that link comes from the DBA filing, the board resolution and the other evidence.

Give this to your AI: Explain to me what a Corporate Digital Name is for my company, then draft (a) a board resolution adopting our root account address as our Corporate Digital Name and (b) the text of a DBA / assumed-name filing that names it, for our jurisdiction. Leave the address as [ADDRESS].
Authority policy — The company's published rules for who may authorize what.

What it is. A document the company adopts and publishes, saying who may register, authorize and revoke digital authority, at what threshold, and how keys are recovered. CorpID stores its exact hash and version, so an old act can be checked against the rules in force at the time.

Why it matters. A key can sign; only a policy explains why that signature binds the company. Without it, a verifier cannot tell an authorized act from a rogue one. Rootz's own record shows this as a gap today — honestly.

How to set it up.

  1. Draft a Corporate Digital Authority Policy (who approves AUTHORIZE / REVOKE, at what threshold, how recovery works).
  2. Adopt it by board resolution.
  3. Publish it through /governance; CorpID records its hash and version.
  4. Re-publish a new version whenever the rules change — never edit the old one.

What it proves. Which policy text, by hash, the company published and when.

What it does not prove. That every act followed the policy — that is checked act by act.

Give this to your AI: Draft a Corporate Digital Authority Policy for my company: who may authorize people, machines and AI agents to act for us, what needs two signatures, how a lost key is recovered by board decision, and how authorizations expire and are revoked. Keep it under two pages and in plain language.
Enterprise identity (provider bindings) — The company's Microsoft, Google, Okta or PKI systems, bound underneath the corporate root.

What it is. A record that a given tenant or certificate authority (for example a Microsoft Entra tenant) carries this company's identity. It is infrastructure under the corporation, not above it.

Why it matters. Employees already sign in through these systems. Binding them to the CorpID lets a verifier follow a login or certificate back to the corporation that stands behind it.

How to set it up.

  1. Pick the system (Entra, Google Workspace, Okta, internal PKI).
  2. Where it allows, place the Corporate Digital Name or a reference to it inside that system (a tenant attribute, a certificate extension).
  3. Record the binding in CorpID. It starts as asserted and climbs only when CorpID can read the reference back from the provider.

What it proves. At its recorded depth, that the provider carries the company's reference.

What it does not prove. That the provider is the authority. The corporation is.

Give this to your AI: For our identity provider [Microsoft Entra / Google Workspace / Okta / our PKI], show me where an administrator could publish a reference to our Corporate Digital Name so a third party can read it back, and list the steps.
Delegated actor (authorization) — A person, machine or AI agent the company has authorized to act for it — with a scope and an end date.

What it is. An authorization says: this identity may do this, for us, until then. The person or agent creates their own key; the company never holds it. The authorization expires; the identity does not.

Why it matters. It is how a counterparty — or their AI — checks that the employee, server or agent in front of them really acts for the company, right now, for this purpose. After revocation, old signatures still verify as of their date.

How to set it up.

  1. The person or agent creates their own identity and key (a wallet or identity contract).
  2. The company issues an AUTHORIZE with scope, title and end date: today through the /sign tool, which records a signed corpid-authority/1 message in CorpID.
  3. Rootz has also done this directly on chain: a Safe transaction whose data reads 'The wallet 0x… is authorized for … by Rootz corp. until …' (see the Root control log).
  4. Revoke with REVOKE when the role ends; renew before the end date if it continues.

What it proves. That the company's authorized signer granted this scope for this period.

What it does not prove. That the actor behaved well within it.

Give this to your AI: Help me authorize [PERSON / SERVER / AI AGENT] to act for my company: write the exact scope, title and end date, explain how they create their own key, and walk me through issuing the authorization and later revoking it. Never ask for anyone's private key.
Root control — Who controls the keys that can change the company's digital authority. Read live from the chain.

What it is. The account behind the Corporate Digital Name. For Rootz it is a Safe — a smart account on Ethereum that only acts when enough of its owners sign. This panel reads it directly from the blockchain, not from CorpID's database.

Why it matters. This is the bootstrap question every other link depends on. If one person's lost laptop or one stolen key could change who speaks for the company, nothing built on top is safe. A Safe with several owners and a threshold removes that single point of failure.

How to set it up.

  1. Choose the owners — usually officers or directors — and give each their own hardware wallet.
  2. Create a Safe at app.safe.global (Rootz uses Ethereum mainnet) with those owners.
  3. Set a threshold of at least 2 (for example 2-of-3) so no single key can act.
  4. Adopt the Safe's address as the Corporate Digital Name by board resolution, and record the recovery process in the authority policy.
  5. Never share a seed phrase with anyone, including Rootz. CorpID only ever needs the public address.

What it proves. Who the owners are and what threshold is set, as of the block it was read.

What it does not prove. Who the owners are as people — that is in the board resolution and policy.

Give this to your AI: Walk me through creating a Safe smart account for my company as its corporate root: how many owners, which hardware wallets, what threshold, which network, and what the board resolution should say. Do not ask for or handle any seed phrase or private key.
Root account (Safe) — The smart account that holds the company's root of authority.

What it is. A Safe is an audited, widely used smart-contract account. It holds no private key of its own; it executes an action only when its owners' signatures meet the threshold. Version and address are read live.

Why it matters. Control is shared, recoverable and visible to everyone. Owners can be added or removed by the same governed process, so the company keeps its name even as people come and go.

How to set it up.

  1. Create at app.safe.global; record the address and network.
  2. Fund it with a small amount of ETH for transaction fees.
  3. Publish the address as your Corporate Digital Name.

What it proves. That this address is a Safe contract of the stated version.

What it does not prove. Anything about the people behind the owner keys.

Give this to your AI: Explain to my board in one page what a Safe smart account is and why our company's digital root should be one, including what happens if a director leaves or loses a key.
Threshold and owners — How many owner signatures the root needs before it acts — and whose keys they are.

What it is. Rootz's root requires 2 of 3 owners. Each owner is a separate key, ideally on separate hardware held by a different officer.

Why it matters. No one person, and no single stolen device, can act for the company. Losing one key does not lose the company: the other owners can replace it.

How to set it up.

  1. Pick a threshold that is more than one and less than all (2-of-3 or 3-of-5 are common).
  2. Record who holds each owner key in the board resolution — not on chain.
  3. Change owners or threshold only through the Safe itself, so every change appears in the log.

What it proves. The current owners and threshold, read live.

What it does not prove. That each owner key is held by the person the company says.

Give this to your AI: Recommend an owner count and threshold for my company's root account given our size [NUMBER OF OFFICERS/DIRECTORS], and explain the trade-off between safety and the risk of being locked out.
Modules and guard — Optional add-ons that let the root do more — or check more — before it acts.

What it is. A module can act for the Safe under its own rules (for example, an authorization registry). A guard checks every transaction before it executes. Rootz's root has neither today, so only owner signatures govern it.

Why it matters. This is where the next layer of corporate automation goes: a CorpID Authority Module for structured authorizations, and a guard that requires a manifest of the controls in force. Both are in Rootz's proposal to the Safe community.

How to set it up.

  1. Leave both empty until you have a specific, reviewed module or guard.
  2. Enable one only through a Safe transaction signed at the threshold, so the change is logged.
  3. Record in your authority policy what each module may do.

What it proves. Which modules and guard are enabled now.

What it does not prove. That an enabled module is safe — review it before enabling.

Give this to your AI: Explain the difference between a Safe module and a Safe guard, and the risks of enabling either, for a company using a Safe as its corporate root.
Root act log — Every action the root has ever executed, read from the chain, with who confirmed it.

What it is. Each row is one transaction the Safe executed. The text and call data are decoded locally; the confirming owners are recovered from their signatures and checked against the owner list. Each date links to the transaction on Etherscan.

Why it matters. It is the company's tamper-evident minute book for digital authority: what was authorized, when, renewed or expired, and by whom — checkable by anyone, without trusting Rootz.

How to set it up.

  1. Nothing to set up: every action your Safe executes appears here automatically.
  2. To make an act readable by people, put a clear sentence in the transaction data, as Rootz has.
  3. To make it readable by machines, use the structured AUTHORIZE / REVOKE format (the CorpID Authority Module is the next step).

What it proves. That the root executed these transactions with these owners' signatures.

What it does not prove. That the English text in an act is true or complete.

Give this to your AI: Read my company's root act log from https://corpid.rootz.global/api/v1/corps/[SLUG]/root-control and summarize, in plain language, who is currently authorized for what, what has expired, and anything I should renew or revoke.
Authorization (text-parsed) — An act in which the root grants a wallet authority, in plain English, with an end date.

What it is. Rootz's root has written, on chain: 'The wallet 0xD447… is authorized for secure messages by Rootz corp. until july 17 2027.' CorpID reads the subject, scope and end date from the sentence and shows whether it is active or expired, and whether it renews an earlier grant.

Why it matters. It shows the whole authorization lifecycle — grant, expiry, renewal — done with nothing but a Safe. Expiry needs no revocation transaction: the grant simply ends on its date.

How to set it up.

  1. In Safe{Wallet}, create a transaction to the wallet being authorized, value 0, with the sentence (encoded as UTF-8 hex) as data.
  2. Use the exact form: 'The wallet 0x… is authorized for [scope] by [company] until [month day year]'.
  3. Collect the threshold of owner signatures and execute.
  4. Renew before the end date by repeating with a new date.

What it proves. That the company's root signed this sentence at its threshold.

What it does not prove. It is labelled text-parsed: CorpID read meaning from English, so it is not counted as a structured CorpID authorization.

Give this to your AI: Write the exact authorization sentence for my company's Safe to authorize [WALLET] for [SCOPE] until [DATE], give me its UTF-8 hex encoding for the transaction data field, and walk me through submitting it in Safe{Wallet} for my co-owners to confirm.
Public statement — A declaration the root signed and published on chain.

What it is. Free text the Safe executed as transaction data — for Rootz, its declaration that the Safe is the EDGAR-filed DBA digital name of Rootz Corporation.

Why it matters. A statement signed by the root itself, permanently public, is the strongest way for a company to say 'this is us' in its own voice — and an AI can quote it with its origin attached.

How to set it up.

  1. Write the statement plainly, naming the company and any registry references.
  2. Submit it from the Safe as transaction data and collect the threshold of signatures.

What it proves. That the root signed these exact words on this date.

What it does not prove. That the words are true — the referenced filings are the evidence for that.

Give this to your AI: Draft a short public identity statement my company's root account can sign on chain, declaring that the account is our Corporate Digital Name and citing our registry and DBA references.
Document anchored — A signed document (here, a DocuSign envelope) tied to the corporate root.

What it is. The root executed a transaction carrying a DocuSign envelope ID, linking that agreement to the company's digital name at that moment.

Why it matters. It ties a conventional e-signature to the corporation's own root, so the agreement can later be shown to have been acknowledged by the company, not just by a signer's email address.

How to set it up.

  1. After an agreement completes in DocuSign, copy its envelope ID.
  2. Submit a Safe transaction with 'DocuSign Envelope ID: …' as data and collect the threshold.

What it proves. That the root referenced this envelope ID on this date.

What it does not prove. The contents of the document — DocuSign holds those.

Give this to your AI: Explain how my company could anchor completed DocuSign agreements to our corporate root account, and what that does and does not prove in a dispute.
Governance change — The root changing its own owners, threshold, modules or guard.

What it is. A call the Safe makes on itself, such as adding an owner or raising the threshold. Rootz's root added an owner in April 2024 and moved to 2-of-3 in May 2024.

Why it matters. Changes to who controls the company are themselves governed and permanently logged, so a verifier can reconstruct who had control at any past date.

How to set it up.

  1. Use Safe{Wallet} settings to add or remove owners or change the threshold.
  2. Record the matching board resolution in your evidence.

What it proves. Exactly which control change executed, when, and who signed it.

What it does not prove. That the board approved it — keep the resolution as separate evidence.

Give this to your AI: Walk me through safely replacing a departing officer's owner key on our company Safe without ever dropping below our threshold, and what board resolution should accompany it.
Transfers and contract calls — Ordinary actions the root took: sending funds, approving contracts, passing an address.

What it is. Value transfers, token approvals and other calls the Safe executed, decoded where the function is known.

Why it matters. Shown so the log is complete: nothing the root did is hidden, which is what makes the authority acts trustworthy.

How to set it up.

  1. Nothing to set up. Keep routine treasury activity in a separate Safe if you want the root log to stay focused on authority.

What it proves. That the root executed the call with these signers.

What it does not prove. The business purpose of the call.

Give this to your AI: Should my company use one Safe for both corporate authority and treasury, or separate them? Explain the trade-offs.
Confirmed by — The owners whose signatures approved each act — recovered from the signatures themselves.

What it is. CorpID does not take an indexer's word for who signed. It recovers each signer from the cryptographic signature over the Safe's transaction hash, then checks the result is a current owner.

Why it matters. This is the 'proposed by one, confirmed by another' record. It is also where an AI agent would appear as proposer, with humans confirming — the pattern Rootz is proposing to standardize.

How to set it up.

  1. Nothing to set up. Each owner signs in Safe{Wallet}; the last to sign usually executes.

What it proves. Which owner keys signed.

What it does not prove. Which human held each key at the time.

Give this to your AI: Explain how signer recovery on a Safe transaction works and why it is stronger evidence than a website saying who approved something.
Evidence depth — How each claim was learned — from a bare assertion up to a contract-verified signature.

What it is. Every link carries its own depth: gap (nothing yet), asserted (someone said so), referenced (points to an outside source), observed (CorpID checked it live), signed-message (a known key signed it), provider-issued (a provider issued it), contract-verified-message (a contract checked the signatures on chain). text-parsed marks meaning read from English.

Why it matters. It stops a page from turning many weak claims into one green tick. A verifier — human or AI — can weigh each link for what it is.

How to set it up.

  1. Depth is earned, never chosen. Add stronger evidence (a registry lookup, a DNS record, a signed message) and the depth rises.

What it proves. How the claim was established.

What it does not prove. Truth. A high depth means strong origin, not correct content.

Give this to your AI: Go through my company's CorpID record and, for each link, tell me its current evidence depth and the cheapest way to raise it.
Evidence ledger — The documents and checks behind the record, each with its source and depth.

What it is. A list of claims (Delaware registration, DBA basis, domain, policy) with who issued each, where to see it, and how deeply it was checked. Gaps stay visible.

Why it matters. It is the company's identity file, made public and checkable, instead of a PDF bundle emailed to every bank and supplier separately.

How to set it up.

  1. Use /setup's evidence room. Add the original artifact and, separately, how it reached you (for example the registry's email).
  2. Never upload private numbers (full EIN, account numbers) to a public record.

What it proves. That each piece of evidence exists at its stated depth.

What it does not prove. Anything an item's depth does not support.

Give this to your AI: Build my company's evidence list for CorpID: for each item in the roadmap, tell me where the authoritative copy lives, how to obtain it, and what it would prove.
Epistery bindings — Identity contracts that point back to this corporation.

What it is. An Epistery IdentityContract is an on-chain identity with device keys (rivets). A binding means that contract publishes a reference to this CorpID, and CorpID can read it back.

Why it matters. It connects people's and machines' own on-chain identities to the company that authorizes them, both ways, without Rootz in the middle.

How to set it up.

  1. Prepare the binding at /api/v1/epistery/prepare.
  2. Write the profile from an already-authorized rivet on the identity contract.
  3. Verify the read-back at /api/v1/epistery/verify.

What it proves. That the contract publishes a matching CorpID reference.

What it does not prove. That the contract's owner is an employee — that needs an authorization.

Give this to your AI: Explain what an Epistery IdentityContract is and walk me through binding one to my company's CorpID.
Verify a signed authority message — Check that a key really signed these exact bytes, and whether it was authorized to.

What it is. Paste a corpid-authority/1 envelope, the signer's address and the signature. CorpID checks the signature (locally for ordinary keys, on chain for contract identities) and whether that signer was authorized at the time.

Why it matters. This is the everyday use: before acting on an instruction, an invoice or an agent's request, confirm it came from someone the company authorized.

How to set it up.

  1. Ask the sender for the envelope JSON and signature.
  2. Paste them here, or call POST /api/v1/authority/verify from your own software or AI agent.

What it proves. Who signed the exact bytes, and their authority at that time.

What it does not prove. That the instruction is wise or the content true.

Give this to your AI: Here is a signed message claiming to come from [COMPANY]. Use https://corpid.rootz.global/api/v1/authority/verify to check the signature and whether the signer was authorized by the company at the time, and explain the result to me.