Railcard Pay Docs
Overview
Railcard Pay is a Web3 card platform built on Ethereum and powered by $RAIL, a Uniswap v4 hook token designed to connect on-chain activity with future real-world card infrastructure.
The project begins with three core layers:
- The Card Layer — a premium card interface and user profile designed for future Mastercard-linked card activation.
- The Token Layer — the $RAIL token launched on Ethereum through a Uniswap v4 pool.
- The Rewards Layer — a simple fee model where buy-side activity rewards holders, while sell-side activity funds future card infrastructure.
Railcard Pay is built around one simple idea:
Before the full card program goes live, Railcard Pay launches the on-chain foundation: token mechanics, holder rewards, card profiles, dashboards, claim systems and infrastructure funding.
The long-term goal is to build toward a real Mastercard-linked crypto card experience through licensed issuing partners, compliance providers and payment infrastructure. The first phase focuses on the interface, token utility and the economic system that supports future card development.
What is Railcard Pay?
Railcard Pay is a card-first Web3 product.
Most crypto projects start with a token and add a dashboard later. Railcard Pay starts with the card as the center of the user experience.
The card is not just a visual element. It is the user’s main interface inside the ecosystem.
Through the Railcard dashboard, users will be able to:
- connect an Ethereum wallet;
- generate a Railcard profile;
- display a cardholder name;
- view a card number, expiry date and CVV inside the interface;
- track their $RAIL balance;
- view pending holder rewards;
- claim rewards;
- follow the progress of the card infrastructure treasury;
- prepare for future card activation.
In the first phase, the card interface represents the user’s on-chain card profile. Real payment functionality is planned for a later stage and will require licensed infrastructure partners, issuer support, compliance processes and regional availability.
Railcard Pay is not just trying to create another token. It is building a card ecosystem where $RAIL powers the relationship between holders, rewards and future card infrastructure.
The Vision
Crypto should not stay locked inside wallets, charts and decentralized exchanges forever.
The long-term vision of Railcard Pay is to create a bridge between Ethereum-based assets and real-world card usage.
The project is built around the idea that future crypto card infrastructure should have an on-chain economic layer behind it. Instead of launching a card product with no native community, Railcard Pay begins by building a holder base, a rewards system and an infrastructure treasury.
The vision is simple:
Sell builds the card.
Every buy of $RAIL contributes to the Holder Rewards Pool. Every sell of $RAIL contributes to the Card Infrastructure Treasury.
This creates a direct relationship between market activity and the future development of the card platform.
Mastercard Card Direction
Railcard Pay is designed with the goal of building toward a future Mastercard-linked card program.
A real Mastercard card cannot be created only with a smart contract. A live payment card requires licensed partners and traditional payment infrastructure. This may include:
- an issuing bank or BIN sponsor;
- card program manager;
- issuer processor;
- KYC/AML provider;
- compliance and risk systems;
- settlement infrastructure;
- regional legal availability;
- payment network approval;
- card backend and user account systems.
For this reason, Railcard Pay’s first phase focuses on the on-chain layer and user interface rather than claiming that live spending is already available.
The current product phase is:
The future product phase is:
This structure allows Railcard Pay to build the community, token economy and product interface first, while the full payment system can be developed later with the correct infrastructure.
Current Card Phase
In the current phase, users can generate a Railcard profile through the website interface.
The card profile can include:
- cardholder name;
- card number;
- expiry date;
- CVV;
- linked wallet status;
- rewards status;
- card profile ID;
- claimable rewards;
- $RAIL balance;
- card infrastructure status.
This card profile is designed to look and feel like a real fintech product interface. It is created to prepare the system for future card activation.
The card interface is the foundation for the next stages of the product. It allows users to become part of the Railcard ecosystem before payment functionality is enabled.
Future Card Activation
Future card activation is planned as a later development stage.
The goal is to enable real card functionality after the necessary infrastructure has been prepared. This may include:
- user verification;
- account creation;
- card issuing partner integration;
- Mastercard-linked virtual card support;
- top-up functionality;
- online payments;
- transaction history;
- spending limits;
- regional availability controls;
- mobile wallet support if supported by the issuer.
The exact availability, limits and requirements will depend on the future issuing partner, compliance structure and supported jurisdictions.
Railcard Pay should be understood as a staged product. The first stage builds the tokenized card ecosystem. The later stages aim to connect that ecosystem to real payment rails.
$RAIL Token
$RAIL is the native token of Railcard Pay. It powers the on-chain layer of the project and connects the card interface with the rewards system.
Basic token setup:
- Token: $RAIL
- Chain: Ethereum
- DEX: Uniswap v4
- Pair: ETH / RAIL
- Token mechanic: v4 hook fee model
$RAIL is designed to be simple. There are no complex tiers, no multipliers, no fake APY system and no complicated staking model in the base design.
The core purpose of $RAIL is to connect three things:
- holders
- card rewards
- future card infrastructure
Uniswap v4 Hook Model
$RAIL uses a Uniswap v4 hook-based fee model. The hook applies different fees depending on whether the transaction is a buy or a sell.
The fee model is:
- Buy fee: 2%
- Sell fee: 4%
These fees do not go to the same place. The system is intentionally split into two clean directions:
- buy fees reward holders;
- sell fees fund card infrastructure.
This creates a very simple narrative and a very simple economic model.
Buy Fee: Holder Rewards
Every buy of $RAIL includes a 2% buy fee. 100% of this buy fee goes to the Holder Rewards Pool.
The Holder Rewards Pool is distributed across eligible $RAIL holders according to their share of the total eligible supply.
The formula is simple:
There are no tiers. There are no multipliers. There are no hidden boosts. The more $RAIL a user holds, the larger their share of the Holder Rewards Pool.
When users buy $RAIL, they generate rewards for holders.
Sell Fee: Card Infrastructure Treasury
Every sell of $RAIL includes a 4% sell fee. 100% of this sell fee goes to the Card Infrastructure Treasury.
The Card Infrastructure Treasury is dedicated to the future development of the Railcard Pay card program. The treasury may be used for:
- card infrastructure development;
- frontend development;
- backend development;
- security work;
- compliance preparation;
- legal setup;
- issuer partner discussions;
- BIN sponsor preparation;
- card program planning;
- payment processor integration;
- KYC/AML provider setup;
- product design;
- future card rollout.
When users exit the token, part of that activity funds the future card infrastructure.
Rewards Claim System
Holder rewards are claimable through the Railcard Pay dashboard. The user flow is designed to be simple:
- Connect wallet.
- Hold $RAIL.
- Open the Railcard dashboard.
- View pending rewards.
- Click Claim Rewards.
- Receive claimable rewards.
The claim system is connected to the card interface. Instead of presenting rewards as a generic DeFi claim page, Railcard Pay presents them as Card Rewards. This means the card becomes the user’s main financial dashboard inside the ecosystem.
Card Rewards
The rewards system should be displayed as Card Rewards inside the product. Possible dashboard fields:
- $RAIL Balance
- Pending Card Rewards
- Total Claimed
- Reward Share
- Total Rewards Distributed
- Holder Rewards Pool
- Last Claim
- Card Profile Status
- Wallet Linked
Example dashboard:
- $RAIL Balance: 1,250,000 RAIL
- Reward Share: 0.83%
- Pending Card Rewards: 24,184 RAIL
- Total Claimed: 88,521 RAIL
- Card Status: Active Profile
- Wallet Status: Linked
The goal is to make the rewards system feel like part of the card product, not like a generic token dashboard.
No Tiers, No Multipliers
Railcard Pay does not need a complicated tier system in the first version. There are no Basic, Silver, Black or Infinite levels in the rewards formula. There are no reward multipliers. There is no hidden weighting model.
Rewards are based only on the user’s eligible $RAIL balance. This keeps the system:
- easier to explain;
- easier to implement;
- easier to audit;
- easier for users to trust;
- easier to display on the website.
The card itself is the main identity layer. The user does not need a tier to understand their position. Their $RAIL balance determines their share.
Card Interface
The Railcard interface is one of the most important parts of the product. The card should feel premium, realistic and ready for future infrastructure. The card design may include:
- Railcard logo;
- cardholder name;
- 16-digit card number;
- expiry date;
- CVV;
- EMV chip visual;
- wallet linked status;
- rewards active status;
- card profile ID;
- future activation status;
- transaction/rewards history.
Visual direction: matte black or graphite card; electric blue accent color; subtle rail-line pattern; metallic typography; clean spacing; premium lighting; futuristic but not overcomplicated.
The card should work as the central product image across the website, Twitter, docs and dashboard.
User Flow
1. Connect Wallet
The user connects an Ethereum wallet such as MetaMask, Rabby or OKX Wallet.
2. Generate Card Profile
The user enters a cardholder name and generates a Railcard profile. The interface displays a card number, expiry date and CVV as part of the card profile UI.
3. Hold $RAIL
The user buys and holds $RAIL. Their balance determines their share of holder rewards.
4. Track Rewards
The dashboard shows pending rewards, total claimed, reward share and card status.
5. Claim Rewards
The user can claim available holder rewards from the website.
6. Follow Card Infrastructure Progress
The user can view the Card Infrastructure Treasury and track future development progress.
Product Structure
Card Profile
The card profile is the user’s main identity inside the Railcard ecosystem. It connects the wallet, the card interface and the rewards dashboard.
Holder Rewards Pool
The Holder Rewards Pool receives 100% of buy fees and distributes them proportionally to $RAIL holders.
Card Infrastructure Treasury
The Card Infrastructure Treasury receives 100% of sell fees and is reserved for future card development.
Dashboard
The dashboard displays balances, rewards, claim history, treasury progress and card profile data.
Future Card Layer
The future card layer is the planned infrastructure for real Mastercard-linked card functionality through licensed partners.
Why the Model Works
Railcard Pay uses a simple split:
Sell side = infrastructure
This avoids confusing tokenomics. Many tokens send every fee into multiple small buckets. Railcard Pay keeps the model clear. When someone buys, holders are rewarded. When someone sells, the card gets funded.
This gives the project a simple public message:
Sell builds the card.
It also creates a natural reason to hold $RAIL: holders participate in the buy-side rewards pool. At the same time, sell-side activity contributes to future product development.
Roadmap
Phase 1 — Token and Interface
The first phase launches the core on-chain and product interface. Planned elements:
- $RAIL token launch;
- Uniswap v4 hook;
- ETH / RAIL pool;
- buy fee and sell fee logic;
- Holder Rewards Pool;
- Card Infrastructure Treasury;
- Railcard interface;
- card profile creation;
- dashboard;
- claim rewards module;
- basic docs and public roadmap.
Phase 2 — Rewards and Dashboard Expansion
The second phase improves the user dashboard and tracking systems. Planned elements:
- live rewards tracking;
- claim history;
- holder statistics;
- reward share calculation;
- treasury dashboard;
- public treasury address;
- card profile improvements;
- improved mobile UI;
- frontend wallet integration.
Phase 3 — Infrastructure Preparation
The third phase focuses on preparing for future real card integration. Planned elements:
- legal structure research;
- compliance planning;
- issuer partner research;
- BIN sponsor preparation;
- card program architecture;
- KYC/AML provider research;
- backend planning;
- risk and region availability review;
- security review.
Phase 4 — Partner Integration
The fourth phase focuses on external infrastructure partners. Planned elements:
- issuer discussions;
- payment processor discussions;
- compliance vendor integration planning;
- card backend development;
- user account systems;
- possible closed beta preparation;
- future virtual card activation design.
Phase 5 — Future Card Rollout
The final long-term phase is the future rollout of real card functionality. Possible future features:
- Mastercard-linked virtual card;
- crypto top-up;
- online spending;
- transaction history;
- spending limits;
- user verification;
- mobile wallet support if available;
- regional expansion.
The exact features and availability depend on partners, compliance and supported jurisdictions.
Website Positioning
Railcard Pay should be presented as a serious Web3 fintech product.
Suggested headline:
Suggested subheadline: Railcard Pay is a Web3 card platform built on Ethereum and powered by $RAIL, a Uniswap v4 hook token where buys reward holders and sells build future card infrastructure.
Suggested core phrase:
Twitter Bio
Building Mastercard-linked crypto card infrastructure on Ethereum. Powered by $RAIL — a Uniswap v4 hook token. Buy rewards holders. Sell builds the card.
Important Disclaimer
Railcard Pay’s first phase provides a card interface, $RAIL token utility, holder rewards and a pre-issuance card profile.
Real payment card functionality is planned for a future phase and may require licensed issuing partners, compliance verification, supported jurisdictions and additional infrastructure.
Railcard Pay should not claim that live Mastercard spending is available until the required card infrastructure and partnerships are active.
Core Summary
Railcard Pay connects a future card product with an on-chain token economy. $RAIL powers the ecosystem. The model is simple:
- buy fee: 2%;
- sell fee: 4%;
- buy fees go to holders;
- sell fees go to card infrastructure;
- rewards are proportional to $RAIL balance;
- no tiers;
- no multipliers;
- no complicated staking.
The card is the user interface. The token is the economic layer. The treasury is the infrastructure path. The future goal is real card rails.