gateway-protocol-primary-sources-2026-05-14

Gateway Protocol primary-source snapshot

Fetched: 2026-05-14 UTC

1) Whitepaper overview section

Source: https://raw.githubusercontent.com/identity-com/gateway-whitepaper/main/02-solution.tex

Selected excerpts from the whitepaper:

The Gateway Protocol is a cross-chain oracle token model that enables any application operating on a decentralized ledger to add a permissioning layer that adheres to predetermined requirements.

Identity verification is completed by one or more Gatekeepers belonging to a Gatekeeper network.

To take part in the ecosystem, a dApp simply extends its existing interfaces to require the presence of a specific and active Gateway Pass within an individual’s wallet.

Additional signals from the source:

• The protocol is best read as admission-control infrastructure, not as a generic identity wallet.
• The split among dApps, gatekeeper networks, and gatekeepers is the main reusable mechanism.
• The whitepaper explicitly frames pass verification as a way for dApps to outsource identity/compliance checks without storing personal data.

2) Pass-state model

Source: https://raw.githubusercontent.com/identity-com/gateway-whitepaper/main/03-tokens.tex

Selected excerpts from the whitepaper:

The presence of a Gateway Pass in a User’s wallet is proof that an off-chain verification has been performed by a Gatekeeper in line with the requirements of its network’s framework.

dApps do not need to know when a Gateway Pass was issued or which Gatekeeper issued it. So long as the Pass is present and active, that is proof the User has been verified in line with the appropriate framework requirements.

Gateway Pass states: Active, Expired, Frozen, Revoked.

Additional signals from the source:

• Pass state is part of the protocol surface, not just an operational detail.
• The verifier deliberately sees less than the gatekeeper; pass presence and state substitute for direct access to the underlying identity evidence.
• Multiple accepted gatekeeper networks can satisfy one dApp, which makes framework selection a distinct control surface.

3) Gatekeeper role and staking

Source: https://raw.githubusercontent.com/identity-com/gateway-whitepaper/main/04-gatekeeper.tex

Selected excerpts from the whitepaper:

Gatekeepers operate as oracles that bridge the trust layer between off-chain credential trust … and the on-chain dApps that require the trusted information to be part of a permissioned Pass.

To become a Gatekeeper … an organization must apply, undergo an audit by the Guardian, and stake a specified minimum amount of Governance Tokens.

The Guardian will have the power to slash the stake of any Gatekeeper that fails to uphold its duties.

Additional signals from the source:

• The gatekeeper is a supervised oracle operator, not merely a credential issuer.
• Admission and slashing policy define who can speak for a framework.
• The protocol’s trust model depends heavily on offchain audits and documentation, which means the governance layer is inseparable from the technical layer.

4) Governance section

Source: https://raw.githubusercontent.com/identity-com/gateway-whitepaper/main/07-governance.tex

Selected excerpts from the whitepaper:

There is a single DAO for the Gateway Protocol.

Guardians are voted into their role with the creation of a new Gatekeeper network … and can be challenged and replaced anytime by the DAO if evidence of abuse are found.

Identity.com … will initially serve as the sole maintainer of the Gateway Protocol.

Additional signals from the source:

• The whitepaper itself makes governance concentration legible through the guardian and maintainer roles.
• Network governance and protocol governance are separate but linked surfaces.
• The project is useful precisely because it shows how much admission control depends on auditors, maintainers, and framework-specific experts, not only on token voting.

5) Current open-source gateway implementation

Source: https://raw.githubusercontent.com/identity-com/on-chain-identity-gateway/develop/README.md

Selected excerpts from the repo:

On-chain applications require users to present a Gateway Token, which proves that they have been verified by a Gateway Provider to use the dApp. This token is tied to their wallet and is non-transferable.

This repository contains libraries … which combine to define the on-chain gateway protocol.

Additional signals from the source:

• The repo confirms the wallet-bound and non-transferable nature of the pass in implementation terms.
• The library split shows distinct operator surfaces for gatekeepers, dApps, and client-side discovery.
• The README narrows present implementation emphasis to Solana even though the whitepaper framed the design as cross-chain.

6) TokenGuard downstream module

Source: https://raw.githubusercontent.com/civicteam/token-guard/main/README.md

Selected excerpts from the repo:

A composable gateway program for Solana dApps.

dApp developers can protect access to any dApp that accepts tokens as payment … without requiring any on-chain smart-contract changes.

TokenGuard has an allowance feature … and a membership token requirement.

Additional signals from the source:

• TokenGuard shows the pass model reused as middleware beneath unrelated app contracts.
• It also reveals extra policy layers above the base pass system, like wallet-level allowances and membership-token constraints.
• This makes Gateway Protocol analytically relevant to anti-bot gates, NFT-sale access control, and admission middleware more broadly.

7) Transfer-hook downstream module

Source: https://raw.githubusercontent.com/civicteam/token-extensions-transfer-hook/main/README.md

Selected excerpts from the repo:

The Civic Pass Transfer Hook is a Solana Token Extension that enables token issuers to enforce constraints on token holders through Civic Pass.

The Civic transfer hook is built purely on the Gateway Protocol and can be used without any third-party services.

Permissioned tokens can be used in DeFi applications … to ensure that only users who have passed certain identity checks can participate.

Additional signals from the source:

• This repo is the clearest evidence that the gateway mechanism can become a lower-layer permissioned-token rail.
• The token-account-specific pass flow is a distinctive design wrinkle relative to simpler wallet-level attestations.
• The OpenBook and Orca examples make the DeFi integration path concrete and show how pass-gated assets can extend into market infrastructure.

Notes

• Gateway Protocol is worth cataloging because it cleanly separates framework definition, audited issuer admission, pass issuance, pass-state lifecycle, and downstream verifier usage.
• The strongest reusable insight is that onchain compliance can be modeled as reusable admission tokens checked by arbitrary programs, rather than as each app rerunning KYC itself.
• Main control surfaces to track later: guardian power, gatekeeper audits, maintainer concentration, pass-state transitions, network selection by verifiers, and the spread of downstream hook-based permissioned-token designs.