Smart Contract Analysis Statement

Contract Analysis

This statement covers a re-audit. The TruderRouter contract was reviewed once before, twenty-seven items were reported, and the project has since rebuilt the contract and redeployed it at three new addresses on Ethereum, Base and BNB Smart Chain. This review examines those new deployments, checks each previous item to see whether the fix works rather than merely exists, and looks for anything the rebuild introduced.

The contract is still not a token. It is a payment routing contract: it accepts native currency or a third-party token from a sender, forwards the bulk of it to a recipient, forwards a fee to the project treasury, and records what it did as an event. It has no supply of its own, no balances, no allowances and no transfer function, which means the usual token questions - can it mint, can it burn, can it blacklist an address, can it lock holdings - do not apply here, because the corresponding code does not exist. Anyone assessing this contract should read it as a payment rail rather than as an asset.

The contract is 147 lines of application code resting on a widely used and extensively reviewed open-source contract library. Nothing about the project's own description was taken on trust. All sixteen source files are identical across the three networks, the published interfaces are identical, the deployed code is identical, and a local rebuild reproduces the deployed code byte for byte on each chain, including the trailing metadata. Every one of the fifteen bundled library files was compared against the official public release and found identical, which matters because the correctness of one of the fixes depends entirely on the exact behaviour of two of those files. Real payment calls were also simulated against the live code on each network to confirm the deployed contract behaves as its published source says, and those simulations independently prove that a newer processor feature the rebuild now depends on is genuinely available on all three chains.

The engineering work is good, and most of it is genuinely fixed. Of the twenty-seven previous items, nineteen are fully resolved and three are partially resolved. Every cost optimisation was carried out. Every code quality item bar two was carried out. Three of the four moderate issues were addressed in whole or in part, and the fixes hold up under testing rather than only on paper: each one was re-run against the exploit that originally demonstrated the problem. Where the previous report insisted that a particular fix be proven by measurement rather than argument, it was measured - the gas amplification attack that a hostile recipient could previously mount has been reduced from more than fourteen million gas to within a third of one percent of the theoretical minimum.

No critical and no high severity issues were identified. One moderate issue is nonetheless the most important item in this statement. It is not a coding error. The rebuild correctly split the administrative role away from the fee treasury, which is exactly what was asked for, but the administrative role was then handed to a single ordinary wallet address rather than to the multisig. The previous review identified the two-of-three multisig as the single strongest control in the whole deployment. That control has been taken off the administrative path: the multisig now receives the fees but has authority over nothing. One leaked key is now enough to redirect every future fee, halt the service, sweep whatever the contract is holding to any destination, or permanently destroy all administrative control. Previously two of three keys were required, and the only place funds could be sent was the multisig itself.

To be precise about what is not at risk: user funds remain safe. The contract still has no code path that can move tokens from any account other than the one calling it, so users who grant unlimited spending permission cannot be drained by a compromised administrator, and the recipient of a payment is chosen by the sender and cannot be altered. Both properties survived the rebuild intact and were re-confirmed by testing. What is exposed is fee revenue, service availability, and anything the contract happens to be holding at the time.

The good news is that this needs no new deployment and no code change. The mechanism to fix it is already built into the contract and already tested: ownership can be handed to the existing multisig through a two-step transfer, and because the transfer only completes when the multisig accepts it, the process cannot go wrong. Doing so would also exercise the multisig for the first time, which closes a separate long-standing concern at no extra cost. At the time of review the contracts had not processed a single payment - the Ethereum deployment has exactly one transaction, its own creation - so this is the least costly possible moment to act.

Ownership Privileges

Ownership is no longer permanent, which is a substantial improvement over the previous deployment. The owner can now be changed, and the fee destination can now be changed. The owner is currently a single ordinary wallet address rather than a multisig, and that address holds every privilege the contract has. The owner can:

• Redirect all future fee revenue to any address, in a single transaction, taking effect immediately with no delay and no second signature. Because payments are visible before they are processed, this can also be aimed at one specific large payment.
• Halt all payments on a given network. This stops the service but puts no funds at risk, because the contract is a pass-through that holds nothing.
• Sweep the contract's balance of native currency or of any single token to any destination of their choosing. In the previous contract funds could only ever be sent to the multisig, so a compromised administrator could relocate but not steal; that is no longer the case. The change was necessary - without it a token issuer could freeze the treasury and strand funds permanently - but it widens the consequences of a key compromise.
• Permanently destroy all administrative control, in one transaction, with no confirmation step and no way back. The standard renounce function was inherited from the library and left enabled. Should it ever be called, the treasury could never be changed again, nothing could ever be recovered, the emergency stop could never be used, and no replacement owner could be appointed. Payments would continue working normally throughout, so nothing about the contract's behaviour would signal that all recovery capability had been lost. In effect this would restore the exact permanence the rebuild was meant to remove, but with no remedy.
• Hand ownership to a new address through a safe two-step process, where the recipient must accept before the transfer takes effect. A mistyped destination therefore cannot strand the contract. This was verified by testing.
• The owner still cannot touch user funds or user approvals. This is the most important limitation on the role and it survived the rebuild. The contract always draws funds from the account calling it, so spending permission granted to this contract remains under the sole control of the account that granted it.
• The owner cannot alter where a payment goes. The recipient is chosen by the sender. The principal always reaches its intended destination; only the fee portion is under the owner's influence.
• The owner cannot upgrade, replace or alter the contract's logic. There is no proxy, no delegated call and no initializer. This was confirmed by automated checking and independently by the exact match between the deployed code and a direct build of the published source. One point of caution for readers: a comment in the published source incorrectly states that the owner can upgrade the contract. That comment is wrong and is reported as an item to correct.
• The owner cannot mint, burn, blacklist, freeze balances, or set or raise a fee rate. None of that code exists. The fee ceiling is a fixed value written into the code with no setter and no upgrade path, and it was mathematically proven that no accepted payment can ever exceed one tenth of its gross amount.

A separate operational concern applies to the same address. The owner wallet holds very little native currency - enough to pay for an emergency stop only while network fees stay below roughly four gwei on Ethereum and roughly a quarter of a gwei on BNB Smart Chain. Both are ordinary rather than extreme levels. Since network congestion and on-chain incidents tend to coincide, the emergency stop may be unaffordable precisely when it is most needed. The multisig, meanwhile, has still never executed a transaction on any network, so the required quorum has never actually been assembled.

Security Features

The rebuilt contract implements a materially stronger set of security features than its predecessor:

• The fee destination is now separate from the administrative role, and both can be changed. The previous contract fixed the fee destination permanently at deployment, which was reported as a moderate issue and is now closed.
• An emergency stop was added. Both payment functions can be halted, while the recovery function deliberately remains available during a stop, so a halted contract does not also become an unrecoverable one. Both behaviours were mathematically proven rather than only tested.
• Ownership transfer is two-step, so ownership cannot be lost to a mistyped address, and a pending transfer can be cancelled.
• The recovery function now takes an explicit destination and no longer fails when there is nothing to recover. Combined with the changeable treasury, this closes the scenario in which a hostile token issuer could freeze the treasury and permanently trap funds - demonstrated closed by recovering funds and resuming payments after a simulated freeze.
• Recovery still operates on one token per call rather than looping over a list. This is the right choice and was preserved: a loop would allow a single frozen asset to block the recovery of every other asset.
• The reentrancy guard was modernised to use a newer, cheaper mechanism, and it was confirmed working on all three live networks rather than assumed from documentation. Hostile recipients, a hostile treasury and hostile token callbacks were all used to attempt re-entry into every entry point, and every attempt was rejected. The tests fail loudly if the attempts ever stop actually occurring, rather than passing vacuously.
• No function anywhere writes to the contract's memory after making an external call, so the ordering mistake that causes most reentrancy vulnerabilities is absent by construction, and there is no way for an outside observer to read a partially updated state.
• The gas amplification weakness reported previously is fixed, and the fix was verified by direct measurement across four payload sizes rather than by reading the code.
• Input validation was tightened throughout. Zero amounts, zero addresses, payments to the contract itself and payments to the token contract are all now rejected with clear, specific errors instead of failing silently or obscurely.
• The token path still measures the contract's own real balance change instead of trusting the requested amount, which keeps it correct for tokens that tax their own transfers or rebase, and neutralises manipulation based on inflating the contract's balance beforehand.
• The contract still cannot pull a third party's spending permission under any circumstances.
• All arithmetic remains protected by the compiler's built-in overflow checks. The contract contains no blocks that opt out of those checks, no loops, no inline assembly, no delegated calls, no self-destruct, and no dependence on the transaction originator or on block timestamps. It also has no function for receiving plain transfers, so currency sent to it by mistake is rejected rather than silently absorbed.
• The compiler optimiser is now enabled, and the compiler target is now stated explicitly rather than left to a default. Payments cost meaningfully less than before: about twenty-one percent less on the native path with a fee, twenty-seven percent less without one, and the deployed code is twenty-nine percent smaller.
• Every privileged action emits an event, including the initial setup, which makes the contract straightforward to monitor.
• Correctness was established three independent ways and none produced a failure: fourteen mathematical proofs across the full range of possible inputs, eight behavioural properties each checked over 32,768 randomised call sequences, and sixty-four tests including working demonstrations of every issue reported here.

Points Requiring Attention

No critical and no high severity issues remain open. Five moderate issues, five minor ones, five code quality observations and one cost note do. The full report sets each out with a reproduction and a recommended fix. In order of importance:

• Hand ownership to the existing multisig on all three networks. This is the single highest-value action available, it requires no new deployment and no code change, and it uses a mechanism already built into the contract and already tested. It also proves the multisig quorum works for the first time. Do it before any value flows.
• Fund the owner wallet and every multisig signer with enough gas on every network to act during a fee spike, not just at today's prices. An emergency stop that cannot be paid for is not an emergency stop.
• Disable the renounce function in any future version, and in the meantime treat it as a transaction that must never be approved. One call would permanently destroy all recovery capability while leaving payments running normally, so the failure would be silent.
• Add a published delay to fee redirection. This can be done without redeploying, by placing the owner behind a standard delay contract controlled by the multisig. The emergency stop should stay outside the delay.
• Determine, in writing, whether any backend or accounting system credits balances, settles invoices or triggers payouts on this contract's payment records. The project has chosen not to restrict which tokens may be routed, which is a legitimate decision for a permissionless product and is respected here. It does mean, however, that anyone can still cause the contract to emit a complete, correctly formed payment record for value that never moved. Nothing is lost on-chain when this happens. The risk sits entirely at the boundary with the project's own systems, and if those systems act on these records then independent verification becomes mandatory rather than advisable. This question was asked in the first review and has still not been answered; it is the one item whose answer changes a severity rating.
• Report the amount the recipient actually received rather than the amount dispatched. For tokens that tax their own transfers these differ, measured here at 855 units claimed against 812.25 delivered. The project declined a related change on the grounds that it would break compatibility with the mobile applications, which is a fair objection to that change - but it does not apply to this one, which needs no interface change at all and so forces no app release.
• Note that the compatibility claim holds for the two payment functions but not for the contract as a whole. The payment functions are unchanged, so no app release is required and that goal was met. An administrative lookup and the old recovery function were removed, however, and the recovery event changed shape. Any dashboard, indexer or back-office script reading those will fail silently against the new deployments.
• Correct the published documentation. Two comments in the verified source are factually wrong - one states the contract can be upgraded, which it cannot, and one describes a ten percent fee where the reality is a caller-chosen fee with a ten percent ceiling and no minimum. These sit in the source that three block explorers display, so they are the version most third parties will read.
• Decide the fee model explicitly. The fee is still supplied by whoever calls the contract, and the code enforces only a ceiling. Anyone constructing the transaction themselves routes value at no cost. Fee income is therefore not enforced by the contract and depends on users choosing the official client. Either compute the fee inside the contract from a stored rate, or accept that it is voluntary and stop describing it as a fee.
• Retire the three superseded deployments from every reference, and monitor them. They remain live, unpaused and unpausable, with none of the new protections, so any stale link or saved address keeps working.

The contract as deployed is materially healthier than its predecessor and the code-level work is sound. If the operational recommendations above are carried out - the ownership handover, the funding and the monitoring - no further code review is required for the code now running, and this report covers it. A future deployment adding a delay, disabling renunciation and correcting the reported amount would warrant a focused review of those three areas rather than a full audit.

Note - This Audit report consists of a security analysis of the TruderRouter smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the TruderRouter team. Other contracts associated with the project were not audited by our team. In particular, the off-chain systems that consume this contract's events - the backend, the interface and any indexing infrastructure - were outside the scope of this review, and one of the findings above cannot be given a final severity rating without knowing how those systems treat the contract's payment records. A security review reduces risk but cannot prove the absence of every vulnerability, and the conclusions here apply to the code as deployed at the addresses stated in the full report: any change to the source, the compiler settings, the ownership or treasury configuration or the surrounding systems invalidates them. This statement is not an endorsement of the project, its operators or its commercial prospects, and it is not financial advice. We recommend investors do their own research before investing.