WOTA Passport: Trust + Access + Receipts for Agentic Apps

0. Abstract

WOTA is a passport-centric trust network designed for the emerging “agentic” internet—where users and autonomous software agents interact with applications, marketplaces, and workflows that require strong authorization, eligibility gating, and auditability. WOTA Passport enables verifiable eligibility (e.g., membership, age-gate, domain ownership), scoped permissions for agents, and tamper-evident receipts for every verification and authorization event. Settlement and incentives are handled on Base using the WOTA token, avoiding the security and operational risks of maintaining a separate settlement chain and bridge infrastructure.

WOTA’s core thesis: identity is messy, eligibility is shippable—and the fastest path to real adoption is to standardize proofs and receipts, not store personal profiles.

1. The problem: agentic systems need trust primitives

Software agents can now:

  • browse, summarize, and propose actions,
  • draft and publish content,
  • operate workflows across multiple tools,
  • and coordinate with other agents.

But production systems still lack a universal way to answer:

  1. Can this user access this feature?
  2. Can this agent perform this action—under what limits?
  3. Can we prove what happened afterward?

Today’s solutions are fragmented:

  • account/password systems don’t map cleanly to wallets or composable apps,
  • “KYC identity” is often too heavy for simple eligibility gating,
  • many platforms cannot produce portable, cryptographically verifiable audit trails.

WOTA Passport focuses on eligibility, authorization, and receipts as the universal trust layer for agentic apps.

2. WOTA’s approach: Passport + Permissions + Receipts

WOTA consists of three tightly coupled components:

2.1 WOTA Passport (the product layer)

WOTA Passport is a credential + policy system that supports:

  • Eligibility proofs (membership, proof-of-adult, region/jurisdiction gates, partner access)
  • Domain proofs (DNS TXT / meta-tag verification)
  • Agent binding (agent keys bound to wallet/org identity)
  • Scoped authorization tokens (what an agent is allowed to do, how often, how long)
  • Receipts for every significant event

WOTA Passport is compatible with modern Verifiable Credential models and verification flows. World Wide Web Consortium (W3C) published Verifiable Credentials Data Model v2.0 as a Recommendation on May 15, 2025, reflecting the maturity of credential-based verification as a standard primitive.

2.2 WOTA Trust Network (the service layer)

A set of actors and services that perform and attest to “passport work,” including:

  • Issuers (entities allowed to issue certain credentials)
  • Verifiers (services that verify presentations and evaluate policy)
  • Receipt anchors/retention services (store receipts, optionally anchor hashes on-chain)
  • Challenge/Dispute mechanisms (optional, for higher-stakes use cases)
2.3 WOTA Token on Base (the incentive + settlement layer)

WOTA uses a single canonical token on Base for:

  • paying for verification/authorization work,
  • staking and reputation (optional but recommended),
  • and rewarding agents/verifiers for valid, provable services.

Base provides mature EVM tooling and widely supported network configuration; its chain ID is 8453.

3. Why Base-only: removing bridge risk and chain overhead

Many systems introduce a second settlement layer (custom chain) and bridge value across networks. WOTA explicitly avoids this for the initial launch.

3.1 Bridges expand the attack surface

Cross-chain infrastructure has historically been a major source of loss in crypto security incidents. Industry analyses repeatedly highlight that large-scale theft has often concentrated around DeFi and cross-domain attack surfaces (including bridge-adjacent patterns). Chainalysis reports emphasize the persistence of hacking threats across years of crypto markets.

WOTA design principle: Do not bridge value unless absolutely necessary.
Instead, WOTA moves signed receipts (data), not tokens.

3.2 Running a chain is a product in itself

Operating a chain requires:

  • validator security assumptions,
  • upgrades, forks, governance,
  • monitoring, incident response,
  • and long-horizon maturity expectations.

If the goal is a near-term launch of passport and agent authorization, chain operation is not leverage—it is distraction.

4. Optional OTR layer: transport, not settlement

WOTA supports an optional “OTR transport mode” for low-connectivity environments:

  • store-and-forward messaging,
  • local receipt spooling,
  • delayed submission when connectivity returns.

Critically: OTR is not a token settlement layer in the Base-first architecture, which means:

  • no OTA↔WOTA bridge,
  • no cross-chain value movement,
  • no bridge exploit class introduced by design.

In Base-first mode, OTR is simply a delivery network for signed receipts and payloads.

5. System roles

WOTA Passport supports the following roles:

  • Holder: user or org that holds credentials.
  • Issuer: entity that issues a credential type (allowlisted or permissioned per credential class).
  • Verifier: entity that checks proofs and evaluates policies.
  • Agent: software identity bound to an org/user with scoped permissions.
  • Relying Party (RP): application that depends on WOTA Passport decisions (gating/authorization).
6. Credentials, presentations, and receipts
6.1 Credential types (v1)

WOTA Passport focuses on minimal, high-signal credential classes:

  1. Proof-of-Membership
  2. Proof-of-Adult / Eligibility (age-gate without doxxing)
  3. Proof-of-Domain Control (DNS TXT / meta tag)
  4. Proof-of-Agreement / Consent Receipt
  5. Agent Binding Credential (agent key ↔ org/user)
6.2 Receipts (the WOTA “unit of work”)

Every verification or authorization produces a receipt that includes:

  • event type (issue/verify/bind/authorize/policy decision),
  • hashed references to the credential/presentation,
  • policy version hash,
  • timestamp + nonce,
  • signer identity (verifier/issuer),
  • result (allow/deny + reason codes),
  • optional anchor hash pointer (if anchored later).

Receipts are designed to be:

  • portable (exportable),
  • auditable,
  • privacy-minimizing (hash references rather than store raw PII),
  • and machine-actionable (agents can reason over receipts).
7. Policy engine: eligibility and permissions

WOTA Passport includes a rules layer to answer:

  • “Is this membership tier sufficient?”
  • “Is this feature allowed for this jurisdiction?”
  • “Does this user meet eligibility constraints?”
  • “Does this agent have scope to do this action?”
  • “Do we require human approval for this class of action?”

Policy versioning is critical: every receipt includes the policy hash/version so auditors can reproduce the decision basis later.

8. Tokenomics: pay-for-proof, stake-for-trust

WOTA tokenomics reward verifiable work, not vanity actions.

8.1 Fee-funded rewards (default)

A relying party pays a fee for:

  • verification,
  • authorization token issuance,
  • receipt retention/anchoring.

Fees are distributed to:

  • verifiers/agents performing the work,
  • retention/anchoring services,
  • protocol treasury (optional parameter).
8.2 Stake + slashing (recommended for open networks)

To reduce fraud and enable open participation:

  • verifiers/agents stake WOTA to provide services,
  • provably bad behavior (upheld challenges, repeated incorrect attestations) leads to penalties/slashing,
  • good reputation earns more routing volume and fees.
8.3 Anti-farming constraints

Rewards only apply to “hard events” that produce:

  • signed receipts,
  • nonces tied to real sessions,
  • rate-limits per identity,
  • and caps per domain/credential class per period.
9. Security model
9.1 Threats addressed
  • Credential forgery (issuer verification)
  • Replay attacks (nonces + expiries)
  • Key compromise (rotation + revocation receipts)
  • Sybil farms (stake + rate limits + reputation)
  • Over-privileged agents (scopes + expiries + optional human approval gates)
  • Audit disputes (policy version hashes + signed receipts)
10. Privacy and data minimization

WOTA Passport is designed for:

  • selective disclosure: prove eligibility without revealing unnecessary data,
  • receipt-first auditing: prove what happened without building user dossiers,
  • off-chain sensitive data: avoid placing PII on-chain; only anchor hashes when needed.

This aligns with global trends toward wallet and credential frameworks, including the EU Digital Identity approach. The European Commission states the European Digital Identity Regulation (EU) 2024/1183 was adopted May 20, 2024, supporting a continent-wide move toward wallet-based digital identity primitives. European Commission European Union

11. Compliance posture (high-level)

WOTA Passport is an eligibility and authorization layer; it is not inherently a KYC provider. However:

  • certain use cases may require KYC/AML through third parties,
  • applications must comply with local regulations for their activity (e.g., financial products, wagering, derivatives).

For U.S. contexts, the Commodity Futures Trading Commission publishes primers describing digital assets and the agency’s role, which can help frame how product design affects regulatory exposure.

(This section is informational only and not legal advice.)