Buyback & Burn

EarnKit turns any on-chain fee revenue into automatic buyback & burn — with the user retaining custody of every contract along the way.

Under the hood, every buyback is anchored on a 0xSplits V2 PullSplit contract that you (the project owner) control. The split routes your fee revenue between yourself and an EarnKit-managed buyback wallet. When the buyback wallet’s share crosses a USD threshold, EarnKit swaps it to your target token and burns it.

Two paths to set up

The /create page offers two entrypoints. Pick whichever matches your situation.

Both paths converge on the same back-end machinery; the only difference is who deploys the split.

Path 1: Token (we deploy the split)

You give us your token, your wallet, and the revenue percentages. We provision a buyback wallet and you sign one tx to deploy a fresh 0xSplits V2 PullSplit with those recipients.

Form fields

Flow

1. Sign auth — proves you control the owner wallet.
2. Backend provisions a Turnkey-managed buyback wallet and creates the config in deferred mode (no split attached yet).
3. Deploy split — your wallet pops with the createSplit calldata. The split is deployed with [owner, buybackWallet] as recipients at your chosen percentages, with owner = your wallet (so you can rotate recipients later via 0xSplits’ UI).
4. Sign set-split — attaches the freshly-deployed split to your config. Status flips to ACTIVE.
5. Ready screen shows the split address and a one-click panel for redirecting your token’s fees, when supported (see supported redirectors).

Supported redirectors (Clanker & vanilla)

After the split is deployed, the final step is pointing your token’s fee revenue at the split address. EarnKit auto-detects three patterns and offers a one-click update from the connected wallet:

If none of these match (e.g. Doppler, see below), point fees at the split address manually through your launchpad’s admin UI or BaseScan.

Path 2: Splits (you already have an 0xSplits contract)

If you’ve already deployed a 0xSplits V2 contract and want to add a buyback wallet as one of its recipients, use the Splits card on /create.

Form fields

Same as Path 1, minus the percentage inputs (the split already exists) and minus the Token Contract field. You’ll provide the existing split address instead.

Flow

1. Sign auth — proves you control the owner address.
2. Backend provisions a Turnkey buyback wallet keyed to the split you supplied.
3. Add the wallet to your split — update your split’s recipients (via 0xSplits’ own UI, your Safe, or a direct updateSplit call) to include the buyback wallet. Whatever allocation you give it becomes the buyback share.
4. Click “Check now” in the dashboard to verify membership — config status flips to ACTIVE once on-chain readers confirm the wallet is a recipient.

What you can do from /shared-buyback/[id]

Every config has a dedicated detail page (linked from /home and /shared-buyback). Three panels:

Distribute fees

The split contract holds funds temporarily until someone calls distribute(...) on it — that moves the balances into the per-recipient SplitsWarehouse. The Distribute all button bundles every non-zero token sitting on the split (ETH, WETH, USDC, etc.) into a single Multicall3.aggregate3 tx so you get one wallet popup regardless of how many tokens have accumulated.

This is permissionless — anyone can call it. Each recipient is credited their share automatically based on the split’s allocations.

Claim my share

After distribute credits the SplitsWarehouse, the owner-side share sits there until the owner claims it. The Claim all button reads your connected wallet’s warehouse balance across ETH + supported tokens and fires warehouse.withdraw(yourAddress, token) per non-zero balance. One tx per token (warehouse doesn’t allow batching withdraws from msg.sender).

The buyback wallet’s share is claimed automatically by the worker — you don’t manage that.

Redirect fees to this split

Paste the source token contract. We probe Clanker v4, Clanker v3, AND vanilla setters in parallel and surface whichever applies as a one-click update button. See supported redirectors.

Per-config controls

How the worker fires

Buyback wallet receives its split allocation
  └── threshold reached?
        ├── yes → deduct 1% platform fee (sent to platform treasury)
        │         → swap remaining → your target token (Uniswap V3, best route)
        │         → burn (token.burn() OR transfer to 0x000...dEaD)
        └── no  → keeps accumulating until next tick

The worker polls active configs on an interval; you can also press Check now in the dashboard to trigger an immediate check.

Supported swap input tokens

Each input is swapped in its own try/catch — if one route fails, the others still proceed. If fees arrive already denominated in your target token, no swap is needed; the executor goes straight to burn.

Doppler

Doppler launches are structurally unsupported for automatic redirection. The Doppler Airlock sets the integrator and fee recipient at launch time via create(CreateParams) and exposes no update setter — they are immutable post-deploy. The only paths are:

• Be the launch integrator and manually collectIntegratorFees(splitAddress, token, amount) per claim, OR
• Have your launchpad re-launch with the split address as integrator from the start.

Both are out-of-band of EarnKit. The buyback wallet & split work fine; only the redirection step is missing for Doppler.

Execution states

Security design

• Non-custodial. You own the split contract (Path 1: deployed with owner = your wallet; Path 2: you owned it before us). You own your token contract. EarnKit only operates the buyback wallet, and that wallet’s Turnkey policy is locked to: swap inputs → target token → burn or recovery destination.
• Immutable buyback wallet. Once provisioned, the wallet address is baked into your config. There is no admin key, on our side or yours, that can rotate it. To change it you re-register, which provisions a fresh wallet.
• Per-asset swap isolation. ETH, USDC, MINIDEV are each swapped in their own try/catch — a failed USDC route doesn’t block ETH and vice versa.
• Operator gas drip. EarnKit funds a small ETH reserve on the buyback wallet before each execution so gas is always available. The drip is excluded from the swappable-balance check so it can’t false-trigger the threshold.
• Recovery address. The Turnkey policy allows the worker to sweep all assets to the recovery address you set at registration. If something goes permanently wrong, funds end up back with you.

FAQ

Can I change the split percentages later? Yes for Path 1 — your split was deployed with owner = your wallet, so you can call updateSplit(...) on 0xSplits’ own UI to rotate recipients or allocations. For Path 2 it depends on how you set up your original split.

Can I change the target token after registering? No. The Turnkey policy bakes in the target token at registration; changing it requires a fresh registration (and a fresh buyback wallet).

What happens if my target token has no burn() function? EarnKit transfers tokens to 0x000000000000000000000000000000000000dEaD. We auto-detect which mode applies at registration via a transfer probe.

My Clanker v3 LP doesn’t show up in the detail-page list. The auto-discovery uses getLpTokenIdsForCreator(yourWallet), which only includes the original creator. If you received admin rights via updateCreatorRewardAdmin post-launch, expand “Don’t see your LP? Add by tokenId” on the v3 panel and paste the LP NFT’s tokenId — we’ll probe both v3.0 and v3.1 lockers.

My Clanker v4 update reverts. The locker requires msg.sender == admin_of_reward_index. Try a different reward index — 0 is the main creator slot but multi-recipient launches use indices 1–6 for other parties. The dashboard surfaces the revert as “your wallet isn’t the admin for this reward index.”

What if the swap fails (e.g. no Uniswap pool, slippage)? The execution retries with backoff up to five times. Past that, the funds remain in the buyback wallet — the Turnkey policy still permits a sweep to your recovery address.

Can I use any ERC-20 as my target token? Any ERC-20 on Base with a Uniswap V3 pool. We check direct routes first and two-hop via WETH as a fallback.