A newly filed TTSwap security report alleges that liquidity providers can redirect part of the protocol’s withdrawal fee distribution back to themselves by supplying their own wallet as the transaction’s Gate address, potentially reducing revenue that would otherwise accrue to the protocol treasury.
GitHub issue #301, opened at 04:42 UTC on September 25, targets the v2.0.0 implementation of TTSwap_Market.disinvestProof(). The report remains open and, at the time of review, had no maintainer response. There is also no evidence presented that the technique has been used against the live protocol.
The researcher says the behavior was reproduced locally with Foundry rather than executed against TTSwap’s Phase 1 on-chain bug-bounty range.
The issue centers on the _gate parameter supplied when an LP withdraws liquidity. TTSwap uses a multi-party fee model under which profit can be distributed among LPs, operators, Gates, referrers, customers and the protocol.
Project documentation describes the Gate role as a frontend, aggregator or portal operator serving as a separate participant in that fee-sharing structure.
The Withdrawal Function Does Not Reject a Self-Selected Gate
The relevant v2.0.0 code supports the central part of the report.
When disinvestProof() is called, TTSwap verifies that the supplied trader corresponds to the caller and retrieves the LP’s referral address. The contract also checks whether the supplied Gate address has been banned.
What it does not appear to do is reject a Gate address simply because that address is the withdrawing LP.
After those checks, the Gate address flows into the protocol’s fee-allocation logic. In the branch where a Gate exists but no referral is active, L_Good.allocateFee() assigns the relevant operator and customer fee components to commission[_gater].
If the withdrawing LP supplied their own address as the Gate, that commission balance is therefore credited to the same address that is withdrawing.
The withdrawal function subsequently checks the caller’s accumulated commission and transfers it out during the same transaction, meaning the disputed fee share does not simply remain as an accounting entry.
The reporter’s three-way Foundry test compared a withdrawal with no Gate, one with the LP acting as their own Gate and one using a genuine third-party Gate. In the test fixture, the self-selected LP received an additional 2,236,018 units. The independent Gate received 2,236,017 units in the control case.
The one-unit difference was attributed to TTSwap’s commission sentinel mechanism, under which a minimal balance remains stored rather than the slot being completely cleared.
The Reporter Also Flags a Self-Controlled Referral Path
The report argues that the economics could become more favorable to an LP controlling multiple addresses.
TTSwap does explicitly prevent an address from registering itself directly as its own referral. However, its code allows a different recipient address used during a qualifying buyGood interaction to become the trader’s referral if no referral has previously been recorded.
The researcher argues that an LP could therefore use a second wallet they control as the referral while continuing to use their original wallet as the Gate, allowing additional parts of the fee split to remain within wallets under common control.
That escalation has not been confirmed by TTSwap maintainers, and no live transaction demonstrating it was included in the report.
The distinction matters. Unlike incidents such as the Payy bridge exploit, there is currently no identified drain, attacker transaction or demonstrated loss of user principal tied to issue #301.
V2.0.0 Is Publicly Documented, but Current Capital at Risk Is Unclear
TTSwap’s public documentation identifies Market and Token v2.0.0 as the protocol baseline and lists an Ethereum mainnet Market Proxy at 0x8E2FF92834C75D3132ad5CED6482E660822f5EF6.
Separately, the protocol’s Phase 1 bug-bounty documentation describes a staged on-protocol range intended to contain approximately 4,000 USDT or equivalent assets across multiple funding tranches.
That figure should not be treated as the amount currently exposed to this reported issue. TTSwap explicitly says the live balance depends on funds already injected minus any settlements or extractions, while portions of the Phase 1 documentation still contain placeholder contract and scheduling fields.
A current dollar value at risk therefore could not be established from the public program documentation alone.
More importantly, this particular issue does not appear to give an LP arbitrary access to all assets held by the market contract. Its claimed economic effect is narrower: diverting part of the profit fee allocation during the LP’s own withdrawal.
This Looks More Like a Revenue-Integrity Bug Than a Pool-Drain Bug
That makes the investor implications different from the usual DeFi exploit headline.
If the report is correct, the immediate concern is not that an attacker can empty TTSwap’s pools. It is that the protocol may not be enforcing the economic identities on which its fee model depends.
A Gate commission only has a distinct economic purpose if a Gate is actually a separate participant providing distribution, aggregation or frontend services. If an LP can nominate themselves without permission, part of what appears to be protocol-controlled fee economics becomes optional from the LP’s perspective.
That can matter even when the amounts involved are small.
Protocols use fee-sharing models to attract different participants while preserving revenue for treasury operations, development and token economics. TTSwap’s documentation says its protocol treasury is used for buyback budgets. Systematic leakage from that bucket would therefore affect more than a single withdrawal.
The situation also illustrates why a locally reproducible vulnerability should not automatically be reported as an active exploit. Dave Finances made the same distinction when examining the FomoPeek kernel exploit framework: proving that a security mechanism can be abused is different from establishing that users have already suffered losses.
The More Important Question Is Whether Gate Identity Is Enforced at All
The obvious patch is straightforward: prevent the withdrawing LP from simultaneously being supplied as the Gate.
But that would solve only the clearest version of the problem.
If Gate commissions are intended exclusively for genuine external frontends and aggregators, simply requiring _gate != msg.sender does not prevent an LP from supplying another wallet they control.
The deeper design question is therefore whether the Gate role is supposed to be permissionless at the smart-contract level or whether the contract should verify that an address has actually been approved for that role.
That question becomes more important when referral relationships can also direct fee shares toward separate addresses. A system can prevent literal self-referral while still allowing economically self-controlled identities unless there is some stronger registration or authorization layer.
This type of identity-versus-address problem regularly appears in decentralized systems: smart contracts are very good at proving which wallet called a function, but far less capable of determining whether two apparently independent wallets ultimately belong to the same person.
Historic Withdrawals Are Now the Key Evidence
The next useful evidence is on-chain rather than theoretical.
TTSwap’s withdrawal event records both the Gate and trader addresses. That means historic disinvestProof activity can be reviewed for transactions where the two addresses matched directly.
More complicated self-controlled referral structures would be harder to establish because common ownership between wallets cannot normally be inferred from an address relationship alone.
The difference between a latent bug and an economically meaningful incident will therefore depend on what historical withdrawals show, how much profit was actually subject to the affected fee paths and whether the currently deployed implementation still contains the reported behavior.
That distinction has become increasingly important across crypto security reporting. A compromised mechanism can remain dormant for months, while incidents such as the SingularityNET bridge attack show how quickly a vulnerability becomes a materially different story once real transactions and losses appear.
For now, issue #301 is best understood as a reproducible economic-accounting concern in TTSwap’s withdrawal logic, not a confirmed theft. The code path supports the reporter’s central claim, but the questions investors should watch next are whether maintainers confirm the finding, whether the live implementation is affected, whether a patch changes Gate authorization and whether historical withdrawals reveal that anyone was already using the behavior before it was publicly documented.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.