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 a Blockaid classification concerning the ImplicitEx USDC approval request as a deceptive request. The sections below document the complete transaction lifecycle, deployed security controls, fee mechanics, and independently verifiable on-chain evidence available for review.

The July 23 transaction is the original Blockaid-observed event and is supported by contemporaneous screenshots and its public on-chain record. The July 24 approval-path and transfer-only transactions are separate controlled certification runs whose original browser-exported proof packets were preserved byte-for-byte at time of export.

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 contract limits the fee rate to a maximum of 100 basis points but does not enforce an absolute USDC transfer or fee-value ceiling. The fee formula is (amount × feeBasisPoints) / 10000 with no cap on the resulting USDC amount. The supported production portal separately limits transfers to 250.00 USDC, making the maximum fee reachable through that interface 2.50 USDC. Direct contract callers are subject to the same deterministic percentage calculation but are not subject to the portal's amount ceiling. 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 the observed transaction flow and independently verifiable on-chain evidence for both supported execution paths. The 2026-07-23 transaction is the original Blockaid-observed event, preserved as a distinct historical record supported by contemporaneous screenshots and its public chain record. The 2026-07-24 approval-path and transfer-only transactions are separate controlled certification runs whose original browser-exported proof packets were preserved byte-for-byte at time of export and are not attributed to the earlier event.

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 On-chain confirmation

After approval, the portal issued the separate transferWithFee() call. The transfer was confirmed on Polygon at block 90,776,572.

7.6 Activity record and on-chain verification

7.7 Production settlement evidence — two execution paths

Two production execution paths were exercised against the deployed system and each is supported by an exact browser-exported proof packet preserved byte-for-byte at time of export. Together they establish that both paths produce a consistent, independently verifiable settlement record.

7.7.1 Original Blockaid-observed approval-path transaction (2026-07-23)

Documents the first-time-user flow visible in Figures 1–12 above. The wallet had no prior allowance; an ERC-20 approval was required. The Blockaid spending-cap warning appeared during the approval step (Figure 8) and did not prevent settlement. This transaction is independently verifiable on Polygonscan. The original browser-exported proof packet for this transaction was not preserved at time of export; the chain record and screenshot evidence stand as the independent verification record.

The approval transaction calldata was independently verified on-chain: selector 0x095ea7b3 (approve), target USDC contract (0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359), spender the ImplicitEx transfer contract (0x5015841D6E665e63Ea174aD6b8FeF854026dE0C0), approved value 1010000 (1.010000 USDC). This value matches the portal review total displayed in Figures 5–8: 1.00 USDC transfer plus 0.01 USDC platform fee.

The transfer transaction emitted two ERC-20 Transfer events from the USDC contract: 1.000000 USDC from sender directly to recipient, and 0.010000 USDC from sender directly to treasury. Both transfers originate from the sender's address. The supported execution path does not route the transferred amount through the ImplicitEx contract.

7.7.2 Approval-path certification run (2026-07-24)

A dedicated approval-path certification run was executed to close the artifact gap. The wallet allowance was zeroed to 0 USDC before execution, forcing the full approval lifecycle. The exported proof packet is the browser-generated artifact, preserved byte-for-byte immediately after confirmation. Reference: APPROVAL-PATH-002.

The exported proof packet for this certification run includes all settlement fields, user-entered metadata, timestamps, and the three evidence sections from the proof-packet.v1 schema. The approval transaction targets the USDC contract with spender set to the ImplicitEx contract and an approved value of exactly 1.01 USDC — matching the disclosed total debit. On the approval-path branch, the exact 1.010000 USDC allowance is fully consumed by the transfer; post-transfer allowance was independently read back on-chain at 0.000000 USDC. Zero residual allowance is a property of the exact-approval branch: a wallet that enters through the transfer-only branch retains whatever valid allowance remains after the 1.010000 USDC deduction.

7.7.3 Transfer-only path transaction (2026-07-24)

Documents the returning-user flow: wallet had an existing allowance of 3.03 USDC established via a direct contract call. The portal detected sufficient allowance and submitted the transfer directly — no approval step, no MetaMask spending-cap prompt, no Blockaid warning. The exported proof packet is the browser-generated artifact, preserved byte-for-byte.

The exported proof packet for this transaction includes all settlement fields, user-entered metadata, timestamps, and the three evidence sections from the proof-packet.v1 schema.

The preexisting 3.030000 USDC allowance decreased to 2.020000 USDC after the transfer — exactly matching the 1.010000 USDC total debit — confirming that the correct amount was consumed and no phantom spending occurred. The remaining 2.020000 USDC is the unused portion of the preexisting 3.030000 USDC allowance. The transfer neither created nor increased the allowance; it consumed exactly the disclosed 1.010000 USDC total debit.

8 Internal Verification Evidence

8.1 Test suite results

8.2 Contract test coverage — areas exercised

The contract test suite (66 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

When the approval path is triggered, MetaMask's spending-cap value will equal the portal's displayed total debit exactly: transfer amount plus the disclosed 1% platform fee, with no additional allowance buffer. For a 1.00 USDC transfer, the spending cap will be 1.01 USDC. The precise classifier basis for Blockaid's warning has not been provided by Blockaid; this packet documents observable behavior and reproducible transaction evidence rather than attributing an unconfirmed cause.

11 Addresses and Evidence Inventory

11.1 Deployed addresses — Polygon mainnet (chain ID 137)

11.2 Deployment record

11.3 Evidence inventory