Last Updated: 2026-02-05

The T402 team takes security seriously. This document outlines our security practices, threat model, and guidelines for secure deployment.

• Reporting Vulnerabilities
• Supported Versions
• Security Architecture
• Cryptographic Primitives
• Threat Model
• Chain-Specific Security
• Deployment Security
• Security Best Practices
• Responsible Disclosure

Please do not report security vulnerabilities through public GitHub issues.

1. GitHub Security Advisories (preferred): Report a vulnerability
2. Email: security@t402.io

• Type of vulnerability (e.g., signature bypass, replay attack, injection)
• Affected component (SDK, facilitator, specific chain mechanism)
• Steps to reproduce the issue
• Proof-of-concept code (if possible)
• Impact assessment
• Suggested fix (if any)

T402 is a payment protocol that enables HTTP-based payments using cryptocurrency. The security model relies on:

1. Cryptographic signatures for payment authorization
2. On-chain verification for settlement finality
3. Time-bounded validity to prevent replay attacks
4. Server-side verification before resource delivery

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Client    │────▶│   Server    │────▶│ Facilitator │
│  (Wallet)   │     │ (Resource)  │     │ (Settler)   │
└─────────────┘     └─────────────┘     └─────────────┘
      │                   │                   │
      │ Signs payment     │ Verifies sig      │ Executes
      │ off-chain         │ & requirements    │ on-chain
      └───────────────────┴───────────────────┘

Client Security:

• Private keys never leave the client
• Signatures created locally (browser, mobile, CLI)
• Support for hardware wallets and secure enclaves

Server Security:

• Verifies payment signatures before serving resources
• Validates payment parameters (amount, recipient, deadline)
• Does not hold user funds

Facilitator Security:

• Executes on-chain settlements
• Holds hot wallet for gas fees
• Rate-limited and API key protected

EIP-712 Typed Data:

• Domain separator prevents cross-chain replay
• Structured data prevents signature malleability
• Human-readable signing prompts

1. Blockchain Security: Underlying blockchains are secure
2. Token Contracts: USDT/USDT0 contracts function correctly
3. Client Integrity: User's device is not compromised
4. TLS/HTTPS: Transport layer is secure

USDT0 (EIP-3009):

// Authorization includes all critical parameters
transferWithAuthorization(
    from,      // Payer address
    to,        // Recipient address
    value,     // Amount in smallest unit
    validAfter,  // Not valid before this timestamp
    validBefore, // Not valid after this timestamp
    nonce,     // Random 32-byte nonce (replay protection)
    v, r, s    // ECDSA signature
)

Security Considerations:

• Always verify validBefore is in the future
• Use cryptographically random nonces
• Check return value of transfer

Jetton Transfer:

• Uses comment field for metadata
• Verify sender wallet address matches signed address
• Check query_id for replay protection

Security Considerations:

• Validate workchain ID (0 for basechain)
• Verify Jetton master contract address
• Check sufficient balance before sending

TRC-20 Transfer:

• Standard approve + transferFrom pattern
• Energy/bandwidth considerations

Security Considerations:

• Validate Base58Check address format
• Check contract is official USDT
• Verify sufficient energy for transaction

SPL Token Transfer:

• Associated Token Accounts (ATA)
• Compute unit limits

Security Considerations:

• Validate token mint address
• Check ATA ownership
• Verify transaction simulation before signing

# 1. Use strong, random secrets
export REDIS_PASSWORD=$(openssl rand -hex 32)
export GRAFANA_PASSWORD=$(openssl rand -hex 32)
export API_KEYS="$(openssl rand -hex 32):production"

# 2. Never expose internal services
# Only Caddy (reverse proxy) should be exposed to internet

# 3. Enable API key authentication
export API_KEY_REQUIRED=true

• Run containers as non-root
• Use read-only filesystem where possible
• Enable no-new-privileges
• Use internal networks for service communication
• Limit container resources (memory, CPU)
• Scan images for vulnerabilities (Trivy)
• Use specific image tags, not latest

# docker-compose.prod.yaml security configuration
networks:
  internal:
    internal: true  # No external access
  external:
    driver: bridge  # Only for reverse proxy

security_opt:
  - no-new-privileges:true

read_only: true
tmpfs:
  - /tmp:noexec,nosuid,size=64M

1. Minimum Balance: Keep only necessary funds for gas
2. Monitoring: Alert on unusual activity
3. Rotation: Rotate wallet addresses periodically
4. Separation: Use different wallets per environment
5. Multi-sig: Consider multi-sig for high-value operations

Default production limits:

• 1000 requests per 60 seconds per IP
• Configurable via RATE_LIMIT_REQUESTS and RATE_LIMIT_WINDOW

// Good: Load from environment
signer, _ := evmsigners.NewClientSignerFromPrivateKey(os.Getenv("PRIVATE_KEY"))

// Good: Load from secret manager
signer, _ := evmsigners.NewClientSignerFromPrivateKey(vault.GetSecret("evm-key"))

// Bad: Hardcoded
signer, _ := evmsigners.NewClientSignerFromPrivateKey("0x1234...")

// Always verify on server before delivering content
result, err := facilitator.Verify(ctx, payloadBytes, requirementsBytes)
if err != nil || !result.IsValid {
    return http.StatusPaymentRequired
}

// Settle after delivery (or use escrow pattern)
settleResult, err := facilitator.Settle(ctx, payloadBytes, requirementsBytes)

// Validate all parameters match expectations
if (payment.amount < expectedAmount) {
  throw new Error("Insufficient payment");
}
if (payment.payTo !== myAddress) {
  throw new Error("Wrong recipient");
}
if (payment.deadline < Date.now() / 1000) {
  throw new Error("Payment expired");
}

1. Verify URLs: Ensure you're on the correct domain
2. Check Amounts: Review payment details before signing
3. Use Hardware Wallets: For high-value transactions
4. Monitor Transactions: Set up alerts for wallet activity

• Protocol security review (Trail of Bits, OpenZeppelin, or similar)
• Penetration testing of facilitator service
• Smart contract integration review

• Dependency Scanning: Dependabot, govulncheck, npm audit
• Container Scanning: Trivy in CI/CD pipeline
• SBOM Generation: Software Bill of Materials for each release
• Secret Scanning: GitHub secret scanning enabled

We follow responsible disclosure practices:

1. Report: Submit vulnerability privately via channels above
2. Acknowledge: We respond within the timeline specified
3. Investigate: We confirm and assess the issue
4. Fix: We develop and test a fix
5. Release: We deploy the fix and publish a security advisory
6. Credit: We credit the reporter (unless anonymity requested)

• Security Issues: security@t402.io
• General Support: See SUPPORT.md
• Code of Conduct: See CODE_OF_CONDUCT.md