Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lfg.rich/llms.txt

Use this file to discover all available pages before exploring further.

LFG.RICH V5 uses an on-chain referral contract to bind wallets into referral trees. This referral state is used by the protocol to decide where the referral portions of trading fees and borrowing fees are sent. Referral binding is optional for normal protocol use. A wallet can create tokens, buy, sell, borrow, repay, and use the app without binding to an inviter. Binding is only required if the wallet wants to join a referral tree and make its activity eligible for referral reward routing.
Referral binding is permanent. Once a wallet is bound to an inviter, it cannot unbind, change inviter, or move to another referral tree.

Core idea

The referral system has two different reward paths:
ActivityReward ratePaid toWhy
Buy / Sell1.00% of the trade amountThe trader’s initial inviterTrading rewards go to the whitelisted root of the referral branch.
Borrow / Borrow more2.00% of the borrowed valueThe borrower’s direct parentBorrow rewards go to the address that directly invited the borrower.
This distinction is important. The initial inviter and the parent can be the same address in a direct invite, but they can be different addresses in a deeper referral tree.

Fee split summary

Trading fees

Every V5 buy and sell has a total trading fee of 1.25% of the trade amount.
Trader statePlatformInitial inviterTotal trading fee
Bound user0.25%1.00%1.25%
Unbound user1.25%0.00%1.25%
When the trader is bound, the 1.00% inviter reward goes to the trader’s initial inviter. When the trader is not bound, there is no inviter to reward, so the full 1.25% goes to the platform side.

Borrow fees

Every V5 borrow and borrow-more action has a total borrow fee of 3.00% of the borrowed value.
Borrower statePlatformDirect parentTotal borrow fee
Bound user with parent1.00%2.00%3.00%
Unbound user / no parent3.00%0.00%3.00%
The 2.00% parent reward is part of the total 3.00% borrow fee. It is 2.00% of the borrowed value, not 2.00% of the 3.00% fee.

Referral roles

RoleMeaning
Whitelisted addressA root address approved by the platform owner. Whitelisted addresses act as root nodes in the referral system.
ParentThe address that directly invited a user. This is one level above the user.
Initial inviterThe first whitelisted address at the top of the user’s referral branch. This is the root that receives the 1.00% trading reward.
Bound userA wallet that has already called bind(inviter) successfully.
Unbound userA wallet that has not joined any referral tree.

Whitelisted addresses

Whitelisted addresses are very important because they start the referral trees. When the platform owner whitelists an address:
  1. that address becomes an approved referral root;
  2. that address is treated as already bound by the referral system;
  3. that address becomes its own initial inviter;
  4. users can bind directly to that address;
  5. non-whitelisted users below it inherit that same initial inviter.
A normal wallet cannot become the root of a new referral tree by itself. A normal wallet can invite others only after it is already bound under an existing whitelisted root.

Binding rules

RuleExplanation
Binding is one-timeA wallet cannot bind twice.
Binding is permanentThe inviter cannot be changed later.
Inviter must be eligibleThe inviter must already be bound or whitelisted.
Self-binding is not allowedA user cannot bind to their own referral code or wallet.
One parentEach bound user has exactly one direct parent.
One initial inviterEach bound user has exactly one initial inviter inherited from the tree root.
Whitelist is owner-controlledOnly the referral contract owner can add or remove whitelisted root addresses.
The app normally applies referral codes instead of asking users to paste raw wallet addresses. The frontend resolves the referral code to an inviter wallet, checks that the inviter is eligible, and then calls the on-chain bind(inviter) function.

How the chain is assigned

When user A binds to inviter B:
A.parent = B
Then the initial inviter is assigned like this:
if B is whitelisted:
    A.initialInviter = B
else:
    A.initialInviter = B.initialInviter
That means the initial inviter remains the whitelisted root of the branch, even if the tree becomes many levels deep.

Direct invite example

Setup:
W1 is whitelisted
Alice binds to W1
Tree:
W1 (whitelisted root)
 └── Alice
Alice’s referral state:
FieldValue
parentW1
initialInviterW1
If Alice buys 1 BNB of tokens:
Fee partAmountRecipient
Platform fee0.0025 BNBPlatform
Inviter reward0.0100 BNBW1
Net to bonding curve0.9875 BNBToken pool accounting
If Alice borrows 1 BNB of value:
Fee partAmountRecipient
Platform fee0.0100 BNBPlatform
Parent reward0.0200 BNBW1
Net to Alice0.9700 BNBAlice
In a direct invite, the parent and the initial inviter are the same address, so the same wallet receives both kinds of reward.

Two-level example

Setup:
W1 is whitelisted
Alice binds to W1
Bob binds to Alice
Tree:
W1 (whitelisted root)
 └── Alice (parent = W1, initialInviter = W1)
      └── Bob (parent = Alice, initialInviter = W1)
Bob’s referral state:
FieldValue
parentAlice
initialInviterW1
If Bob buys or sells, the 1.00% trading reward goes to W1, because W1 is Bob’s initial inviter. If Bob borrows or borrows more, the 2.00% borrow reward goes to Alice, because Alice is Bob’s direct parent.
This is the key V5 rule: trading rewards follow the initial inviter, while borrow rewards follow the direct parent.

Deep-chain example

Setup:
W1 is whitelisted
Alice binds to W1
Bob binds to Alice
Charlie binds to Bob
Diana binds to Charlie
Tree:
W1 (whitelisted root)
 └── Alice (parent = W1, initialInviter = W1)
      └── Bob (parent = Alice, initialInviter = W1)
           └── Charlie (parent = Bob, initialInviter = W1)
                └── Diana (parent = Charlie, initialInviter = W1)
Diana’s trading activity:
ActivityRewardRecipientReason
Buy1.00% of trade amountW1W1 is Diana’s initial inviter.
Sell1.00% of trade amountW1W1 is Diana’s initial inviter.
Diana’s borrowing activity:
ActivityRewardRecipientReason
Borrow2.00% of borrowed valueCharlieCharlie is Diana’s direct parent.
Borrow more2.00% of additional borrowed valueCharlieCharlie is Diana’s direct parent.

Multiple whitelisted roots

Different whitelisted addresses create independent referral trees.
W1 (whitelisted root)             W2 (whitelisted root)
 └── Alice                         └── Bob
      └── Charlie                       └── Diana
UserParentInitial inviter
AliceW1W1
CharlieAliceW1
BobW2W2
DianaBobW2
If Charlie trades, the 1.00% trading reward goes to W1. If Diana trades, the 1.00% trading reward goes to W2. Referral trees do not merge. Once a user is bound under one whitelisted root, that user’s branch remains under that root permanently.

Unbound-user example

If Eve never binds to an inviter, she is unbound. If Eve buys 1 BNB of tokens:
Fee partAmountRecipient
Platform fee0.0125 BNBPlatform
Inviter reward0.0000 BNBNobody
Net to bonding curve0.9875 BNBToken pool accounting
If Eve borrows 1 BNB of value:
Fee partAmountRecipient
Platform fee0.0300 BNBPlatform
Parent reward0.0000 BNBNobody
Net to Eve0.9700 BNBEve
The user can still use the protocol. The difference is only fee routing: without a valid referral binding, there is no initial inviter or parent to receive rewards.

Reward routing table

User activityBound user: platformBound user: referral recipientUnbound user: platformUnbound user: referral recipient
Buy0.25%1.00% to initial inviter1.25%none
Sell0.25%1.00% to initial inviter1.25%none
Borrow1.00%2.00% to direct parent3.00%none
Borrow more1.00%2.00% to direct parent3.00%none

Contract functions

The referral contract exposes the referral state used by the app, integrations, and protocol fee routing:
function isWhitelist(address user) view returns (bool);
function initialInviter(address user) view returns (address);
function parent(address user) view returns (address);
function inviteCount(address user) view returns (uint256);
function isBound(address user) view returns (bool);
function bind(address inviter);
function getInfo(address user)
    view
    returns (
        address _initialInviter,
        address _parent,
        uint256 _inviteCount,
        bool _isBound
    );
Useful checks before showing or applying a referral binding:
isBound(user)       -> whether the user already joined a referral tree
parent(user)        -> direct inviter
initialInviter(user)-> whitelisted root used for trade rewards
isWhitelist(user)   -> whether the address is an approved root
getInfo(user)       -> all common referral fields in one call

Frontend referral-code flow

The site uses referral codes and referral links for user experience, but the on-chain binding is still wallet based.
1. User opens a referral link or pastes a referral code.
2. The frontend extracts the referral code.
3. The API resolves the code to an inviter wallet.
4. The frontend checks that the inviter is eligible.
5. The user confirms the binding.
6. The frontend calls referral.bind(inviterAddress).
7. The backend mirror records the binding transaction for dashboard/indexing purposes.
The referral code is only a convenient way to find the inviter wallet. The permanent source of truth is the on-chain referral contract.

Important integration notes

  • Always check whether the user is already bound before showing an apply-referral action.
  • Always check whether the inviter is bound or whitelisted before attempting to bind.
  • Do not offer users a way to change their inviter after binding.
  • Do not calculate referral rewards from frontend assumptions only. Read the referral contract and protocol fee data.
  • Do not confuse the 1.00% trading reward with the 2.00% borrow reward. They use different recipients.