Grantor documentation#
OAuth with no authorization server. A caller presents a deed — a self-certifying credential it mints itself — and your app verifies it with a library call against a public on-chain registry. No authorization server exists in this path: Grantor operates no service, and the trust anchor is a contract readable from any RPC endpoint.
The 30-second model#
- Your app issues a challenge (the OIDC
nonceshape — one value, one use). - The caller signs or proves against it and returns a deed. No redirect, no token endpoint, no round trip to anyone.
- Your app calls
verify_deed, which checks the cryptography and reads the on-chain registry: is this tenant paid up, and for agents, is this member still un-revoked? - You mint your own session however you already do. Grantor never sees it.
Step 3 is a plain eth_call — a read. It costs no gas, needs no API key, and works from any RPC provider.
Pick your path#
| You are… | Start here |
|---|---|
| An app that needs to authenticate callers | Getting started |
| Just trying it out without spending anything | Develop locally — a free, disposable local devnet |
| Adding wallet login for humans | Wallet login |
| Adding passkey login for humans (closes the wallet-login phishing residual) | Passkey login |
| Your users hold smart-contract wallets (Safe / EIP-1271) | Smart-wallet login & admin |
| Building an AI agent that needs API access | Agent tokens · Agent integration |
| Restricting login to an admin-curated allowlist, anonymously | User gating |
| Gating a remote MCP server | MCP server auth |
| Granting bounded, delegated authority (not just identity) | Capabilities |
| Licensing software / gating a paid feature | Software licensing |
| Operating a tenant and want to detect a compromised admin key | Chain watcher |
| Wondering how any of this works | Concepts |
| A contributor | Architecture · Contributing |
Kinds of deed#
| Mode | Who holds it | Proves | On-chain check |
|---|---|---|---|
user-sig | a human with a wallet | control of a wallet-derived, app-scoped key; the app sees a pseudonym, not an address | tenant billing status |
user-passkey | a human with a passkey (WebAuthn) | control of a browser-bound P-256 credential; the app sees a pseudonym | tenant billing status |
user-1271 | a human with a smart-contract wallet (Safe / EIP-1271) | on-chain isValidSignature approval; the app sees a pseudonym, but one linkable to the wallet's public address — tradeoff | isValidSignature (the login itself) + tenant billing status |
agent-zk | an enrolled agent | ZK membership of the tenant's registry without revealing which member | membership-root recency (revocation) + billing |
user-zk | a human enrolled in the tenant's own user allowlist | ZK membership of that allowlist without revealing which member; the app sees a pseudonym | membership-root recency (revocation) + billing |
admin-sig | a Grantor dashboard admin (EOA); a Safe / EIP-1271 wallet is supported as a library capability, not yet wired into Grantor's own dashboard | control of a wallet address (identified, not pseudonymous) | none, deliberately — why |
All five user/agent modes verify through one call, verify_deed; admin-sig has its own entry point that verify_deed refuses. Why each mode exists and when to pick which: Sovereign tier, User gating for user-zk.
Everything ships in TypeScript, Python, Go and Rust — parity is CI-enforced. The matrix.
Reference#
- Concepts: the mental model — read this first.
- Machine docs:
llms.txt(index) ·llms-full.txt(everything, one file). - Every page here is also Markdown — same URL,
.mdinstead of.html. - Live, per RP deployment: an app that accepts deeds publishes its own
/.well-known/grantor-deeddiscovery document and challenge endpoint — see Sovereign tier § Discovery.
Guides#
- Concepts — the mental model
- Getting started
- Verify a deed — the relying-party side
- Wallet login —
user-sig, for humans - Passkey login —
user-passkey, phishing-resistant browser login for humans - Smart-wallet login & admin —
user-1271+ Safe/EIP-1271admin-sig, for smart-contract wallets - Agent tokens —
agent-zk, for machines - User gating —
user-zk, anonymous login restricted to an admin-curated allowlist - MCP server auth — gate a remote MCP server with a deed, no authorization server
- Capabilities — bounded, delegated authority on top of a deed
- Software licensing — a license is a deed, no license server, tiers via capability grants
- Develop locally — a free, disposable local devnet, no production spend
- Sovereign tier — the full deed reference
- Chain watcher — an operator sidecar that watches the registry for revocations/billing changes
- Errors
Agents (LLM-first)#
Internal (contributors)#
Status: developer preview. The contract and the full six-language end-to-end proof run on a local devnet (anvil). It has not been deployed to a public testnet or mainnet, and grantor-verify is not yet published to any package registry — today it resolves by path inside this workspace. It has not been audited. Do not put it in front of production money.
Licence: proprietary, all rights reserved. The source is readable — package registries distribute source — but that is not a grant of rights. You may use these libraries to integrate with Grantor; you may not fork, redistribute, or build a competing service with them. Full terms in LICENSE; enquiries for broader terms are welcome.