KaspaKaha is using an in-progress automated market maker to test whether the new draft fungible-token convention can support real DeFi composition. On August 23 the builder said a full AMM on KCC-0020 was almost integrated, reported that swaps, liquidity and farming were live on testnet, and called the work the first conformant build (report).
That first-conformant label is KaspaKaha's claim, not an independent ranking of the specification. The AMM itself is not finished production software, is not on mainnet, and has not been presented as audited. The value of the post is the implementation record: a builder took a Draft convention into a working testnet integration and came back with specific constraints around token-family bounds, covenant size, dispatch semantics, output-state inspection and transaction mass.
KCC-0020 is still a Draft. The Fungible Token Covenant Specification, authored by Sivan Helfer, Michael Sutton and Romain Billot, was created on July 15, updated on August 21, and merged into kaspanet/kccs as a Draft in PR #2 on August 20 (specification, PR #2, reviewed commit). It standardizes token state, the transfer interface, borrowed-receive rules and program information. KCCs are ecosystem conventions. They do not change Kaspa consensus (KCC README).
Two days earlier, KaspaKaha announced a self-contained, dependency-free KCC20 AMM browser client. The builder said the client builds and signs swaps in the browser, the wallet signs only the user's funding input, a relay broadcasts, and no keys leave the machine. It also said a self-test can compare those transactions byte-for-byte with its production builder (SDK announcement). Those remain builder claims. The short artifact link from that post could not be independently resolved for this review, the full SDK was not inspected, and the self-test was not reproduced. Private-key handling was not audited.
The AMM report then ran into the default family bounds. KCC-0020's default configuration declares max_token_inputs: 3 and max_token_outputs: 3. A single pool action that consumes and recreates a small set of token states can still fit in one transaction. Combining more token-state families, such as routing through several pools in one user action, can exceed those counts. The extra hops then have to be split across sequential transactions. If an intermediate hop confirms and a later hop fails, the composition is no longer a one-step atomic trade.
That limit is configurable rather than a universal protocol defect. A non-default token configuration may override maximum token inputs and outputs, and the Program ABI must describe those maxima. KaspaKaha argued that tokens intended for DeFi should consider a larger family size at mint, because the default three-in, three-out bound is a token-configuration choice, not a network rule.
The same integration produced size and semantics questions. KaspaKaha said its pool program reached about 113 KB before manual deduplication because token templates were re-embedded at each validated note, and asked whether a constant-pooling or shared-template mechanism already exists. It also reported a perceived dispatch mismatch: the specification defines a hash-derived dispatch tag, while the reference compiler appeared to emit a one-byte positional branch index.
The builder asked whether output-state read asymmetry is intentional, because an input's state can be inspected while an output can only be asserted as a candidate. It cited an approximately 500,000 mass ceiling and asked whether multi-transaction composition is the intended design once richer flows no longer fit. Those are implementation findings and open questions from KaspaKaha. They are not confirmed defects in the specification.
The draft convention is still being revised. An extended-state fungibility clarification merged on August 27 in PR #16, and a hash-chain borrow front-running change remains open in PR #18 (PR #16, PR #18).
The unresolved engineering choice from the AMM work sits at mint time. A DeFi-bound KCC-0020 token can raise its input and output maxima so multi-pool composition can stay inside one transaction, or builders can treat sequential hops as the normal path once covenant size and mass start crowding a single transaction.
