supply
the token.
$REP is a fixed-supply ERC-20 on Ethereum, intended to trade against ETH in a Uniswap v4 pool. Every buy and every sell pays a fee in $REP, and the entire fee goes to holders — no treasury slice, no development cut, no burn. What the reputation score decides is how much of that fee you pay, and how large a share of it you take.
Section 1
Supply
One mint,
at birth
1,000,000,000 REP. Minted once, inside the constructor, in a single transaction that can never happen again. The contract has no mint function of any kind — not an owner-gated one, not a capped one. The number you see on the first block is the number forever.
$REP also carries ERC-20 Votes checkpoints on a timestamp clock, so balances can be snapshotted for governance later. Nothing on this page depends on that, and no governance exists today.
Section 2
Where the fee goes
One path,
no branches
The fee is charged only when the pool is on the other side of the transfer — that is, on a buy or a sell. Sending $REP to a friend costs nothing. The rate is read from the trading wallet, never from the pool, so a purchase routed through a normal router — one that delivers the tokens straight to you — is charged at your tier exactly as a direct one would be.
Your claim on the pool is your balance multiplied by your tier's weight.
Because the weight is recorded when you are last touched rather than
recalculated for everyone on every trade, crossing into a new tier does not
apply to new fees until your position is refreshed — which any trade, any
claim, or a sync on your own wallet does.
Section 3
The schedule
Constants,
not
settings
| Tier | Score | Fee on a trade | Reward weight | All-in cost |
|---|---|---|---|---|
| Unproven | < 0.30 | 3.00% | 1.00× | ≈ 3.30% |
| Known | 0.30 + | 2.25% | 1.25× | ≈ 2.55% |
| Trusted | 0.55 + | 1.50% | 1.50× | ≈ 1.80% |
| Core | 0.80 + | 1.00% | 2.00× | ≈ 1.30% |
All-in cost is the tier fee plus the pool's own 0.30% liquidity fee, added together — arithmetic on the two constants, not a measurement. Slippage and gas are not included.
Launch parameters
The remaining numbers are chosen once, at deployment, and are immutable afterwards — no owner function exists to change any of them. These are the values in the deployment script.
| Parameter | Value | Meaning |
|---|---|---|
| Age saturation | 7 days | Time in the system at which the age component maxes out. |
| Hold saturation | 7 days | Unbroken holding at which the hold component maxes out. |
| Volume saturation | 1,000,000 REP | Cumulative traded volume at which that component maxes out. |
| Decay grace | 30 days | Idle time before the score starts coming off. |
| Decay window | 30 days | Time from the start of decay to a score of zero. |
| Tier thresholds | 0.30 / 0.55 / 0.80 | Known, Trusted and Core, out of a maximum score of 1.00. |
Section 4
Why anyone would want it
Three
arguments,
no
promises
Nothing here predicts a price and nothing here is advice. These are the three reasons the design gives someone to hold rather than pass through.
1 — The distribution is a mechanic, not a pledge
The reward pool is not funded from a treasury that has to keep choosing to fund it. It is funded by the transfer function itself: every taxed trade deposits its fee into the pool in the same transaction. If there is trading, there is a distribution. If there is no trading, there is none, and the page will not pretend otherwise.
2 — The discount is worth most to whoever trades most
Two percentage points separate the floor from the top of the ladder. For a wallet that trades often, that difference compounds into a real reason to build standing on one address and keep it, instead of rotating through fresh ones — which is the behaviour the token is trying to buy.
3 — Standing cannot be sold, so leaving is expensive
A wallet's score is recomputed from its own history every time it is read. There is nothing to transfer, so there is no market in aged wallets and no way to buy your way past the queue. The only route to a Core-tier wallet is to have run one — and once you have, breaking the position throws away the 45% of the score that took the longest to build.
Section 5
Limits and dependencies
Read
this
part
| Item | Position |
|---|---|
| Deployment | Not deployed. No contract address, no pool, no liquidity, nothing to buy. |
| External audit | None. The contracts have been reviewed internally and carry a test suite, and that is not the same thing as an independent audit. No audit badge appears on this site because there is no audit. |
| Owner powers | The contract has an owner. It can exempt an address from fees, add or remove an address from the reward book, and open trading once. It cannot mint, cannot alter the fee schedule or the score weights or the saturation and decay constants — those are compile-time constants and constructor immutables — and there is no function anywhere that lets it withdraw rewards belonging to holders. |
| Decay | Real and unavoidable. Sixty days of silence returns any wallet to Unproven regardless of what it holds. If you want the yield, you have to keep showing up. |
| Custodial routing | The fee is read from the wallet the pool is trading against. Direct buys and normal router buys land on your own wallet and price at your tier. If you buy through a contract that takes custody first and forwards the tokens on afterwards, the fee is read at that contract's tier, not yours. |
| The score is a heuristic | It measures wallet behaviour, not people. One person can run several wallets. Every one of them still has to pay the same price in elapsed time, and money still does not shorten it. |
| Dependencies | Ethereum, and Uniswap v4 — the PoolManager, the PositionManager and Permit2. A failure or a migration in any of those affects trading in $REP. |
Section 6
Contract
Field
not yet
filled
Pool · — — — — — — — — — — — — — — — —
$REP has not been deployed. There is no contract address, no pool and no token in circulation. When there is, the address will be printed in this field and nowhere else on this site. Anything presenting itself as $REP today is not this.