Cross Border Payments on Arc with Private Verifiable Records
A payment is a number and a reason. Arc makes the number move across borders in under a second. The reason, the invoice, the remittance advice and the compliance file, still travels by email.
Cross border payments are one of Arc's headline use cases. USDC is the gas token, EURC is native, Circle StableFX supports round the clock onchain FX between stablecoins, and settlement is deterministic and sub second. The founding validator set includes Visa, Mastercard, MoneyGram and Worldpay, companies that move money for a living.
The part blockchains do not solve is the paperwork that travels with every business payment. This post covers how to attach that paperwork to Arc payments in a way that is private, verifiable and durable, using Lighthouse.
What Travels With a Business Payment
A single supplier payment in B2B trade usually involves:
| Record | Who needs to see it |
|---|---|
| Invoice | Payer, payee, both finance teams |
| Purchase order and delivery proof | Payer, payee, sometimes a financier |
| Remittance advice | Payee's accounts receivable |
| FX quote and confirmation | Both parties, treasury |
| Sanctions and KYB screening results | Payer's compliance, regulators on request |
| Tax documents | Both parties, tax authorities |
In a traditional wire, these ride alongside the payment through email, portals and message fields with strict length limits. Reconciliation breaks when they get separated. And in a dispute, each side produces its own copy of the invoice, and nobody can prove which one was paid.
On Arc, you can bind the payment to the documents permanently, without exposing the documents to the public.
The Pattern: Encrypted Record, Public Commitment
- Encrypt and store. The payer's system encrypts the invoice bundle client side and uploads it to Lighthouse. The result is a CID.
- Share. Decryption is granted to the payee's address, and to any other named party such as a trade financier.
- Pay with a commitment. The USDC or EURC payment on Arc carries the CID, in the calldata of a payments contract or in an event.
- Verify anytime. Either party, or an auditor they authorize, decrypts the bundle and confirms it matches the CID that was paid against.
The CID is public. The contents are not. Anyone can see that a payment is bound to a specific document; only authorized parties can read it.
import lighthouse from "@lighthouse-web3/sdk";
// 1. Encrypt the invoice bundle before it leaves the payer's system
const { data } = await lighthouse.uploadEncrypted(
"./outgoing/INV-88213-bundle.zip",
process.env.LIGHTHOUSE_API_KEY,
payerAddress,
signedMessage
);
const recordCID = data[0].Hash;
// 2. Give the supplier access
await lighthouse.shareFile(payerAddress, [supplierAddress], recordCID, signedMessage);
// 3. Pay on Arc with the CID bound to the payment
await walletClient.writeContract({
address: INVOICE_SETTLEMENT,
abi: invoiceSettlementAbi,
functionName: "settle",
args: [supplierAddress, EURC_ADDRESS, 48_250_000000n /* 48,250 EURC */, recordCID],
chain: arc, // chain ID 5042
});
And a minimal settlement contract:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
contract InvoiceSettlement {
event Settled(address indexed payer, address indexed payee, address token, uint256 amount, string recordCID);
function settle(address payee, address token, uint256 amount, string calldata recordCID) external {
require(IERC20(token).transferFrom(msg.sender, payee, amount), "transfer failed");
emit Settled(msg.sender, payee, token, amount, recordCID);
}
}
The Settled event is the reconciliation key. The payee's accounts receivable system watches for events addressed to it, reads the CID, decrypts the remittance data and matches the payment automatically, whatever the payer typed in a free text field.
Privacy on Two Layers
Arc is adding opt in confidential transfers and balances with view keys, so amounts can be hidden from the public while remaining visible to parties holding a view key. That protects the payment.
Lighthouse protects the documents in the same spirit:
- Encrypted before upload. Storage providers and Lighthouse only ever see ciphertext.
- No single key holder. The key is split with BLS threshold cryptography across independent nodes. Reconstructing it requires a threshold of nodes, each checking access rules.
- Selective disclosure. Share with specific addresses: payee, financier, auditor. Each grant is independent.
- Revocation. When a relationship ends, revoke access. The CID and the onchain commitment do not change.
Public IPFS alone would be the wrong tool here. Anything uploaded unencrypted is readable by anyone with its CID, a point covered in Is IPFS Private? What Content Addressing Hides, and What It Doesn't.
FX Payments and Quote Records
Circle StableFX brings onchain FX between stablecoins with near instant settlement. For a treasury team, the FX quote is itself a record: the rate offered, the time, the counterparty. Store the quote and confirmation by CID and include it in the settlement event, and the rate a payment was converted at is provable long after the fact.
This matters most in the cases people argue about: a disputed rate, a late payment across a weekend, or a regulator asking how a conversion was priced.
Retention Without a Records Server
Payment records often must be retained for years under tax and anti money laundering rules. On the Filecoin path, Lighthouse holds files in storage deals with ongoing cryptographic proofs. Retention becomes something you can demonstrate, not just assert. Deals run for a term and are renewed; What Happens When a Filecoin Deal Expires? explains how.
For teams whose records pipeline already writes to S3, Lighthouse's L3 is S3 compatible, with each object's CID returned in the x-amz-meta-cid header. Existing archival jobs can point at it with a configuration change.
Where This Fits
Payment companies and PSPs building on Arc can offer reconciliation that just works, because every payment carries a document commitment.
Trade finance platforms can finance invoices whose integrity is anchored onchain, reducing double financing risk: the same invoice CID cannot be presented twice unnoticed.
Payroll and contractor platforms can pay globally in USDC or EURC and deliver payslips to each worker encrypted to their address.
Marketplaces can bind order, delivery and dispute evidence to the payment that settled them.
Chain support note. Everything above works on Arc today, because it depends only on storing CIDs and sharing with addresses. Lighthouse can also gate decryption on onchain conditions for chains on its Chains Supported list; Arc is not listed yet. For Arc native conditions, request support on Discord.
Frequently Asked Questions
Can Arc be used for cross border payments? Yes. Arc settles USDC and EURC with deterministic sub second finality, uses USDC for gas, and supports onchain FX through Circle StableFX.
How do you attach an invoice to a stablecoin payment? Store the invoice with Lighthouse, then include its CID in the payment transaction or an event. The CID permanently binds the payment to that exact document.
Are invoices stored on IPFS private? Only if encrypted. Lighthouse encrypts client side and shares decryption with named addresses, so the public sees a CID and nothing else.
How long can payment records be kept? As long as needed. On the Filecoin path, records are held in renewable storage deals with ongoing storage proofs.
Get Started
New to Arc? Start with What Is Arc by Circle and How Lighthouse Adds the Storage Layer. Building payments on Arc? Talk to our team.
Stay in Touch
Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.
