Build your company's CorpID
Who authorized it? CorpID is where that answer leads. Here the company creates its own digital name, puts it under root control, publishes the rules for who may act for it, and authorizes the people, machines and AI agents that do. Each step is written so you, and the AI helping you, can follow it.
Every button explains the step: what it is, why it matters, how to set it up. Each one has Copy task for my AI.
Your company's authority, checkable by anyone who receives your work.
Microsoft, Google, AWS, hardware keys and AI platforms each prove their own credentials. None of them says which company stands behind the work, or who it allowed to act. Your CorpID does: the corporation is the authority, and the record shows the evidence for each link. The recipient checks it against its own policy and decides.
Why isn't an Entra tenant or certificate enough?
Those are good infrastructure identities, but each belongs to one provider and can be replaced. Your CorpID records the corporation above them: its digital name, the rules for who may connect a provider, and the evidence that ties each credential back to the company. The precedent: "we have an org chart and an SSO" is a claim; proof that this signer was authorized when they signed is the record.
Start with the legal corporation
Enter the company's legal name and jurisdiction, as its state or national registry records them, and the domain people already know it by. Everything else on the record speaks for this legal person. No single registry is the root of your CorpID; registry entries are evidence, added next.
What proves the corporation exists?
CorpID works with any registry. State, national, tax, banking, procurement and other records can each be added as evidence. What a registry reference proves: what that registry says. What it does not prove: anything beyond that. CorpID never quietly promotes it into more.
Next, the evidence room lists what to collect: formation documents, the registry entry, the domain, DBA filings. Keep each original, and separately, how it reached you (for example the registry's email). Gaps stay visible. Never put private numbers, such as a full EIN or account numbers, in a public record.
The company creates its digital name
The digital name is an address the company controls and adopts as its name, so other systems can carry it. It outlives staff changes, cloud moves, certificate rotation and a change of AI provider. Recommended order: create the root account first (step 4). The Safe's address becomes the digital name. Then adopt it by board resolution, and, as Rootz did, you can file a DBA (assumed name) with your state that names the address, so the law links the name to the company. You can leave this field empty, create the draft, and add the name once the Safe exists.
Why an address, not just the company name?
Company names are ambiguous. An address can be carried inside provider credentials, signed messages and public records without depending on spelling or on any one directory. The address is not the corporation. It is a name the corporation creates, adopts and governs. Nobody issues it to you, Rootz included.
Put the company's root under shared control
The root is the account behind the digital name: the one that can speak for the company. Set it up before you publish rules or authorize anyone. The recommended root is a Safe: a smart account that acts only when enough of its owners sign. Give each owner, usually an officer or director, their own hardware wallet, set a threshold of at least 2, and adopt the Safe by board resolution. CorpID records the public address, the design and the evidence. It never holds a private key or recovery phrase.
Safe, owners on separate hardware
A Safe is the company's root account. Each owner keeps their key on their own hardware wallet, and at least two must sign before it acts. No single key can act alone.
One hardware-held signer
One company signing address on one hardware device. Simpler to start, but one key can act alone, so your written rules have to make up for it.
Your existing key custody
Use an HSM, signing service or governed key process the company already runs, and record its public address or identifier here.
How to set up root control, step by step
What does a Safe on hardware actually protect?
A Safe needs more than one owner to sign, so no single person's key can act for the company alone. Hardware wallets make it harder for malware to copy an owner's key. Your authority policy then says who may be an owner, how many must sign, how owners change, and how recovery works. Change owners or the threshold only through the Safe itself, so every change shows in its log.
What this proves: who controls the root, and who authorized an act. What it does not prove: that every statement the company signs is true. Possession of a key proves control of a key; governance and legal evidence prove the key is entitled to speak for the company.
/.well-known/corpid.json, /spec and /corpid-v1.5.schema.json. Help the person choose how the root is held, but never ask for, display, send or log a private key or seed phrase. Treat a root-control record as a claim about custody until its signature and evidence have been checked.Publish who may act for the company
The Corporate Digital Authority Policy says who may authorize and revoke, at what threshold, and how keys are recovered. Adopt it by board resolution, then sign and publish it here. CorpID records its exact hash and version, so an old act is judged by the rules in force at that moment. When the rules change, publish a new version; never edit the old one. Keep it free of product names; provider details go in step 6.
Why publish the rules?
A valid signature tells the recipient which key signed. The policy tells them whether that key was entitled to act for the company, for that kind of act, at that moment. Publish the rules before the act, and a missing or unauthorized authorization becomes something anyone can detect.
Connect the systems that carry your identity
Entra, Google Workspace, Okta or your own certificate authority sit under the corporation, not above it. Where the system allows, place the digital name, or a clear reference to it, inside that system (a tenant attribute, a certificate extension). CorpID records the company's side of the same link. A binding starts as asserted and rises only when CorpID can read the reference back from the provider.
Why should the link point both ways?
CorpID saying a Microsoft or Google credential belongs to the company is only a claim. When the provider's own artifact also carries the digital name, or a clear reference to it, the recipient can start from either side and reach the same company. Depth is earned, never chosen.
Authorize people, machines and AI agents
An authorization says: this identity may do this, for us, until then. The person or agent creates their own identity and key; the company never holds it. The company signs the authorization with its scope, conditions and end date. It is a signed act, not a role hidden in a database. The authorization expires; the identity does not. Revoke it when the role ends; renew it before the end date if the role continues.
Why give an AI agent an end date?
"This agent belongs to Rootz" is too broad to rely on. A useful authorization says which agent, which kinds of act, which systems, under what conditions, and until when. Forty days later, whoever received the work can check the authority that existed at that moment, not the authority that exists today.
Link an Epistery IdentityContract
Not a new identity model. CorpID prepares one public-profile write; a rivet (device key) already authorized on that contract must execute it. The contract then carries its own link back to the company, and CorpID can read it back.
Publish the record, and check it yourself
The public page is not a green badge. It shows every link, who issued it, its evidence depth, its date and its gaps, with enough detail for a person or their AI to follow the chain without taking our word for it. The recipient decides. Ideally, also publish a copy at your own domain under /.well-known/corpid.json, so your record does not depend on Rootz.
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.
/assets/corpid-explainers-v1.json (this guide),
/assets/corpid-roadmap-v1.json (the setup roadmap),
/.well-known/corpid.json (every API).
- The corporation is the authority. Rootz, Microsoft, Google, CAs and blockchains are infrastructure and evidence underneath it.
- Identity is created by its owner, not issued by a provider.
- A signature proves who signed which bytes. It does not make the words true.
- Every link carries its own evidence depth. There is no global 'trusted' flag.
- A completed CorpID must still work and verify if Rootz disappears.
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.
- Build your company's CorpID: digital name, root control, policy, authorizations (start at /setup).
- Have the systems that act for you — people, servers, AI agents — carry a signed authorization that points back to it.
- 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.
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.
- Start at /setup with the company's legal name and jurisdiction.
- Collect the evidence the roadmap lists (formation documents, registry entry, domain, DBA filings).
- Create the Corporate Digital Name and its root control (see those items).
- 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.
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.
- A record starts as draft when created.
- Prove domain control (a DNS TXT record) to move it to claimed.
- 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.
Legal corporation — The company that exists in law — the true source of authority.
What it is. The entity formed under a state or national registry (for Rootz Corp., Delaware file 3246351). Everything else on this page speaks for this legal person.
Why it matters. Keys, wallets, accounts and software all change. The legal entity is the one thing a court, a bank and a counterparty all recognize, so every digital authority must trace back to it.
How to set it up.
- Find the formation record in the state or national registry and note its file number.
- Keep the certificate of incorporation and any delivery email from the registry — the email is evidence of where the document came from.
- Record it in CorpID as legal-entity evidence.
What it proves. That a registry references this entity, at the depth recorded.
What it does not prove. That the person operating the record is an officer of that company.
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.
- Create the root account first (see Root account) — the Safe's address becomes the digital name.
- Adopt it by board resolution as the company's digital name.
- File a DBA / assumed-name with your state that names the address, as Rootz did, so the law links the name to the company.
- 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.
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.
- Draft a Corporate Digital Authority Policy (who approves AUTHORIZE / REVOKE, at what threshold, how recovery works).
- Adopt it by board resolution.
- Publish it through /governance; CorpID records its hash and version.
- 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.
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.
- Pick the system (Entra, Google Workspace, Okta, internal PKI).
- Where it allows, place the Corporate Digital Name or a reference to it inside that system (a tenant attribute, a certificate extension).
- 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.
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.
- The person or agent creates their own identity and key (a wallet or identity contract).
- 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.
- 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).
- 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.
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.
- Choose the owners — usually officers or directors — and give each their own hardware wallet.
- Create a Safe at app.safe.global (Rootz uses Ethereum mainnet) with those owners.
- Set a threshold of at least 2 (for example 2-of-3) so no single key can act.
- Adopt the Safe's address as the Corporate Digital Name by board resolution, and record the recovery process in the authority policy.
- 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.
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.
- Create at app.safe.global; record the address and network.
- Fund it with a small amount of ETH for transaction fees.
- 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.
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.
- Pick a threshold that is more than one and less than all (2-of-3 or 3-of-5 are common).
- Record who holds each owner key in the board resolution — not on chain.
- 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.
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.
- Leave both empty until you have a specific, reviewed module or guard.
- Enable one only through a Safe transaction signed at the threshold, so the change is logged.
- 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.
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.
- Nothing to set up: every action your Safe executes appears here automatically.
- To make an act readable by people, put a clear sentence in the transaction data, as Rootz has.
- 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.
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.
- In Safe{Wallet}, create a transaction to the wallet being authorized, value 0, with the sentence (encoded as UTF-8 hex) as data.
- Use the exact form: 'The wallet 0x… is authorized for [scope] by [company] until [month day year]'.
- Collect the threshold of owner signatures and execute.
- 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.
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.
- Write the statement plainly, naming the company and any registry references.
- 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.
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.
- After an agreement completes in DocuSign, copy its envelope ID.
- 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.
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.
- Use Safe{Wallet} settings to add or remove owners or change the threshold.
- 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.
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.
- 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.
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.
- 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.
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.
- 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.
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.
- Use /setup's evidence room. Add the original artifact and, separately, how it reached you (for example the registry's email).
- 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.
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.
- Prepare the binding at /api/v1/epistery/prepare.
- Write the profile from an already-authorized rivet on the identity contract.
- 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.
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.
- Ask the sender for the envelope JSON and signature.
- 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.