Crypto Joke:
Join crypto, they said, it’s great because we have:
- Anonymity (just slowly rotate your head with your passport’s first page open)
- Decentralization (except if your region is restricted)
- Ownership of your assets (until your account is suspended — please show proof of funds and address)
The crypto industry has evolved from a cypherpunk haven to a regulated space where speculation and compliance dilute the original principles of decentralization, freedom, and privacy. It’s a common phase for innovations to become mundane and face a crisis of new ideas. We are determined to make crypto exciting again, which is why even Vitalik mentions our “weird ideas” — because being weird is more fun.
Our Vision: We aim to decentralize asset transfers by creating the most efficient and most stateless infrastructure driven by the global demand for privacy. So, how do we plan to achieve this, and why is it crucial for the industry? Let’s dive deeper!
Statelessness in the Age of Statism
Existing ZK-rollups shift computation costs away from the Layer 1 (L1) blockchain but still need to post all necessary data on L1 for verifying balances. This includes transaction details such as sender, token index, amount, and recipient, which limits the number of transactions per second that can be supported by the rollup
Okey, what is Statelessness — simply it is when all the calculations and data storage are on the client side.
On step back why it is so important:
A key challenge for blockchains is data availability, which means that transaction data must be accessible to verify the blockchain’s current state, like account balances. This affects both Layer 1 blockchains and rollups. Layer 1 blockchains ensure data availability by making all transaction data publicly accessible. Rollups rely on the underlying blockchain’s data availability, posting all transaction data to Layer 1 (e.g., via calldata on Ethereum). Because this data must be updated across many nodes, it limits the number of transactions per second that the blockchain or rollup can support.
However, for simple payment transactions in INTMAX, it’s enough to provide a commitment to the set of transactions in a block (like a Merkle tree root) and the senders’ signatures confirming they received inclusion proofs. Users can then generate Zero-Knowledge proofs (ZK-proofs) of their balances by combining proofs of their sent transactions with proofs of received transactions. Our rollup design uses this method to increase throughput compared to existing alternatives.
In simple words you make all transactions off-chain between users and it makes significant impact on Privacy Side
Privacy and Scalability
INTMAX hosts only 5 bytes information on-chain, block producer doesn’t receive transactions history, and in general only thing that block producers and aggregators do is producing blocks and trees. This design allows permissionless block building in parallel, without leader election or coordination between block builders. Block builders don’t verify transactions’ validity, allowing them to be fully stateless and creating a simple, censorship-resistant rollup.
INTMAX inherits Ethereum’s security and stateless approach on client side is O(1) verified with cyclic Recursive ZK-Proofs
This method allows INTMAX to validate the entire chain of transactions at a constant and minimal cost. We can prove the entire chain of ZKPs by verifying the most recent one, as each ZKP inherently verifies the previous one. This ensures the chain of correctness extends back to the origin, enabling fast and efficient system verification. Our system consistently checks the whole transaction chain at a low cost, all on the user side.
With this technology, users can remain offline for a certain period and then synchronize and calculate the corresponding recursive zero-knowledge proof when back online.
Scalability
INTMAX uses less on-chain data than any existing rollup, supporting an upper limit of 7500 transaction batches per second on Ethereum, where each transaction batch can transfer an unlimited number of tokens to an unlimited number of recipients.
INTMAX can execute at least 100,000 transfers per second, with bulk transfers incurring no additional data costs. The system can also parallelize to the number of users.
Decentralization
Very low node requirements help make the system fully decentralized, promoting a healthy Layer 2 (L2) concept that prioritizes developer convenience along with non-negotiable scalability and security.
User Experience:
INTMAX offers advanced technology for fast, low-fee, private, scalable, and stateless off-chain transactions. But how it will look like for user?
- We need wallet that supports INTMAX protocol, the first will be our own INTMAX Wallet one the most secure wallet on the market with fantastic functionality like Link Transfer(you can send crypto to your granny, just knowing her phone number or to your friend by using his twitter handle)
- User should top up this wallet with ERC20 tokens(We support only Ethereum network, because we are the most native Ethereum scalability solution)
- User simply locks their preferred amount of crypto in INTMAX Rollup contract(let’s say 1,000 USDC ERC20). It will be pretty same as in liquidity pool. Just with one button “Use INTMAX Network”
- Now User has assets(1,000 USDC) on INTMAX and can send it to other people in the INTMAX network and also receive transactions.
- For user it is quite simple you add INTMAX address of recipients and instantly executed with client side verification, including several transfers to different recipients in one transaction without additional cost. Let’s say User sent 3 transactions 300 USDC, 500 USDC and 100 USDC, also User received on transaction with 500 USDC. Now his balance 600 USDC
- To withdraw user’s assets they just unlock current balance from the INTMAX and pay fee to INTMAX. User has 600USDC balance and they could unlock it simply press the button Withdraw to Ethereum Network and get assets with 0.5% withdrawal fee.
[Advanced content] How transfer protocol looks like from the inside:
In this example, Alice wants to send 5 coins to Bob.
a) Alice starts by sending the hash of the the transaction batch, consisting of a single transaction of 5 coins to Bob, and a random salt to an aggregator.
b) The aggregator then constructs a merkle tree consisting of Alice’s transaction batch hash and the transaction batch hashes of other senders.
c) The aggregator sends the merkle proof of Alice’s transaction batch to Alice.
d) Alice verifies the merkle proof and signs the merkle root together with the pre-determined extradata e. This signature is sent back to the aggregator.
e) The aggregator collects the signatures from all users, constructs the transfer block, and sends it to the rollup contract.
f) Alice watches the blocks that are added to the rollup contract until the block containing her transaction is published.
g) Alice updates her balance proof by adding her transaction batch, the salt and the merkle proof.
h) Alice sends to Bob her updated balance proof.
h) Bob updates his view of the rollup blocks.
i) Bob updates his balance proof by merging it with the balance proof he received from Alice.
Conclusion:
We have many use cases like financial markets, trading, gaming, and AI where fast transactional services with adjustable privacy and billions of transactions are needed. These services must be cheap, off-chain, secure, and verified. INTMAX has built this technology, and you should try it. We will be in testnet in August — sign up here to be one of the first!
Check the full paper about Intmax2 here
And watch the video about INTMAX here
