As we are designing our protocol and platform for Rubix and NFT Engage, we are standing in front of architectural decisions that many other projects deal with. We are still early and so, as with any cutting edge technology, we are all reinventing each others' wheels and design the same things over and over. Following post muses about web3 platform architecture from the perspective of a web2 architect.

Many current web3 DApps use relatively simple architecture.

• Web App usually uses React.js and libraries like web3.js or ethers.js to interact directly with smart contracts.

• Indexer is used to scale access to information stored on blockchain by processing events (logs) produced by contracts and aggregating them in a database queriable through API (usually GraphQL). Major player in this space is The Graph Protocol.

• Permanent storage is mainly represented by IPFS and Arweave and is commonly used as a replacement for object storage like AWS S3.

This is great because it lowers the barrier for deployment and updates. There is almost no infrastructure to pay for and manage. No complex microservices and databases.

It comes at a cost though. You cannot easily manage additional information about users, the frontend web applications grow large and complex and hence become slow and clunky, often unusable on mobile phones. There is no (simple) way to build a native mobile app with this architecture. There is no easy way to handle errors or pending transactions - as long as everything works, it is all good, but any transaction error results in users fishing for transaction hashes and going through (Ether/Bsc/Polygon)scan interface trying to figure out what went wrong.

More powerful and wider adopted platforms end up coming up with more complex architecture, which I believe is going to become a standard as the web3 space matures.

There are obviously pros and cons in bringing more infrastructure components into the picture. Suddenly you need to deploy it to one of the large(r) cloud providers and manage it. It brings centralization into the space that is trying to be decentralized, but it unlocks possibilities.

It allows us to smooth out the user experience, build native mobile clients, integrate into existing web2 systems and so on.

The question is whether the way to go is to build your own abstractions or use existing providers like Moralis or Tatum. This depends on each developer team as there are often no precedents in what they are building.

I feel like what is missing is a framework or an SDK which we could use to start building the API "from scratch" and rely on our own infrastructure which would still provide basic building blocks for exposing custom smart contracts through API without going through third party servers.

This is how I envision such system/framework:

• Relatively generic API layer which defines high level primitives on the outside, but allows implementing the contract specifics on the inside.

• The caching layer would allow for capturing the operations and interactions users intend.

• The execution layer, which picks up operations from the cache and broadcasts transactions to the blockchain allowing for error handling, retries, timeouts etc.

• Wallet Management for optional custody of user wallets and being able to offer "WithSig" methods on contracts relayed by dedicated project wallets.

Ideally you'd simply fork a repository, fill in the blanks (pardon my oversimplification:)), deploy and viola your own SaaS like solution for blockchain interactions is ready.

It can come with "batteries included" for standard contracts like ERC20, ERC721 and ERC1155, but should be easy enough to extend for custom ones.

Another important consideration is decentralization. I believe some/most of these components could be eventually run by multiple/many participants in the community and synchronized at a higher level through some kind of proxy where the new "nodes" would connect based on a governance consensus (staking, proposal vote etc.) which would allow us to at least partially decentralize a web2 like infrastructure.

In any case, when you are building smart contract protocols, you should ideally make it possible for users and especially other developers to interact with them directly on chain. You may need to have some privileged access from the wallets managed by the API system (think waiving protocol fees), but that should be it.

I believe web3.2 (as a pun on bringing web3 closer to web2 UX) is the next evolution. Make your smart contracts permissionless and offer smooth access to them through API for those who cannot or do not want to interact with the chain directly.

This will require new tools, SDKs and frameworks to be developed, but since we are in the midst of bear market, it seems everyone is doing just that.

As we are designing our protocol and platform for Rubix and NFT Engage, we are standing in front of architectural decisions that many other projects deal with. We are still early and so, as with any cutting edge technology, we are all reinventing each others' wheels and design the same things over and over. Following post muses about web3 platform architecture from the perspective of a web2 architect.

Many current web3 DApps use relatively simple architecture.

• Web App usually uses React.js and libraries like web3.js or ethers.js to interact directly with smart contracts.

• Indexer is used to scale access to information stored on blockchain by processing events (logs) produced by contracts and aggregating them in a database queriable through API (usually GraphQL). Major player in this space is The Graph Protocol.

• Permanent storage is mainly represented by IPFS and Arweave and is commonly used as a replacement for object storage like AWS S3.

This is great because it lowers the barrier for deployment and updates. There is almost no infrastructure to pay for and manage. No complex microservices and databases.

It comes at a cost though. You cannot easily manage additional information about users, the frontend web applications grow large and complex and hence become slow and clunky, often unusable on mobile phones. There is no (simple) way to build a native mobile app with this architecture. There is no easy way to handle errors or pending transactions - as long as everything works, it is all good, but any transaction error results in users fishing for transaction hashes and going through (Ether/Bsc/Polygon)scan interface trying to figure out what went wrong.

More powerful and wider adopted platforms end up coming up with more complex architecture, which I believe is going to become a standard as the web3 space matures.

There are obviously pros and cons in bringing more infrastructure components into the picture. Suddenly you need to deploy it to one of the large(r) cloud providers and manage it. It brings centralization into the space that is trying to be decentralized, but it unlocks possibilities.

It allows us to smooth out the user experience, build native mobile clients, integrate into existing web2 systems and so on.

The question is whether the way to go is to build your own abstractions or use existing providers like Moralis or Tatum. This depends on each developer team as there are often no precedents in what they are building.

I feel like what is missing is a framework or an SDK which we could use to start building the API "from scratch" and rely on our own infrastructure which would still provide basic building blocks for exposing custom smart contracts through API without going through third party servers.

This is how I envision such system/framework:

• Relatively generic API layer which defines high level primitives on the outside, but allows implementing the contract specifics on the inside.

• The caching layer would allow for capturing the operations and interactions users intend.

• The execution layer, which picks up operations from the cache and broadcasts transactions to the blockchain allowing for error handling, retries, timeouts etc.

• Wallet Management for optional custody of user wallets and being able to offer "WithSig" methods on contracts relayed by dedicated project wallets.

Ideally you'd simply fork a repository, fill in the blanks (pardon my oversimplification:)), deploy and viola your own SaaS like solution for blockchain interactions is ready.

It can come with "batteries included" for standard contracts like ERC20, ERC721 and ERC1155, but should be easy enough to extend for custom ones.

Another important consideration is decentralization. I believe some/most of these components could be eventually run by multiple/many participants in the community and synchronized at a higher level through some kind of proxy where the new "nodes" would connect based on a governance consensus (staking, proposal vote etc.) which would allow us to at least partially decentralize a web2 like infrastructure.

In any case, when you are building smart contract protocols, you should ideally make it possible for users and especially other developers to interact with them directly on chain. You may need to have some privileged access from the wallets managed by the API system (think waiving protocol fees), but that should be it.

I believe web3.2 (as a pun on bringing web3 closer to web2 UX) is the next evolution. Make your smart contracts permissionless and offer smooth access to them through API for those who cannot or do not want to interact with the chain directly.

This will require new tools, SDKs and frameworks to be developed, but since we are in the midst of bear market, it seems everyone is doing just that.