[ RESEARCH REPORT // 06 ]CROSS-CHAIN BILLINGDEVNET DEPLOYED

InvoiceChain: Decentralized Multi-Chain Billing & Anchor State Settlement

Bridging frictionless cross-chain client checkouts with non-custodial Solana Anchor state tracking, settling USDC receivables without manual reconciliation or payment tracking drift.

BY VINICIUS PONTUAL — SMART CONTRACT & FULL-STACK ARCHITECT
DEPLOYED: JAN 2026 // PROGRAM ID: 4wy5...ypSu7
InvoiceChain Cross-Chain Settlement Flow
FIG 1.0: INVOICE PDA INITIALIZATION → KIRAPAY CROSS-CHAIN ROUTER → WEBHOOK VERIFICATION → ON-CHAIN SETTLEMENT[ CROSS-CHAIN SPECIFICATION ]
Smart ContractAnchor / Rust
Payment GatewayKIRAPAY API
Settlement AssetUSDC on Base
State VerificationSolana SVM

01. The Problem: The Web3 Freelance Billing Friction

Independent software engineers, auditors, and digital creators operating globally face constant hurdles when attempting to get paid in stablecoins. While traditional invoicing solutions require banking rails with heavy FX conversions and chargeback risks, crypto-native invoicing tools force clients into rigid token constraints:

  • Ecosystem Fragmentation: A freelancer billing on Solana often deals with clients whose treasury resides strictly on Ethereum, Arbitrum, or Base, causing days of friction over manual bridging.
  • Reconciliation Hell: Clients send irregular tokens or round up amounts incorrectly, leaving developers to manually parse block explorers to prove an invoice was settled.
  • Centralized Custody Risk: Legacy invoicing platforms hold user balances in proprietary database ledgers, introducing single-point-of-failure counterparty risk.

02. Architectural Solution: Multi-Chain Routing & SVM Settlement

InvoiceChain pairs multi-chain payment routers with an Anchor smart contract state machine on Solana. The settlement lifecycle proceeds deterministically:

// Step 1: Invoice InitializationThe freelancer connects a Phantom wallet and initializes an on-chain Invoice account on Solana, defining the counterparty, invoice ID, and requested amount in USD value.

// Step 2: Payment Link GenerationThe Next.js 16 backend invokes KIRAPAY via POST /api/link/generate, establishing a multi-chain checkout link tagged with the Solana invoice ID.

// Step 3: Multi-Chain Liquidity IngestionThe client accesses the checkout link and pays with any arbitrary token (ETH, USDT, DAI) across supported EVM networks. KIRAPAY handles cross-chain swaps and routes settled USDC directly to the receiver's Base address.

// Step 4: Cryptographic Webhook & State MutationUpon transaction finality, KIRAPAY dispatches a cryptographically verified transaction.succeeded webhook. The backend relayer executes the Anchor instruction mark_paid, locking the invoice state on Solana permanently.

“Freelancers should not care which chain their client’s treasury is locked in. The client pays with whatever token they have; the contractor gets USDC, and the final state is verified immutably in Solana bytecode.”— Vinicius Pontual, Project Architecture

03. Public Verification: Announcement & Demo on X

Technical demonstration published on X documenting the end-to-end payment loop, cross-chain checkout execution, and instant Solana state synchronization:

X DISPATCH // @vini77pontualSTATUS ID: 2052971276923281908

“On-chain invoice system for freelancers. Create a payment link, share with your client, get paid in USDC via KIRAPAY — payment confirmed on Solana.”

04. Smart Contract Mechanics: Anchor Account Constraints

State guarantees are enforced through deterministic account derivations:

01 / Deterministic Seeds: Invoices are stored at ["invoice", authority.key(), invoice_id], preventing account collisions across different contractors.
02 / Relayer Key Segregation: The mark_paid instruction is strictly restricted to the authorized relayer keypair, preventing malicious actors from artificially settling unfulfilled invoices.
03 / State Immobility: Once set to paid, the status flag cannot be reversed, overwritten, or re-initialized, creating a permanent audit trail.

05. Webhook Security & Replay Prevention

Because payment settlement spans two distinct networks (Base and Solana), the relayer infrastructure enforces defensive boundaries:

  • HMAC Signature Verification: Inbound webhooks from KIRAPAY require strict SHA-256 signature verification matching the WEBHOOK_SECRET. Spoofed HTTP requests are rejected before hitting the database.
  • Idempotent Event Ingestion: In the event of webhook retries, the backend checks on-chain state via Solana RPC before constructing the transaction, eliminating redundant network fees and transaction reversions.
  • Key Isolation: The backend signing key (BACKEND_WALLET_PRIVATE_KEY) is held entirely in serverless runtime memory and never exposed to the client bundle.

06. Specifications & Deployments

On-chain program and deployment configuration:

ParameterValue / Address
Solana Program ID4wy52jbYZop2pWWBtBmVZKUMFMrj86qrork9StcypSu7
Target NetworkSolana Devnet (Settlement) / Base (Receivables)
Frontend FrameworkNext.js 16 App Router + TypeScript + Tailwind CSS
Gateway IntegrationKIRAPAY Merchant API (POST /api/link/generate)
BUILD COMMANDS: anchor build && anchor deploy --provider.cluster devnet
GATEWAY URL: https://api.kira-pay.com
// ENGINEERING DOSSIERS

Explore More Projects

All 13 Projects →