INTMAX main

Instead of splitting liquidity across separate bilateral paths, INTMAX3 groups multiple participants around a shared channel state. That means balances stay confidential, liquidity is used more flexibly, and payments do not depend on a separate path for every pair of users.

INTMAX3 introduces multi-party payment channels. Multiple participants can share one channel state, keep balances confidential, and move payments without depending on separate liquidity paths for every pair. Private payments need better liquidity use.

Private payments shouldn’t feel like liquidity management. INTMAX3 uses multi-party payment channels with shared capacity and confidential balances, so small payments don’t depend on pre-funding every path.

Agent payments change what payment infrastructure needs to optimize for. A person might make a few transactions a day. An agent can make hundreds of small payments in the background: API calls, data requests, model access, compute, content unlocks, and payments to other agents. That is why x402 is an interesting signal. It treats payment less like a checkout flow and more like a native internet action: request a resource, pay, get access. Once payments become that granular, small inefficiencies get expensive fast. A fee that looks fine on a $100 transfer can break a $0.02 API call. A channel that requires too much pre-positioned liquidity becomes clunky when agents need to pay for many services across many contexts. There is also the privacy problem. A public payment trail can reveal more than the transfer itself. It can show which tools an agent used, which data it bought, how often it paid, and roughly what kind of task it was running. For agent micropayments, cheap is not enough. The payment layer also needs privacy and better capital efficiency. INTMAX3 is being built around multi-party payment channels with confidential balances. Instead of forcing every payment path to depend on isolated liquidity, a channel can support shared capacity across multiple participants. For agents, that matters. You do not want capital sitting in the perfect place before an agent can pay a few cents for a resource. You want small payments to clear without turning liquidity management into the product. Privacy matters for the same reason. If agents are paying APIs, services, and other agents all day, those payments become behavioral data. Over time, that data can leak workflows, strategies, and business logic. INTMAX3 keeps balances confidential inside the channel using encrypted balance ciphertexts, so balance updates can be checked without exposing balances as plaintext. It also adds a post-quantum authentication path verified inside the proof pipeline. If x402 points to a world where payments become native to HTTP, INTMAX3 is working on the private payment infrastructure that those flows will need underneath.

If payments become native to the internet, the layer underneath has to change too. INTMAX3 combines confidential balances with multi-party channels, so private payments can clear without liquidity management becoming the whole job.

Every time you transact on a public ledger, you pay a tax. Not in gas fees, in data. Your entire transaction history is exposed forever by default. You'd never accept this from a bank. You shouldn't accept it from your chain. Stop paying the surveillance tax, choose privacy.

1. Channel update A new off-chain state is constructed for the channel. In practice, this is where the parties agree on how balances and channel state should change before anything is pushed into the proof system. The key point is that the state transition is prepared off-chain first, instead of exposing the raw payment flow directly on the public chain. 2. Signature/authorization Once the updated state is formed, it has to be authorized by the channel participants. This is the authentication layer of the flow: the system needs cryptographic proof that the proposed state transition was actually approved by the right parties, rather than injected by an external actor or forged after the fact. In the current framing, this is represented as a post-quantum authorization path. 3. Validity proof After authorization, that approval is checked inside the validity proof pipeline. This is the important distinction: the system is not just collecting signatures at the application layer and asking users to trust them. The authorization data is pulled into the proof flow itself, so the verifier checks that the state transition satisfies the protocol rules and that the corresponding authorization conditions were met before settlement is accepted. 4. Private payment/settlement Once the proof pipeline accepts the transition, settlement can move forward without revealing balances in plaintext on the public chain. The result is a payment flow where authorization is enforced, validity is proven, and privacy is preserved through settlement rather than being treated as an afterthought. The point of the design is not just to add a signature. It is to bind authorization and privacy into the same proof-oriented flow. If private payments are meant to hold a longer security horizon, the authentication model matters just as much as the settlement model.

INTMAX3 combines encrypted balances with post-quantum authentication in the proof flow. Channel updates are authorized off-chain, verified inside the validity pipeline, and settled without exposing balances. Private payments need a longer security horizon.

Most privacy models still depend on a shared pool that needs to stay sound forever. INTMAX works the other way around. Users hold their own balance proofs and transaction history, while the protocol keeps almost nothing on-chain. This shifts the main soundness risk away from a central pool and onto individual proofs.

INTMAX3 is aiming for the thing payment channels always promised: instant payments without turning liquidity into a parking lot. Multi-party channels let users share capacity while balances stay confidential.

Lightning made instant settlement feel possible. INTMAX3 asks if the same UX can be private, post-quantum, and less wasteful with capital. That is the point of multi-party channels with confidential balances. Testnet on Q3

Imagine the following: An AI agent pays for compute every hour. On public rails, that payment is more than a transfer. It tells outside observers which compute provider the agent uses, how often it runs, when activity spikes, and whether usage is growing or slowing down. Now add storage. Then APIs. Then data access. Then subscriptions. Then payments to other agents. After a while, the wallet stops looking like a wallet and starts looking like an operations log. This is already uncomfortable for humans. A linked wallet can expose where you move funds, who you interact with, how often you transact, and which services you use. For companies, the leak is larger. Vendor payments, recurring costs, treasury flows, partner relationships, and internal cadence can all show up as transaction metadata. For agents, the problem gets stranger because the payment trail can reveal how the system behaves. A transaction graph is not source code. But it can still show dependencies, routines, and changes in activity. That is enough to be useful to competitors, attackers, data brokers, or anyone watching the chain. This is the part that gets missed in most “AI agents need crypto” takes. Agents do need financial rails. But if those rails are public by default, every useful agent becomes easier to study precisely because it is active. More usage means more metadata. More metadata means a clearer picture of what the agent depends on. So agent payments are not only about UX, stablecoins, or wallet automation. They are also about metadata leakage. INTMAX was built for this category of problem. The goal is not to make agents mysterious. It is to make their financial activity less revealing than an open operations log. If software is going to move money, the transaction layer needs to leak less.

We don't make Intmax4. The next version, Intmax3, should be the answer.

Cash works because it doesn't carry a public history of every hand it passed through. Onchain assets often do. When transfer history becomes readable, the asset starts carrying baggage. Private transfers help money stay fungible.

INTMAX is built for one simple idea: You should be able to transfer the assets you already own without exposing your financial history.

Quantum isn’t breaking Ethereum today. But IBM just put $10B behind quantum computing, and Ethereum is already mapping post-quantum upgrades. Serious crypto infrastructure has to be built for the threat model that comes next, not only the one we have now.

A transfer you make today could be decrypted by a quantum computer that doesn't exist yet. That's why @NIST spent eight years standardizing post-quantum cryptography. INTMAX3 is designed around those standards with account auth built for that threat model.

Most privacy tools put you in a binary: hide your activity or prove you're clean. INTMAX has a third option: Proof of Innocence allows you to prove your funds aren't from blacklisted sources without revealing your transaction history. Compliance and privacy aren't opposites.

Payments need privacy, and that's the gap we're filling.

Our new version further advances the stateless privacy model. Private transfers remain core, but contract-driven transaction insertion opens a new path: logic can request transactions without turning INTMAX into a generic public smart contract chain. Privacy + programmability.