Spec v0.1 · devnet nextRoadmap →

A payment is only proven when both sides say so.

Lóng Protocol turns a crypto payment on any rail into a proof of payment that anyone can check. The money moves natively, wallet to wallet. Only the proof is written on chain: recorded on Solana, anchored on Ethereum. No custody, no token to buy, no fee on the sale.

Record layerSolana
Anchor layerEthereum
Payment railsBTC · Lightning · Tron · Ethereum · Polygon
CustodyNone, ever

Illustrative register feed. Solana sees a commitment, a merchant id, the rail, which verifiers agreed and when. Ethereum sees one Merkle root per epoch.

What it is

A chain proves a transfer. It does not prove a sale.

A transaction hash says that coins moved. It says nothing about what was bought, who received it, or whether the seller accepted it. Lóng Protocol adds the missing half and keeps the details with the two people who were there.

Prove

Independent verifiers confirm the transfer, the merchant signs the receipt, and a commitment is recorded on Solana. Each epoch of records is anchored on Ethereum.

Keep private

By default only a hash goes public. Amount, items and parties stay encrypted with the payer and the merchant. Show one field to one person when you need to.

Connect

Any rail in, one register out. Wallets, point-of-sale apps and venues speak LPR-1, one request format for every coin LongPay accepts, so a proof means the same thing everywhere.

How it works

Four steps between a scan and a proof.

Watch one HK$42 coffee, paid in USDT on Tron at a counter in Sheung Wan, become a proof. The customer pays the way they always do. Pause the sandbox or jump to any step.

Sandbox · sample sale THRESHOLD 0 of 2 VERIFIERS · TRON detector oracle Tron · 0 confirmations PAY HK$42.00 5.40 USDT · Tron RECEIPT Lóng Café HK$42.00 · signed Acknowledge? Sign CUSTOMER any LPR-1 wallet ₮5.40 USDT CHARGE HK$42.00 waiting… Received 5.40 USDT MERCHANT LongPay app RECEIPT INV-0042 AmountHK$42.00 ItemsFlat white, 2 tarts Time8 Oct · 12:41 RailUSDT · Tron commitment 0x3f9a…e47b merchant · key 7f21 SIGNED ✓ payer co-signed 0x3f9a SOLANA register 0x3f9a…e47b● pending slot 451 208 337 + Pearls ETHEREUM epoch root
Step 1 · Pay, natively

The customer pays on the rail they already use.

They scan the LPR-1 request and send the exact amount from any wallet: Lightning, on-chain Bitcoin, or USDT and USDC on Tron, Ethereum or Polygon. The funds go straight to the merchant's own address. Lóng never touches the money.

Non-custodialAny walletNo new app for the payer
How the register learns that a payment happened, per rail
RailHow the register learns the payment happenedAt launchLater
LightningThe invoice preimage is the proof itself.1 of 1Same
Tron · USDT, USDCLongPay detector plus an independent oracle reading a Tron node.2 of 22 of 3 with a third verifier
Ethereum · PolygonDetector plus independent oracle, as on Tron.2 of 2Guardian-signed cross-chain queries
Bitcoin on-chainDetector plus independent oracle, as on Tron.2 of 2SPV proof against a header relay
New verifiers raise a threshold without changing the record format.A fake sale needs the detector, the oracle and the merchant to collude.
Architecture

Recorded on Solana. Anchored on Ethereum.

Two chains, two jobs. Solana records every proof as it happens, cheaply enough that a HK$42 coffee is worth recording. Ethereum holds the Merkle root of each epoch, so any proof can be checked on the most widely trusted settlement layer by anyone with a node.

Solana · record layer Every proof · sub-second · about US$0.01 0x3f9a…e47b · TRX · 2/2 · confirmed 0xa71b…0812 · LN · 1/1 · confirmed 0xe204…77c3 · POL · 2/2 · confirmed 0x5cd0…b9a4 · BTC · 2/2 · confirmed Merkle tree of epoch 1 482 root 0x9b2e…4f10 Ethereum · anchor layer One root per epoch · PoPAnchor contract Latest anchor anchorEpoch 1 482 · 4 proofs root 0x9b2e…4f10 signers 2 of 3 · EIP-712 ✓ Anchored on Ethereum

Why two chains

S
Solana, because every sale counts

A coffee, a taxi, a bar tab. Recording each one needs sub-second finality and a cost close to zero. Solana gives both.

E
Ethereum, because auditors already check it

Accountants, banks and counterparties know how to read an Ethereum contract. Each epoch root is signed by a threshold of anchor signers, at least one of them outside LongPay, and stays there permanently.

∴
One proof, checkable on both

Given a commitment, anyone can fetch its Merkle path from the register and check it against the root on Ethereum with a few lines of code.

  1. 1Look up the record on Solanarecord status, rail, verifier bitmap
  2. 2Fetch its Merkle pathepoch and sibling hashes
  3. 3Recompute the leaf and the rootleaf = keccak(keccak(commitment ‖ merchant ‖ rail ‖ time))
  4. 4Check the root in PoPAnchor on EthereumverifyLeaf on the anchor contract

Sample data. The live verifier will accept any commitment from the register.

Check full proofs in the explorer demo
What a screenshot, a transaction hash and a Lóng proof can each prove
What it provesScreenshotTransaction hashLóng proof of payment
Coins movedNoYesYes · verified per rail
The seller accepted the saleNoNoYes · merchant signature
What was soldClaimedNoYes · disclosed on demand
A third party can check itNoOnly the transferYes · on Solana and Ethereum
Payer stays privateDependsAddress exposedYes · not recorded
Works across chainsManualOne chainYes · one format, every rail
Public and private register

Prove it to everyone, or to exactly one person.

Each shop and each sale chooses. Public records feed network stats and a verified-venue badge. Private records show nothing but the commitment and can disclose a single field on demand.

  • Private is the default. Only the commitment is public. The receipt is encrypted off chain; the keys stay with the payer and the merchant.
  • Selective disclosure. Each receipt field is its own leaf, so you can prove the amount to your accountant without the items, or the date to a landlord without the amount.
  • Public is opt-in. A venue that wants to show it takes crypto can publish fields, earn the verified badge and appear in network stats. It can switch back at any time.

Try it: tap Disclose on one field of the receipt.

Receipt · Lóng Café, Sheung WanPrivate
AmountHK$42.00 · 5.40 USDT
ItemsFlat white ×1 · Egg tart ×2
Time8 Oct 2026 · 12:41 HKT
RailUSDT · Tron · 2 of 2
Merchantlp:merchant:7f21 · signed
commitment 0x3f9a1c0d…e47b · verifiers 0b11 · status confirmed · epoch 1 482

On chain: commitment, merchant id, rail, verifier bitmap and time. Hidden fields can be proven one at a time.

What goes on chain

Six fields on Solana. One root on Ethereum.

The register is deliberately small. It cannot leak what it never stores.

Commitment
0x3f9a1c0d8e2b47a1…e47b

A hash of the full receipt. One changed character in the receipt changes it.

Merchant id
lp:merchant:7f21

A registry id, not a wallet address. The shop can rotate keys without changing identity.

Rail
TRX · USDT

Which chain the money moved on, so the right threshold applies.

Verifier bitmap
0b11 · 2 of 2

Which verifiers agreed. Anyone can check that the rail's threshold was met.

Status
pending → confirmed

Confirmed at threshold. A refund or correction is a new record that supersedes the old one, never an edit.

Confirmed at
2026-10-08 04:41:07 UTC

When the threshold was reached, from the Solana clock.

Epoch root · Ethereum
epoch 1 482 · root 0x9b2e…4f10 · 4 proofs · signed 2 of 3

One line per epoch in the PoPAnchor contract. Every proof in the epoch can be checked from Ethereum alone, with its Merkle path.

Never stored payer namepaying addressamountitemslocationphone or email

Amount and items appear only if the venue publishes that record. A payer who acknowledges a receipt adds their own Solana key, by choice.

Ecosystem

One protocol, four doors.

Lóng Protocol is the layer underneath products people already use. Each one is a way into the network.

The points layer

Pearls

Confirmed proofs and finished lessons earn Pearls. They are loyalty points, not a token you can trade: they live only in approved accounts, cannot be sent to anyone, and are spent as discounts. Partners can issue their own points under the same rules.

Approved accounts onlyNo transfersNo cash valueCapped per dayExpire when unused
Earna confirmed proof, as payer or merchant, or a finished lesson
mint →
Holdin an account LongPay approved
burn →
Redeemas a discount at a shop
Principles

Three zeros we will not move.

0%

Fee on the sale

We never take a percentage of a transaction. Plans are flat and monthly, so a busy night costs the same as a quiet one.

0custody

Your keys, your money

Funds go wallet to wallet on the native chain. Lóng records proofs. It never holds, routes or converts a payment.

0tokens

Nothing to buy first

No protocol token and no staking. Pearls are points. The apps pay the fee for writing a proof, not the people paying.

Build on Lóng

A payment request anyone can read.

LPR-1 is the request format every Lóng wallet and point of sale understands. One object says what is owed, which rails are accepted and where the proof goes.

  1. Request. The merchant app issues an LPR-1 request with the accepted rails and a receipt schema.
  2. Pay. Any wallet pays on one rail and returns the transfer reference.
  3. Verify. The verifier set for that rail checks the transfer and attests on Solana.
  4. Record. The merchant's receipt key co-signs the commitment. At threshold the record is confirmed, and your app reads it back with one call.
  5. Anchor. At the end of the epoch, the root of all confirmed records is signed and written to Ethereum.

        
Record layerSolanaAnchor programs: pop_register (merchants, verifiers, per-rail thresholds, records, epochs) and pearls
Anchor layerEthereumPoPAnchor: one root per epoch, EIP-712 signatures from a threshold of anchor signers, governed by a multisig
VerificationPer-rail verifier setLightning preimage · detector + independent oracle on Tron, EVM and Bitcoin · thresholds rise as verifiers join
Request formatLPR-1One JSON object: amount, accepted rails, receipt schema, proof destination
PrivacyPrivate by defaultCommitment only on chain · receipt encrypted off chain · per-field disclosure
EconomicsNo protocol tokenFlat plans · 0% on the sale · proof fees paid by the apps · Pearls are non-transferable points
Where we are

Built in order, shown as it ships.

The contracts are written and tested but not yet audited or deployed. This is the order the network goes live in.

  1. 01Done · Oct 2026

    Spec and contracts

    Register and Pearls programs on Solana, PoPAnchor and a Pearls reference on Ethereum. End-to-end tests pass.

  2. 02Next

    Signed receipts in LongPay

    Every sale gets a receipt and a merchant signature inside the app, before anything touches a chain.

  3. 03Planned

    Register on Solana devnet

    LongPay writes real proofs to devnet. The program is audited before mainnet.

  4. 04Planned

    Pearls on chain

    Pearls move from the LongPay database to the closed-loop program, after legal sign-off.

  5. 05Planned

    Independent verifiers

    An oracle outside LongPay joins every rail, and Ethereum anchoring starts with an outside signer.

  6. 06Planned

    Explorer and private mode

    A public register to look up any proof, and per-field disclosure for payers and merchants.

    Preview the demo
Early access

Start proving payments.

Merchants already on LongPay get proofs first. Wallets, venues and developers can join the verifier set and the SDK programme, from Hong Kong outward.