Pay Anyone Legend
Private cross-chain x402 payments for merchants.
Created on 3rd December 2025
•
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
ands
format (needed 32 bytes, not hex strings)
Root Cause:
- Chain Signatures return
recovery_id
(0 or 1), not EIP-155v
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
ands
are exactly 32 bytes (64 hex chars) fortransferWithAuthorization
- 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 forprepareTransactionForSigningLegacy
andfinalizeTransactionSigningLegacy
- 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 forchainsig.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
Network School
Cross-Chain Privacy Solutions
Helius
Cross-Chain Privacy Solutions
NEAR Protocol
Privacy-Preserving AI & Computation
NEAR Protocol
Private Payments & Transactions
NEAR Protocol
Technologies used
