SecurityAudit Scope

Audit Scope

This document defines the scope for security audits of the T402 protocol, including critical code paths, focus areas, and testing recommendations.

Executive Summary

T402 is an HTTP-native payment protocol for USDT/USDT0 stablecoins across multiple blockchains. The audit should focus on:

  1. Signature generation and verification across all chains
  2. Payment verification logic in the facilitator
  3. Replay protection mechanisms (nonces, time windows)
  4. Fee payer safety for sponsored transactions (Solana)
  5. SDK cryptographic implementations in all four languages

Repository Structure

github.com/t402-io/t402/
├── typescript/              # TypeScript SDK (36 npm packages)
│   └── packages/
│       ├── core/           # Protocol types
│       ├── mechanisms/
│       │   ├── evm/        # EVM signing (IN SCOPE)
│       │   ├── svm/        # Solana signing (IN SCOPE)
│       │   ├── ton/        # TON signing (IN SCOPE)
│       │   ├── tron/       # TRON signing (IN SCOPE)
│       │   ├── near/       # NEAR signing (IN SCOPE)
│       │   ├── aptos/      # Aptos signing (IN SCOPE)
│       │   ├── tezos/      # Tezos signing (IN SCOPE)
│       │   ├── polkadot/   # Polkadot signing (IN SCOPE)
│       │   ├── stacks/     # Stacks signing (IN SCOPE)
│       │   └── cosmos/     # Cosmos signing (IN SCOPE)
│       └── ...
├── go/                      # Go SDK
│   ├── signers/            # Signer implementations (IN SCOPE)
│   │   ├── evm/
│   │   └── svm/
│   ├── mechanisms/         # Chain-specific logic (IN SCOPE)
│   │   ├── evm/
│   │   ├── svm/
│   │   ├── ton/
│   │   ├── tron/
│   │   ├── near/
│   │   ├── aptos/
│   │   ├── tezos/
│   │   ├── polkadot/
│   │   ├── stacks/
│   │   └── cosmos/
│   └── ...
├── python/                  # Python SDK
│   └── t402/src/t402/
│       ├── schemes/        # Scheme implementations (IN SCOPE)
│       ├── wdk/            # Wallet signing (IN SCOPE)
│       └── erc4337/        # Account abstraction (IN SCOPE)
├── java/                    # Java SDK
│   └── src/main/java/io/t402/
│       └── crypto/         # Crypto signers (IN SCOPE)
├── services/
│   └── facilitator/        # Facilitator service (IN SCOPE)
└── specs/                   # Protocol specifications (REFERENCE)

In-Scope Components

Priority 1: Critical Path (Must Audit)

ComponentLocationDescriptionRisk Level
EVM Verificationgo/mechanisms/evm/exact/facilitator/Payment verification and settlementCritical
EVM Signersgo/signers/evm/, java/crypto/EvmSigner.javaEIP-712 signingCritical
Nonce Managementgo/mechanisms/evm/, Facilitator DBReplay preventionCritical
SVM Verificationgo/mechanisms/svm/exact/facilitator/Solana payment verificationCritical
Fee Payer Validationgo/mechanisms/svm/Instruction safety checksCritical

Priority 2: High Importance

ComponentLocationDescriptionRisk Level
EIP-712 Hashinggo/mechanisms/evm/eip712.goTyped data hashingHigh
EIP-1271 Verificationgo/mechanisms/evm/verify_1271.goSmart wallet supportHigh
ERC-6492 Parsinggo/mechanisms/evm/erc6492.goCounterfactual walletsHigh
TON Signingtypescript/packages/mechanisms/ton/TON message signingHigh
TRON Signingjava/crypto/TronSigner.javaTRON transaction signingHigh

Priority 3: Important

ComponentLocationDescriptionRisk Level
Python WDKpython/t402/wdk/signer.pyBIP-39 wallet signingMedium
Python ERC-4337python/t402/erc4337/Account abstractionMedium
TypeScript Signerstypescript/packages/mechanisms/*/src/signer.tsClient signingMedium
Java SVM Signerjava/crypto/SvmSigner.javaEd25519 signingMedium

Out-of-Scope

ComponentReason
UI Components@t402/react, @t402/vue - No crypto operations
HTTP Framework Adapters@t402/express, @t402/hono - Wrapper code
CLI ToolsUser interfaces, no crypto logic
Documentation SiteStatic content
CI/CD PipelinesInfrastructure

Critical Code Paths

1. EVM Payment Verification

File: go/mechanisms/evm/exact/facilitator/scheme.go

Function: Verify(ctx, payload, requirements)
├─ 1. Validate scheme = "exact"
├─ 2. Parse EVM payload from bytes
├─ 3. Extract authorization from payload
├─ 4. Get network configuration
├─ 5. Validate recipient matches payTo
├─ 6. Validate amount ≥ required
├─ 7. Check nonce not already used          ← CRITICAL: Replay prevention
├─ 8. Query payer balance                    ← CRITICAL: Sufficient funds
├─ 9. Get token metadata (name, version)
├─ 10. Compute EIP-712 hash                  ← CRITICAL: Correct hashing
├─ 11. Recover signer from signature         ← CRITICAL: Signature validation
├─ 12. Compare recovered address with from   ← CRITICAL: Authorization match
└─ 13. Return VerifyResponse

2. EVM Payment Settlement

File: go/mechanisms/evm/exact/facilitator/scheme.go

Function: Settle(ctx, payload, requirements)
├─ 1. All verification steps (above)
├─ 2. Build transferWithAuthorization call
├─ 3. Estimate gas
├─ 4. Submit transaction                     ← CRITICAL: Correct parameters
├─ 5. Wait for confirmation
├─ 6. Mark nonce as used                     ← CRITICAL: Prevent double-spend
└─ 7. Return SettlementResponse

3. Solana Fee Payer Validation

File: go/mechanisms/svm/exact/facilitator/scheme.go

Function: ValidateTransaction(tx, feePayer, requirements)
├─ 1. Verify exactly 3 instructions
│   ├─ [0] ComputeBudget.SetLimit
│   ├─ [1] ComputeBudget.SetPrice
│   └─ [2] SPL Token TransferChecked
├─ 2. Verify compute price ≤ 5 lamports     ← CRITICAL: Fee limit
├─ 3. For each instruction:
│   └─ Verify feePayer NOT in accounts      ← CRITICAL: Fee payer safety
├─ 4. Verify transfer authority ≠ feePayer  ← CRITICAL: Fee payer safety
├─ 5. Verify token source ≠ feePayer        ← CRITICAL: Fee payer safety
├─ 6. Verify transfer amount = required     ← CRITICAL: Exact amount
└─ 7. Verify destination = payTo ATA        ← CRITICAL: Correct recipient

4. EIP-712 Hash Computation

File: go/mechanisms/evm/eip712.go

Function: HashEIP3009Authorization(domain, authorization)
├─ 1. Encode domain separator
│   ├─ Hash type string
│   ├─ Hash name
│   ├─ Hash version
│   ├─ Encode chainId
│   └─ Encode verifyingContract
├─ 2. Encode struct hash
│   ├─ Hash type string
│   ├─ Encode from
│   ├─ Encode to
│   ├─ Encode value
│   ├─ Encode validAfter
│   ├─ Encode validBefore
│   └─ Encode nonce
├─ 3. Compute final hash
│   └─ keccak256(0x19 || 0x01 || domainSeparator || structHash)
└─ 4. Return hash                           ← CRITICAL: Must match contract

Focus Areas for Auditors

1. Signature Verification

Review Checklist:

  • ECDSA v value adjustment (27/28 conversion)
  • Ed25519 signature format validation
  • Public key recovery correctness
  • Constant-time comparison for signatures
  • Handling of malformed signatures (no panic)

Key Questions:

  • Can an invalid signature cause verification to return true?
  • Are there edge cases in v value handling?
  • Is signature length validated before processing?

2. Nonce Management

Review Checklist:

  • Nonce uniqueness enforcement
  • Race condition handling in nonce checks
  • Nonce storage persistence
  • Nonce format validation (32 bytes)

Key Questions:

  • Can the same nonce be used twice under any circumstances?
  • What happens if nonce storage fails after verification but before settlement?
  • Is there a time-of-check to time-of-use (TOCTOU) vulnerability?

3. Time Window Validation

Review Checklist:

  • validAfter checked correctly
  • validBefore checked correctly
  • Block timestamp vs. system time handling
  • Overflow/underflow in timestamp comparison

Key Questions:

  • Can a signature with validBefore = 0 be valid?
  • What is the maximum allowed validity window?
  • How is clock skew handled?

4. Amount and Recipient Validation

Review Checklist:

  • Amount comparison (≥ required, not just ==)
  • Recipient address validation
  • Checksum address handling
  • Integer overflow in amount calculations

Key Questions:

  • Can an amount of 0 pass validation?
  • Are mixed-case addresses handled correctly?
  • What happens with very large amounts (near uint256 max)?

5. Solana-Specific Checks

Review Checklist:

  • Instruction count validation
  • Instruction order validation
  • Account list completeness check
  • Associated Token Account derivation
  • Compute budget price enforcement

Key Questions:

  • Can additional instructions be added without detection?
  • Can instruction accounts be reordered?
  • Is the fee payer check exhaustive for all instruction types?

6. EIP-1271 and ERC-6492

Review Checklist:

  • Magic value hardcoded correctly (0x1626ba7e)
  • Contract call error handling
  • Gas limit for verification call
  • ERC-6492 magic suffix detection
  • ABI decoding for wrapped signatures

Key Questions:

  • What if the contract returns a different value?
  • Can a malicious contract cause denial of service?
  • Is ERC-6492 unwrapping secure against malformed data?

Testing Recommendations

Unit Tests

// Signature edge cases
func TestVerifySignature_InvalidLength(t *testing.T) {
    // Signatures shorter than 65 bytes
    // Signatures longer than 65 bytes
}
 
func TestVerifySignature_InvalidV(t *testing.T) {
    // v = 0, 1, 26, 29, 30, 255
}
 
func TestVerifySignature_MalleableS(t *testing.T) {
    // s > n/2 (signature malleability)
}
// Nonce tests
func TestNonceUniqueness(t *testing.T) {
    // Same nonce, same payer
    // Same nonce, different payer
    // Concurrent nonce usage
}
// Time window tests
func TestTimeWindow_BoundaryConditions(t *testing.T) {
    // validAfter = now (exact boundary)
    // validBefore = now (exact boundary)
    // validAfter = validBefore
    // validAfter > validBefore
}

Integration Tests

// Full payment flow on testnet
func TestFullPaymentFlow_EVM(t *testing.T) {
    // 1. Generate valid payment
    // 2. Verify payment
    // 3. Settle payment
    // 4. Verify nonce marked as used
    // 5. Attempt replay (should fail)
}

Fuzzing Targets

TargetInputGoal
ParseEVMPayloadRandom bytesNo panic, graceful error
HashEIP3009AuthorizationRandom domain/authConsistent output
VerifyEOASignatureRandom signatureNo panic, correct result
ValidateTransaction (Solana)Random tx bytesNo panic, reject invalid

Dependency Audit

Go Dependencies

# Check for known vulnerabilities
go list -m all | nancy sleuth
 
# Key dependencies to review:
# - github.com/ethereum/go-ethereum (crypto)
# - github.com/gagliardetto/solana-go (Ed25519)
# - golang.org/x/crypto (Ed25519)

Python Dependencies

# Check for known vulnerabilities
pip audit
 
# Key dependencies:
# - eth-account (EIP-712 signing)
# - web3 (RPC client)
# - pynacl (Ed25519)

TypeScript Dependencies

# Check for known vulnerabilities
npm audit
 
# Key dependencies:
# - viem (EVM signing)
# - @solana/web3.js (Solana)

Java Dependencies

# Maven dependency check
mvn dependency-check:check
 
# Key dependencies:
# - web3j (EVM)
# - bouncycastle (Ed25519)

Environment Setup

Local Development

# Clone repository
git clone https://github.com/t402-io/t402
cd t402
 
# Go SDK
cd go && go test ./...
 
# Python SDK
cd python && pip install -e ".[dev]" && pytest
 
# TypeScript SDK
cd typescript && pnpm install && pnpm test
 
# Java SDK
cd java && mvn test

Testnet Configuration

NetworkChain IDRPCFaucet
Base Sepolia84532https://sepolia.base.orgfaucet.quicknode.com
Solana Devnet-https://api.devnet.solana.comsolfaucet.com
TON Testnet-https://testnet.toncenter.com@testgiver_ton_bot
TRON Nile-https://nile.trongrid.ionileex.io

Deliverables

Expected Audit Report Sections

  1. Executive Summary

    • Overall risk assessment
    • Critical findings summary
    • Recommendations overview
  2. Methodology

    • Tools used
    • Testing approach
    • Coverage metrics
  3. Findings

    • Severity classification (Critical, High, Medium, Low, Info)
    • Detailed description
    • Impact analysis
    • Proof of concept (where applicable)
    • Remediation recommendations
  4. Code Quality

    • Architecture review
    • Best practices compliance
    • Documentation quality
  5. Appendices

    • Test results
    • Coverage reports
    • Tool outputs

Timeline

PhaseDurationActivities
Kickoff1 dayRepository access, environment setup
Code Review2-3 weeksManual review of in-scope components
Testing1-2 weeksAutomated testing, fuzzing
Report Draft1 weekFinding documentation
Remediation Review1 weekVerify fixes
Final Report2-3 daysFinal documentation

Contact Information

RoleContact
Technical Leadengineering@t402.io
Security Contactsecurity@t402.io
Project Managerpm@t402.io

For audit engagement inquiries, please contact security@t402.io with your firm’s credentials and proposed timeline.