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 official statements, actual contract events, and inferences 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 294 Harvested events. Each one records the quote-token amount moved into the distribution process and the caller that triggered it.
04
An offchain allocation is committed
pons publishes a Merkle root, total GLD, 90-day deadline and metadata URI onchain. The metadata includes a block window, total weight, accounts and amounts; replay strongly indicates balance over the window matters. The exact selection formula is not public, while listed rewards currently bottom out near 0.00105 GLD.
05
A keeper submits the payouts
Observed keeper batches have produced 30,073 successful claim events. Each success transfers GLD directly from the distributor to the named wallet; in those observed transactions, the recipient did not sign or spend gas. 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 numerical holder thresholdNonefound on ponsfamily.com or in the current pons docs
Who gets GLD?
The allocator chooses a list offchain.
The official Golden Goose page says creator fees route to GG holders, but it does not say that every holder is included or publish a minimum, maximum, or exact weighting formula. The contract verifies the resulting list; it does not decide who belongs on it.
Fees route to GG holders
That is the full public holder-selection claim we could verify on the correct pons domain.
Selection and weighting rules
Epoch files name each account, weight and amount, but do not explain why a wallet was included or omitted.
Correction · 1M GG is not a published gate
The earlier 0.1%–4% claim came from an unrelated, similarly named site. It is not a pons rule. Chain replay independently shows why 1M should not be treated as a gate: 300 of epoch #0’s 521 rewarded wallets never reached 1M GG, and the smallest peak was about 72,345 GG.
Current effective payout floor≈ 0.00105 GLD
The clearest explanation for the changing wallet count is a minimum reward amount, separate from the headline GG balance band. Across the latest 45 verified epochs, pot size and list size have a 94.2% correlation. A smaller pot means fewer weighted shares clear the line.
See the round-pair proof →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.
You were not in the Merkle list
This is the only exact answer for an unallocated round. The root proves the chosen list, but the unpublished allocator gives no wallet-level omission reason.
Your estimated share was too small
Recipient counts closely track the GLD pot. A smaller round can leave more wallets below the observed minimum listed reward even when their GG holdings did not change.
You held for too little of the window
Epoch metadata contains block windows and total weights, and replayed amounts fit balance over time better than a closing snapshot. Buying late may therefore produce little weight.
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.
Your share missed the payout cutoff
Since epoch #106, verified lists bottom out near 0.00105 GLD. A wallet can fall outside a small-pot round because its estimated share does not clear that effective floor.
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.