VibeCode Saga: Swaps without Borders: a charity swap built in public

​

What it is

1. You connect a wallet and swap across networks through the SODAX solver.
2. The SDK deducts a 0.1% partner fee, which accrues on the Sonic hub to a public charity wallet (0x95A8E0BcF616f7eF630b0D923667fbF52AA721AD).
3. Once the solver confirms your swap, you earn points based on its USD value.
4. When the pot crosses a threshold, an admin opens a vote round with three charities from the shortlist. Connected wallets vote, weighted by their points.
5. The winning charity takes the pot and the cycle restarts.

​

The design idea: the fee is the product

• One reviewable diff turns money on. For the first week the Sodax config had no partnerFee at all, and the build log said so explicitly (“partnerFee config touched: 0”). The fee went live on Day 9 as its own commit.
• One dedicated wallet. It is used only for charity fees, so every inflow is a fee and every outflow is a payout.
• Points only for real swaps. The server asks the solver whether an intent executed before crediting anything. The client cannot self-confirm.

​

Scaffolded against the Builders MCP

• The SodaxProvider > QueryClientProvider > SodaxWalletProvider nesting, and why the config must be one stable reference.
• The shapes of useQuote, useSwap, useSwapAllowance, useSwapApprove, including the nested params.payload pattern.
• CreateIntentParams field by field, including srcChainKey (request side) vs srcChain (read side).
• ChainKeys constants and token addresses with decimals.

​

The SDK pieces that carried this

​

1. Partner fee as config

// `percentage` is basis points (FEE_PERCENTAGE_SCALE = 10_000): 10 = 0.1%
const charityPartnerFee: PartnerFee = {
  address: CHARITY_FEE_ADDRESS,
  percentage: 10,
};

export const sodaxConfig: DeepPartial<SodaxConfig> = {
  swaps: { partnerFee: charityPartnerFee },
  bridge: { partnerFee: charityPartnerFee },
  moneyMarket: { partnerFee: charityPartnerFee },
  // ...
};

​

2. The swap hooks from dapp-kit

const { data: quoteResult } = useQuote({
  params: { payload: {
    token_src: src.address, token_dst: dst.address,
    token_src_blockchain_id: src.chain, token_dst_blockchain_id: dst.chain,
    amount: parsedAmount, quote_type: "exact_input",
  } },
});

const { mutateAsync: swap } = useSwap();
const swapRes = await swap({ params: intentParams, walletProvider, timeout: 120_000 });

​

3. Fees accrue on the hub

const result = await sodax.partners.feeClaim.fetchAssetsBalances(CHARITY_WALLET);

​

4. Server-side confirmation with getStatus

const res = await sodax.swaps.getStatus({ intent_tx_hash: h });
if (res.ok && res.value.status === SolverIntentStatusCode.SOLVED) {
  return { verdict: "confirmed", matchedHash: h };
}

​

5. One wallet layer for every ecosystem

​

6. Self-serve recovery from the hub

​

What made it easy

• The Builders MCP. An afternoon from an empty Next.js app to a real mainnet swap, with the provider tree, hook shapes and intent fields served straight to my coding agent.
• Partner fees as plain config. One object routes 100% of the fee to the charity across swaps, bridge and money market.
• Readable fee accrual. fetchAssetsBalances turns the hub basket into a live charity pot with one call.
• The wallet layer. Eight ecosystems behind one hook shape.
• Smooth upgrades. The mid-build bump from 2.0.0-rc.1 to 2.0.0-rc.8 was type-clean for my usage.

​

Tips for builders

• Check the SODAX Intents spec when building a token picker: native gas tokens are used on the hub, so offer ERC-20s on spoke networks.
• Pass a timeout to useSwap and validate network and balance before signing.
• In Next.js, render the provider tree after a client mount, since wallet adapters touch browser globals.

​

Stack

​

Try it