1 Executive Summary

ImplicitEx is a non-custodial USDC transfer interface operating on Polygon (chain ID 137). It allows a sender to transfer USDC to a recipient address they specify. A platform fee of 1% is charged on each transfer. The production portal currently limits transfers to 250.00 USDC, making the highest fee reachable through the supported interface 2.50 USDC. The application does not hold, route through, or control user funds beyond what the user explicitly authorizes through their own wallet.

This document was prepared in response to Blockaid tickets #1290666 and #1290665 concerning the classification of the ImplicitEx USDC approval request as deceptive. The sections below document the complete transaction lifecycle, deployed security controls, fee mechanics, and independently verifiable on-chain evidence available for review.

Why the wallet requests an approval

USDC is an ERC-20 token. ERC-20 tokens cannot be spent by a smart contract without the token holder first granting a spending allowance to that contract. The approve() call is the standard ERC-20 mechanism for establishing this permission. The allowance requested equals exactly the amount the user has already reviewed on-screen: the recipient amount plus the platform fee. No additional buffer is requested.

Why the approval amount is exact rather than unlimited

Many applications request an unlimited or large blanket allowance to avoid requiring a new approval on each transaction. ImplicitEx does not do this. The allowance request is calculated per transaction and covers only the current transfer total. After the contract calls transferFrom(), the allowance returns to zero. The user's residual exposure is zero after each transaction completes.

Why the contract is non-custodial

The smart contract does not hold funds at any point in the transfer. The transferWithFee() function issues two safeTransferFrom() calls in a single atomic execution: one from the sender directly to the recipient, and one from the sender directly to the treasury. The contract is not an intermediate holder. If either call fails, the entire transaction reverts and no funds move.

2 System Architecture

2.1 Component map

User Browser
     │
     ▼
ImplicitEx Transfer Portal
(https://implicitex.com  /  https://portal.implicitex.com)
     │
     ├──── Reads on-chain state via public JSON-RPC
     │     (polygon-bor-rpc.publicnode.com, chain ID 137)
     │
     ▼
MetaMask or WalletConnect-compatible wallet
     │
     ├──── Prompt 1 of 2: User signs USDC approve() for exact total debit
     │
     └──── Prompt 2 of 2: User signs transferWithFee() execution
               │
               ▼
    ImplicitExTransfer contract
    0x5015841D6E665e63Ea174aD6b8FeF854026dE0C0
               │
               ├────► Recipient (address entered by user)
               │       Receives: transfer amount
               │
               └────► Treasury
                       0xa7cE4232811021d2Dd01f4f0f264Df2427ab3919
                       Receives: platform fee (1% of transfer amount)

2.2 Domains

2.3 Network parameters

3 Transaction Lifecycle

The following describes a 1.00 USDC transfer. The same sequence applies at all amounts within the configured limits.

3.1 User input

The user enters a recipient Ethereum address and a transfer amount. No wallet connection is required at this stage.

3.2 Pre-flight validation (no wallet prompt)

The portal calls previewTransfer(sender, amount) on the contract. This is a read-only view call. It returns the calculated fee, total debit, sender USDC balance, current allowance, and a boolean indicating whether the transfer can proceed.

The portal also validates locally:

• Connected network matches Polygon mainnet (chain ID 137)
• Recipient address is non-zero and is an externally owned account (EOA), not a contract
• Amount falls within the configured transfer limits (1.00 USDC floor, 250.00 USDC ceiling)

No wallet action is initiated during this phase.

3.3 Review screen

Before any wallet prompt is triggered, the portal presents a summary of the pending transaction:

Recipient:      0xe0B02A6d...796B
Amount:         1.000000 USDC
Platform fee:   0.010000 USDC
Total debit:    1.010000 USDC
Network:        Polygon

The user must explicitly confirm past this screen to proceed. No wallet prompt has been issued at this point.

3.4 USDC spending approval (wallet prompt 1 of 2)

The portal calls approve(contractAddress, totalDebit) on the Circle USDC token contract (0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359).

MetaMask surfaces this as a "Set a spending cap for your USDC" dialog. The spending cap displayed equals the exact total debit shown on the review screen — 1.010000 USDC in this example. During the observed 2026-07-23 transaction documented in Section 7, MetaMask displayed a Blockaid warning at this stage.

The approval amount is not unlimited. It is not padded with a buffer. It matches the review screen figure precisely.

3.5 Transfer execution (wallet prompt 2 of 2)

After the approval transaction is confirmed on-chain, the portal calls transferWithFee(recipientAddress, 1000000) on the ImplicitExTransfer contract. MetaMask surfaces this as a separate contract interaction confirmation. The user must approve this second step independently.

3.6 On-chain execution

The contract executes atomically:

USDC.safeTransferFrom(sender, recipient, 1000000)   // 1.000000 USDC → recipient
USDC.safeTransferFrom(sender, treasury, 10000)      // 0.010000 USDC → treasury fee

If either call reverts, the entire transaction reverts. The contract retains nothing.

3.7 Confirmation

The portal polls for block confirmation. It displays a pending state until the transaction is confirmed on-chain, then transitions to a confirmed state. It does not report success at submission time.

3.8 Economic summary — 1.00 USDC example

4 Trust Boundaries

4.1 What the application can and cannot do

4.2 User authorization sequence

Every on-chain action requires a private-key signature from the user. The wallet mediates this. The portal cannot initiate, sign, or bypass any wallet action.

Portal      →  constructs transaction parameters
Wallet      →  displays parameters to user
User        →  signs or rejects
Blockchain  →  executes only if user signature is valid and allowance is sufficient

The portal has no mechanism to sign transactions on the user's behalf, store private keys, or initiate any transaction without explicit user action at the wallet prompt.

5 Smart Contract Behavior

5.1 Core function: transferWithFee(address recipient, uint256 amount)

This is the only function that moves funds. Execution sequence:

1. Rejects call if contract is paused (whenNotPaused)
2. Applies reentrancy guard (nonReentrant)
3. Rejects zero-address recipient
4. Rejects contract addresses as recipients (recipient must be EOA)
5. Enforces minimum transfer amount
6. Enforces transfer precision (amount must be divisible by configured precision)
7. Calculates fee: (amount × feeBasisPoints) / 10000
8. Calls safeTransferFrom(sender, recipient, amount)
9. Calls safeTransferFrom(sender, treasury, fee)
10. Emits TransferExecuted event

5.2 View function: previewTransfer(address sender, uint256 amount)

Read-only. Returns five values without any state change or gas cost beyond the RPC call:

The portal calls this function before presenting the review screen and again immediately before initiating the approval step, to confirm on-chain state has not changed between input and execution.

5.3 Fee constants (compile-time constants; not administratively configurable)

The deployed contract does not enforce an absolute per-transfer fee ceiling in USDC terms. The fee formula is (amount × feeBasisPoints) / 10000 with no cap on the resulting amount. The production portal's 250.00 USDC transfer ceiling (portal-enforced, not contract-enforced) limits the maximum fee reachable through the supported interface to 2.50 USDC. See Section 9 for disclosure of the future fee cap policy.

5.4 Events emitted

5.5 Owner-controlled parameters

5.6 Ownership model

The contract uses OpenZeppelin Ownable2Step. An ownership transfer requires two transactions: the current owner nominates a new address, and that address must explicitly accept. This prevents accidental or unilateral ownership loss.

Current owner: 0x776A0D6b9F96445A38303F56d5B923e6d1FF8E97

6 Deployed Security Controls

The following controls are active in the currently deployed contract and portal. "Deployed" means the control is live in production and was verified during the Gate 4 controlled smoke (2026-06-15). "Portal-enforced" means the control is implemented in the frontend JavaScript and does not rely on the contract.

7 Observed Transaction Flow

This section documents a production portal transaction observed on 2026-07-23. It follows the user-visible lifecycle from portal initialization through transaction submission. The Blockaid warning is recorded as one observed event within the ERC-20 approval stage.

7.1 Portal initialization and wallet connection

7.2 Recipient validation and fee calculation

7.3 Explicit user confirmation

7.4 ERC-20 approval request and observed wallet warning

The portal requested a USDC allowance equal to the current transfer total. The requested cap was not unlimited and did not include an additional buffer.

7.5 Separate transfer transaction request

After the approval transaction completed, the portal issued the separate transferWithFee() request. This second wallet prompt identified Polygon, portal.implicitex.com, and the ImplicitEx contract.

7.6 Transaction submission and Activity record

7.7 Submitted-state proof packet

The exported proof packet records both wallet-stage and transaction-stage identifiers:

8 Internal Verification Evidence

8.1 Test suite results

8.2 Contract test coverage — areas exercised

The contract test suite (59 tests, Hardhat / Chai) covers the following scenarios:

• Constructor validation — zero-address rejection for USDC and treasury; fee cap enforcement on initial fee basis points
• Treasury management — address update, event emission, zero-address guard
• Fee configuration — floor boundary, cap boundary (MAX_FEE_BPS), event emission
• Transfer execution — happy path, fee routing correctness, direct balance checks
• Pause and unpause — state enforcement (transfers blocked when paused), event emission
• Ownership transfer — two-step requirement (acceptance required)
• Recipient validation — zero-address rejection, contract-address rejection
• Reentrancy protection — reentrant call behavior under nonReentrant
• previewTransfer() accuracy — fee and total-debit calculation
• rescueERC20 — USDC rejection, non-USDC token recovery
• Allowance and balance edge cases — insufficient balance, insufficient allowance

8.3 Gate 4 — Mainnet controlled live smoke (2026-06-15)

A controlled transfer was executed on Polygon mainnet from the production frontend. This is the primary on-chain evidence of correct fee routing and zero-custody behavior.

Date:           2026-06-15
Network:        Polygon mainnet, chain ID 137
Site:           https://implicitex-236f2.web.app
Contract:       0x5015841D6E665e63Ea174aD6b8FeF854026dE0C0

Sender:         0x2489587C9da6EaB970a5479BA70273BA37961221
Recipient:      0xe0B02A6d9738aa36eE48004211E264b7a815796B
Treasury:       0xa7cE4232811021d2Dd01f4f0f264Df2427ab3919

Amount:         1.000000 USDC
Fee:            0.010000 USDC  (100 basis points)
Total debit:    1.010000 USDC

Transaction:    0x37fd733a7f1854740bf702aa5bf59794f4ebab0f39d2a84fb2c231c29df622d9
Block:          88565097

Polygonscan:    https://polygonscan.com/tx/0x37fd733a7f1854740bf702aa5bf59794f4ebab0f39d2a84fb2c231c29df622d9

The Polygonscan ERC-20 token transfer log for this transaction shows exactly two transfers originating from the same sender address: 1.000000 USDC to the recipient and 0.010000 USDC to the treasury. No additional transfers are present.

8.4 Gate 5 — Public launch attempt (2026-06-18)

Transfers were enabled for a first-user walkthrough on 2026-06-18. The walkthrough was halted at the USDC approval step (prompt 1 of 2) due to the Blockaid "deceptive request" classification. The transfer execution step (prompt 2 of 2) was not reached. No funds moved. Transfers were returned to disabled standby state on the same date.

The false-positive report was submitted to Blockaid on 2026-06-18 for both implicitex.com and implicitex-236f2.web.app.

9 Known Limitations

The following limitations apply to the currently deployed version. They are stated here for completeness and accuracy.

10 Reviewer Reproduction Procedure

The following verification steps can be completed independently by a Blockaid analyst without wallet connection or access to the ImplicitEx codebase.

10.1 Contract source

The deployed contract is at 0x5015841D6E665e63Ea174aD6b8FeF854026dE0C0 on Polygon mainnet (chain ID 137).

The source is verified on Polygonscan. The matched Solidity source, compiler version, optimizer settings, ABI, and constructor arguments are publicly visible at:

https://polygonscan.com/address/0x5015841D6E665e63Ea174aD6b8FeF854026dE0C0#code

The contract's verified-source status was confirmed during the deployment procedure on 2026-05-22. A Hardhat verify invocation returned that the contract had already been verified on the block explorer. Polygonscan reports that the published source compiles to bytecode matching the deployed contract, and publicly exposes the matched Solidity source, compiler configuration, ABI, and constructor arguments for the deployed address. A reviewer can inspect these directly on Polygonscan without any supplemental file attachment.

10.2 Transaction verification

The Gate 4 controlled smoke transaction is publicly accessible:

https://polygonscan.com/tx/0x37fd733a7f1854740bf702aa5bf59794f4ebab0f39d2a84fb2c231c29df622d9

In the "ERC-20 Token Txns" tab on Polygonscan, two transfers are visible originating from the same sender:

• To 0xe0B02A6d...796B — 1.000000 USDC (recipient)
• To 0xa7cE4232...3919 — 0.010000 USDC (treasury fee)

10.3 Contract state — read-only queries

The following state can be read from the deployed contract via Polygonscan "Read Contract" or any JSON-RPC client, without connecting a wallet:

10.4 Live approval flow — reviewer reproduction

Transfers are currently enabled on Polygon mainnet. The approval flow can be reproduced as follows:

1. Connect a Polygon wallet with at least 2 USDC to https://portal.implicitex.com
2. Enter any valid EOA recipient and an amount (e.g. 1.00 USDC)
3. Proceed past the review screen
4. Observe the MetaMask spending-cap prompt

The spending-cap field will display the exact total debit — not an unlimited amount, not a padded amount.

11 Addresses and Evidence Inventory

11.1 Deployed addresses — Polygon mainnet (chain ID 137)

11.2 Deployment record

11.3 Evidence inventory