Components
- Operator binding. Every Passport sits on the 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.
- 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 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:/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 viaDojangScroll.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.
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_stateofunassigned, 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.
Evidence
The full local slice (sign-in, gateway usage, receipts, epoch anchoring, and the Passport page) is exercised hermetically by the localnet harness: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.
Next steps
- For the identity foundation the Passport binds to, see Dual Identity.
- For the attestation rail and the Verified Address read path, see Dojang: On-Chain Attestations.
- For how usage climbs from self-reported to attested, see Verified Usage and the Evidence Ladder.