> ## Documentation Index > Fetch the complete documentation index at: https://docs.giwa.tokscale.ai/llms.txt > Use this file to discover all available pages before exploring further. # Builder Passport > Learn what goes into a Passport, why it cannot be sold or transferred, and which parts of it are not built yet. A credential passport with a verified seal set into its face, bound and non-transferable A Builder Passport is a non-transferable record of how a builder actually works with AI, assembled from signed receipts and epoch Usage Roots. ## Components * **Operator binding.** Every Passport sits on the [dual identity](/builder-passport/dual-identity) foundation: one account joining a GitHub identity (immutable numeric ID) and one or more wallets (per `(chain_id, address)`). This binds a human-operated account to the addresses receipts accrue to. * **Usage proof.** Signed receipts rolled into epoch Usage Roots, provable down the chain: receipt → receiptRoot → leaf → Usage Root. For more information, see [Verified Usage and the Evidence Ladder](/builder-passport/evidence-ladder). * **Skill signal.** Per-harness proficiency derived from verified usage: which agents you use, at what intensity, at which tier. A dedicated Skill Signal attestation schema is part of the Tokscale schema set; see [Dojang](/builder-passport/dojang) for the schema plan and its live status. * **Verification rate.** The share of a builder's usage that sits at gateway-verified or attested tiers rather than self-reported. Anyone can report usage; only gateway-observed usage raises the rate. ## The profile mock The target profile looks like this. Every value below is illustrative, not a live profile: ``` juno.giwa VERIFIED ✓ AI-Native Builder Passport 41.2B verified tokens 486 active days 95% verification rate Claude Code EXPERT Codex ADVANCED Gemini CLI ADVANCED OpenCode EXPERT ``` What ships today is more restrained: `/passport/[username]` renders a shareable, network-labeled artifact from the strict public projection, with the publication network and gateway trust scope labeled on the page. ## Three principles ### Dojang as provenance Tokscale reads the Dojang Verified Address attestation, a wallet that passed KYC with a Dojang issuer, on-chain via `DojangScroll.isVerified`. That read path is delivered, runs behind a fail-closed validator, and returns every result marked `informationalOnly`. Gating Passport registration on a Verified Address is Phase 2: today no eligibility decision turns on Dojang. In demos the TESTNET FAUCET attester stands in, which is technical test evidence and not a KYC claim. For more information, see [Dojang: On-Chain Attestations](/builder-passport/dojang). ### Non-transferable by construction The Passport is EAS attestations about an address, not an ERC-721 token owned by an address. There is nothing to list, sell, or transfer, because identity lives as attestations rather than as a tradable asset. Reputation that can be sold is not a credential; this is the ERC-8004 gap, fixed by construction. **Builder Passport: identity you can't buy.** ### Private by design No prompts, code, or responses ever go on-chain. The chain carries salted commitments and verifiable aggregates only (epoch roots and salted summary commitments), and builders selectively disclose what they hold. Usage is proven without being published. ## Epochs and wallet binding Receipts accrue to a wallet, not just an account, and the binding is immutable: * At receipt creation, the active wallet is snapshotted into the receipt commitment as `subject_wallet`. * A wallet change starts a new subject epoch. Existing commitments are never rewritten; history stays attached to the wallet that earned it. * If no active wallet exists, the receipt remains verifiable but its commitment records a `wallet_subject_state` of `unassigned`, which leaves it ineligible for Passport attestation. There is no automatic retroactive assignment. * Anchoring publishes one EAS attestation per builder subject per epoch, with `recipient = subjectWallet`, so epoch membership is provable for that Passport and a receipt cannot appear under a second wallet. This is what makes the Passport a work history rather than a dashboard: the past cannot be re-attributed, only extended. ## Evidence The full local slice (sign-in, gateway usage, receipts, epoch anchoring, and the Passport page) is exercised hermetically by the localnet harness: ```sh theme={null} BUILDX_BUILDER=desktop-linux bun run local:e2e ``` Pass marker: `GIWA_LOCAL_E2E_OK`, browser artifacts `verified=receipt,passport,transactions`. This proves the pipeline locally, not a public deployment. Public status lives on [Live Evidence](/overview/live-evidence). ## Next steps * For the identity foundation the Passport binds to, see [Dual Identity](/builder-passport/dual-identity). * For the attestation rail and the Verified Address read path, see [Dojang: On-Chain Attestations](/builder-passport/dojang). * For how usage climbs from self-reported to attested, see [Verified Usage and the Evidence Ladder](/builder-passport/evidence-ladder).