Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Audit & security

The Kumbaya stack is built from two layers, each with its own audit lineage:

Layer
Auditor(s)
Status

Kumbaya launchpad (Fire* contracts)

BlockSec

Signed report; no critical or high findings open

DEX (Uniswap V3 fork)

Trail of Bits, ABDK Consulting (inherited from Uniswap V3 upstream)

Bytecode-verified against upstream; both audits public

Kumbaya launchpad - BlockSec

Every contract in the Kumbaya launchpad - FireLaunch, FireToken, FireGraduator, FireRegistry, FireStream, FuelVault (the Fire* family) - is covered by a BlockSec audit. The scope includes the full lifecycle: token deployment via ignite, the bonding-curve seed positions, graduation and the position-consolidation step, the tip-credit ledger (FuelVault), and post-graduation fee streaming through FireStream.

The signed report is published in the integrator-kit: blocksec_Kumbaya-xyz_Fire_v1.0-signed.pdf.

No critical or high findings remain open. Lower-severity findings have been addressed and verified.

DEX - Uniswap V3 audit lineage

The Kumbaya DEX is a fork of Uniswap V3. The fork is bytecode-equivalent to upstream for everything except the protocol-fee range - Kumbaya's contract allows feeProtocol ∈ {0, 2..10} (up to 50%) vs. upstream's {0, 4..10} (up to 25%). The values currently set in production sit within Uniswap's standard range (25% on 0.01% / 0.05% tiers, ~16.67% on 0.30% / 1.00% tiers, 0% on launchpad pools). Pool math, swap math, tick spacing, position management, and periphery routers are all unchanged.

Bytecode equivalence verification

The integrator-kit ships a script that compiles upstream Uniswap V3 contracts at the same Solidity version and flags and compares the resulting bytecode against the Kumbaya deployments:

cd integrator-kit
pnpm install
node scripts/compare-bytecode.ts

The comparison is byte-for-byte modulo the documented protocol-fee range change. Any other divergence would surface as a test failure.

Inherited Uniswap V3 audits

Because the fork preserves upstream's protocol behaviour, every audit Uniswap V3 went through applies to Kumbaya's DEX. Both formal V3 audits live in the upstream v3-core repo:

Auditor
Report
Scope

Trail of Bits

v3-core/audits/tob/audit.pdf

Full V3 core protocol review (March 2021)

ABDK Consulting

v3-core/audits/abdk/audit.pdf

Mathematical correctness, edge-case behaviour

Index: Uniswap/v3-core/audits.

In addition to formal audits, Uniswap V3 has been live since May 2021 with billions of dollars of cumulative TVL and trillions of dollars of cumulative volume. The protocol is among the most battle-tested AMMs in production.

⚠️ Don't reference V2 or V4 audits - those are different protocols and don't apply to Kumbaya.

Trust model

What's enforced by the contracts (no admin can override):

  • User funds are non-custodial. Tokens move directly between traders and pool contracts; LP positions are NFTs held by the user. Launchpad launches don't custody the token.

  • Creator address is immutable. FireLaunch.getLaunchState(token).creator is set at ignite time and cannot be changed. The off-chain "Claim" flow on kumbaya.xyz is metadata-only.

  • Pool init code hash is fixed. All Kumbaya V3 pools deploy with 0x851d77a4…628a3da7.

  • Streaming recipient list can be permanently locked. FireRegistry.lockStreamingRecipients() is irreversible. Once called, the post-graduation creator share is fixed forever - see Fees and credits.

What's governance-tunable (you should read live values, not trust JSON snapshots):

  • gracePeriodDuration, forceGraduationDelay, burnCountdownDuration, fuelVestedBps, the requiredFeeTier / requiredSkimBps / requiredVestingDuration registry pins.

  • Streaming recipient list and total-bps share, until locked.

  • Protocol fee-recipient and guardian addresses.

Read these on-chain via the snippets in Live registry config rather than trusting any documentation snapshot.

What's not in scope

  • Arbitrary third-party tokens that aren't deployed through the Kumbaya launchpad. Tokens launched via FireLaunch.ignite() are in scope - every launch is a FireToken with the audited bytecode, no custom admin powers, no per-launch divergence. The risk surface only opens up for ERC-20s deployed outside the launchpad (e.g. a token someone manually imports into the Kumbaya UI by pasting an address). See the Unknown tokens warning.

  • Off-chain services (frontend, exchange-api, client-api, search-service, indexer). These are non-custodial - they can't sign transactions on a user's behalf - but bugs there can affect what data users see. They're outside the audit scope.

Reporting a vulnerability

Email support@kumbaya.xyz with details and a proof of concept if you have one. Please don't disclose publicly until we've coordinated a fix.

Where to next

PreviousOverviewNextOverview

Last updated