PayMaster

Bridging Web2 corporate finance workflows with Web3 liquidity, our agentic payment router gives companies programmatic, single-click settlement across yield protocols and chains.

Comment

Inspiration

The Problem: Fragmentation and Operational Friction in Web3 Financial Settlement Both individual consumers and enterprise treasuries face a significant disconnect between high-yield digital asset management and real-time Web2 usability. This gap is defined by three systemic barriers, including capital inefficiency & liquidity gaps, complex operational friction and lack of autonomous execution.

First, a large amount of capital is locked in yield-generating protocols or left unused in native gas tokens because moving these assets for everyday payments or business-to-business (B2B) transactions is too complicated.

In addition, current processes often require several manual steps, such as cross-chain transfers and gas management. This makes transactions more time-consuming, expensive, and prone to human error.

Finally, Web3 still lacks smart financial systems that can understand what users want and automatically complete transactions. This makes it difficult to connect digital assets smoothly with the existing Web2 economy.

To address these problems, a unified platform is built to mitigate these inefficiencies and helps bridge the gap between digital assets and real-world payments.

What it does

PayMaster for B2B changes how companies manage their corporate funds and pay vendors by turning simple business instructions into automated blockchain transactions. Instead of finance teams spending hours manually withdrawing funds from DeFi platforms, swapping tokens on decentralised exchanges (DEXs) and moving funds between different blockchain networks, a manager can simply give a command such as, “Pay our $50,000 monthly vendor invoice using the yield earned from Aave and Compound.”

The system uses a fine-tuned LLM to understand these instructions, create possible transaction plans, and explain the steps clearly. The Treasury Engine then checks the blockchain to confirm which assets the company actually has. After that, the Route Optimizer finds the best way to complete the transaction while keeping as much yield as possible and reducing gas fees.

For enterprise-grade security, the Risk Engine checks every transaction before it is approved, applying rules such as daily spending limits and approved wallet addresses. A finance manager then reviews and gives the final approval. Once approved, the Smart Wallet (ERC-4337) automatically carries out all the required steps as one smooth, gasless transaction on the blockchain. Throughout this process, Supabase acts as the central data layer, persisting the complete business, payment, and audit state to provide immutable logs for accounting and compliance.

At its core, PayMaster is an intelligent payment system built on blockchain technology. Traditional financial systems depend on banks and centralised databases, which can make payments slower and more complicated. PayMaster instead connects directly to blockchain smart contracts and liquidity pools such as Aave, Compound, and Uniswap across EVM-compatible networks.

Using Account Abstraction (ERC-4337), the Smart Wallet can combine several actions—such as withdrawing yield, swapping tokens, and moving funds across chains—into one transaction. While traditional finance relies on centralized bank databases and slow clearinghouses, this router interacts with decentralized smart contracts and liquidity pools (such as Aave, Compound, and Uniswap) across EVM-compatible blockchains. Smart contracts can also handle network fees using stablecoins such as USDC, so businesses do not need to manually manage gas tokens.

Overall, PayMaster allows businesses to use the benefits of blockchain, such as faster global payments, access to yield, and transparent transactions, without requiring them to deal with the complicated technical parts of crypto.

How we built it

PayMaster is a full-stack monorepo (npm workspaces) with five packages:

  • A SmartWallet.sol written in Solidity ^0.8.24 with incrementing nonces (replay protection), reentrancy guards, safe ERC-20 handling and two-step ownership transfer. -Deployed and tested on Hardhat localnet with 23 unit tests. An IntentRouter.sol maps parsed intents to execution paths.

  • Backend (backend): A thin Express + TypeScript API layer with health endpoints, powered by Supabase PostgreSQL for the full 8-stage payment lifecycle: 

    Payment Request → AI Intent → Payment Plan → Route Options → Risk Assessment → Approval → Execution (Txns) → Audit Logs.

  • Frontend: Next.js 14 App Router with a design system on TailwindCSS . The UI includes a chat interface for natural-language payment instructions and a business operations dashboard

  • AI / Deterministic Pipeline (in lib): The core of the product. Six engines chained together:

  • Intent Parser — OpenAi & Gemini Structured Outputs + Zod re-validation parses natural language into typed PaymentIntent

  • Planner— generates candidate execution strategy families

  • Route Optimizer (Phase 7) — deterministic weighted scoring model \(Score(r) = Gas(r)+ Time(r) + Steps(r) +Risk(r) \).

  • Risk Engine— 7 deterministic checks (balance, gas, recipient, network, slippage, route, complexity) produce a 0–100 risk score

  • Execution Engine (Phase 10) — builds validated payloads with 6 typed error modes

  • Human Approval Gate — explicit approve/reject before any transaction is signed

  • Shared types : Cross-package TypeScript types for intents, routes, transactions, and API contracts.

Challenges we ran into

  1. AI Trust Boundary: The hardest design challenge was deciding exactly where the LLM stops and deterministic code starts. We solved this with a hard principle: the LLM interprets language only — it never touches a wallet, never computes a financial figure, never selects a route. Every dollar amount, risk score, and route ranking comes from pure math.

  2. Safe ERC-20 Interoperability: Not all ERC-20 tokens return a boolean on transfer (USDT is the classic example). We implementedncallOptionalReturn() with low-level staticcall checks to handle both compliant and non-compliant tokens without silently swallowing failures.

  3. Race Conditions in Chat : A deep-linked prompt could be sent while loadHistory was still resolving, causing the live conversation to be clobbered by an empty history. We fixed this with a functional state update that never overwrites an active conversation.

4. Monorepo Coordination : Five packages with interdependent types, ABIs, and deployment addresses required careful orchestration. The wallet deployment addresses in localhost.json must mirror the frontend's ABI registry exactly, or execution silently fails.

Accomplishments that we're proud of

  1. We built a proper mathematical optimization model for min-max normalization across gas, time, steps, and risk with configurable weights , meaning route selection is provably optimal for a given set of candidates, not "whatever the AI guessed."

  2. Every payment is evaluated against 7 deterministic Risk-Check Engine that checks before a human can approve it. The weighted scoring formula (recipient 13pts, balance 12pts, gas 8pts, etc.) reflects real-world payment risk priorities. The engine flags issues but never blocks , it informs the human.

  3. The contract has incrementing nonces, reentrancy guards, two-step ownership transfer, input validation, and a dedicated ReentrancyAttacker.sol mock to prove the guard works. 23 unit tests cover happy paths, auth failures, and attack vectors.

4. Every step from intent parsing to on-chain execution is recorded in Supabase with typed event logs. A single SQL query can trace the full lifecycle of any payment.

What we learned

LLMs are great interpreters, terrible executors. The natural language → structured intent pipeline works beautifully with Structured Outputs + Zod, but letting an LLM anywhere near financial computation or transaction signing is a design anti-pattern. The trust boundary must be explicit and enforced in code, not convention.

  1. Determinism is a feature, not a constraint: Making route selection and risk scoring purely mathematical (rather than AI-driven) turned out to be a competitive advantage. It's auditable, explainable, and predictable.

  2. Solidity's low-level call semantics are subtle: Handling tokens that don't return booleans, bubbling revert reasons properly, and ensuring atomic batch execution (all-or-nothing) required deep understanding of the EVM's call/staticcall/delegatecall distinctions.

3. TypeScript monorepos need discipline: Shared types in shared must be the single source of truth. We learned to never duplicate a type definition across packages ,barrel exports and path aliases keep everything consistent.

What's next for PayMaster/ Future Plan

  1. ERC-4337 Account Abstraction: Migrate from the simplified PayMaster wallet to a full ERC-4337 stack with UserOperations, bundler integration, and paymaster-sponsored gas , enabling gasless transactions for business users.
  2. *Expand beyond Hardhat localnet to Polygon, Arbitrum, and Optimism mainnets with cross-chain route optimization *(currently the route optimizer penalizes bridges; we'd promote them when they're the best option).
  3. Recurring Payments & Invoicing: Support scheduled/recurring payment intents ("Pay Alice $500 every Friday") with automated plan generation and approval workflows.
  4. Team-Based Approval Policies: Multi-signature approval gates where payments above a threshold require N-of-M signers, with role-based access control integrated into the existing approval pipeline.
  5. Real-Time FX & Gas Oracles: Replace static currency configs with live Chainlink price feeds for accurate multi-currency settlement amounts and dynamic gas estimation.
  6. Mobile Wallet Integration: Build a React Native companion app so business operators can review and approve payments on the go, with push notifications for high-risk payment alerts.

Built With

Share this project:

Updates