01
$GG trades against GLD
Golden Goose launched through Pons V2 with GLD as its quote asset. The fixed 1B GG supply began on a constant-product bonding curve and later graduated into a locked Uniswap V4 pool.
Mechanism, decoded
How the goose
lays GLD.
A plain-English walk from a $GG trade to GLD landing in a holder wallet—with the published rules, actual contract events, and uncertainties kept separate.
The complete route
Trade fee to wallet receipt.
The route below is specific to Golden Goose. It combines Pons V2’s launch mechanics with the events and contract state observed at the GG distributor.
01$GG / GLDTrading market
→02Pons fee pathQuote-denominated fees
→030x44dB…5ed7GG distributor
→04Merkle epochWeighted allocation
→Your walletDirect GLD transfer
Factory launch record
02
Quote fees feed the distributor
The launch record names Golden Goose’s distributor as creator-fee recipient. It receives the 70% creator side of GG’s 1% base fee plus the separate 1% creator tax; buyback is disabled. Recipient-change powers are documented on the transparency page.
03
The distributor harvests GLD
We indexed 147 Harvested events. Each one records the quote-token amount moved into the distribution process and the caller that triggered it.
04
A weighted epoch is committed
An offchain process reconstructs holder balances over a block window, produces account allocations and publishes a Merkle root, total GLD, a 90-day deadline and an API URI in an onchain epoch event.
05
A keeper pushes the payouts
Observed keeper batches have produced 22,419 successful claim events. Each success transfers GLD directly from the distributor to the named wallet. The recipient does not sign or spend gas—but the keeper does not always submit every page immediately.
Backfill rounds
Published now.
Delivered later.
An epoch can commit a real allocation before Pons’ delivery worker submits its claims. The GLD remains reserved in the distributor, and a later keeper run can catch up the untouched pages. That makes “not submitted” different from “you were not eligible.”
Inspect the delivery audit →older epochs cleared in one run
- Holder payouts
- 2,767
- GLD delivered
- 48.148552 GLD
- Longest wait
- 32h 31m
Published holder band0.1%to4%of GG’s fixed supply
Who gets GLD?
Eligible, time-weighted holders—not a flat split.
Ponsi’s public explanation says wallets holding between 0.1% and 4% of “supply” receive a share, weighted by both supply and holding time. Applied literally to GG’s 1B total supply, that headline balance range is 1M–40M GG.
Balance × holding time
Longer exposure earns more weight; a momentary end-of-window snapshot is not the whole calculation.
Merkle account amounts
The epoch file names each account and amount. The onchain contract verifies the proof but does not calculate holder weights itself.
Observed exception
Replaying every GG transfer in epoch #0 shows that 300 of its 521 paid wallets never reached 1M GG during that window; the smallest peak was about 72,345 GG. So the real allocator is not a simple “fixed total supply × closing balance” filter. A different supply denominator, time logic, or additional backend rules are involved.
The question everyone asks
“Why did I miss
that round?”
A claim event says who was paid, but there is no onchain ‘rejection reason.’ The wallet checker therefore labels evidence and likelihood instead of pretending it can read a reason code that does not exist.
Below the literal 0.1% line
Under 1M GG is below 0.1% of fixed total supply, but observed wallets have been paid below it. Treat this as a signal, not a rejection rule.
Above the published cap
More than 40M GG is outside the published 4% whale cap. Splitting wallets solely to game a reward system may carry separate risks and is not endorsed here.
Not held for enough of the window
Because weight includes time, buying near an epoch boundary can produce little allocation even when the closing balance looks large.
Infrastructure or non-standard account
Epoch files explicitly exclude protocol addresses. Contract and delegated accounts also deserve scrutiny; the published page does not document every backend filter.
Allocation too small or absent
Observed epoch lists are not identical to a simple closing-balance list. Small early-round payouts cluster around practical floors, but that behavior changes over time.
The keeper has not submitted it
An announced allocation can precede delivery by hours—or more. Pons has backfilled older rounds in later runs, so the checker labels known allocations as waiting instead of calling them missed.
Contract map
Trust, then verify.
These are the live addresses this analysis follows. Token names can be copied; contracts are the identity.
Full methodology →- Golden Goose · GG
- 0xcacb0e9c…cb68
- Reward asset · GLD
- 0xc9a981fe…fc4e
- Golden Goose distributor
- 0x44db4ecd…5ed7
- Pons V2 factory
- 0x7ed598bc…ec7e
- Bonding curve
- 0x52956293…0079
Turn theory into your timeline
Ask the ledger about your wallet.
The checker uses public logs only. It never asks for a signature.