Referrals
Referrers earn a share of the platform fee on every trade they bring in, claimable as ETH at any time.
When someone trades with your referral attached, a share of the platform fee accrues to you as ETH inside ReferralManager. You claim it whenever you like. Nothing vests, nothing expires, and there is no minimum.
#The economics
MAX_REFERRAL_BPS), enforced in bytecodeConcretely: 10 ETH of volume routed through your link earns you 0.01 ETH. It is a volume-scaled stream, not a bounty — which is why it accrues per trade rather than per signup.
#Claiming
mapping(address => uint256) public pending; // claimable now
mapping(address => uint256) public lifetimeEarned; // lifetime, for analytics
mapping(address => address) public referrerOf; // first-touch attribution
function claim(address to) external returns (uint256 amount);claim(to) pays out everything pending for msg.sender to the address you name. It zeroes the balance before sending (checks-effects-interactions) and is reentrancy-guarded. There is no admin claim, no clawback, and no expiry on an unclaimed balance.
ref. That address must be the msg.sender of the claim — you can direct the payout anywhere with to, but you cannot claim someone else’s balance.#How attribution works
The ref address is supplied by the caller of the trade, and the contract trusts it. That is a deliberate design decision, and it is worth being blunt about what it does and does not guarantee:
- Payout follows the
refon the trade. Whoever is named on a transaction is paid for that transaction. Full stop. referrerOfis analytics, not authority. It records the first referrer ever seen for a trader and never overrides who gets paid on a later trade. Read it for display; do not build accounting on it.- The rules live off-chain. One-referrer-per-user, no self-referral, campaign eligibility — the app enforces those when it vends the
refvalue. Encoding them on-chain would have meant a trade manager redeploy every time a rule changed. - Multi-level trees are reconstructed off-chain from the events below. The contract pays exactly one level.
#Events
event ReferralAttributed(address indexed trader, address indexed referrer);
event ReferralFeeAccrued(address indexed referrer, address indexed trader,
address indexed token, uint256 amount);
event ReferralClaimed(address indexed referrer, address indexed to, uint256 amount);The subgraph indexes all three into Referrer, Referral, ReferralEarning and ReferralClaim entities, which is where the in-app referral dashboard gets its numbers.
#Custody
Every wei of ETH in the contract is owed to a referrer, so there is deliberately no ETH rescue path — not for the owner, not for anyone. The owner can authorise or de-authorise trade managers (that is how a manager upgrade keeps the same referral balances) and recover stray ERC-20s, which are always accidents. It cannot touch pending.
The manager instance is shared across every generation of the trade manager, so a referral balance earned under an older terminal is still claimable today at the same address.
