DICKBUTT

DICKBUTT is a decentralized, community-run coin. The fee system is intended to support that community over time, with defined allocations that do not depend on the continued involvement of any single contributor. This objective informs the allocation design; the operating roles and remaining administrative powers are documented in §09.

Trading creates fees. The central question is where those fees go after collection. The system gives each supported fee token a defined route, making the connection between trading activity and its destinations easier to inspect.

The design has four outcomes: fund SPCXC distributions for eligible DICKBUTT holders; send DICKBUTT to the shared burn address; provide WETH to the Strategic Dickbutt Reserve; and recognize the artist behind the original character. Each outcome is accounted for in its own token. These flows do not create a fixed return or make a token balance a claim on the reserve.

Architecture and allocation design: [1] [2]

3.1   Clanker: two collection paths

The existing DICKBUTT/WETH Uniswap V3 position is held by the Clanker LP locker. The locker sends 40% of collected DICKBUTT and WETH to its collection recipient and 60% to its protocol fee Safe. LockerHarvester owns the locker and collects its recipient share into SplitsFeeRouter. These percentages describe upstream collection; they are separate from the downstream holder, reserve, artist and burn allocations.

LegacyFeeHarvester recovers eligible DICKBUTT fees from two configured Safes through the Clanker legacy fee module. The current Safe is adapter index 0 and the historical Safe is index 1. Both routes feed the same router. The adapter can recover DICKBUTT from those Safes, but cannot recover their WETH. When the direct and legacy claims succeed, the pipeline can therefore receive effectively all collected DICKBUTT and 40% of collected WETH.

3.2   Completed fee-authority assignments

The deployment reference records both required authority handoffs as completed. The Clanker locker’s owner() is LockerHarvester. Separately, the legacy module’s tokenCreator(DICKBUTT) is LegacyFeeHarvester. Locker ownership and legacy creator authority are distinct relationships; completing one does not automatically complete the other. Their assignment transactions appear in §11.

The configured position is NFT ID 1391176, held by the existing Clanker locker through the Uniswap V3 position manager. This is the existing Clanker position, not an Aerodrome NFT or an ERC-20 LP token held by this deployment. These assignments control collection of fees. They do not transfer ownership of the DICKBUTT ERC-20 token contract.

3.3   Fixed adapter and remaining upstream control

The legacy adapter’s module, token, destination and two-Safe list are fixed. It has no owner or destination setter and cannot relay another creator transfer. Upstream Clanker Safe owners still control their Safes and module enablement. A fixed adapter cannot guarantee that every future upstream claim will remain available.

The Clanker harvester has a separate administrator: the project’s 3-of-4 Safe. Its current fee destination is the router, but that destination is not permanently locked. A change is subject to a seven-day delay. Recovery of the configured Clanker position is possible only after the upstream lock expires. These controls and the immutable split destinations should be assessed separately.

3.4   Aerodrome’s role in this deployment

The deployed system does not hold or harvest an Aerodrome LP position. It does not collect fees from the existing DICKBUTT/SPCXC or DICKBUTT/WETH Aerodrome pools. Those pools are explicitly excluded from holder rewards. Aerodrome Slipstream is used only to purchase SPCXC through WETH → USDC → SPCXC. The market route is described in §05 and its dependency addresses are recorded as part of the deployment register.

This distinction separates a fee source from a trading venue. Trading through a pool during a purchase does not give the rewards system ownership of that pool’s liquidity or entitlement to its LP fees. The diagram in §02 follows the deployed Clanker-derived receipts and their destinations. [5]

The router creates two genuine Splits PushSplit V2.2 contracts through the official factory. One distributes DICKBUTT; the other distributes WETH. Both deployed splits have the zero address as owner; their recipient lists and percentages are immutable. The fee router has no owner-controlled recipient setters. Splits handles the allocation, while a separate executor handles conversion to SPCXC. [2]

4.1   The denominator matters

“10% of WETH and 10% of DICKBUTT” means 10% of each incoming token stream. It does not add up to a 20% share of their combined value. Likewise, 80% applies to WETH that reaches the splitter, after upstream collection. It is not 80% of total trading volume or 80% of all gross WETH fees generated by the pool. For example, if 100 WETH in collected fees is subject to the documented upstream 40/60 allocation, 40 WETH reaches this pipeline: 32 WETH funds SPCXC purchases, 4 WETH goes to the reserve, and 4 WETH goes to K.C. Green. The other 60 WETH is outside this adapter’s recovery path.

Splits rounds allocations down in the tokens’ smallest units and retains small residual balances. That dust remains in the Split and participates in later distributions, subject to the protocol’s retained-unit behavior. Sending DICKBUTT to the burn address does not call an ERC-20 supply-reduction function; it is a token transfer to that address. SPCXC is purchased on the market and is not minted by this system. No separate WETH allocation is deducted for bot gas; operation is funded externally. [2]

The 80% WETH allocation reaches SpcxcSwapExecutor. Its configured route uses Aerodrome Slipstream to exchange WETH for USDC, then USDC for SPCXC. The resulting SPCXC is delivered to the fixed rewards distributor. The executor does not take another percentage of the allocation. [2]

The deployed executor fixes its router, token path and rewards destination. The WETH/USDC purchase pool uses tick spacing 1 and the USDC/SPCXC purchase pool uses tick spacing 10. Operations use the configured Slipstream quoter to assess output before execution. The use of those existing pools is a market purchase, not LP harvesting. Executable liquidity must still be checked at the time of a swap. [5]

5.1   Bounded execution

Only an approved keeper can trigger a conversion. Each call is subject to a size cap, cooldown, deadline, and minimum acceptable output. A separate floor-setter role refreshes a price floor above an owner-defined lower bound. That floor expires within one day; an expired floor stops swaps until it is refreshed.

The contract checks the actual WETH spent and the actual SPCXC received, rather than trusting the router’s reported output alone. The price floor is an administrative protection. It is not an independent price oracle, and it does not eliminate slippage, market manipulation, or owner authority. [2] [4]

5.2   Purchased SPCXC is distributed to holders

After the executor buys SPCXC, the tokens are delivered to the rewards distributor for payment to eligible DICKBUTT holders. This is the purpose of the 80% WETH allocation: purchase the reward asset, account for each holder’s share, and send that share to the holder’s wallet.

The deployed funding path buys SPCXC using the holder-reward share of received WETH. There is no separate Aerodrome LP-fee contribution in this deployment. Payment follows the calculation, commitment, activation, and verification process in §07; the completion of a swap does not itself trigger an immediate payment to every wallet. [1]

5.3   SPCXC: backing and redemption

SPCXc is the SpaceX tokenized stock listed in the official Coinbase Tokenized Stocks catalogue on Base. Issued by Coinbase Onchain SPV Ltd, these securities represent beneficial interests in underlying SpaceX shares. Coinbase describes the programme as fully backed: tokens are issued against shares held in regulated custody, with assets separated from Coinbase through a bankruptcy-remote structure. [6] [7] [9]

In his 14 September 2026 announcement, Brian Armstrong described Coinbase Tokenized Stocks as fully backed securities redeemable for their underlying shares, with corporate dividends integrated into the product. SPCXC therefore connects the DICKBUTT reward mechanism to a share-backed security issued through Coinbase. [8]

Redemption is subject to the issuer’s terms. Coinbase’s FAQ limits primary minting and redemption to approved institutional partners and Authorised Participants. The SPCXc prospectus also provides for redemption by other holders who satisfy its vesting conditions, subject to the stated procedures. Holding tokens in a wallet alone does not establish an unconditional right to redeem; eligibility, identity checks, jurisdiction, fees, and settlement requirements apply. [7] [9]

Within this protocol, “stock dividends” describes trading-fee distributions paid to DICKBUTT holders in SPCXC. These payments are funded by the fee mechanism described in this paper. Any corporate dividend declared on the underlying shares is handled separately under SPCXC’s issuer terms, including reinvestment after applicable deductions. [7] [9]

A single snapshot can treat a balance held for one moment as if it had been there for an entire period. The calculator instead reconstructs transfer history and measures the time-weighted average balance: how much DICKBUTT a wallet held, multiplied by how long it held that amount.

6.1   Eligibility and exclusions

The selected minimum is a time-weighted average of at least 6.9 million DICKBUTT across the reward period. Exactly 6.9 million qualifies. Eligibility also follows the configured exclusion list. The current calculator combines 25 explicit exclusions with pool-interface detection. It excludes liquidity pools and their management infrastructure, the burn address, fee-pipeline contracts, K.C. Green’s recipient, the CDB vault, the project Safe and the bot wallets. Unknown custom pool designs may still require an explicit exclusion.

A wallet’s current balance alone cannot determine eligibility for a completed period. The calculation must consider its history, the period boundaries, exclusions, the selected minimum, and any payout threshold. SPCXC has eight decimals, so the smallest payable raw unit is 0.00000001 SPCXC. Values smaller than one raw unit cannot be transferred as fractions of a token unit; rounding dust remains for later accounting. There is no fixed 3,000-holder requirement and no entitlement to equal payments. [1] [3]

Eligibility and proportional allocations are calculated off-chain from finalized DICKBUTT transfer history. The distributor verifies committed Merkle proofs and prevents duplicate payments; it does not independently reconstruct DICKBUTT balances or enforce the 6.9M threshold on-chain. The keeper checks a proposed plan against its own accounting before payment. A newly funded wallet qualifies according to its time-weighted holding over the period, not merely the balance visible when it first receives tokens.

6.2   Dividing the available reward pot

The selected reward policy uses linear weighting: an eligible wallet’s weight is its time-weighted average DICKBUTT balance. Its new allocation is proportional to that weight within the eligible set.

For example, a wallet with 15M average DICKBUTT represents 5% of an eligible total of 300M. With an illustrative 100 SPCXC allocation pot, its new share is 5 SPCXC before rounding and settlement rules. Neither the pot nor that return is fixed.

Square-root weighting is also supported, but splitting a balance across multiple qualifying wallets can increase its combined weight. Linear weighting avoids that particular advantage, ignoring eligibility thresholds and integer dust. Neither method identifies unique people. The selected economics are bound into the calculator configuration and need an explicit migration if changed after accounting begins. [3]

6.3   Choosing the first period

The calculator reconstructs balances from the token’s first block. A bootstrap run can establish a starting boundary with a zero reward pot, allowing the next period to measure from that boundary. Without this decision, the initial average can cover the token’s entire history. A completed launch round is now recorded in §11. Its completion establishes payment history, but does not by itself reveal every accounting-period boundary. Period journals remain the source for the precise finalized interval used in a particular allocation.

6.4   Balance changes within a period

Each transfer changes the balance used for the remaining portion of the period. A transfer does not rewrite the amount previously held or the time for which it was held. The calculation therefore distinguishes a continuous position from a position acquired shortly before the period closes.

Consider two wallets over a six-hour period. A wallet holding 10M DICKBUTT throughout the period has a 10M average. A wallet holding zero for the first three hours and 20M for the remaining three hours also has a 10M average. Under linear weighting, the same eligibility rules, and no exclusions, they receive the same weight despite having different closing balances. Prior accrued rewards can still make their final payable amounts differ. [3]

Receiving SPCXC at the distributor and paying holders are separate stages. Funds must be reconciled, assigned to a payment plan, committed, and delivered. This prevents the same funds from being promised to multiple rounds.

1. Measure a finalized period

   The calculator uses a selected finalized block and consistent historical data to reconstruct balances, payments, and existing commitments. Missing data or inconsistent commitments stop the calculation.

2. Build the payment commitment

   A Merkle tree summarizes the wallet addresses and payment amounts in a compact root. The calculator journals the period, its configuration, allocations, and payment plan.

3. Propose and activate

   An approved proposer submits the root and total. The selected deployment setting adds zero activation delay, so a new round can activate immediately. Independent keeper verification still precedes payment.

4. Verify and deliver

   The standard keeper independently reconstructs the historical allocation before signing. After activation, an approved keeper sends proof-verified batches of SPCXC directly to wallets. The current operator configuration allows up to 100 recipients per transaction.

5. Reconcile the result

   Failed recipients can be retried individually. Paid amounts are matched against the plan. Unpaid amounts in cancelled or closed matching rounds are credited back once by the calculator.

7.1   What a proof establishes

A valid Merkle proof shows that a payment belongs to the committed plan. It does not establish that the plan used fair eligibility rules or correct historical balances. Those properties depend on the independent reconstruction of the calculation and the controls around proposer, keeper, and owner authority. [3] [4]

7.2   Six-hour reward cycles and carried balances

Rewards are scheduled every 6 hours. The deployed minimum between new round proposals is 21,600 seconds, and the current per-round cap is 10,000 basis points: 100% of the unreserved SPCXC balance. The Safe set this cap in the recorded launch transaction. The operating policy allocates available SPCXC to eligible holders, subject to reservations, accounting and integer rounding. Pending obligations, unpaid batches, and small accrued rewards also affect the distributor’s balance. A balance in the contract is therefore not automatically the same as the amount available for a new round. The 100% cap permits allocation of all unreserved funds; it does not override existing commitments or eligibility calculations.

The selected activation delay is zero seconds: no additional review wait is added after a proposal. This is the deployed setting; historical constructor or documentation defaults do not describe the current configuration. The payout worker checks every minute for ready rounds and unpaid batches. A rate-limited proposal is retried every minute using the existing plan, without recalculating its period. Finality, available fees, completed swaps, bot operation, and transaction processing can still delay delivery. [3] [4]

7.3   Separate available funds from committed funds

The distributor’s token balance contains more than one accounting category. Some tokens may already be reserved for pending or active rounds. Those obligations must be excluded before another round is proposed. Plans prepared locally but not yet committed also require a reservation in the calculator’s records.

This separation prevents funds already committed to one group of recipients from being allocated again. As payments succeed, the record of each round is reconciled against its actual transfers. An unsuccessful recipient can be retried without paying recipients who already received their allocation a second time. [3] [4]

7.4   Capped instalments and recovery

If payable accrued rewards exceed the live round cap, the calculator pays proportional instalments within that cap. Every unpaid amount remains credited to its wallet. Deterministic raw-unit rounding conserves the available budget. The payout threshold selects accrued balances eligible for payment; an individual capped instalment can be smaller than that threshold. Small budgets may therefore pay only some eligible holders in a particular round.

The calculator and proposer share the same journal of periods and payment plans. Retries use that history, and the independent keeper reconstructs each allocation before signing. Fee collection continues after a competing harvest only when its outcome has been conclusively reconciled. Monitoring flags stalled active payouts so an interrupted process can be investigated and resumed. [1] [3]

8.1   Strategic Dickbutt Reserve (SDR)

The Strategic Dickbutt Reserve receives 10% of WETH reaching the splitter. Its mandate is to buy CryptoDickbutts NFTs from the floor and hold them in a Dickbutt community treasury wallet, building a shared reserve to help fund the Gooch Island goal.

These acquisitions also pay homage to CryptoDickbutts, the collection that helped pave the way for the meme in the crypto space. Building the reserve recognizes the collection and its community for bringing Dickbutt into on-chain culture. [10]

The fee contracts deliver WETH on Base. Bridging funds and buying CryptoDickbutts NFTs remain manual treasury actions outside the fee contracts. The allocation provides funding for the reserve; the selection of NFTs, purchase timing, and subsequent use of reserve assets are treasury execution decisions. [1]

The fee router does not choose a listing, bridge funds, verify a listing’s price, or execute a marketplace purchase. Acquisition criteria and transactions should be published alongside the reserve’s holdings, so the community can inspect how funds are deployed toward the stated objective. The allocation alone does not establish automatic floor purchases, minimum purchase volumes, or redemption rights for DICKBUTT holders.

The configured CDB vault recipient is a wallet address, not a deployed automated NFT-buying contract. Its address is listed with the other recipients in §11. Its presence in the WETH split establishes the destination of that allocation; any subsequent purchase must be inspected separately.

8.2   Reserve reporting

The reserve should be evaluated through its holdings and transaction history. A useful record would identify incoming WETH allocations, any bridge transfers, the NFTs acquired, their purchase prices, and the community wallet holding them. Recording transaction hashes and NFT identifiers would allow each acquisition to be checked independently.

Funds allocated to the SDR, funds spent on acquisitions, and funds later deployed toward Gooch Island represent separate stages. Reporting them separately would make the reserve’s progress clear without treating an NFT purchase as an island expenditure. These reporting principles distinguish treasury activity from fee-contract execution; they do not add execution powers to the fee contracts.

8.3   Recognition of the original artist

The two Clanker-derived fee splits each allocate 10% of their respective tokens to the configured K.C. Green recipient. This produces a WETH transfer from the WETH stream and a DICKBUTT transfer from the DICKBUTT stream. The allocation is an ongoing homage to K.C. Green as the creator of Dickbutt. [2]

For years, Dickbutt has circulated through copies, remixes, and communities far beyond its original comic. Green has publicly said he freely lets others use the character. That circulation does not automatically return income to its creator. The allocation is a gesture of gratitude from the community: directing a share of the value built around Dickbutt back to the person who drew it, without asking him to police its use or pursue licensing payments. [11]

The tribute is unsolicited: K.C. Green did not request the payments and does not support crypto. It recognizes his authorship without implying participation in, operation of, or endorsement of the protocol. His configured Bankr wallet is listed in §11.3. Whether he accesses the recipient wallet remains his decision. The allocation does not depend on those balances being used.

Permissionlessness is a property of particular actions. Anyone can trigger supported harvesting, token splitting, activation of eligible rounds, and closure of a fully paid round. Swapping and paying require approved keepers; proposing a reward root requires an authorized proposer. Routine automation can operate without multisig signatures, while administration and intervention remain possible. [4]

9.1   Ownership and operating wallets

The project Safe is a 3-of-4 multisig. It owns the rewards distributor, SPCXC swap executor and Clanker harvester, and it also acts as distributor guardian. The original deployment wallet is historical; those three ownable contracts are now owned by the Safe. The keeper, proposer and price updater are separate operating wallets. Their addresses and the four current Safe signers are listed in §11.

Three signer approvals are required for Safe execution. Routine holder payout transactions do not require three fresh signatures: authorized bots perform those operations using their configured roles. Separating daily operations from Safe administration allows automation to continue without removing the Safe’s remaining authority.

9.2   What is immutable

The selected PushSplits have zero owners and fixed recipient allocations. The router has no owner or arbitrary token-routing method. Those properties fix the allocation contracts themselves; they do not remove authority in fee sources, the swap executor, the reward proposer, or external token infrastructure.

9.3   What can be changed

The Safe can manage proposer and keeper roles, reward limits and the review delay. It can pause future proposals and cancel pending rounds before activation. It also controls swap limits and the price-floor lower bound. The Clanker harvester currently permits fee-destination changes after a seven-day delay; its destination is not permanently locked. These are live administrative powers, not merely possibilities in unused deployment code.

The Clanker harvester’s administrator can recover the configured position only after the upstream lock expires. Current and pending fee destinations, lock state and ownership should be checked together when the system is reviewed. Fee-destination controls and custody of the underlying position are separate relationships. The legacy adapter has no owner or destination setter, while upstream Safe owners retain their own module and Safe controls.

The zero-delay reward setting removes the guaranteed time to cancel a bad pending proposal. The guardian can still pause future proposals, and the standard keeper still checks allocations independently. Pausing proposals does not itself stop payout of an already activated round. The owner can change the delay for future proposals within the contract’s permitted range; existing pending rounds retain their recorded activation times.

The distributor has no direct SPCXC rescue function, and the executor blocks rescue of WETH and SPCXC. The Safe’s ability to propose reward roots and appoint keepers remains a material trust assumption. Its authority over swap roles and execution bounds is also broader than the narrow price-updater role. Fixed splits and fixed token destinations therefore operate within a governed system. [2] [4] [5]

A complete description includes the conditions under which the system can slow down, stop, or produce a different economic outcome than expected.

Fee income is variable.

It depends on trading activity, liquidity, routing, and the fee sources actually controlled by the pipeline. A new pool cannot force an aggregator to route trades through it.

Conversion depends on the market.

Available liquidity, slippage, price-floor validity, router behavior, and reward-token transfer policies affect whether WETH can be converted and how much SPCXC arrives.

Automation needs operation.

Bots need gas, functioning infrastructure, correct configuration, and available chain data. A fixed recipient does not guarantee uninterrupted collection or payment.

A commitment needs independent checking.

A cryptographically valid plan can still encode the wrong allocation. Independent keeper verification and multisig review remain part of the security model.

Custody choices can be permanent.

An incorrectly configured immutable recipient or permanent position lock can be difficult or impossible to repair. The deployed configuration determines the actual result.

Accounting needs its history.

The journal supports recovery and detects inconsistencies. Its hashes cannot recover a deleted history; independent backups remain necessary.

10.1   Hosted automation and operating resources

The deployment reference records six server timers enabled on 22 September 2026 at 17:56 UTC, followed by a check confirming that all six were enabled and active. Four hosted services handle keeper work, proposal submission, price updates and monitoring. They run independently of the operator’s Mac. Contracts do not wake themselves up; hosted operators submit the required Base transactions.

The first scheduled pending-round and payout checks, price checks and monitoring jobs completed successfully in that snapshot. The next complete scheduled fee-and-reward cycle had not yet occurred. This operational observation is separate from the already completed first holder round in §11, and should not be read as evidence of uninterrupted operation after the snapshot.

The keeper, proposer and price-updater wallets need native Base ETH for gas. Hosting and data services must remain funded, available and monitored. Gas is not automatically taken from the WETH fee split. Chain finality, cooldowns, operator polling and service faults can delay a six-hour target schedule. Zero additional review delay permits immediate activation of a new proposal; it does not combine collection, conversion, calculation and payout into a single transaction.

The implementation includes caps, timelocks, role separation, retries, and failure checks. Each addresses a specific failure mode. None establishes a fixed yield, a guaranteed token price, or independence from all administrators and external protocols. These limitations are part of the architecture described in the source documents. [1] [3] [4]

On-chain verification connects the fee flow in Figure 01 to the contracts that carry it out. This register records the tokens, deployed application contracts, fixed recipients, upstream dependencies and operating wallets in the project’s 22 September 2026 Base mainnet reference. The network is Base, chain ID 8453, and transaction gas is paid in native ETH. Contract addresses and ordinary wallet addresses are labelled by role so that governance or operator wallets are not mistaken for deployed application contracts.

A token contract, reward distributor, fee router and operating wallet serve different purposes. Readers can follow the explorer links for the application contracts and launch transactions and compare them against the allocation rules in this paper. The dependency records identify the trading route, while the exclusion records identify pools that do not receive holder allocations or contribute harvested fees.

11.1   Token contracts and precision

DICKBUTT

0x2D57C47BC5D2432FEEEdf2c9150162A9862D3cCf

18 decimals.

SPCXc — reward token

0xb2000000000000000000007b9fcbd005511aCBd5

8 decimals.

WETH

0x4200000000000000000000000000000000000006

18 decimals.

USDC

0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913

6 decimals.

11.2   Deployed application and split contracts

Clanker harvester (LockerHarvester)

0xDc6BCe01E614ECbb449aDA34804723A2693557c6

Owns the Clanker locker and collects its recipient share into the fee router.

Legacy fee harvester (LegacyFeeHarvester)

0x9FC56b0283085CE893028eE62C96741FF37E792C

Recovers DICKBUTT from the two configured legacy fee Safes into the same router.

Fee intake and routing (SplitsFeeRouter)

0x40d09b189EdAD85c5BE27729b735b36a06D25f9D

Routes DICKBUTT and WETH through their respective immutable splits.

DICKBUTT split

0xB484a2778C5d603Acd5046947688d38D153fF5d2

10% KC; 90% burn address.

WETH split

0x440B068cc254A9c1069C9a0cc8124fEe72E9156F

10% KC; 10% CDB; 80% SPCXc purchase executor.

SPCXc purchase executor (SpcxcSwapExecutor)

0x456091B6D448310cab7BDf9459d85CF46E590397

Swaps WETH through USDC and sends SPCXc directly to the distributor.

Holder rewards distributor (DickbuttRewardsDistributor)

0xa1cBE4ADe80b6Db67c5ac75B6509FA55C4a11c6C

Stores SPCXc, commits allocation roots and executes verified batch transfers.

The five application deployments are the distributor, purchase executor, fee router and two harvesters. The two split contracts were created by the fee-router deployment through the Splits factory. The zero-owner splits and fixed legacy adapter have different authority models from the three contracts administered by the project Safe.

11.3   Fixed fee recipients

K.C. Green · Bankr wallet

0x331BB8664d032544327E61753485d06d663995B6

CDB vault — configured recipient wallet

0xB58f2Ce04bd5d397F34ba319316CfaB471E16cF3

DICKBUTT burn address

0x000000000000000000000000000000000000dEaD

The CDB entry is the configured recipient wallet for the reserve allocation. It is also one of the current Safe signers, but the two roles are distinct. K.C. Green’s Bankr wallet on X receives its share in the original fee tokens, while the burn address receives the routed DICKBUTT allocation.

11.4   Clanker sources and dependencies

Existing Clanker DICKBUTT/WETH Uniswap V3 pool

0x92d90f7f8413749Bd4BeA26ddE4e29efC9e9A0B6

Clanker LP locker

0x2Ad4DB8ba8de03834DB14454Afcd74C2393d81C4

Uniswap V3 position manager

0x03a520b32C04BF3bEEf7BEb72E919cf822Ed34f1

Clanker legacy fee module

0x10F4485d6f90239B72c6A5eaD2F2320993D285E4

Current legacy fee Safe — adapter index 0

0x1eaf444ebDf6495C57aD52A04C61521bBf564ace

Historical legacy fee Safe — adapter index 1

0x04F6ef12a8B6c2346C8505eE4Cff71C43D2dd825

The position identifier is 1391176. The existing locker retains custody of that Uniswap V3 position. The current and historical legacy Safes occupy fixed adapter indices 0 and 1 respectively. The position manager, locker, legacy module and Safes are upstream dependencies rather than additional reward distributors.

11.5   Purchase route and split infrastructure

Aerodrome Slipstream swap router

0x698Cb2b6dd822994581fEa6eA4Fc755d1363A92F

Aerodrome Slipstream quoter used by operations

0x514c8B5f54112481E28028F1166Bd78501089259

Slipstream pool factory

0xf8f2eB4940CFE7d13603DDDD87f123820Fc061Ef

WETH/USDC purchase pool — tick spacing 1

0x4e392fBfE4D0557C82D2F97F02ec39daA31516dd

USDC/SPCXc purchase pool — tick spacing 10

0x0bf58fe0FAc935Ac69595c19B12Ba0d75E3F8c0E

Splits V2 PushSplit factory

0x8E8eB0cC6AE34A38B67D5Cf91ACa38f60bc3Ecf4

Splits V2 warehouse

0x8fb66F38cF86A3d5e8768f8F1754A24A6c661Fb8

The purchase pools are used to execute the WETH → USDC → SPCXC conversion. Neither represents an LP position held by this rewards deployment. The quoter informs operations, while the executor’s configured price floor and transaction bounds control acceptable execution. The Splits factory and warehouse provide the split infrastructure.

11.6   Current eligibility and settlement settings

11.7   Governance and operating wallets

Project Safe / owner / guardian

0xA15BDE99c19E908db4fa07abe4220De13CFbcF7b

3-of-4 multisig; owns the distributor, swap executor and Clanker harvester; also acts as distributor guardian.

Keeper

0x44aa412ec0B2589BFbb9227e1336F87030D53321

Pays Base gas for fee collection, splits, authorized swaps and authorized holder payout batches.

Proposer

0xEd36De3d0edBF550c159e184cAf4A628F9e3E585

Submits the calculated reward root and total.

Price updater

0x6FCa3eFAae58aa7432d2b3931CDed75395B1cf00

Updates swap-price protection within the configured owner bound.

Original deployment wallet

0xD77cc54f781BA07Fbba9CBe2783AC4241a3e96E3

Historical deployer; the three ownable contracts are now owned by the Safe.

11.8   Current Safe signers

1

0xB58f2Ce04bd5d397F34ba319316CfaB471E16cF3

2

0xDF3eFAfdA19D2dF229eF3fbEC73d2EE6C5fB6d7c

3

0xBd0Fad6aFCe3Dbe364A6B4B62c20e6F89BdF0FE7

4

0xf236Cb0Cf2076432541BB2051140dbA39cD31f86

Three of the four signers are required for Safe execution. The Safe’s ownership of the distributor, executor and Clanker harvester, and its guardian role, remain material governance powers. The historical deployer address is retained for provenance; it is not the current owner of those three contracts.

11.9   Application deployment transactions

DickbuttRewardsDistributor

0x2edba8044ea153780c84b8ca214ac40eedfa59535047d5fde6a98219aae146aa

SpcxcSwapExecutor

0x4681c4414b1c96bfebe75ebddc389979abf0abcbdab4e84b93b103b6c4cfbd2e

SplitsFeeRouter

0x543b12d8a75e46aecb8b90f6198ba409f85c4d0e06b9fb0cf7323ef46f93f61c

LockerHarvester

0x319bcef2ffd2b712067f3cbefc6608a2b56d6c8d692f77470d7b4b322411b8aa

LegacyFeeHarvester

0xd0f87726f5debf5a99e86133f97d7a0530ec8c1f27fdf49b0928fb96cd9e29be

11.10   Launch and payout evidence

Safe accepts ownership of the three ownable contracts

0xf64c4643dd277ac481386c0f0b10a3617d9b433f8938facb8739dc8c689875aa

Clanker locker ownership assigned to LockerHarvester

0xff50a3cbc53d4051d28fab990eda1e9740521f8edce6b733310b1b27dc356731

Legacy creator assigned to LegacyFeeHarvester

0x49ba13a354864d6487e2a2cfde90ce9a9e1b22c24067791fd991002ba71b0fe5

Safe sets 100% round cap and retains six-hour interval

0xf97b0eb9d30fd7fef4b90425488fbe2fcdf498d12f18c67eb674ac1f6f9dac84

First verified WETH → USDC → SPCXc purchase

0x5d2bb66a0990bd9fcd811a605e44c994a1ff67fcbd9b763dadec5aec45cf986b

First holder round proposed

0x639add78ce893fb6b58d988a21643ef934819cc95af46286927cdb5ed5d7bda8

First holder round closed after six payout batches

0xf11ba921a87a51377f0008f788428da840ef909dbae6fcab71ecc6051265b842

This historical round demonstrates a completed delivery using the deployed pipeline. It does not set the size of later reward pots, establish a fixed recipient count or promise equal payments. Future amounts depend on received fees, execution prices, eligibility, reservations and successful operations. The later activation of the hosted timers is an operating milestone separate from this already completed round.