Hi,
I’m currently building a platform that bridges a centralized backend with a Smart Contract on Polygon. The Smart Contract follows the ERC1155 standard, which enables batch token minting. The core idea of the application is to perform minting and other on-chain operations on behalf of customers who may not be familiar with Web3 technology.
I’m designing and coding the system architecture to handle operations at scale, aiming to support hundreds of concurrent operations. For example, consider 10-20 customers simultaneously minting 100 tokens each — this would create a substantial payload for the blockchain.
Currently, my backend utilizes a “single blockchain wallet account” to pack requests into batches, process operations, await confirmation, and then repeat the cycle. However, a significant limitation of this approach is that a single account can only process one operation at a time, which bottlenecks the system.
I’m exploring the idea of using “multiple blockchain wallet accounts” to simultaneously process operations, thereby increasing system capacity and throughput.
Do you have any recommendations or best practices for scaling such a system? Are there alternative approaches, frameworks, or architectural patterns you would suggest to efficiently manage high on-chain transaction volumes?
Hi there,
in general:
Try to gain efficiency off-chain by evaluation for which actions on-chain txs are absolutely needed and where they maybe aren’t.
For the bottleneck problem, you could definitely have multiple wallets sending batched txs concurrently (depends on your backend language how easy this is).
I think this would be wise from a security and risk perspective.
But also it should be no problem to hammer out batch txs with one wallet and track the status of each tx async!
Depending on your programming language, you can wait for tx results and process them in concurrent threads.
Coming back to the first point, try to think if all those mints are really necessary or if you could i.e. store some balances in a DB and only mint when a user wants to exit the App or something.
1 Like
But also it should be no problem to hammer out batch txs with one wallet and track the status of each tx async!
I could continuously increase the nonce value for each transaction, but the problem complicates whenever any of the previous tx fails for any reason then each transaction must be reverted and resend again to the chain.
Coming back to the first point, try to think if all those mints are really necessary or if you could i.e. store some balances in a DB and only mint when a user wants to exit the App or something.
Minting is just one of the features supported by the Smart Contract, a token owner (for example the system backend wallet) may process more operations for each token. Very likely the wallet pool may reduce traffic and increase the throughput.
hm no, if a transaction reverts, the nonce also gets counted. You only run into problems with the nonce if a transaction stays pending for a long time. Then you might need to increase the gas limit for example, to speed things up.
But a failed / reverted tx is still a valid tx and the nonce gets counted.