Hinkal & P2Flux: Private Settlement for Direct USDC Payments
Key takeaways
- Hinkal and P2Flux are starting work on private settlement for merchants who accept USDC through P2Flux on Base.
- P2Flux already took the payment provider out of the flow: no merchant account, no custody, and the merchant's share lands in the merchant's wallet inside the payment transaction itself. Hinkal takes the public ledger out of the merchant's side of that flow.
- Merchants receive into a Hinkal deposit address. Every incoming payment is screened with Chainalysis on arrival, and only funds that pass move into the private balance. Unsolicited dust and transfers that fail screening never mix with the merchant's funds.
- Subscriptions keep running exactly as P2Flux runs them today. Hinkal sits after the renewal, not inside it.
- No merchant account or personal details, such as name or email, are required. Viewing keys keep every private balance disclosable to an auditor or regulator on request.
What this partnership is for
A merchant who accepts stablecoins on a public chain publishes their business. Every sale, every renewal, and every payout lands at an address anyone can open in a block explorer. Add up the incoming transfers, and you have the merchant's revenue. Count the monthly renewals, and you have the subscriber base. Follow the outgoing transfers, and you have the suppliers, the partners, and the exchange the merchant cashes out through.
P2Flux is non-custodial payment infrastructure for direct USDC payments and recurring billing on Base. It splits each payment inside a single transaction, so the merchant's share goes straight to the merchant's wallet and P2Flux never holds a balance. Hinkal and P2Flux are now working to make the receiving side of that flow private. P2Flux merchants will be able to settle into a private balance controlled by the wallet they already use, with every incoming payment screened before it reaches that balance.
This is the start of the work, not the finish. The integration is being built now, and private settlement reaches P2Flux merchants as it ships.
Why P2Flux exists
P2Flux was first built for a subscription platform for sports analysts, where card payments and crypto recurring billing both fell short. Today it is built more broadly for online businesses that want direct USDC payments and recurring billing. The team runs a platform where sports tipsters sell predictions to subscribers, and they hit two walls that every merchant in a restricted vertical knows well.
The first wall is acceptance. Card processors routinely refuse businesses that sit close to betting, and a merchant without a processor cannot sell. The second wall is recurring billing. Recurring crypto payments have historically been much less standardized than card-on-file billing. A customer had to come back and pay by hand every month, and many do not.
P2Flux answers both. There is no application, no approval queue and no merchant account. A buyer pays from a wallet they already hold, through MetaMask, Rabby or a QR scan, and a wallet holding only USDC can still pay where the merchant enables network fees in USDC. A subscription is approved once from the buyer's wallet and renews under that authorization until the buyer cancels or revokes it. Merchants connect through PHP and JavaScript SDKs, a WooCommerce plugin, no-code payment links, a drop-in for Tipster Script, and P2Flux Gate, a Telegram bot that admits paying subscribers to a private channel and removes them when they stop paying.
P2Flux solved how the payment arrives. What the chain shows once it has arrived is the part Hinkal adds.
Why we are partnering
On Base, the ledger is a complete record of a merchant's commercial life. For the merchants P2Flux serves, that record creates two separate problems.
Exposure. Take a tipster with 2,000 subscribers renewing at 30 USDC a month. That is a 60,000 USDC monthly business, and anyone who finds the receiving wallet can calculate it to the dollar, track churn week by week, and watch where the money goes after it lands. Competing tipsters can read it. So can every counterparty the merchant negotiates with. A card processor would never publish a merchant's statement. A public chain publishes it by default.
Commingling. A public address cannot refuse a transfer. Anyone can send to it, and once the address is known, anyone does. Dusting is the familiar version: tiny unsolicited amounts sent to a business address to trace its activity, or sent from flagged addresses to attach the business to them on-chain. Ordinary payments carry the same problem in a quieter form. A merchant has no way to check every payer's history before the money lands, so funds of very different origins end up in one balance. When a bank, an auditor or an off-ramp provider reviews that balance, the merchant has to explain all of it, including transfers they never asked for. Regulated finance solved this long ago with a simple rule: check funds before they join the books, and keep anything that fails apart.
Hinkal addresses both at the receiving end, and leaves P2Flux's checkout untouched.
The fit also runs deeper than the technology. P2Flux is stateless by design: it creates no buyer accounts, hosts no order history, and leaves customer and order data in the merchant's own systems. Hinkal works on the same principle. It runs no KYC on users and collects no personal information. It screens money, not people. When both systems are designed to minimize the data they collect, neither has to become the data store the other was built to avoid.
How it fits the P2Flux model
The integration touches two points in the flow. Where the merchant’s share is sent, and where the buyer can pay from.
Today that share lands in the merchant's public wallet. With Hinkal, it lands at a Hinkal deposit address, generated for the merchant through the Hinkal API. A deposit address is an ordinary address. P2Flux's split transaction pays it exactly as it would pay any wallet, so the buyer, the checkout, and the payment logic stay as they are.
From there, Hinkal takes over:
- Each incoming payment is screened against Chainalysis on arrival.
- Funds that pass move automatically into the merchant's private balance, held inside Hinkal's smart contracts on Base and controlled by the merchant's existing wallet key.
- Funds that fail stay at the deposit address as a public balance. They never mix with the private balance. The merchant still owns them and can return them to the sender or move them elsewhere.
- Dust and unsolicited transfers are handled by the same rule. They are screened like any payment, and nothing that fails reaches the private balance.
- The merchant can switch to a fresh deposit address in a single step at any time and keep receiving.
The merchant connects the same wallet to Hinkal Pay at pay.hinkal.io and sees the private balance there. Payouts to partners, payments to suppliers, and withdrawals to an off-ramp all run from that balance, with amounts and counterparties shielded on-chain. Hinkal never holds the funds or the keys.
Subscriptions need no special handling. Each renewal runs exactly as it does today, whether P2Flux collects it or the merchant’s system does; the renewal pays the deposit address, and Hinkal shields it. The recurring logic stays with P2Flux, where it belongs.
On the buyer side, P2Flux has built “Pay privately with Hinkal”: the buyer pays from their Hinkal private balance through the normal P2Flux flow. Initially, this applies to one-time payments.
To be exact about what stays visible: The buyer's payment into the deposit address is a normal on-chain transfer, so an individual payment can still be seen arriving. When the buyer pays privately with Hinkal, the buyer’s side is also shielded. What leaves public view is everything that makes the merchant legible: the main wallet, the balance it accumulates, and every payment made out of it.
For P2Flux, the work is an API integration. There are no smart contracts to write and none to modify. Hinkal ships the API alongside SDKs for JavaScript, mobile and Go, so the integration fits next to the SDKs P2Flux already maintains.
Where private settlement matters for P2Flux merchants
P2Flux serves online businesses that want direct USDC payments and recurring billing, including merchants that traditional payment infrastructure does not serve well. In each case below, the P2Flux flow stays the same. Hinkal changes only what the chain reveals after the merchant gets paid.
Tipsters and subscription sellers. This is the business P2Flux was built for. Recurring revenue on a public chain is unusually easy to read: identical amounts, arriving on a schedule, from a growing or shrinking set of wallets. A private balance keeps the merchant’s accumulated earnings and outgoing activity off the public ledger, and keeps a competitor from pricing against numbers they should never have seen.
Paid Telegram channels and private communities. P2Flux Gate already runs membership without touching money: pay, get a one-use invite, stop paying, lose access. The payments behind that membership are the only part still in public. With private settlement, the community owner's private balance and outgoing payouts stay as private as the channel itself.
Marketplaces and platforms paying many sellers. P2Flux can be integrated into marketplaces and platforms, with each payment settling directly to the relevant seller’s wallet. On a public chain, each seller's earnings are readable, and so is the platform's take. Settling each seller into their own private balance keeps individual earnings between the seller and the platform, and keeps the platform's economics off the explorer.
High-volume merchants who convert to fiat. Every off-ramp provider runs its own checks on the funds it receives, and a merchant converting USDC at volume goes through those checks constantly. Screening at the point of entry means the private balance only ever holds funds that passed Chainalysis before they arrived, with a record of that check for each deposit. The merchant brings a balance with a documented origin to the off-ramp, instead of explaining a mixed one after the fact. Funds that fail stay separate, owned by the merchant and handled on the merchant's terms.
Privacy that stays compliant
Privacy here does not mean hiding. It means selective disclosure: the market sees nothing, and the parties entitled to see get exactly what they need.
Hinkal is not a mixer. A mixer pools whatever arrives and breaks the link between sender and receiver, with no screening at all. Hinkal screens every deposit with Chainalysis before it can enter a private balance, so flagged funds never get in. Viewing keys let a merchant disclose their full history, or specific transactions and time ranges, to an auditor, a tax authority or a banking partner.
For a merchant in a restricted vertical, that combination answers the question an off-ramp or a regulator will ask. Where did this money come from, and was it checked? The answer is on record, and it is checked at the door. Privacy and compliance are the same problem seen from two sides: who sees what, when, and why.
Why Hinkal
Hinkal is compliant privacy infrastructure for stablecoin payments. Wallets, amounts, and counterparties remain private while settlement stays public, auditable, and compliant. It runs across Solana, Tron, Robinhood chain, Arc by Circle, and EVM networks including Base, Polygon, Arbitrum, Optimism, Tempo, and has processed more than $1B in private on-chain volume.
On-chain privacy on its own is not hard to find. Privacy that screens funds at entry, stays disclosable to the parties a business answers to, keeps custody with the user, and settles at normal on-chain speed is a much narrower category. That is the problem Hinkal is built to solve. Hinkal has completed 6 independent security audits by Quantstamp, Zokyo, zkSecurity, Secure3, and Hexens, and runs a public bug bounty through Immunefi. It has raised $6M from investors including Draper Associates and is a member of the Mastercard Crypto Partner Program.
.png)
.png)
.webp)
