GongFu 功夫

Version 1.0 - Mainnet edition

Take enough. Strengthen the system that supports everyone.

#About this document

This whitepaper describes the rules of the first GongFu mainnet version: the reserve, participant rights, constraints, price sources, reward logic, WindDown, and the principal risks.

The document explains the system but does not replace verification of the deployed contract. Before interacting, a user verifies the official GF address, the GongFu address, source code, bytecode, and immutable parameters through the public deployment manifest and Robinhood Chain block explorer.

GongFu is not a bank deposit, investment agreement, or promise of return. The GF price, market liquidity, actual reward, and duration of the reward phase cannot be known in advance.

Protocol priority:

Security > Sustainability > Simplicity > Features.

#1. GongFu in two minutes

GongFu is an immutable Solidity smart contract on Robinhood Chain. It holds a shared GF reserve and accepts time-bound participant positions under the same rules for everyone.

A user does not transfer GF to a team or management company. GF goes directly to the smart contract. The contract has no private key, owner, administrator, or hidden withdrawal function. GF can leave the reserve only through the public rules encoded in deployed bytecode.

A participant chooses a term, transfers GF to the contract, and waits until maturity. On 90 and 180 days the reward arrives in monthly parts, while the principal comes back at the end of the term. Principal remains an exact protocol liability to the Position owner. A reward is neither created from nothing nor minted: it may be allocated only from the free portion of the existing reserve.

The central GongFu protection is WindDown. If free reserve is insufficient to continue the reward phase, the contract irreversibly stops new Positions and new rewards. Each participant's principal remains available to its owner through a manual claim. GongFu does not turn one participant's principal into another participant's reward and does not create a last-user-loss merely because that user arrived later.

WindDown is not an emergency button controlled by the developer. It is a predefined, honest end state of the reward phase that nobody can cancel or alter.

#2. Why the protocol exists

Many reward protocols depend on one or more of the following:

• continuous issuance of new tokens;
• endless inflow of new participants;
• external yield that may disappear;
• discretionary reserve management.

GongFu starts from the opposite premise. The reserve is finite. The contract therefore does not promise an endless reward, conceal liabilities, or leave the shortage outcome undefined.

The economic question behind GongFu is:

Can a shared reserve operate for a long time when principal is protected, larger personal limits must be earned through time, and the rules cannot be changed in favor of the creator?

GongFu does not claim to prove the answer through marketing. The protocol publishes its rules, code, deployment manifest, and research laboratory. A good simulation result is not a guarantee of a future result.

#3. Core concepts

The interface uses plain names. Technical terms remain visible so cabinet actions can be matched to contract functions.

#4. Network, token, and launch

#4.1 Robinhood Chain

GongFu runs on Robinhood Chain, an EVM-compatible Ethereum L2 built on Arbitrum. The mainnet chain ID is 4663, and the native gas asset is ETH.

The actual transaction payer pays all network gas. GongFu does not reimburse ETH or deduct fees from principal, reward, contribution, referral balances, or the reserve. Voluntary third-party gas sponsorship may exist, but it is not a protocol obligation.

#4.2 GF token

GF is created on the Pons (V2) launchpad on Robinhood Chain as one canonical fixed-supply ERC-20:

1 000 000 000 GF

Canonical GF has no:

• post-launch mint;
• pause, freeze, or blacklist;
• fee-on-transfer;
• rebase;
• hooks or callbacks;
• upgrade;
• second canonical token representation.

Technically, GF is a standard Pons token: a small immutable ERC-20 with no owner. The whole supply is minted once at creation and goes straight onto the Pons launch curve (section 4.5). The token only has transfers, allowances (approve) and burning of the holder's own GF (burn); there is no mint, pause, code change, or change to anyone else's balance. Burning can only reduce supply, never increase it.

GongFu accepts only the GF pinned in the contract. Token address, decimals, total supply, and runtime code are verified before protocol activation.

#4.3 Permanent initial reserve

Before activation, at least the following amount is transferred to GongFu:

500 000 000 GF

This is half of the total supply. Pons gives the creator no separate allocation: every token is sold from the curve. So the reserve is bought. The launch service address buys 500 000 000 GF in the same transaction that creates the token (launchAndBuy), before anyone else can buy. With Pons parameters at the time of writing this costs about 3 269 USDG, including the 1% curve fee.

Right after that, the launch service address deploys the GongFu contract and transfers all 500 000 000 GF into it (fundPermanentSupport); any amount bought above 500 000 000 GF also goes to the reserve. A few minutes pass between the purchase and the transfer. This is the only moment when the reserve depends on a private key: if the key were compromised at exactly that time, the reserve might not reach the contract. All launch transactions are published in the deployment manifest, so anyone can check that the purchased GF were transferred to GongFu in full. The contract cannot activate without the full reserve (section 4.4).

After launch, the 1 000 000 000 GF supply is distributed as follows:

Pons sets aside the last two parts itself and does not sell them on the curve; the team receives nothing from them.

This GF forms the initial cushion of the shared reserve. After transfer, it:

• is not the developer's treasury;
• gives the creator no right of return;
• cannot be withdrawn through a separate owner or admin function;
• can leave only through immutable claim and settlement rules.

The token origin is disclosed publicly but creates no special creator right inside GongFu.

#4.4 Activation

Mainnet publication and activation occur only after joint verification of:

• one canonical GF;
• an actual reserve of at least 500 million GF;
• the canonical market and quote asset;
• sufficient liquidity and acceptable manipulation cost;
• one valid pinned Uniswap V4 GF/USDG spot route;
• immutable constructor parameters and the deployment manifest.

At the on-chain state level, transition into Active is permissionless: any address may call it, but only after the contract observes the exact initial reserve and the single valid route. The canonical market, its liquidity, and manipulation cost are disclosed and checked separately in the mainnet deployment manifest. GongFu has no privileged activation function with weaker conditions.

Activation is possible only after GF graduates from the Pons curve to the Uniswap V4 pool (section 4.5). Until the curve sells out there is no pool, the price route sees no market, and Active cannot be reached. After graduation anyone can activate the contract; the first generation is activated manually, without a bot.

Activation also sets the starting reference price (section 14). It equals the route's minimum valid price, which is the activation gate, not the spot price at activation. So pushing the price up to activate early cannot be turned into an immediate gain from that pushed price.

#4.5 Launch market

The GF market goes through two phases.

The Pons curve. After creation the token trades on the Pons curve in the GF/USDG pair. It is a constant-product curve with a virtual ("phantom") reserve of 3 236 USDG; it holds no real USDG at the start, and the price rises only through purchases. Curve parameters at the time of writing:

• the launch service address's first purchase (500 000 000 GF) moves the price from about 3.2 to 12.9 µUSD per GF — the open market starts from that price;
• the curve closes once it has received 8 090 USDG; the market buys the remaining ≈214 million GF for about 4 900 USDG, and the closing price is ≈39.6 µUSD (FDV ≈ $39 600);
• every curve trade pays a 1% fee;
• in the first seconds after creation Pons applies a higher anti-sniper tax; the launch service address's purchase in the creation transaction is not subject to it;
• there is no per-address balance limit.

While the curve is open, the GongFu price route sees no market and activation is impossible (section 4.4).

The Uniswap V4 pool. Once the curve sells out, anyone can trigger graduation (createGraduatedPool). Pons creates a Uniswap V4 GF/USDG pool (pool fee 0, tickSpacing 200, Pons hook) at the curve's closing price and places the collected 8 090 USDG and ≈204 million GF in it. This is the pool from which GongFu reads its price (section 14):

• pool liquidity is locked forever and cannot be withdrawn by the team or by Pons;
• there is no further migration: the pool remains GF's main market;
• an outsider cannot initialize the pool before the curve closes — the Pons hook rejects such an attempt.

The launch kit checks the exact curve and pool parameters before sending the first transaction, and they are published in the deployment manifest; if Pons changes them before launch, the launch stops without sending anything.

#5. What the smart contract stores

#5.1 Protocol state

The contract stores:

• Bootstrap, Active, or WindDown mode;
• total principal liability;
• total settled reward liability;
• total personal referral liability;
• open Position count;
• the reward-settlement epoch queue;
• the timestamp of irreversible WindDown entry.

#5.2 Participant state

Only necessary information is stored for each address:

• whether the participant is registered;
• the longest unlocked term;
• successful Continue history;
• active USD-notional for each term and in aggregate;
• accumulated referral balance;
• cumulative donation notional;
• number of Positions whose principal has been claimed while Exit or Continue remains unresolved;
• whether Exit has permanently closed the address to new Positions.

A participant record is permanent. It is not closed or confiscated because referral rights may be credited to it later.

#5.3 Position

Each Position has a unique sequence within its owner address and stores:

• owner;
• principal in minimum GF units;
• selected term;
• opening timestamp and exact maturity;
• accepted GF/USD snapshot;
• entry USD-notional;
• maximum reward;
• stored referrers;
• principal, owner-reward, and referral-component state;
• pending-owner-choice flag;
• finalization flag.

An existing Position is not repriced after the market changes.

#6. Reserve accounting

The entire contract balance cannot be treated as free reserve. GongFu separates protected liabilities from available surplus.

protected liabilities = principal liability
                      + settled epoch liability
                      + personal referral liability

available surplus = contract GF balance - protected liabilities

The primary invariant is:

contract GF balance >= protected liabilities

Principal is never free reserve. An unsettled maximum reward is tracked as a future risk but does not become protected debt until its epoch is settled.

All production calculations use checked integer arithmetic. The contract does not use floating point. Rounding direction is fixed in advance and cannot vary from one user to another.

A lost key does not transfer GF to the community. An unclaimed amount remains a protected liability with no expiry.

#7. Terms, access, and maximum reward

GongFu supports exactly five terms:

These are maximums, not promised returns. Actual reward may be lower and is determined only after settlement from genuinely available surplus.

For 90 and 180 days the maximum reward arrives in equal monthly parts: 3 parts of 1/3 for 90 days and 6 parts of 1/6 for 180 days (section 9.3). Rates and limits do not change, and principal stays locked until the end of the term.

A new address starts at the SevenDays history tier with 20% earned-history capacity. The 1-day Position remains optional under its own 10% duration limit and 0.16% maximum reward, but a successful 1-day Continue does not advance history. A successful Continue of the current 7-day maximum unlocks the next step:

7D -> Continue -> 30D -> Continue -> 90D -> Continue -> 180D

Term completion alone does not unlock the next level. One successful Continue of a 180-day Position unlocks 100% of the history-earned limit.

Above the starting 20%, the history-earned limit is also bounded by the size of the history itself. It cannot exceed four times the value, at the current price, of the principal of the Position whose completion unlocked the current level. Once a participant is at the full level, the largest such Position counts. The measure is in GF, so a price rise never stops anyone from continuing the same amount of GF. A history built from tiny Positions unlocks longer terms but not a larger limit: such an address stays at the starting 20%, like a new one.

Position count is not independently capped. Aggregate active USD value is capped, so splitting one amount across many transactions creates no extra capacity.

#8. Personal MaxCap

MaxCap limits the active dollar value of Positions held by one address. It is an anti-whale and sustainability mechanism, not a recommended Position size.

The market base is calculated from the accepted GF/USD price and fixed supply:

GF FDV = GF/USD price * 1 000 000 000 GF
m = GF FDV / 1 000 000 USD

TotalCapUSD = max(
  500,
  100 000 * m^0.746 / (m^0.746 + 39)
)

Base Total MaxCap starts at $500 and smoothly approaches $100,000. Growth is sublinear: increasing FDV does not create an unlimited personal cap.

For a new Open or Continue, the single price route must first be available; the contract then uses the minimum applicable ceiling:

available capacity = min(
  remaining Total MaxCap,
  remaining duration ceiling,
  remaining earned-history ceiling
)

A donation boost can raise capacity only for 30-, 90-, and 180-day Positions. It does not bypass term, history, or occupied-capacity constraints.

A Position occupies MaxCap until its principal is claimed by the owner. Maturity, settlement, and time alone never release capacity. Stored notional is removed exactly once, only in the same successful transaction that returns principal. A failed claim or Continue releases nothing.

For MaxCap a Position is valued at the higher of two prices, spot and reference (section 14), and Total MaxCap uses the same price. Pushing the price down inside one's own transaction to fit more GF therefore does not work.

Existing Positions are not repriced. If the current route is unavailable, new price-dependent capacity is unavailable; existing Positions remain unchanged.

V1 has no separate global cap on total unclaimed principal and no separate concentration cap for a six-hour epoch. Exact principal coverage and personal MaxCap remain mandatory.

#9. Position lifecycle

#9.1 Registration

A participant registers an address once. If the eligible-referrer queue is empty, registration succeeds without a referrer and the referral components of that relationship are zero.

When eligible participants exist, automatic assignment uses deterministic, bounded O(1) round-robin. The caller cannot choose a more favorable referrer. Only a participant with at least one personally invited user holding an active Position worth at least $50 enters the queue. The value is measured at that Position's lock price. Positions under $50 work normally but do not put the inviter in the queue, which makes filling the queue with thousands of empty wallets expensive. An automatically assigned relationship does not count as a personal invitation.

#9.2 Opening a Position

The participant chooses an amount and one available term. In one transaction, the contract:

1. verifies Active mode;
2. verifies registration, term access, and absence of an unresolved owner choice;
3. obtains the canonical GF/USD spot price and the reference price;
4. calculates MaxCap and exact USD-notional at the higher of the two, and records the Position's lock price at the lower;
5. receives the exact GF amount;
6. creates the Position and binds it to a maturity epoch;
7. increases principal liability and active notional by matching verified values.

The user does not supply the price, price route, reward rate, referrer, or a precomputed MaxCap. Those values are derived from immutable state.

#9.3 Active term

Early withdrawal is disabled before maturity. The only exception begins after irreversible WindDown, when principal becomes available regardless of remaining term.

Reward is not transferred daily, does not auto-compound, and does not grow after maturity.

Monthly parts for 90 and 180 days. The maximum reward of a 90-day Position is split into 3 equal parts, of a 180-day Position into 6. Every part except the last is tied to the maturity epoch of its month: the epoch that contains "opening + 30 days", "+ 60 days" and so on. The last part settles in the Position's own maturity epoch.

• A part settles together with every Position in its epoch and gets the same proportional payout scale (section 9.4). Nothing is reserved for it in advance.
• Once settled, the owner claims the part at any time (claimMonthlyReward). If the epoch has matured but is not settled yet, the same transaction settles it first.
• The 7/3/2% referral shares are taken from each part separately when it is paid. Anyone may move them to the referrers earlier (rollupMonthlyReferrals) without waiting for the owner.
• Principal stays locked until the end of the term. The principal-first claim, Exit and Continue work as before and cover the principal and the last part.
• The division remainder (fractions of the smallest GF unit) goes to the last part, so the parts always add up to exactly the maximum reward.

1-, 7- and 30-day Positions do not change: their whole reward settles in their maturity epoch.

#9.4 Reward settlement

Positions are grouped into global six-hour maturity epochs only for reward settlement. Each Position keeps its exact maturity; it is not delayed until the end of the epoch.

Epochs are settled strictly from oldest to newest, one epoch per step, so the contract never traverses an unbounded list of users. No separate operator is needed: every new deposit, every Continue and every exit with reward first settles mature epochs itself (up to 32 per transaction; an exit only up to its own epoch) and then performs its own action. After WindDown, a participant's claim itself cancels the epochs queued ahead of their own. If the system has gone unused for a long time, anyone can settle the accumulated epochs in one call (settleMatureHeads), or cancel them the same way after WindDown (cancelWindDownHeads). If such a settlement itself starts WindDown, or more mature epochs are waiting than one transaction settles, the settlement is kept and the action ends without executing and without moving funds: a deposit or Continue is simply repeated. After WindDown, an exit pays out directly under the WindDown rules. If more than 256 epochs stand ahead of a participant's own, a WindDown claim keeps the cancellations it made and also asks to be repeated. If the price is unavailable after a deposit has already settled mature epochs, the settlement is kept and the deposit ends without executing.

A monthly part of a 90- or 180-day Position is one more entry in the epoch of its month. For settlement it is no different from a Position maturing there.

A Position's maximum reward is not reserved when it opens. The reward is only determined when its epoch settles, from the surplus free at that moment. Epochs settle in maturity order, not in opening order. A long Position can therefore wait behind later short ones that mature earlier and are paid from the same reserve first.

All Positions in one epoch receive a common proportional payout scale. If their aggregate maximum reward is 100,000 GF while only 60,000 GF is available, each Position receives 60% of its maximum. Claim order gives no advantage to the first user.

#9.5 Principal-first claim

Immediately after exact maturity, the owner may claim principal even if the reward epoch has not yet settled. That transaction:

• returns exactly the principal;
• releases the Position notional exactly once;
• pays no reward;
• withholds no contribution;
• preserves future owner and referral rights;
• does not choose Exit or Continue on behalf of the user.

Until the later choice is resolved, the address cannot open an unrelated new Position. After settlement, the owner completes that exact Position through Exit or Continue. If WindDown begins first, a terminal claim applies and continuation is unavailable.

#10. Two choices after settlement

#10.1 Exit - take everything

Exit returns:

• all principal not already claimed;
• the entire actual settled owner reward (for 90 and 180 days, of the last part; monthly parts are claimed separately and do not need Exit);
• with no contribution.

If principal was already received through a principal-first claim, Exit pays only the settled reward and does not release MaxCap a second time.

After Exit, the address is permanently closed to new Open and Continue actions. Other existing Positions remain claimable. Funds are not confiscated. A new address starts again at the 7-day history tier; the optional 1-day Position does not advance history.

#10.2 Continue - keep participating

Continue completes the old Position and creates a new one in a single atomic transaction. The contract:

1. determines unclaimed principal and settled owner reward (for 90 and 180 days, of the last part);
2. calculates current MaxCap and available term;
3. determines the actual new Position amount;
4. calculates contribution from the old Position's settled owner reward (for 90 and 180 days, from the last part only);
5. moves referral rights into personal referrer balances;
6. creates the new Position;
7. pays the remainder to the owner.

If the former GF amount no longer fits within current dollar-denominated MaxCap, the contract places only the allowed amount and returns the remainder. There is no minimum Continue amount. If no new Position is created, contribution is zero.

If principal was already claimed, GF for the new Position must actually arrive from the owner. Old principal cannot be reused virtually a second time.

Contribution depends on gross value multiple. The contract compares the value of principal at the recorded lock price with the value of principal + settled owner reward at the higher of spot and reference price at Continue. Pushing the price down inside one's own transaction to reach a lower rate therefore does not work:

Contribution applies only to Continue and only to earned reward: the rate is taken from the old Position's full settled owner reward, even if fewer GF go into the new Position. For 90 and 180 days this is the reward of the last part: monthly parts already received are never touched, and the multiple is also measured with the last part. Principal is never withheld at any multiple.

#11. WindDown: principal does not remain trapped

WindDown is an irreversible state that protects owner rights when free reserve can no longer support new rewards.

When settling the oldest maturity epoch, the contract first preserves coverage of principal and all previously settled rights. If free reserve cannot cover the full maximum of the new epoch, available surplus is distributed proportionally and GongFu enters WindDown.

After WindDown:

new Open = disabled
Continue = disabled
new rewards = disabled
contribution = disabled
all principal = owner pull-claimable

Every Position's principal becomes available to its owner whether or not the original term has ended. Existing settled rewards remain protected liabilities. This includes monthly parts of 90- and 180-day Positions: a part whose epoch settled before WindDown (including the epoch that started it) can be claimed at any time, while parts in unsettled epochs are cancelled with those epochs. An epoch that was not settled receives a final no-reward state, while the principal of its Positions remains intact.

The contract performs no mass distribution. Each owner manually claims their Position. This creates no race in which the first user takes the last user's principal: all principal is already accounted for separately from surplus.

WindDown cannot be cancelled by a donation, creator, price route, interface, or any later transaction. It does not change old rules or create a privileged exit.

Under GongFu rules, principal is not used for rewards, contribution, or donations and always retains an owner-authorized claim route. Like any on-chain mechanism, transaction execution still depends on network availability, key custody, and the absence of unknown code defects.

WindDown ends the reward phase of this generation of GongFu, not the experiment as a whole. What happens next is described in section 19, "Generations".

#12. Referral system

V1 uses no more than three referral levels:

The total referral share never exceeds 12% and is never calculated from principal.

During Exit or Continue, every remaining referral component of the Position receives a final state. Positive amounts move from maturity-epoch liability to the cumulative personal balances of stored referrers. GF does not leave the contract, no referrer signature is needed, and total protected liabilities do not change.

Any address may move the referral rights of a settled Position without waiting for its owner, both in Active and after WindDown. A referrer therefore does not depend on whether the invited participant ever returns for their own payout. The owner's payout is unaffected.

A referrer later claims the entire accumulated balance in one manual transaction. The balance has no expiry, cannot be confiscated or converted into a donation, and does not depend on the referrer's continued participation.

A lost key leaves the referral balance protected but does not keep the original Position open after the right has been correctly transferred.

In the next generation, invitation links are kept (section 19.8).

#13. Donations and fee buyback

#13.1 Donation

A donation is irreversible reserve support. It creates no principal, reward, referral right, governance right, or right to receive GF back.

The contract accepts any positive GF amount. A donation increases surplus and does not increase the reward rate.

For 30-, 90-, and 180-day Positions, donation history may provide a limited additional MaxCap boost:

D = cumulative donated USD notional

donationBoostUSD = 15 000 * D / (D + 250 000)

At $250,000 cumulative donation-notional, the boost is $7,500. At $1,000,000 it is $12,000. The theoretical ceiling is $15,000, so the maximum aggregate base is $115,000 before other constraints are applied.

Capacity boost is a secondary benefit, not the purpose of a donation. Every positive amount is accepted even when rounding produces zero new USD credit. When price is unavailable, a donation is still accepted but may give zero new capacity credit.

The USD credit of a donation uses the lower of spot and reference price, so a price pushed up inside one transaction does not raise the boost.

After WindDown donations are refused: no new Position can use them, and the GF would simply be locked forever.

#13.2 Reserve buyback from creator fees

Pons pays the token creator a share of GF trading fees (section 4.5). Pons sets the size of that share; it accrues in USDG and is held in the Pons fee escrow until the recipient claims it. The recipient of GF's creator share is not the team but a separate immutable contract, GongFuFeeCollector (the fee collector). It is deployed before the token is created and named as the recipient in the creation transaction, so it receives fees from the first trade.

The collector has no owner and no function that pays USDG out to anyone. It can only:

• claim accumulated USDG from the Pons escrow (claimFees);
• while the generation is Active, buy GF with that USDG in the Uniswap V4 pool and transfer the purchase straight into the GongFu contract (buybackToReserve). The trade goes through only if it buys no less than the reference price (section 14) implies, minus 3% for slippage; otherwise it reverts. The caller chooses the size of each buyback, so a large amount can be split into parts;
• move into the reserve any GF that end up on the collector (sweepGfToReserve);
• after WindDown, forward USDG to the next generation's Bridge (section 19.7).

Anyone can call every function. Only the current recipient can change the fee recipient in Pons, and the collector has no such function.

Fees accrued before activation accumulate on the collector in USDG and are used for buybacks after activation. The reference price starts at the activation gate and catches up with the market by at most 25% per hour, so early buybacks may revert until it approaches spot; anyone can move it along with observeReferencePrice.

A buyback is a direct GF transfer, not a donation call. It increases surplus just like a donation, but creates no donation history and gives no one a capacity boost. Its volume depends on trading activity and is not a guaranteed source of solvency: neither principal nor claims depend on it.

Pons keeps a takeover path: the owner of the Pons protocol can itself assign a different creator-fee recipient (according to Pons documentation, with a 3-day delay). This is a trust boundary outside GongFu's control (section 18.10). A takeover would only deprive the reserve of future buybacks; it would not touch the reserve, principal, or claims.

Fees on other markets, exchanges or launchpads outside the Pons curve and pool exist outside the GongFu core and are not treated as a source of solvency.

#14. Price source and market value

The GF/USD price is required for MaxCap and for calculating value multiple at Continue. It does not determine principal and is not required for protected claims. V1 uses one immutable Uniswap V4 GF/USDG spot-price route bound to the pinned PoolManager and the exact PoolKey; poolId is derived from that PoolKey, never supplied by the caller. The route reads slot0 and active liquidity, rejects malformed, uninitialized, out-of-bounds, low-liquidity, or intermediate unlocked state, and fails closed. There is no fallback and no 60% mode. The route is pinned to the GF/USDG pool that Pons creates at graduation (section 4.5); before that the pool is not initialized, the route fails closed, and activation is impossible. If the route is unavailable, only new Open and Continue are blocked; principal, Exit, settled reward, referral balance, settlement, WindDown and other protected claims remain price-free. Positive donations remain accepted, but may receive zero capacity credit.

The spot price itself is not a TWAP or independent oracle. Trading, flash liquidity, hooks, and same-block MEV can move it. So the contract keeps a reference price next to it that cannot be moved inside one transaction:

• the reference moves only toward the spot seen by earlier transactions, by at most 25% of itself per hour;
• every observation is first clamped to a ±25% band around the reference, so one manipulated transaction moves it by at most 25%, however much time passes;
• the reference starts at the route's minimum valid price (the activation gate) and rises from there.

Every price-dependent value takes whichever of the two prices is less favourable to the caller:

Moving the spot inside one's own transaction therefore does not help the mover. Repeated manipulation during a quiet period can drag the reference gradually, but each attempt costs fees and is limited by the band. During a fast real market move the reference lags by hours. New Positions may then record a lock price below market, which makes a later Continue contribution slightly higher. The route's bounds and liquidity floor remain. The user cannot select the PoolManager, token, pool, price, or route.

#15. Smart-contract security

#15.1 No hidden control

The production contract is deployed without:

• owner or admin;
• proxy or upgrade;
• pause;
• rescue or generic withdrawal;
• delegatecall;
• selfdestruct;
• hidden price-route or beneficiary assignment.

After deployment the launch service address can take exactly two actions: at launch, bind the fee collector to this contract once (section 13.2), and, once and only after WindDown, name the next generation's Bridge for fees (section 19.7). It cannot change GF, USDG or any rule.

Immutability protects the rules from the developer but makes defects unrepairable. Published source, bytecode, and constructor manifest must therefore be verified before interaction. GongFu launches without a paid audit firm: the verified source is public at the contract address, and review is open to the community, security researchers, and anyone's own tools, including AI agents.

#15.2 Authorization and tokens

• Principal and owner-reward actions are authorized only for the Position owner.
• The contract uses msg.sender, not tx.origin, so contract wallets work.
• Each Position has a unique owner/sequence pair that is never reused.
• Incoming and outgoing GF are verified by exact balance changes.
• Fee-on-transfer, short transfer, malformed return data, and unexpected callbacks revert the whole transaction.
• Checks-effects-interactions and one reentrancy guard cover every token-moving route.
• A zero-accounting disposition does not make an unnecessary ERC-20 transfer.

#15.3 Lifecycle invariants

• Principal liability decreases only together with exact principal payment.
• MaxCap notional is released exactly once in the same successful transaction.
• Repeated claim, Exit, Continue, or referral rollup is rejected.
• Pending owner choice changes only with the exact Position flag.
• Referral liability may move only from a maturity epoch into a personal balance or leave through a full referral claim.
• Integer dust remains protected until one-time epoch finalization.
• WindDown is irreversible.
• No action traverses an unbounded list of users or Positions; work is limited to one Position, one epoch, and no more than three referral components.

#15.4 Public mainnet verification

The deployment manifest binds:

• chain ID 4663;
• GongFu address and runtime code hash;
• GF address, decimals, total supply, and runtime code hash;
• canonical market address;
• pinned Uniswap V4 PoolManager, USDG, derived poolId, PoolKey, price bounds, and minimum active-liquidity parameters;
• source hash and reproducible-bytecode hash;
• explorer source verification and links to independent review reports as they are published.

The interface does not replace this verification and cannot substitute its own values for contract-derived state.

#16. Scenario Lab and modeling boundaries

The public GongFu laboratory is a research stress tool, not a marketing forecast. It explores a finite reserve under different inflow rates, profit-taking, participation loss, and combined shocks.

Mandatory model invariants are:

• conservation of fixed GF supply;
• principal-first accounting;
• no forced exit before maturity except WindDown;
• contribution only from reward;
• external sales change the market but do not fund GongFu;
• permanent participant profile across all purchases and Continue actions;
• irreversible WindDown;
• no interpretation of results as an FDV or return forecast.

The simulator is not the production price source and does not define the canonical market. Its results are not encoded in the contract.

#17. Immutable V1 parameters

No reward percentage is guaranteed. Immutability means these rules cannot be quietly replaced after activation.

#18. Risks and trust boundaries

#18.1 Market risk

The GF price may fall substantially. Liquidity may disappear, and a sale may incur severe slippage. Returning the same GF quantity does not guarantee preservation of dollar value.

#18.2 Spot-price risk

A valid V4 slot0 price may still reflect a manipulated thin market. It is not a TWAP or independent oracle. The reference price (section 14) removes the gain from moving the price inside one transaction, but does not protect against a lasting market change. It can be dragged gradually by repeated paid manipulation while nobody else acts. Bounds and the liquidity floor reduce but do not eliminate the risk.

#18.3 L2 risk

Transaction availability depends on the Robinhood sequencer, RPC, Ethereum data availability, and finality. Temporary downtime or censorship may delay a claim, although GongFu rules preserve the owner's right.

#18.4 Immutable-code risk

An unknown defect in an immutable contract cannot be fixed through an upgrade. There is no paid professional audit at launch. Independent review by the community, researchers, or AI tools reduces risk but cannot eliminate it completely.

#18.5 Key risk

The contract cannot restore a wallet. A lost key leaves principal or referral balance protected in accounting but makes the owner's signature impossible.

#18.6 Gas and liveness

Users pay for their own transactions. Settlement of mature epochs is built into deposits, Continue and exits with reward, and cancellation after WindDown into claims, so no separate bot is needed to move the queue. If more than 32 unsettled epochs have accumulated ahead of a participant's own, a separate call settles them first, which anyone can make, including the website. The transaction that happens to settle an accumulated backlog costs more than a usual one. High gas or heavy network load may delay actions but do not convert principal into surplus.

#18.7 Sybil and address identity

MaxCap, donation history, and progression attach to an address, not a person. One person may use multiple wallets, but each address separately starts at the 7-day history tier; the optional 1-day Position does not advance history. Each address remains bound by its own MaxCap. Warming many addresses with tiny Positions unlocks longer terms for them, but the limit above the starting 20% grows only with amounts actually continued (section 7). This is a limit, not a Sybil defence: several addresses of one person still each get their own starting limit. The same applies to referrals: a person can invite their own wallets and receive up to 12% of their rewards.

#18.8 Legal and tax risk

Digital-asset ownership and taxation rules vary by jurisdiction. Each participant independently evaluates applicable requirements.

#18.9 Next-generation risk

Launching the next generation (section 19) is a separate event after WindDown, not a function of this contract. It may be delayed or may not happen for technical, market or external reasons. This changes none of the current generation's obligations: principal, settled rewards and referral balances remain protected and claimable under the rules of this document. Priority in the next generation is not compensation for a fall in the GF price and does not guarantee income.

#18.10 Pons launchpad risk

The GF market is created by a third-party launchpad, Pons, and GongFu does not control its code:

• the owner of the Pons protocol can assign a different creator-fee recipient (according to Pons documentation, with a 3-day delay). Fee buybacks into the reserve would then stop; the reserve, principal and claims are not affected;
• at the time of writing, the Pons V2 contracts have no published audit. A bug in the Pons curve, hook or pool could affect the GF market and, through the price route, the availability of new Open and Continue;
• Pons can restrict which addresses may launch. The launch kit checks this before the first transaction; if launching is closed, it will not start;
• a few minutes pass between buying the reserve and transferring it to GongFu, during which the 500 000 000 GF sit on the launch service address (section 4.3).

#19. Generations: what happens after WindDown

#19.1 Principle

Every generation of GongFu is finite. Its reserve is not replenished by issuance, and its rules do not change after activation. When a generation's reward phase ends through WindDown, the experiment continues with the next generation: a new protocol with a new token and a new reserve.

The current generation is neither extended nor rewritten. Its contract keeps working under its immutable rules until every participant has claimed their GF. The next generation cannot seize, move or "convert" the current generation's funds.

#19.2 Fixed commitments for any next generation

Whatever the next version looks like, it must meet these conditions:

• no owner, administrator, upgrade, pause or hidden withdrawal;
• a participant's principal is accounted for separately from the reserve and never becomes another participant's reward;
• WindDown remains an irreversible, honest end of the reward phase;
• the new token has a fixed supply, and at least 50% of that supply is bought in the token-creation transaction and transferred into the new generation's contract during the same launch; the team keeps nothing from that part;
• a fixed share of the new token's supply (the Generations Bridge basket, section 19.4) goes to participants of the current generation under a formula announced in advance;
• launch is possible only after the current generation has entered WindDown, and this condition is checked against contract data;
• the source code of the next generation and of the Bridge is published, verified in the block explorer and independently audited before launch.

#19.3 Two launch paths

Base path. The next generation uses the same audited GongFu code as the current one, with a new token and new market parameters, plus the Generations Bridge. This path requires no new decisions and does not depend on the protocol's creator. The base-path launch kit (token and market parameters and the deployment sequence) is fixed before the current generation is activated: its cryptographic hash is published in the deployment manifest, and the kit itself is revealed no later than the moment of launch. Anyone can check the revealed kit against the published hash.

Improved path. If an audited improved version is ready by the time of WindDown, it is launched instead of the base one. Improvements may concern reward and limit parameters, terms, the Continue mechanics and market depth. They are based on public on-chain data from the current generation's operation. The improved version must meet every condition of section 19.2. If it is not ready, the base path is launched.

#19.4 Generations Bridge: priority for current participants

The Generations Bridge is a separate small immutable contract of the next generation. During the new token's launch, it receives a fixed basket:

5% of the new token's supply

The basket is distributed among participants of the current generation who received less than their maximum reward because of WindDown. The Bridge reads the current contract's data itself; no list or amount is compiled by hand.

The weight of each position:

weight = position principal in GF
       × days the GF were actually locked
         (until maturity or WindDown, whichever came first)
       × unpaid share of the maximum reward

The unpaid share is:

• 100% if the position's window was cancelled by WindDown;
• the reduction applied if the window was settled with a proportional scale;
• zero if the position received its full maximum reward or its maximum reward is zero (a position too small to earn anything).

For 90- and 180-day positions the unpaid share covers all monthly parts at once: each part counts with its own maximum and the share its epoch did not pay. For example, if the first of three parts was paid in full, the second at half and the third was cancelled, the unpaid share is 50%.

Counting actual lock time makes entering "a day before the end" for the bonus pointless: a recently opened position weighs almost nothing. Weight is in GF, not dollars: the price at opening has no effect, so pushing the price up at entry cannot buy a bigger share. Splitting one amount across addresses does not increase weight, which is proportional to the GF amount.

The Bridge activates only after the current generation has entered WindDown, the next generation has been activated, and the basket has arrived at the Bridge's address.

Distribution happens in two stages:

1. A 30-day registration window after the Bridge is activated. A participant submits their positions; the Bridge checks each one against the current contract's data. Each position can be registered once.
2. Distribution. After the window closes, the basket is split in proportion to weights. There is no race: registration order does not affect the share.

Only an address registered in the next generation can receive its share. This is priority for those who continue participating, not a payment for leaving. A share can be claimed within 180 days after the registration window closes. Whatever remains in the basket after that deadline (unclaimed shares and rounding remainders) does not return to the team: anyone can trigger its transfer into the next generation's reserve. If no position is registered during the window, the basket goes to the reserve as soon as the window closes.

#19.5 Who launches the next generation

The launch is executed by a service address named in the current generation's deployment manifest. Its role is technical: it creates the token and deploys the contracts according to the published kit. It keeps no tokens and does not control the reserve: in the token-creation transaction it buys 55% of the supply (50% for the reserve and 5% for the Bridge basket) and transfers them to the contract addresses during the same launch. The purchase is paid with the service address's own USDG. Any deviation from the kit is visible to anyone who compares the deployment with the published hash. After the launch, the same address binds the next generation's Bridge to the current contract once (section 19.7).

#19.6 What "Generations" does not promise

• current-generation GF does not convert into the next generation's token;
• priority does not compensate for changes in the GF price and is not income;
• the size of a share in the Bridge basket is unknown in advance: it depends on the number and weight of registered positions;
• the next generation is also finite and follows the same principles.

#19.7 Fees after WindDown go to the next generation

After WindDown, buying GF back into this generation's reserve no longer funds anyone's reward. But the GF market keeps working, and trades keep bringing USDG to the fee collector (section 13.2). So after WindDown the collector stops buying GF and sends the USDG to the next generation:

1. Buyback stops. Once the generation is in WindDown, buying GF into its reserve (buybackToReserve) is no longer possible. USDG accumulates on the collector.
2. Binding. The launch service address (section 19.5) names the next generation's Bridge once, and only after WindDown. The contract checks that this Bridge points to the current generation as its previous one and that its next generation has already started. The service address has no other power: it cannot take GF or USDG or change the rules or the binding.
3. Forwarding. Anyone can call forwardToNextGeneration on the collector: all USDG it holds goes to the Bridge bound to this generation's contract. The collector cannot choose any other address.
4. Buyback into the reserve. Anyone can call buybackNextGenerationToken on the Bridge. The Bridge buys the next generation's token on its market and sends it straight into that generation's reserve as free liquidity. The trade succeeds only if it buys at least the amount implied by the next generation's reference price, minus 3% for slippage; otherwise it reverts. The caller chooses the size of each buyback, so a large amount can be split into parts. The next generation's reference price is updated by its own trading and donations; if there are none, anyone can call observeReferencePrice, the same price observation any donation makes, with the same limits (section 14).

The next generation uses the same code and its own collector, so after its own WindDown its fees move on the same way.

This flow is not guaranteed. Its size depends on GF trading after WindDown. Until the binding, USDG accumulates on this generation's collector and cannot go anywhere except the bound Bridge; if no next generation is launched, it stays there.

#19.8 Referrals carry over to the next generation

The next generation is a new contract with its own registration, but invitation links are not lost. If a person registering in the next generation names no inviter, the contract reads who invited this address in the previous generation. If that inviter has already registered in the new generation, they become the inviter, as with a personal invitation. If not yet registered, the usual queue applies (section 12). An inviter named explicitly always takes precedence over the inherited one.

Reading the previous contract is gas-capped: any failure only means there is no inherited inviter, and registration proceeds as usual. Referral balances of the previous generation are not carried over: they are claimed in its contract.

#20. Sources

1. Robinhood Chain: overview
2. Robinhood Chain: network connection
3. Robinhood Chain: smart-contract deployment
4. Uniswap v4 core: PoolId derivation
5. Uniswap v4 core: pool state reads
6. PROJECT_CHECKPOINT_v1.json and GongFu root protocol documents.

#Conclusion

GongFu does not hide the finite reserve or disguise it through unlimited issuance. It separates principal from surplus and defines an honest end to the reward phase in advance. The central idea is simple: immutable rules, transparent accounting, and a WindDown in which principal does not become the price of somebody else's exit. And when one generation ends honestly, the next one begins under rules announced in advance.