SwaptoX: Trustless Execution Aggregator

SwaptoX is designed with a Trustless Architecture. Our core philosophy is that users should not need to trust the administrator; they should only need to trust the immutable code. Below is a detailed breakdown of our security model for Grant committees and community voters.

Contract Entry Points

View Functions: getTokenFeeBP, getSwapFeeLadder, getActualSwapAmount, getSwapFeeBP, getFeeLadderDiscount

Admin Functions: setLadderEnabled, setFreeSwapToken, setCustomFeeToken (Capped at 0.3%), setDefaultSwapFee, setWalletAddress, setSwapAddress, setSwaptoXToken, setFeeLadder, transferOwnership

Core Business: swap (Entry), iSwap (Referral Entry), native2Wrapped, wrapped2native

Security Analysis & Risk Mitigation

1. Privileged Access (Admin Misconduct)

Scenario: What if the admin key is compromised or the admin turns malicious?

Defense: The protocol has hard-coded limits. Protocol fees are strictly capped at 0.3%. Admin can only disrupt service availability but cannot steal user funds. There is no "backdoor" to drain authorized tokens.

Result: No direct financial loss to users.
2. Malicious Executor (Entered Contract)

Scenario: Can a malicious swap executor be set to drain funds?

Defense: We follow the industry standard (similar to 1inch/KyberSwap) by separating the Router from the Executor. The contract validates the output balance after execution. If the executor fails to return the expected amount of tokens, the transaction automatically reverts.

Result: Executor cannot withhold funds or return insufficient amounts.
3. Permit Parameter Forgery

Scenario: Can permitData be used to call unauthorized functions?

Defense: The permit function is restricted to specific EIP-compliant selectors (0xd505accf/0x8fcbaf0c). It cannot execute arbitrary logic. Furthermore, all business functions are protected by nonReentrant guards.

Result: Forgery only results in a failed swap, with no impact on other users.
4. Unauthorized transferFrom Attacks

Scenario: Can anyone use the contract's permission to pull user funds?

Defense: The contract is non-upgradeable and lacks delegatecall or arbitrary execution methods. transferFrom is only triggered by the msg.sender for their own transaction. No one, including the admin, can trigger a transfer from a non-active user.

Result: Fund safety is guaranteed by the immutable code.
5. Gas Optimization Strategy

Question: Why use ownerWithdraw instead of automatic fee distribution?

Answer: This is a deliberate choice for Gas Efficiency. Automatic distribution adds significant gas costs to every swap. On networks like Base, we prioritize the lowest possible gas for users. Fees are securely held and batch-withdrawn to reduce overhead.

6. Anti-Reentrancy & MEV Protection

Mechanism: All value-moving functions (Swaps and Withdrawals) are protected by a nonReentrant modifier. Output amounts are strictly verified against user-defined amountMinOut to protect against slippage and sandwich attacks.

7. Referral & Incentive Logic

Logic: We accept the "Sybil" risk where users create multiple wallets to farm referral discounts. This is viewed as a growth incentive that increases protocol volume and liquidity without risking core protocol assets.

SwaptoX: Built for Security. Verified by Logic.