White Paper

The idea is simple:

Paste a mint. We verify the wallet. You ship the gate.

Solana projects keep running into the same problem. They want to give holders access to something private, but every team has to rebuild the same stack: wallet connect, message signing, token checks, session handling, protected content, private rooms, get-access links, and backend verification.

KEYCARD turns that repeated work into shared infrastructure.

For users, the pitch is easier:

Your wallet is the key.

If a project uses KEYCARD, access is based on what the wallet actually holds. No Discord role delays. No leaked links. No custom bot stack. No fake holder checks sitting in the client.

$KEYCARD is the network token for that access layer. It is designed to give holders access, give builders more capacity, give issuers trust tools, and route protocol activity back into the token economy as KEYCARD adoption grows.

Projects need holder chats. Creators need private drops. Teams need beta links. Alpha groups need private docs. NFT collections need collector-only files. Apps need protected pages. Launches need rooms where verified holders can talk without sending everyone to another platform.

Most teams solve this badly.

They rely on Discord roles, manual invite links, basic wallet connect, or one-off scripts. That creates a few problems:

• Wallet connect alone does not prove access.
• Leaked links keep working unless the backend checks every request.
• Every team rebuilds the same verification flow.
• Small teams do not want to maintain token-gating infrastructure.
• Users get bounced between bots, channels, forms, and vague instructions.
• Failed access usually ends at a dead page instead of telling the user what they need.

The result is friction for users and wasted engineering time for builders.

KEYCARD exists because access should be a standard primitive for Solana apps and communities.

KEYCARD Vault

Vault is for creators, communities, and projects that want to gate content without writing code.

It supports:

• wallet-gated files
• private links
• token-gated rooms
• launch rooms
• holder-only drops
• private docs
• protected screens

The creator flow is simple:

1. Upload content or create a room.
2. Paste a mint, NFT collection, or wallet rule.
3. Share one link.
4. KEYCARD verifies the wallet before access opens.

KEYCARD Gate

Gate is the developer layer.

It gives builders a reusable verification system for Solana apps:

• hosted unlock pages
• REST verification
• server-side wallet checks
• signed message sessions
• protected routes
• future React SDK
• future embeds and widgets
• future webhooks and API keys

Instead of rebuilding token gating for every app, developers can use KEYCARD as the verification layer.

The basic flow:

1. A project creates a gate.
2. The gate defines the access rule.
3. A user opens the gate or room.
4. The user signs a message with their wallet.
5. KEYCARD verifies the signature.
6. KEYCARD checks the wallet against the rule.
7. If the wallet passes, KEYCARD issues a short-lived access session.
8. The content, room, link, or app route opens.
9. If the wallet fails, KEYCARD can show what is missing and where to get access.

This matters because the access decision happens on the server. The app does not trust a connected wallet by itself.

• Phantom, Backpack, and Solflare wallet signing
• SPL token gates
• server-side mint and balance verification
• Helius/RPC-backed checks
• encrypted hosted file upload
• private Vercel Blob storage
• browser-encrypted direct upload support
• short-lived HTTP-only access sessions
• hosted unlock pages
• public gate creation
• public room creation
• permanent $KEYCARD holder chat
• basic analytics events
• get-access URL handoff
• wallet allowlist support
• NFT collection check support in the backend

The first live $KEYCARD utility is holder access.

Holders can use the $KEYCARD holder chat and supported launch rooms. This proves the core loop: hold the token, sign with the wallet, enter the private surface.

It is the access token for the KEYCARD network.

The token is designed around four user groups:

• Holders
• Issuers
• Builders
• Sponsors

Each group uses KEYCARD differently.

Holders

Holders get access.

The simplest version is the holder chat. More broadly, holders can be given access to:

• private rooms
• partner gates
• beta links
• early product demos
• launch rooms
• private docs
• creator drops
• holder-only files
• status proofs inside KEYCARD Passport

For users, this is the cleanest part of the product:

Hold $KEYCARD. Your wallet proves you are in.

Issuers

Issuers are projects, creators, and communities that use KEYCARD to create gates.

Issuers benefit from holding or staking $KEYCARD because the token is planned to unlock:

• more active gates
• higher usage limits
• branded gate pages
• verified issuer status
• gate analytics
• official gate bonding
• project-level trust badges

The goal is to make KEYCARD useful to the teams that actually ship gates.

Builders

Builders are developers using KEYCARD as infrastructure.

Builders should not have to rebuild wallet signing, holder checks, access sessions, and private route logic every time they launch an app.

KEYCARD gives builders a standard layer they can plug into. As the developer product rolls out, $KEYCARD is planned to support:

• API key eligibility
• API quota
• SDK access
• webhook access
• higher verification limits
• protected route tooling
• network-tier builder capacity

This gives $KEYCARD a direct role inside the builder stack.

Sponsors

Sponsors pay for access activity around a gate, room, launch, or community.

A sponsor might cover unlock checks, guest keys, or access credits so users can enter without friction. This creates a second use case beyond simply holding for access: projects can use $KEYCARD to activate access tools for their own community.

Planned sponsor utility includes:

• sponsored unlock checks
• guest keys
• temporary access
• file credits
• premium gates
• campaign gates

When developers and projects use KEYCARD infrastructure for paid gates, unlocks, rooms, sponsored access, or other transaction-based flows, KEYCARD plans to charge a 2% protocol fee on supported transactions.

The planned fee loop:

1. A project uses KEYCARD infrastructure.
2. A paid unlock, sponsored access action, or supported transaction happens.
3. KEYCARD charges a 2% protocol fee.
4. The protocol routes that fee into automatic $KEYCARD buybacks.
5. More usage creates more buyback pressure.

This is the core economic idea:

More builders using KEYCARD should mean more protocol activity flowing back into $KEYCARD.

This mechanism is planned infrastructure. It should be activated transparently, with clear public documentation, before it is marketed as live protocol revenue.

Hold

Holding $KEYCARD gives users access to supported KEYCARD surfaces:

• holder chat
• launch rooms
• partner gates
• early links
• private docs
• beta access
• KEYCARD Passport status

Stake

Staking $KEYCARD is planned to give issuers and builders more capacity:

• more gates
• more rooms
• more API quota
• branded pages
• issuer status
• builder tier access

Planned tiers:

• Holder: 1 gate
• Issuer: 5 gates
• Builder: 25 gates
• Network: 100 gates

Exact tier requirements should be published before enforcement.

Spend

Spending $KEYCARD is planned to activate access tools:

• guest keys
• sponsored unlocks
• premium gates
• file credits
• partner unlocks
• campaign access

This lets projects use $KEYCARD as an operating token inside the access network.

Bond

Bonding $KEYCARD is planned as a trust signal for official gates.

A project can stake behind a gate to show that it is the official issuer. This helps users know which gates are real, which matters as partner gates, token launches, rooms, and paid unlocks grow.

It is not a KYC product. It is not a master key. It is a wallet-based status profile that can prove access state across KEYCARD surfaces.

Passport can show:

• $KEYCARD holder status
• genesis status
• issuer status
• builder status
• gate history
• partner access

The goal is to let a wallet carry access status across rooms, gates, launches, and apps without exposing private keys or asking users to manage another account system.

If a wallet does not pass a gate, KEYCARD can tell the user what is missing:

• missing token
• missing NFT
• wrong wallet
• not enough balance
• not on allowlist
• token not configured

Then KEYCARD can send the user to the project's chosen get-access URL.

This turns failed access into a path back into the project.

For token communities, that matters. A locked room or drop can become a clean acquisition point instead of a confusing error screen.

Wallet connect is not access control.

KEYCARD uses:

• signed messages to prove wallet control
• server-side rule checks
• short-lived access messages
• HTTP-only access sessions
• private storage
• encrypted file handling
• no private key access

Private content is served through KEYCARD routes after verification. It is not exposed as a public storage URL.

There are honest limits:

• Already-downloaded files cannot be clawed back.
• Revocation controls future sessions, not files already saved by a user.
• Premium video should use encrypted streaming and watermarking later.
• Access checks must stay server-side for serious gates.

This honesty matters. KEYCARD should be trusted because it is clear about what it protects and what no web app can fully undo.

Phase 1: Launch Access Network

May 26-June 9, 2026

• Publish $KEYCARD CA.
• Launch holder chat.
• Ship holder status checks.
• Track launch analytics.
• Test production wallet flows across browsers and mobile.

Phase 2: Holder Rooms And Partner Gates

June 10-June 30, 2026

• Improve public room creation.
• Add partner gate templates.
• Improve missing-balance copy.
• Add token metadata.
• Start verified issuer pages.
• Publish first partner use cases.

Phase 3: Issuer Utility And Gate Capacity

July 1-July 31, 2026

• Activate holder, issuer, builder, and network tiers.
• Enforce gate quotas by wallet balance or stake record.
• Add creator analytics.
• Add API key beta.
• Add domain allowlists.
• Add signed admin actions.

Phase 4: Developer Access Layer

August 1-August 24, 2026

• Release @keycard/react beta.
• Add no-code embeds.
• Add webhook beta.
• Harden Token-2022 and cNFT checks.
• Publish SDK and developer docs.

But access is still messy.

Teams can launch a coin in minutes, but if they want a real holder room, private file, beta link, or protected app page, they usually need custom dev work. That gap is where KEYCARD fits.

KEYCARD gives projects a repeatable way to turn wallet ownership into access.

For users, it makes holding useful.

For builders, it removes repetitive infrastructure work.

For projects, it turns private content and community access into something they can ship quickly.

For $KEYCARD, it creates a token tied to the usage of the access layer itself.

Every Solana project needs access.

Some need it for files. Some need it for rooms. Some need it for drops, dashboards, apps, or private links. The shape changes, but the access problem is the same.

KEYCARD solves that problem once and lets every project reuse it.

Paste a mint. We verify the wallet. You ship the gate.

Your wallet is the key.

This document is not financial advice and does not promise token price performance.