Skip to content
Pay Anyone Legend

Pay Anyone Legend

Private cross-chain x402 payments for merchants.

Created on 3rd December 2025

Pay Anyone Legend

Pay Anyone Legend

Private cross-chain x402 payments for merchants.

The problem Pay Anyone Legend solves

Anyone Pay solves critical problems in digital payments by combining AI-powered intent recognition, privacy-preserving technologies, cross-chain interoperability, and a universal payment standard.


1. AI-Powered, Private Intent Recognition

Problem: Users suffer fund loss from typos or must manually handle complex crypto addresses. Additionally, the AI used for intent recognition often runs on traditional servers, compromising the user's payment intent and sensitive transaction data.

Solution: The system uses AI to analyze natural language queries (e.g., "Pay onlyfan" -> OnlyFans) and performs semantic matching, filling in missing details automatically. Crucially, this AI intent engine and associated private computation run inside a NEAR AI Trusted Execution Environment (TEE). This hardware-secured enclave protects the user's payment intent, ensuring the AI cannot be compromised or monitored by the server operator.


2. Privacy in Digital Payments & Usability

Problem: Traditional payments expose transaction details, require KYC, and enable surveillance, limiting financial freedom.On-chain transactions are constantly monitored for behavior and often require KYC (Know Your Customer), which compromises security/safety.

Solution: "Anyone Pay" utilizes "near intent" to automatically create Zcash addresses, ensuring all transaction details are hidden. Furthermore, it uses "Chain Sign" to enable a Near Account to generate derived addresses others c from receiving chains and initiate transactions. This combined process results in transactions that are completely anonymous and leave no traceable footprint on the internet.


3. Cross-Chain Payment Complexity

Problem: Users must manage multiple chains, manually bridge assets, and struggle with different gas fees to transact across the decentralized ecosystem.

Solution: A unified interface automatically manages the complexity. It uses NEAR Chain Signatures to perform cross-chain transactions; the asset bridging is driven by the target chain specified (Base, Solana, etc.). The core is an Intent-based architecture where users express the goal, and the system handles the multi-step execution.
Example Intent: Pay $0.20 USDC to a merchant on Base by using the user's existing funds on Base. The user simply says: "pay 0.2 usdc to 0x... Base"


4. Merchant Payment Friction

Problem: Merchants face complex technical setup, require multiple integrations, must manually verify payments, and provide a poor customer experience.

Solution: Merchants benefit from one-click service creation. Service discovery is simplified via the AI's natural language search. Payments are automatically verified using the x402 payment protocol. Customers simply scan a QR code to pay.


5. Multichain Pay-to-API Standardization (x402) & Developer Tools

Problem: Payment APIs are fragmented. There is no universal, easy standard for monetizing digital content or machine-to-machine (M2M) API access across major blockchains (EVM, Base, Solana). Furthermore, developers lack a comprehensive environment to build and test these autonomous AI payment systems.

Solution: Adoption of the HTTP 402 "Payment Required" standard via the x402 protocol combined with Anyone Pay's cross-chain routing. This creates a universal, multichain standard that allows developers to easily implement a simple, granular pay-per-access model for any API or web application.

To support this, the AI-Native Playground provides developers with a complete environment for rapid prototyping, testing, and deploying their verifiable AI agents and applications.

This ensures:

  • Easy Multichain Payment: The client can pay using tokens on their preferred chain (Base, Solana, EVM chains), and the system handles the cross-chain settlement automatically.
  • Universal API Flow: Consistent, native HTTP payment flow across all services.
  • Rapid Deployment: Developers can quickly build and launch agents that interact with the payment standard.

6. Key Management Complexity

Problem: Users must secure and manage seed phrases, private keys, and multi-chain wallets, leading to high risk of loss and high user friction.

Solution: NEAR Chain Signatures (MPC) handle keys automatically and securely on the backend. No seed phrases needed. This key abstraction, combined with QR code scanning, replaces traditional wallet complexity.


Real-World Use Cases

  • Content Creators: Create service, share link, get paid automatically and privately.
  • SaaS Providers: Instant, granular payments for premium features or metered API usage.
  • Digital Goods: Automatic, instant payment verification before unlocking content.
  • Cross-Border: Fast, low-cost private payments across different blockchain networks.
  • Privacy Users: Private Zcash deposits with shielded transactions for all payments.

Challenges I ran into

Major technical challenges encountered while building Anyone Pay, focused on blockchain and AI integration.

1. Chain Signatures Integration Complexity

Challenge: Implementing NEAR Chain Signatures for Ethereum signing.

chainsig.js

library had issues:

  • signAndSendTransactions

    function not working
  • Account object structure mismatches
  • Transaction serialization problems between NEAR and Ethereum

Solution:

  • Switched to direct NEAR API based on

    chainsig-script

    example
  • Created custom

    lib/near.ts

    for direct MPC contract interaction
  • Used

    chainsig.js

    only for EVM adapter utilities (prepare/finalize)

Key Learning: Direct API calls are often simpler than abstraction libraries. Hybrid approach: libraries for utilities, direct calls for core logic.


2. EIP-712/EIP-3009 Signature Handling

Challenge: x402 payments require EIP-712 typed data signing. Multiple signature format issues:

  • Invalid

    v

    value errors
  • Signature recovery failures
  • Incorrect

    r

    and

    s

    format (needed 32 bytes, not hex strings)

Root Cause:

  • Chain Signatures return

    recovery_id

    (0 or 1), not EIP-155

    v

    value
  • Different formats needed for EIP-712 vs transaction signing
  • Gas estimation failed with placeholder signatures

Solution:

  • Implemented

    signTypedDataWithChainSignature

    for EIP-712 authorization
  • Adjusted

    v

    :

    recovery_id + 27

    for EIP-712,

    recovery_id + chainId * 2 + 35

    for EIP-155
  • Ensured

    r

    and

    s

    are exactly 32 bytes (64 hex chars) for

    transferWithAuthorization

  • Manual transaction construction to avoid gas estimation failures
  • Added signature verification before broadcasting

Key Learning: EIP-712 and EIP-155 have different signature format requirements. Chain Signatures recovery_id needs conversion for different standards.


Key Learning: NEAR Account initialization requires keys present in keystore. Synchronous operations shouldn't be wrapped in async/await.


4. Cross-Chain Transaction Signing

Challenge: Signing Ethereum transactions from NEAR Chain Signatures:

  • Converting NEAR format to Ethereum format
  • Handling different signature formats
  • Gas estimation without valid signatures

Solution:

  • Used

    chainsig.js

    EVM adapter for

    prepareTransactionForSigningLegacy

    and

    finalizeTransactionSigningLegacy

  • Manual transaction construction with fixed gas limits when estimation fails
  • Separate transaction objects for ethers (numbers) and viem (BigInt)
  • Proper type conversions between libraries

Key Learning: Legacy transaction format is simpler for cross-chain signing. Gas estimation can be bypassed with reasonable fixed values.


5. Ethers Version Compatibility (v5 vs v6)

Challenge: Needed to downgrade from

ethers

v6 to v5.7.2 for

chainsig.js

compatibility. Extensive API changes:

  • ethers.parseUnits

    ethers.utils.parseUnits

  • ethers.Interface

    ethers.utils.Interface

  • ethers.keccak256

    ethers.utils.keccak256

  • BigNumber handling changes

Solution: Systematically converted all v6 API calls to v5 equivalents. Fixed BigNumber mixing issues with explicit conversions.

Key Learning: Always check library version compatibility. BigNumber operations need explicit type conversions.


6. AI Semantic Search and Service Matching

Challenge: Implementing semantic search for service discovery:

  • Generating embeddings for services
  • Matching user queries to services
  • Setting similarity thresholds (too high = no matches, too low = false positives)

Root Cause:

  • Near AI API key might not be available
  • Vector similarity search requires proper setup
  • Threshold tuning is critical

Solution:

  • Implemented

    generateEmbedding

    with Near.AI
  • Created

    searchServicesSemantic

    with vector search
  • Fallback to

    searchServicesKeyword

    if embeddings fail
  • Adjusted threshold to 0.6 (60% similarity) for better matching

Key Learning: Always provide fallback mechanisms. Similarity thresholds need tuning. Keyword search is valuable when AI unavailable.


Tracks Applied (5)

General Bounty

I’ve heard about the Network School in Singapore — a place with warm golden sunlight near the beach, where you can work ...Read More

Network School

Cross-Chain Privacy Solutions

We are specifically leveraging NEAR Intent to seamlessly bridge SOL (Solana) and Zcash assets, enabling us to execute th...Read More

Helius

Cross-Chain Privacy Solutions

Specifically, we are leveraging NEAR Intent and Chain Abstraction technology to seamlessly execute payments, culminating...Read More
NEAR Protocol

NEAR Protocol

Privacy-Preserving AI & Computation

We utilize NEAR AI to autonomously process user intents, ensuring all cross-chain and privacy steps are handled automati...Read More
NEAR Protocol

NEAR Protocol

Private Payments & Transactions

Crucially, we utilize Zcash and its shielded addresses to ensure maximum privacy, guaranteeing that the user's deposit a...Read More
NEAR Protocol

NEAR Protocol

Discussion

Builders also viewed

See more projects on Devfolio