适用于 V2（当前测试网版本）
Applies to V2, the current testnet version.
Referral program
A valid referral code is attached to a project at creation. Its rewards come from that project's later protocol-fee referral reserve, not token transfer taxes. The current referral page obtains an activation attestation through X follow verification, then uses wallet confirmations for activation and payout-wallet binding.
| Eligibility | Earned share of referral reserve | Share of total protocol fees, before rounding |
|---|---|---|
| Valid activated code, base tier | 40% | 4% |
| Bound payout wallet has launched through the Registry's corresponding Factory | 70% | 7% |
| A project issued by that wallet has canonically graduated in that release | 100% | 10% |
Code-to-payout-wallet binding is permanent: each code has one payout wallet and each wallet one code. A valid code may be activated before a wallet is bound, but cannot pay claims without a payout wallet. Binding can reflect the wallet's already recorded launch/graduation status. Check wallet control before binding.
A payout wallet matching the referred project's creator earns zero referral allocation. Unearned referral reserve goes to the community. Each fee event fixes its earned allocation; later upgrades do not reprice history.
Releases have separate Registries. Only the corresponding Factory's authenticated callbacks record launch and graduation eligibility. History in another version or Factory is not automatically imported. A referral link's refRelease can constrain available tax purposes. Removing referral attribution requires explicit confirmation before creation.
Use the referral page to inspect each release and its claimable credit. At contract level, the bound payout wallet calls the corresponding Ledger's claim(token, 1) and receives payment itself. X login, follow verification or attestation service outages can block new activation without erasing existing on-chain credit.
Sources：S06、S09、S19、S28、S29、S41。 Evidence report