Glossary
This glossary defines the terms used across the not.bot technology documentation. Entries are alphabetical, and each one stands on its own: it states the not.bot-specific meaning in full, so an AI reader that retrieves a single entry has everything it needs. Cross-references point to related terms by name. Implementation-level terms say so in their own text; a reader answering a product question can skip them.
admin service: One of the four components a business deploys to run not.bot Verify. It manages the pool of signature DIDs and runs on the business's internal network with no public path. See also: not.bot Verify, signature server, Kubernetes cluster.
adversarial appliance: Julia Social's containment architecture for honest.bot agents: a confidential virtual machine (AMD SEV-SNP or Intel TDX) that treats the agent inside it as an adversary presumed to want to bypass containment. It runs four cooperating services, an ingress daemon, an identity daemon holding the sealed signing key, an MPC gateway as the agent's only outbound path, and an append-only audit daemon, and it holds the identity even when the agent is compromised through prompt injection. See also: honest.bot, process binding.
age credentials: Credentials derived from the holder's passport date of birth that prove age thresholds without revealing the birthdate. Julia Social produces them through a three-party MPC among the not.bot app, Julia Social, and the Escrow Server, so neither Julia Social nor the Escrow Server learns the birthdate. They carry a one-calendar-month validity window and refresh together through the same MPC. See also: AgeOver credential family, age verification, MPC, birthdate.
age verification: Proving that a user meets an age requirement through threshold or range claims, without revealing the exact age or birthdate. A site requests the threshold it needs (for example "over 18"), and the user presents only that boolean. See also: AgeOver credential family, age credentials, selective disclosure.
AgeOver credential family: A set of single-claim age-threshold credentials (AgeOver13 through AgeOver25, plus AgeOver100), each proving the holder meets or exceeds a stated age as a boolean. They derive from the passport date of birth through a three-party MPC, carry a one-calendar-month validity window, and re-encode the full set on each request so the request never reveals which thresholds apply to the holder. See also: age credentials, age verification, claim, selective disclosure.
agent (AI agent): A running automated process that interacts through natural language, APIs, and audio or video. An agent has no inherent identity, legal standing, or accountability; honest.bot gives it a process-bound identity whose authority derives from a delegation chain rooted in a not.bot-verified human. See also: honest.bot, process binding, delegation chain.
alias: A separate identity a user creates from their root identity for a specific context. Each alias is its own Chia coin with its own keys, credentials, and signature history, and the app derives every alias key from one on-device secret, so no observer, including Julia Social, can determine that two aliases share a parent. See also: root DID, alias DID, hidden alias, pairwise identifier.
alias DID: The decentralized identifier of a specific alias. It rides inside a signature or a verified response, so a reader resolves who signed straight from the signature itself. See also: alias, DID, signature.
Alias Vault Key (AVK): A roadmap feature, planned to ship with not.bot Signer. A per-alias symmetric key the app holds, used so a host application can keep each user's server-side data encrypted at rest under a key it does not retain between sessions. When not.bot Verify requests a signature it can request the AVK in the same exchange; the app returns the key beside the signature and places a commitment to the key inside the signature, so the published signature stays safe while the key travels outside it. The host holds the key for the login session and discards it at logout, and the key lives in the Recovery Data Bundle. See also: Recovery Data Bundle, not.bot Signer.
all-or-nothing approval: The approval model for a not.bot Verify request. The user sees the full set of requested claims, then responds with all of them or declines the entire request. There is no partial approval of individual claims, and the user can also decline to respond at all. See also: selective disclosure, claim, verifier.
antecedent: A dependency of one claim on other claims: a claim is valid in a presentation only when its antecedents are present and valid, which makes real-world authority structures machine-checkable. The corpus names four behaviors. Cascade revocation: revoking an antecedent invalidates every claim that lists it. Cross-issuer: antecedents can come from separate issuers, and the dependent issuer learns only that they exist and are unrevoked. Cross-subject: antecedents can name other subjects, which makes two-person-rule constructions expressible. Structural disclosure: presenting a claim discloses the existence and property hashes of its antecedents, so schema designers should treat the antecedent structure as visible to verifiers. See also: claim, cascade revocation, mandate chain.
argon2id: The key-derivation function the app uses to turn a user's recovery password into the key that encrypts the Recovery Data Bundle, with parameters that meet or exceed OWASP guidance. (The corpus also uses argon2id as a claim-value encoding name in the credential registry.) See also: recovery password, Recovery Data Bundle.
assisted recovery: The recovery path that uses recovery agents. The owner's new device generates a fresh keypair, the owner proves identity to each agent and collects a one-time, time-limited authorization, then submits a quorum of authorizations to the chain naming the new key. The DID then locks for a configured delay (48 hours in Julia Social's configuration), during which only cancellation is possible before the recovery completes. See also: recovery agent, pre-rotated keys, Recovery Server, watchtower.
attenuation: The narrowing of authority at each step of a delegation. Every delegated permission is the same as or narrower than its parent, and a credential issued beyond the issuer's own scope fails verification. In credential delegation, attenuation also comes through each delegation's own expiry, which can be shorter than the underlying credential's. See also: delegation, subdelegation, mandate chain.
biometric authentication: FaceID, TouchID, or the device passcode, required on the user's own device at the moment of an action. The app demands it to sign content, approve a verification request, reveal a hidden alias, and add or reset a device, so a signature can only come from the person holding the unlocked phone. See also: signature, secure element, hidden alias.
birthdate: The date of birth that age verification withholds from sites. The passport supplies it at enrollment, the age-credential MPC consumes it without any party learning it, and the user proves age thresholds without revealing it. The BirthDate claim exists but a site requests it only when it has a specific need. See also: age credentials, age verification, claim property.
BLS12-381: The signature scheme used for every signature in did:julia, with the property that any number of signatures from any number of uncoordinated signers combine into one fixed-size aggregate. did:julia requires it for credential-claim composition: claims from independent issuers aggregate into one all-or-nothing presentation signature that a verifier cannot break apart to lift and reuse a single claim. It is also Chia's native scheme, so it serves on-chain authorization, and claim composition is the property that singles it out. See also: credential, verifiable presentation, Chia.
bricking a DID: Removing all keys, recovery agents, and custodians from a DID while leaving the singleton and its history on chain. It is the destructive action available to an owner, since a Julia DID cannot be melted. The protocol excludes melt for DIDs on purpose: a malicious recovery could otherwise melt a DID and leave nothing to recover, so recovery agents asked to brick a DID ask many questions first. See also: melting, singleton, recovery agent.
Business DID: A did:julia identity for an organization, using the stronger ownership models (multi-sig, multi-class multi-sig, or custodian) and holding organization credentials such as the Domain Name credential that links the DID to a DNS domain. Because a company cannot act, every operational action is a delegation from the Business DID's governance structure to a specific human. See also: multi-class multi-sig, custodian capability, delegation.
BYOC (bring your own cloud): The not.bot Verify deployment model in which a business runs Verify inside its own data center or cloud account: its own signature servers, Chia nodes, key store, and admin service, behind its existing security perimeter. No user data passes through Julia Social during verification, so the business keeps control of its data retention and compliance posture. The corpus describes this as running Verify "inside your own infrastructure"; BYOC is the shorthand. See also: not.bot Verify, Kubernetes cluster.
C2PA: The Coalition for Content Provenance and Authenticity, an industry content-provenance standard under which cameras and editing software attach a tamper-evident record of how a file was created and changed. not.bot's relationship to it is cooperative: C2PA tracks the device and software through the production pipeline but does not track the person, while not.bot adds the human layer, so running both gives coverage neither provides alone. See also: CAWG, signature, deepfake.
capability credential: In honest.bot, a credential that enumerates an agent's permissions, each scoped by property and value, time-bounded, and revocable. It answers the question "what is this agent permitted to do?" These are ordinary did:julia credentials, not a parallel system. See also: honest.bot, task credential, technology stack credential.
CAPTCHA: The legacy challenge that asks a visitor to prove humanity by reading distorted text or picking images. AI now defeats it, and it fails on accessibility and friction, so not.bot replaces it with cryptographic proof of personhood that asks nothing of the user beyond approving a request. See also: proof of personhood, sybil resistance.
cascade revocation: The antecedent behavior where revoking one claim invalidates every claim that lists it as an antecedent. The verifier walks the antecedent chain at presentation time, so a revoked parent collapses the whole tree of authority derived from it. See also: antecedent, revocation, delegation chain.
CAWG: The Creator Assertions Working Group, building the specification-level bridge between device provenance and human identity. Its Identity Assertion specification lets a verified human sign within a C2PA manifest and supports decentralized identifiers, the identifier format not.bot uses, so a path exists for embedding not.bot credentials in C2PA manifests. See also: C2PA.
Chia: The public blockchain on which every not.bot identity is recorded as a did:julia DID. Julia Social uses it as a specialized database for digital identity, chosen for BLS12-381 signature aggregation, a coin (UTXO) model that holds each identity as an independent singleton with no central contract, programmable spending rules, off-chain presentation, low-cost nodes, and proof-of-space-and-time consensus. The chain holds DID state, key history, and credential revocation, and signing and verification run against it with no Julia Social involvement. See also: Chialisp, Chia node, singleton, XCH.
Chia node: A server on the Chia network. Anyone with access to a single Chia node can verify any did:julia identity, and tens of thousands exist worldwide; an online off-chain verification reads from one of these (public or the verifier's own), which keeps Julia Social off the path. A not.bot Verify deployment runs its own. See also: Chia, not.bot Verify, presentation modes.
Chialisp: Chia's functional programming language, which specifies the conditions under which a coin may be spent. did:julia encodes ownership, recovery, delegation, and revocation in the identity coin's Chialisp. Because the same program on the same inputs produces the same output, a verifier can confirm a transaction's one possible effect in advance from a few coin states, including offline, and no party can change a coin's program after creation. See also: Chia, singleton, curried data.
claim: A single statement about the subject within a credential. Each claim names its property through a load-bearing URI of the form encoding:authority/path (for example notbot://./v1/notbot0), where the encoding says how the value is encoded, the authority names the DID whose namespace defines the semantics, and the path is the issuer's own taxonomy. In the Julia Social model, one claim is one credential, signed on its own. See also: credential, single-claim credential, claim property, selective disclosure.
claim property: The named attribute a claim carries. Julia Social's personal-information properties include FirstName, FamilyName, Nationality, BirthDate, and the AgeOver family; each is its own single-claim credential, so a site receives only the properties it requests. See also: claim, AgeOver credential family, selective disclosure, birthdate.
coin-control puzzle: In the open-source Chialisp, coin_control.clsp, the combineable DID operation that sends DID-authorized commands to other coins, emitting one SEND_MESSAGE per target coin. It emits the command and does not check the receiving coin's type. Most readers never need this; see the Chialisp Code Reference (Doc 19). See also: pass-thru, issuer-key-control.
credential: A signed statement by one entity (the issuer) about another (the subject). Credentials let a user prove facts about themselves without revealing more than they intend, without contacting the issuer at presentation time, and without granting the recipient the ability to re-present the underlying claim. They are the operational substrate of every not.bot interaction with the outside world: signatures carry them, website verification exchanges carry them, and the proof-of-human guarantee is itself a credential. See also: claim, single-claim credential, verifiable presentation, not.bot credential.
credential metadata: A separate document, referenced by a claim through a hash, holding the issuer's human-readable name and description, claim-specific names and descriptions, language translations, and the W3C refresh-service, terms-of-use, and evidence fields. A holder can elide parts of the metadata without breaking the link to the claims. not.bot defaults to inline metadata so a presentation reveals nothing to the issuer; hosted metadata is supported but hands the issuer a usage signal when fetched. Issuer name, description, and icon are not trustworthy on their own, since any DID can write anything into them. See also: claim, credential.
curried data: How did:julia represents DID state: the state is curried into the puzzle as data, and a state-changing spend creates the next singleton generation with a different puzzle hash, while an unchanged-state spend keeps the same hash. The DID and issuer-key puzzles are curried with a hash of the state, not the full state, which arrives in the solution and is checked against the hash. See also: singleton, curried-args hash, fast-forward.
curried-args hash: In the open-source Chialisp, the sha256tree hash of a singleton's full curried-args state. The DID and issuer-key puzzles are curried with this hash rather than the full state; the full state arrives in the solution, the puzzle verifies it against the hash, then creates the next generation with the hash of the updated args. Most readers never need this; see Doc 19. See also: curried data, singleton.
custodian capability: The did:julia role in which a separate DID, the custodian, operates another identity using its own keys, with every action attributable through the custodied DID's on-chain spend record. The custodian works inside three fixed restrictions: it cannot rotate the owner's keys, cannot participate in recovery on behalf of the custodied identity, and cannot extend custodial control to a third identity. It is did:julia's bounded analogue of the W3C DID controller, used for power of attorney, commercial asset custody, and ownerless non-human identities. This is unrelated to the Escrow Server. See also: Business DID, custodian puzzle, Escrow Server.
custodian puzzle: In the open-source Chialisp, custody_minion.clsp, the authentication entrypoint for a DID controlled by an external custodian DID. It checks that the custodian is authorized, requires a message from the custodian DID's puzzle hash, asserts its own puzzle hash, and calls an allowed child operation, with recovery not active. Most readers never need this; see Doc 19. See also: custodian capability, minion DID.
decryption key: The key that unlocks encrypted not.bot data, held so that Julia Social cannot read content. For a QR-code signature, the key exists only in the QR image and the scanning app's memory, so Julia Social cannot read the hosted payload. For Signer's hosted content, the key is embedded in the signature, not held by Julia Social. For identity records in escrow, only Julia Social holds the air-gapped key, and the encrypted records sit with Praxis. See also: QR code, not.bot Signer, Escrow Server, Praxis.
deepfake: Synthetic media that impersonates a real person's face or voice. not.bot answers it by verifying the authentic rather than chasing the fake: a signature proves a passport-verified human stands behind content, and public figures, brands, and live video calls are where the harm lands hardest. See also: signature, C2PA, proof of personhood.
delegation: The credential operation by which a well-protected identity grants narrow, time-bound, revocable authority to a less-protected identity that handles routine work. The protected identity keeps the right to revoke any delegate, and a delegation claim can carry antecedents so revocation cascades as intended. See also: delegation chain, subdelegation, attenuation, mandate chain.
delegation chain: The lineage that traces an agent's or delegate's authority back to a principal who authorized it and can revoke it, ending at a human key-holder. In honest.bot, every presentation includes the full delegation chain identifying the accountable not.bot-verified human by alias. See also: delegation, mandate chain, honest.bot, cascade revocation.
DID: A decentralized identifier following the W3C convention did:<method>:<identifier> that names a unique thing: a person, company, agent, or physical object. not.bot identities are DIDs on the Chia blockchain, expressed through the did:julia method. A DID is a string that identifies; it is not an identity in itself. See also: did:julia, root DID, alias DID, DID Document.
DID Document: A document that describes the entity a DID identifies; the W3C specification requires only that it contain the DID itself. In did:julia the DID singleton carries a pointer to the document rather than its contents, so a DID is usable with no document lookup. The pointer mechanism ships today; the publication path that writes and resolves document contents is planned. See also: DID, did:julia.
did:julia: The DID method underlying every not.bot and honest.bot identity. It makes a decentralized identifier the launcher ID of a Chia singleton, with all identity state (authentication keys, recovery and custodian configuration, DID Document pointer) living on chain, so anyone with Chia access can verify it without contacting a central server. One model serves humans, organizations, software agents, and non-human objects. See also: DID, singleton, Chia, self-certifying lineage proof.
display name: The user-visible name shown for an alias. By default this is the alias petname; a subscriber can replace it with a reserved name, and a Verified Signer alias shows the Verified Signer badge in its place. The corpus does not define "display name" as a formal term; it names the specific mechanisms. See also: petname, reserved name, Verified Signer, LifeHash.
dummy transaction: A decoy on-chain operation Julia Social submits, faucet-funded and matching the structure of real DID creation, rekey, and recovery spends, so an outside observer cannot tell a decoy from a real operation. Its purpose is privacy: without decoys, several alias DIDs rekeying in the same block would form a pattern that links them to one person, and the added noise defeats timing analysis and correlation. See also: faucet coin, rekey, alias.
enrollment: The one-time act of scanning a passport in the not.bot app to create a phone-held identity. It is not required to verify other people's signatures, since the free app verifies without it; in-person enrollment options are planned. See also: NFC passport scan, passport, verification levels, scan-only mode.
escrow agent: The independent party that holds encrypted identity records without the key to read them, and whose cooperation a court order requires before any identity can be revealed. Praxis, a US escrow company, is the named escrow agent; it operates the Escrow Server and stores the encrypted records, while Julia Social holds the air-gapped decryption key. See also: Praxis, Escrow Server, decryption key.
Escrow Server: Software Julia Social wrote and an independent escrow agent (Praxis) operates on its own infrastructure. At enrollment it fetches passport data from Signicat, processes it into MPC inputs, hashes it for duplicate detection, encrypts the cleartext to a key only Julia Social can decrypt, and discards the cleartext. It also participates in the MPCs that produce credentials, including the three-party age-credential computation, without learning the underlying personal information. It holds encrypted identity data and cannot decrypt it. This is unrelated to the custodian capability. See also: Praxis, escrow agent, Signicat, MPC, custodian capability.
faucet coin: A coin Julia Social funds to pay a user's on-chain DID operations and fees, so the user never holds, receives, or accounts for XCH. Julia Social signs a faucet coin spend with a concurrent-spend assertion referencing the user's coin, and the user's spend asserts back, so neither confirms without the other and the coin cannot be diverted. Because the user never holds XCH, a tax authority cannot treat it as the user receiving cryptocurrency. See also: XCH, wallet, spend bundle.
fast-forward: A property that lets a DID operation that does not change state stay valid even when another spend of the same DID confirms first. did:julia achieves it by avoiding parent-specific authorization, binding the signature to the state-committing puzzle hash rather than a specific parent coin, so any number of unchanged-state spend bundles can be submitted at once without coordination. See also: singleton, curried data, self-certifying lineage proof.
hidden alias: An alias the user has marked as not visible in the app's regular alias list; reaching it requires an extra unlock step gated by on-device biometric or passcode authentication. It lets a user keep identities for sensitive contexts on a device other people sometimes see, similar in concept to a browser's private-browsing mode. See also: alias, biometric authentication.
holder presentation: Presenting a credential held as supporting context rather than as a statement about yourself, so a recipient can see that the credential exists and is genuine. It contrasts with presenting your own claim about yourself. See also: verifiable presentation, presentation modes, credential.
honest.bot: A roadmap product (targeted Q4 2026) giving verifiable, process-bound identity to AI agents, where each honest.bot identity traces through a delegation chain back to a single alias of a not.bot-verified human, so an agent answers to a named person. The underlying MPC protocol runs in production today inside not.bot Verify: each signature server acquires an honest.bot credential at startup, and no two servers hold the same credential at the same time. The product (the SDK, adversarial appliance, stack credential schemas, and OIDC integration) is the part still in flight. See also: honest.bot credential, process binding, agent, delegation chain.
honest.bot credential: An agent's process-bound credential, produced by an MPC between the agent and Julia Social that computes a value neither party can derive alone and that no second process can present. Julia Social confirms no other process holds a credential for the same identity, and a verifier confirms it by repeating the MPC with the agent, with no traffic to Julia Social during verification beyond a blockchain revocation check. See also: honest.bot, process binding, signature server.
ICAO Public Key Directory: The international directory of passport-issuing authorities' signing keys. During notbot0 enrollment, a certified identity-verification partner validates a passport chip's cryptographic signatures against it to confirm the document is authentic and unexpired. See also: NFC passport scan, Signicat, verification levels.
invalidate: In the open-source Chialisp, invalidate.clsp, which adds an impossible spend condition (plus optional time bounds) to a spend bundle, making it unusable on chain while it stays replayable for off-chain verification. It is the mechanism behind off-chain presentations. Most readers never need this; see Doc 19. See also: presentation modes, spend bundle.
issuer key: An issuer's credential-signing key, held in an Issuer Key Singleton on the Chia blockchain and configured with constraints (allowed properties, validity window, maximum expiration) that bound what it can sign. A Julia Social DID grants issuance authority by delegating to an issuer key, and melting the key invalidates every credential it ever signed. See also: Issuer Key Singleton, melting, issuer revocation override, validity window.
Issuer Key Singleton: A singleton, tied to an issuer DID, that holds an issuer's credential-signing key plus its revocation state, validity window, maximum credential expiration, and allowed property set. It is the on-chain structure that delegates and bounds credential issuance. An issuer DID launches one for its own signing or for a delegate, keeps lifecycle control, and can melt it. See also: issuer key, revocation bitfield, melting, singleton.
issuer-key-control: In the open-source Chialisp, issuer_key_control.clsp, the DID-side operation that sends commands to issuer key singletons: one mode updates a revocation leaf, another melts the issuer key. It changes no DID state. Most readers never need this; see Doc 19. See also: Issuer Key Singleton, melting.
issuer revocation override: The path by which an issuing DID revokes a credential it delegated without the delegate's cooperation, by updating the issuer key's revocation bitfield or by melting the issuer key singleton outright. A credential holder cannot revoke their own credentials; revocation authority rests with the issuer. See also: revocation, revocation bitfield, melting.
JAB code: A visible signature encoding that holds the entire signature payload in a high-density color barcode, alongside or instead of a QR code. JAB signatures are self-contained: the full compressed signature lives in the image, no server is contacted to create or verify it, and the visible code survives screenshots, forwarding, re-uploading, and re-photography that strip embedded metadata. Limits: up to 250 characters of message and up to three credential claims beyond the base not.bot credential. See also: QR code, signature.
JDID message namespace: In the open-source Chialisp, the reserved protocol prefix space for identity-layer messages and announcements, carried as JDID-prefixed byte tags (for example JDIDP, JDIDC, JDIDR). The pass_thru puzzle guards it, rejecting caller-supplied payloads that start with JDID, so application conditions cannot spoof DID, credential, issuer, or recovery signals. Most readers never need this; see Doc 19. See also: pass-thru, coin-control puzzle.
Julia Social: The company that operates not.bot and the issuer of every credential the system issues today. It runs credential issuance, hosts QR signature payloads, runs the faucet, mediates the reserved-names registry, runs the decoy-transaction service, and serves administrative app requests. The architectural privacy claim is that Julia Social never receives user-identifying data; revealing any identity requires Julia Social plus the independent escrow agent plus air-gapped decryption. See also: not.bot, honest.bot, Escrow Server, Praxis.
Julia Vanity Name: A roadmap feature: a self-governing username registry on the Chia blockchain where a chosen name, shown with the .nb suffix, belongs to the user on a registry no company can edit. Registration will take a refundable deposit rather than a fee, names will transfer and sell, and the registry will run without Julia Social maintenance. Reserved Names ship today as its preview mode, and every reserved name will be pre-registered in the new system at launch. See also: reserved name.
Keycloak: A login service a business provides for operator access to its not.bot Verify deployment (OIDC). Verify relies on it but does not include it; the business runs it as a prerequisite. See also: not.bot Verify, admin service, PostgreSQL.
Kubernetes cluster: The private cluster, inside the business's own perimeter and with no public ingress, in which a not.bot Verify deployment runs its four components: the signature servers, the admin service, OpenBao, and the Chia nodes. See also: not.bot Verify, BYOC, signature server, OpenBao.
LifeHash: A colored visual fingerprint derived from an alias DID that lets a user tell their aliases apart at a glance. It is deterministic, so any device holding the alias computes the same one. See also: alias, petname, display name.
mandate chain: A delegation cascade built from mandate credentials, distinct from credential delegation. Credential delegation passes presentation rights for one existing credential down a chain, walking the same underlying claim link by link. A mandate chain instead issues a new credential at each link: the principal issues a mandate granting authority to act, and each downstream agent issues its own narrower mandate that lists the upstream mandate as an antecedent. The verifier walks the antecedent graph and confirms the terminal action falls within the scope of every mandate, each the same as or narrower than the one above. See also: delegation chain, delegation, antecedent, attenuation.
MCP-I: An emerging protocol-layer standard that extends the Model Context Protocol with cryptographic identity and delegation, letting agents prove who they represent and what they are authorized to do. It complements honest.bot: honest.bot's MCP gateway supports MCP-I servers that accept honest.bot presentations, and MCP-I routes requests but cannot guarantee who makes them or that the requester is a single unique process, which is the identity layer honest.bot supplies. See also: honest.bot, agent.
melting: Spending an Issuer Key Singleton out of existence, which invalidates every credential that issuer key ever signed in one on-chain transaction. It is the issuer DID's coarse emergency revocation lever, and it is the enforcement mechanism for notbot1 partner fraud: melting a partner's issuer key revokes all credentials that partner issued. A Julia DID itself cannot be melted, only bricked. See also: Issuer Key Singleton, issuer revocation override, bricking a DID, verification levels.
minion DID: In the open-source Chialisp, a custodied DID that authenticates through custody_minion.clsp and acts on a custodian DID's command. The custodian sends it a message, and the minion verifies the custodian is authorized and matches the expected custodian puzzle hash. Most readers never need this; see Doc 19. See also: custodian puzzle, custodian capability.
Mod signature: In the open-source Chialisp, the first line of a mod, declaring its parameters. By convention, uppercase names are curried parameters and lowercase names are solution parameters. Most readers never need this; see Doc 19. See also: curried data, curried-args hash.
MPC (multi-party computation): A computation run across two or more parties so each learns only the output, never the others' private inputs. This is how Julia Social signs a credential without seeing its value. The not.bot ID credential uses a two-party MPC (the app and Julia Social); age credentials use a three-party MPC (the app, Julia Social, and the Escrow Server), in which neither Julia Social nor the Escrow Server learns the birthdate; a Site Pass uses a three-party MPC among the app, the site's Verify instance, and Julia Social. See also: not.bot credential, age credentials, Site Pass, process binding.
multi-class multi-sig: An ownership model that extends multi-sig by one level: X-of-Y classes, where each class is itself an M-of-N multi-sig, and a signer can belong to several classes but participates in one class per transaction. Julia Social's corporate DID uses "2-of-2: 2-of-3, 1-of-3" (2 of 3 executives and 1 of 3 air-gapped hardware signers). The same model governs both identity operations and every asset the identity owns. See also: Business DID, custodian capability.
NFC passport scan: The notbot0 enrollment action: the app reads the passport's NFC chip and sends the data to a certified partner for validation. The app reads only DG1, the machine-readable-zone text (name, date of birth, gender, nationality), and not DG2, the facial image, so no biometric data leaves the chip. See also: enrollment, passport, Signicat, ICAO Public Key Directory.
nonce: A fresh value tied to one request and bound into a signature or verification exchange to prevent replay, so a captured signature or response cannot be reused for a different request. See also: signature, all-or-nothing approval.
not.bot app: The phone app (iOS and Android) that is the user's identity. It enrolls the user through an NFC passport scan, stores keys, aliases, credentials, and contacts in an encrypted database whose key sits in the device secure element, and it creates signatures, scans and verifies signatures, and presents credentials to sites. It reaches Julia Social for administrative operations only; signing and verification need no Julia Social. The app is not a wallet. See also: not.bot, enrollment, signature, wallet, secure element.
not.bot credential: The credential every alias holds proving the alias belongs to a passport-verified human. It carries a cryptographic value, the not.bot ID, computed through a two-party MPC between Julia Social and the app, so a verifier can confirm "this signature came from a verified human" without learning who. Julia Social can link a specific not.bot ID back to the holder under one narrow circumstance, a court order executed with Praxis's cooperation, with neither party able to do it alone. See also: credential, verified human, MPC, proof of personhood.
not.bot Signer: A web tool, coming soon and targeted for the end of June 2026, for signing content at volume (videos, images, PDFs, links, posts) for newsrooms, brands, and public figures, where signing one item at a time from the phone adds too much friction. Signing still requires the not.bot app on the signer's phone to authorize each signature, so a verified human stands behind every signed item. Signer hosts an encrypted known-good copy of each signed item whose decryption key is embedded in the signature, and it is the first product to use Alias Vault Keys. See also: signature, Alias Vault Key, decryption key.
not.bot Verify: Server software a business deploys inside its own infrastructure to request and verify credentials (proof of humanity, Site Passes, age and attribute claims) from not.bot users. The user's app talks to the business's Verify servers, never to Julia Social, during a verification, and the deployment runs its own Chia nodes and its own key store (OpenBao). This is the customer-deployed model that lets regulated buyers verify without routing data through a third party. See also: BYOC, signature server, OpenBao, Kubernetes cluster, SDK.
one-person-one-account: The enforcement goal that a site can hold each human to a single account. not.bot achieves it through Site Passes, which let a site recognize a returning human and reject duplicates without learning the user's identity and without tracking across sites. See also: Site Pass, sybil resistance.
OpenBao: The vault, deployed inside a not.bot Verify customer's own Kubernetes cluster, that holds every DID's BLS12-381 private key and performs all signing inside the store, so no key leaves the cluster. Keys are generated inside OpenBao, are never written to disk in cleartext, and are never exported; signature servers send signing requests to it and receive signed results. See also: not.bot Verify, signature server, Kubernetes cluster, BLS12-381.
pairwise identifier: An identifier unique to a single pair of parties. In not.bot the Site Pass is the named instance, a pairwise identifier unique to one human-site combination: the same human always produces the same Site Pass for a given site regardless of alias, produces different ones for different sites, and sites cannot correlate them. See also: Site Pass, alias.
pass-thru: In the open-source Chialisp, pass_thru.clsp, the combineable operation that emits arbitrary caller-supplied conditions after guarding the JDID namespace. It rejects structured or JDID-prefixed announcements and message payloads, and it allows only present_claims and present_delegated as children. Most readers never need this; see Doc 19. See also: JDID message namespace, coin-control puzzle.
passport: The government identity document scanned at enrollment to create a not.bot identity. The app reads its NFC chip, a certified partner validates the chip's cryptographic signatures, and the data stays on the device. A passport is required to enroll and to sign; it is not required to verify others' signatures. See also: enrollment, NFC passport scan, verified human, ICAO Public Key Directory.
petname: The default user-visible name for an alias: a three-word phrase (for example "endlessly-altruistic-whale") derived from the alias DID bytes and computed by the app. Any device holding the same alias computes the same petname, so no display data needs to sync. See also: alias, display name, LifeHash, reserved name.
PostgreSQL: A database a business provides for its not.bot Verify deployment's application data and user records. Verify relies on it but does not include it; the business runs it as a prerequisite, the same way it provides Keycloak. See also: not.bot Verify, Keycloak, admin service.
Praxis: The named independent escrow agent, a US escrow company that has completed a SOC 2 Type 1 examination. Praxis operates the Escrow Server on its own infrastructure and stores the encrypted identity records it produces, without holding the decryption key, which Julia Social keeps on air-gapped hardware. A custom escrow contract binds Praxis to release a record only on a specific law-enforcement demand for the identified user, forbids bulk release, and on termination permits transfer only to a successor escrow agent under equivalent restrictions, never back to Julia Social. See also: escrow agent, Escrow Server, decryption key.
prelauncher: A coin that runs before the standard singleton launcher and embeds the original BLS public key, making the resulting launcher ID a cryptographic commitment to the key that created the DID. This commitment is the root of the fast-forward lineage proof and what makes a Julia DID self-certifying. See also: self-certifying lineage proof, fast-forward, singleton.
pre-rotated keys: A replacement key, or full ownership model, that an owner commits to in advance while the current key still works, so a lost or compromised key can be swapped in with one operation, no delay and no agents. The swap re-arms the next pre-rotated key and cancels any recovery in progress, so it also stops a malicious assisted recovery before it completes. The protocol supports it today; the current app does not yet expose it. See also: rekey, assisted recovery, recovery agent.
presentation modes: The three modes a did:julia verifiable presentation runs in, with the same identity and credentials working in all three. On-chain: the presentation is submitted to the blockchain as a permanent public record, for voting or smart-contract interaction. Online off-chain: the holder sends the presentation to the verifier, who checks it against the blockchain with no transaction recorded, prevented from ever going on chain by an invalidator condition. Fully offline: the verifier checks against a local snapshot of issuer state with no internet access and no contact with any issuer or Julia Social. See also: verifiable presentation, invalidate, Chia node.
process binding: honest.bot's binding of identity to a specific running process rather than to a key, achieved through MPC: agent and Julia Social together compute a secret bound to the process's memory that cannot be extracted from the credential. The guarantee is "this specific running process, right now, is the agent," which a copyable private key cannot provide, since one key can assert the same identity on many servers at once. See also: honest.bot, honest.bot credential, MPC.
proof of personhood: Establishing that a real human stands behind an account, comment, click, or vote, without learning who that human is. not.bot delivers it as a boolean: a valid verification requires an enrolled, passport-verified human on their own device, authenticating with their biometric at the moment of the request, and the site receives confirmation with no identity data. See also: not.bot credential, verified human, sybil resistance, CAPTCHA.
QR code: A barcode image used to carry a not.bot signature when the payload is larger than a JAB code holds (the subscriber path). The QR contains a randomized URL, a decryption key, and a hash; a verifier scans it, the app fetches the payload, and the key (held only in the image and the scanning app) lets it decrypt and check that a passport-verified human signed unaltered content. See also: JAB code, signature, decryption key.
recovery agent: A DID the owner pre-authorizes to vouch that a recovery request is legitimate, confirming the owner's identity and signing a one-time, time-limited authorization that the owner submits to the chain. Agents are named by DID, can be arranged as M-of-N quorums or multi-class sets, and are distinct from the Recovery Server, which performs the mechanical chain submission. Julia Social is the only recovery agent available today, in a single-agent configuration. See also: assisted recovery, Recovery Server, pre-rotated keys, watchtower.
Recovery Data Bundle: The encrypted backup of a user's identity state, held by the Recovery Server and encrypted under a key derived from the user's recovery password, which the operator does not possess and cannot decrypt. The same bundle serves both recovery and adding a device, and, under the AVK roadmap, it carries the per-alias Alias Vault Keys. The corpus also calls this the "recovery bundle" or "encrypted recovery bundle"; Recovery Data Bundle is the canonical form. See also: Recovery Server, recovery password, argon2id, Alias Vault Key.
recovery password: The one secret a user pairs with their passport to recover an identity after losing every device. It derives the key that encrypts the Recovery Data Bundle, so choosing a strong one is the protection that matters; no one, including Julia Social, can read the bundle without it. See also: Recovery Data Bundle, argon2id, assisted recovery.
Recovery Server: The server that holds each user's Recovery Data Bundle and submits recovery transactions to the blockchain. Because the bundle is encrypted under a key derived from the user's recovery password, the operator cannot read it; the app contacts the Recovery Server for recovery support and multi-device coordination, never for signing or verification. Julia Social operates the only Recovery Server today, and the roadmap splits its two roles and open-sources it for self-hosting. See also: Recovery Data Bundle, recovery agent, assisted recovery.
rekey: Replacing an identity's keys while the owner still controls a device: the current keys sign a replacement set into place in one operation, with no delay and no recovery agents. A rekey can also change the ownership model, collapsing a multi-sig to a single key or expanding a single key to a quorum, and it is the response to a suspected compromise while a device still works. The app reaches Julia Social only for the faucet coin that funds the transaction, not to authorize the change. (Doc 6D calls this operation "rotation"; Doc 13 names it "rekey.") See also: pre-rotated keys, assisted recovery, faucet coin.
reserved name: A .nb-suffixed name (for example alice-smith.nb) that a Pro or Verified Signer subscriber can request, today through a Julia Social-mediated registry. The roadmap replaces the registry with autonomous on-chain Julia Vanity Names, and existing reserved names convert when that mechanism deploys. See also: Julia Vanity Name, display name, Verified Signer.
revocation: Cancelling a credential so it stops verifying in future presentations. Revocation is checked against the blockchain and cascades down a delegation chain, so revoking a parent credential kills every credential derived from it; signatures already made stay valid. See also: revocation bitfield, cascade revocation, issuer revocation override, delegation chain.
revocation bitfield: A Merkleized bitfield, carried in the issuer key singleton, that records per-credential revocation: each credential maps to one position, and a set bit marks it revoked. The Merkleization lets one on-chain update change a position and lets a verifier prove a single position's state without holding the whole field. An issuer assigns positions off issuance order, so the chain does not leak issuance order or volume. See also: Issuer Key Singleton, revocation, issuer revocation override.
root DID: The recovery anchor of a not.bot identity, created at enrollment. Recovery operates on it first, and once it recovers the user's alias DIDs follow. The root never signs content or presents credentials. See also: alias, did:julia, assisted recovery.
scan-only mode: The app experience available to users outside US app stores, who can download the app and verify other people's signatures, browse contacts, and view history, but cannot enroll, create signatures, or manage aliases. International enrollment support is in progress. See also: enrollment, verifier.
secure element: The device hardware (the iOS Secure Enclave or an Android Trusted Execution Environment) that holds the not.bot encrypted database's key and, in the single-sig model, the alias's BLS12-381 signing key. Keys held here do not leave the device, so signing and database access stay on the user's phone. See also: not.bot app, biometric authentication, BLS12-381.
selective disclosure: Presenting only the claims a verifier requested and omitting the rest, made a list operation by single-claim packaging. Because each threshold is its own credential (AgeOver18 is separate from AgeOver21, both separate from BirthDate), a site can receive only AgeOver18 and learn nothing of the user's age, range, or birthdate. The user can also volunteer more than requested, decline specific claims, or decline to present at all. See also: single-claim credential, claim, all-or-nothing approval.
self-attested credential: A credential an identity issues about itself, with the same identity as both issuer and subject, for example a user issuing a credential that gives the value of their chosen avatar. Self-attested credentials let a user attach verifiable profile data without involving an external issuer; the underlying mechanism is self-delegation. See also: credential, delegation, claim.
self-certifying lineage proof: A presentation that proves a DID's full key history with no blockchain access, by revealing the original BLS public key committed in the prelauncher and every later spend that changed the DID, all covered by one aggregated BLS signature. An offline verifier walks the chain from the prelauncher forward and ends holding the DID's current state plus proof the presenter controls it. A signature under a retired key still verifies, because lineage resolves from the launcher commitment. See also: prelauncher, fast-forward, presentation modes.
signature: A not.bot signature is a cryptographic structure that carries the signer's whole acting identity, not a detached key. Each signature includes the signer's alias DID, a message the signer composed describing what they are signing, credentials (at least the not.bot credential proving the signer is a passport-verified human), and a timestamp and nonce that prevent replay. A verifier resolves who signed from the signature itself, checked against the chain, with no certificate authority or key directory. See also: JAB code, QR code, not.bot credential, alias DID, verifier.
signature server: The not.bot Verify component that signs on a business's behalf and acquires an honest.bot credential at startup, so no two signature servers in the world hold the same credential at the same time. It runs inside the customer's Kubernetes cluster and signs through OpenBao. See also: not.bot Verify, honest.bot credential, OpenBao, Kubernetes cluster.
Signicat: The passport-validation provider that confirms the NFC chip data is authentic, verifies the issuing government's digital signatures against the ICAO Public Key Directory, and confirms the passport has not expired. It holds validated data for up to five minutes keyed by session ID, then deletes it on the Escrow Server's command. Signicat holds ISO/IEC 27001:2022 certification, is an eIDAS Qualified Trust Service Provider on the EU Trusted List, and is certified to ETSI TS 119 461 for identity proofing. See also: NFC passport scan, ICAO Public Key Directory, Escrow Server, enrollment.
single-claim credential: Julia Social's constraint on the W3C model: a Julia Social credential carries one claim, and each claim is signed by the issuer on its own, with metadata held in a separate document referenced by hash. This makes selective disclosure a list operation and avoids the zero-knowledge cryptography that whole-credential signing would require. Claims sharing the same metadata hash can combine into a standard W3C JSON-LD verifiable credential, which keeps the model interoperable. See also: claim, credential, selective disclosure, credential metadata.
singleton: A Chia coin with a permanent launcher ID and one live generation at a time; spending it recreates the next generation. A Julia DID is a singleton whose launcher ID is the stable DID identifier, carrying authentication, recovery, custody, and DID Document state forward across generations. See also: did:julia, Chialisp, curried data, Issuer Key Singleton.
Site Pass: A pairwise pseudonymous identifier unique to one human-site combination, providing sybil resistance. The same human produces the same Site Pass for a given site regardless of alias, and different Site Passes for different sites, so a site can detect duplicate accounts without learning the user's identity or correlating across sites. It is computed through a three-party MPC among the app, the site's Verify instance, and Julia Social, and is the named exception to the general unlinkability property, which the user opts into per site. See also: pairwise identifier, sybil resistance, one-person-one-account, MPC.
spend bundle: A unit of one or more Chia coin spends submitted together. Message coordination and the faucet's mutual concurrent-spend assertions hold within one bundle, and a verifier checks one aggregate BLS signature per bundle no matter how many signers it represents. Off-chain presentations are well-formed spend bundles carrying a deliberate invalidating condition, so they cannot confirm on chain. See also: faucet coin, invalidate, presentation modes, BLS12-381.
subdelegation: When the issuer permits it, a delegate authorizes another identity to present the same credential it was granted. Each delegation is its own independent claim, and the terminal delegatee presents the original subject's claim alongside the chain of delegations connecting them. The chain is validated at presentation, and revoking any link breaks presentation for everyone downstream. See also: delegation, delegation chain, attenuation.
sybil resistance: Detecting when one human is pretending to be many (a Sybil attack: one person creating many accounts to abuse promo codes, post fake reviews, scalp, or farm airdrops). not.bot provides it through Site Passes: because each person produces one Site Pass per site, guaranteed by the math, a site can recognize that many apparent accounts belong to one person. See also: Site Pass, one-person-one-account, proof of personhood.
task credential: In an honest.bot presentation, the credential that describes the agent's current mandate, answering "what task has this agent been assigned?" so a verifier can check whether a requested action fits the stated purpose. It is a standard did:julia credential. See also: honest.bot, capability credential, technology stack credential.
technology stack credential: A credential issued by the platform operator that attests to an agent's runtime, model, and tooling, answering "what technology is this agent using?" It can be presented but not passed to another agent. See also: honest.bot, capability credential, task credential.
universal link: The mobile link a website presents as a button that, when tapped, opens the not.bot app to a verification request. It is the mobile entry point to the verification flow, where desktop uses a QR code instead. See also: not.bot Verify, all-or-nothing approval, signature.
validity window: The Valid-From and Valid-To period outside which a credential does not verify. Age credentials carry a one-calendar-month window and refresh through their MPC; on an issuer key, the window bounds the time during which a delegate can sign at all. See also: age credentials, Issuer Key Singleton, credential metadata.
verifiable credential: The standard credential form (a signed statement an issuer makes about a subject) that did:julia expresses and that other systems also use for identity and agent authentication. In not.bot each verification level is its own verifiable credential with its own notbot:// URI. See also: credential, single-claim credential, verification levels.
verification levels (notbot0, notbot1, notbot2): Three credentials, each with its own URI, describing the strength of identity proofing a user completed at enrollment. notbot0 (shipping today) attests that an authentic, unexpired, unique passport was NFC-scanned and validated against the ICAO Public Key Directory, with no liveness check. notbot1 (planned) adds in-person proofing to NIST SP 800-63A IAL2 at a contracted partner, enforced after the fact by melting the partner's issuer key on suspected fraud. notbot2 (planned) is proofing at a Julia Social-operated facility. The levels are cumulative, and a verifier requests the lowest level it needs without learning the user's maximum level unless the user volunteers it. See also: enrollment, NFC passport scan, melting, verifiable credential.
verified human: A real, unique person whose not.bot identity was established by validating a government passport's NFC chip at enrollment. It is the human layer not.bot adds on top of device provenance: only a verified human on their own device produces a signature, and the not.bot credential is what proves it. See also: not.bot credential, passport, enrollment, proof of personhood.
Verified Signer: A credential that links an alias to an online account, often a social-media handle, giving public figures a consistent verified identity across platforms. Julia Social signs it after the user posts their alias DID on the account and submits the post URL. The Verified Signer badge appears in the alias's signatures in place of the petname or reserved name (for example "Verified Signer: @notbot_official at x.com") and traces back to a passport-verified human without exposing the creator's legal name. Verified Signer is also a subscription tier. See also: alias, display name, reserved name, signature.
verifier: A party who checks a signature or credential. A verifier needs no pre-existing relationship with the signer, because the signature carries the signer's identity and credentials, and for honest.bot a verifier confirms a credential without contacting Julia Social. The free not.bot app makes anyone a verifier with no enrollment. See also: signature, presentation modes, scan-only mode, not.bot Verify.
wallet: A crypto wallet, which not.bot users never hold or see, even though identities live on a blockchain. The not.bot app is not a wallet and will not become one: it does not index the blockchain, track balances, or contain asset-handling logic, and Julia Social funds on-chain fees through the faucet so the user never holds XCH. See also: faucet coin, XCH, not.bot app.
watchtower: A planned third-party service that monitors the blockchain for a pending recovery against a subscriber's identity and alerts the owner inside the cancellation-delay window, even when the owner's app is not running. Julia Social cannot operate one, because alerting a user requires holding an email address or phone number, which identifies the user, and Julia Social will not hold that data. It waits on third parties willing to hold contact information. See also: assisted recovery, recovery agent.
XCH: The native unit of the Chia blockchain, used to pay the small per-transaction fee. The not.bot user never holds it: Julia Social supplies each fee through the faucet, bound to the user's transaction, so the user keeps no wallet, receives no XCH, and has no cryptocurrency receipt or taxable event. See also: faucet coin, wallet, Chia.