While the horizon seekers insist that web3 is an entirely new world and ecosystem that will replace the current one, I still smile when I read posts from a decade ago where electronic payments would replace hard cash within a decade max.

Web3 is indeed a new paradigm, already creating a stadium full of ideas and projects that will reshape how we organize and operate. For starters, it will bring about new employment, governance, and business models.

When the DAO concept appeared in 2014 with MakerDAO, suddenly, things that were mere chimera out of Techno-fiction stories were becoming a reality.

However, what is not going to change is how the economy works. We are still using payment mechanisms that were with us thousands of years ago. We still have financial products that haven't changed in centuries. The world’s sovereign debts, corporate bonds, and stock markets won't go away in favor of DAOs, decentralized financial products, or blockchains. On the contrary, they will most likely be upgraded and revamped with these new technologies.

Eventually, this new technology stack will replace old systems, but it might only replicate the current business model, not fundamentally change or improve it..

This begs the question, how will we connect both worlds?

Today, a decentralized autonomous organization that needs to provide payment for standard services (i.e., pay taxes) has to do two or more steps to exchange its tokens into a currency that is accepted by banks and government entities.

There is a need for a new protocol that can enable all these organizations to leverage the TradFi, web3 speak for the traditional financial systems.

This protocol needs to connect these blockchain-based applications seamlessly with the fiat currency payment networks. It needs a set of smart contracts that would execute instructions outside of the blockchain-centered ecosystem back to the financial system.

These smart contracts would enable simple use cases like paying to a bank account or issuing a debit card sent to your home. Instead of having complex APIs, this protocol will take advantage of the flourishing new standards on the blockchain and enable an interdisciplinary and interoperable set of services via tokens and smart contracts.

If we want the web3 world to interact with the financial system, we must make blockchains aware of it. We can do this via oracles and triggers. Chainlink is an oracle network that securely enables access to real-world data and off-chain computation.

We can connect a bank account to a smart contract using oracles, allowing the decentralized code to know what the account balance is. The same logic applies when linking to other services, like credit card transactions and bill payments. For example, smart contracts can trigger the financial system to initiate or dispute a card transaction.

An issue with linking to legacy financial systems is that an intermediary can intercept vulnerable code as it moves between systems. For example, an attacker can manipulate the balance between the financial system and the blockchain code.

We need to have a more robust mirroring model, less prone to attacks to avoid this issue. In addition, we need to make a hybrid model with the financial system to enable the blockchain to directly access the source of truth.

One option would be to have the actors in the current financial system run nodes on the blockchain with particular adaptations to have the EVM on those nodes interface directly with their systems.

This particular node would enable smart contract access to the banking system’s information, securely connecting it to the blockchain. This information ranges from transaction information to balances and even FX prices. Moreover, it can be done in real-time when needed, where the smart contract can request (pull) this information rather than the node pushing to it.

Now that the information is available to the blockchain contracts, your distributed code can interact with this particular set of contracts to retrieve the information needed.

Security experts will sweat and swear by reading this statement. By definition, anything in web3 is not private. Blockchain-based technology stores the code and its state on the blockchain, where anyone can access it and read it. We cannot keep the account information in the blockchain because it would represent a security breach.

When a smart contract state changes, this is recorded on the blockchain as a transaction. The blockchain needs to record the new state, recording it for future interactions. Specific to Ethereum based chains, the smart contract's state and its code reside in the same place. On other chains like Solana, the data sits differently than the code. But even then, the data is on the blockchain, accessible to everyone.

This change of state is why executing smart contracts incurs gas fees. A transaction is incorporated into the blockchain to record this state change. Gas needs to be paid to the nodes to process this record. Not all functions incur gas fees. These are “read” functions that don't change the state of the contract, such as the ERC-20 token function balanceOf() which gives you the token balance of a specific wallet address.

These read only function calls can be used to retrieve the account information safely, because they cannot change the contract's state.

First and foremost, we need to bring a protection layer to authenticate whoever accesses this system. We cannot display a bank account balance to the world, at least not in the traditional financial system.

Using ERC-721 tokens -or NFTs- we can provide an earmark to which wallets could have permission to access this system. This NFT can be minted by the bank and transferred to the wallet that needs access. In addition, this NFT can be limited and non-transferable, avoiding having someone transfer the token out to another wallet.

When the smart contract executes the function, it checks the NFT balance of this wallet. If it sees the proper NFT, it can proceed with the rest of the logic. If not, it returns a grace error, better known in the HTTP world as a 403, explaining that this wallet doesn't have access.

This will only act as a "restricted list" model, where only those wallets with this specific token can access via this method, but it doesn't differentiate between the wallets.

To represent identity, the bank should have a relation of wallets and bank accounts sitting on their systems. The bank account owner can link its web3 wallet to its bank account, and receive an NFT token to prove it.

Then, the smart contract queries the bank system asking for the bank account balance connected to the wallet that initiated the call.

This model ensures that only a specific wallet can ask for the balance of a particular bank account and not other wallets.

In the web3 world, power resides on building automated logic that makes these processes seamless. With this model, we ask the wallet holder to execute the function on the smart contract every time, which creates usability issues. There might be instances where an authorized third-party protocol makes this inquiry.

If a protocol tries to execute the function, it will receive an error response of “restricted access” because it doesn't have the NFT, nor is the wallet inquiring for the balance the correct one.

The bank can issue a specific NFT token to solve this case, allowing this protocol to access the smart contract function.

But the identity piece still makes it hard. When the foreign protocol inquires about a wallet's bank account balance, somehow, we need to make sure the account holder authorizes it.

Here is where a not-so-known standard ERC-725 comes in handy. This protocol enables a "claims" model where the foreign protocol can obtain a claim from the wallet that states "its permission" to access the linked bank account's balance. This claim can be revoked at any time and allows the foreign protocol to call the function safely.

If the address calling the function is different from the address of whom we want to know the balance, then a claim must exist. This claim must be issued by the bank account's linked wallet and validated. The bank can act as the validator of this claim since it issued it in the first place.

Slowly, as web3 gets better defined and blockchain technologies mature, we will see more interactions between this new world and the traditional monetary world.

The more integrations and interactions that become available, the easier it will be for a day to day use of web3 in our lives. However, even when web3 gains enough critical mass of services to become independent of the traditional financial system, there will still be more to interconnect. Anyone can port the example in this article to more industries.

While the horizon seekers insist that web3 is an entirely new world and ecosystem that will replace the current one, I still smile when I read posts from a decade ago where electronic payments would replace hard cash within a decade max.

Web3 is indeed a new paradigm, already creating a stadium full of ideas and projects that will reshape how we organize and operate. For starters, it will bring about new employment, governance, and business models.

When the DAO concept appeared in 2014 with MakerDAO, suddenly, things that were mere chimera out of Techno-fiction stories were becoming a reality.

However, what is not going to change is how the economy works. We are still using payment mechanisms that were with us thousands of years ago. We still have financial products that haven't changed in centuries. The world’s sovereign debts, corporate bonds, and stock markets won't go away in favor of DAOs, decentralized financial products, or blockchains. On the contrary, they will most likely be upgraded and revamped with these new technologies.

Eventually, this new technology stack will replace old systems, but it might only replicate the current business model, not fundamentally change or improve it..

This begs the question, how will we connect both worlds?

Today, a decentralized autonomous organization that needs to provide payment for standard services (i.e., pay taxes) has to do two or more steps to exchange its tokens into a currency that is accepted by banks and government entities.

There is a need for a new protocol that can enable all these organizations to leverage the TradFi, web3 speak for the traditional financial systems.

This protocol needs to connect these blockchain-based applications seamlessly with the fiat currency payment networks. It needs a set of smart contracts that would execute instructions outside of the blockchain-centered ecosystem back to the financial system.

These smart contracts would enable simple use cases like paying to a bank account or issuing a debit card sent to your home. Instead of having complex APIs, this protocol will take advantage of the flourishing new standards on the blockchain and enable an interdisciplinary and interoperable set of services via tokens and smart contracts.

If we want the web3 world to interact with the financial system, we must make blockchains aware of it. We can do this via oracles and triggers. Chainlink is an oracle network that securely enables access to real-world data and off-chain computation.

We can connect a bank account to a smart contract using oracles, allowing the decentralized code to know what the account balance is. The same logic applies when linking to other services, like credit card transactions and bill payments. For example, smart contracts can trigger the financial system to initiate or dispute a card transaction.

An issue with linking to legacy financial systems is that an intermediary can intercept vulnerable code as it moves between systems. For example, an attacker can manipulate the balance between the financial system and the blockchain code.

We need to have a more robust mirroring model, less prone to attacks to avoid this issue. In addition, we need to make a hybrid model with the financial system to enable the blockchain to directly access the source of truth.

One option would be to have the actors in the current financial system run nodes on the blockchain with particular adaptations to have the EVM on those nodes interface directly with their systems.

This particular node would enable smart contract access to the banking system’s information, securely connecting it to the blockchain. This information ranges from transaction information to balances and even FX prices. Moreover, it can be done in real-time when needed, where the smart contract can request (pull) this information rather than the node pushing to it.

Now that the information is available to the blockchain contracts, your distributed code can interact with this particular set of contracts to retrieve the information needed.

Security experts will sweat and swear by reading this statement. By definition, anything in web3 is not private. Blockchain-based technology stores the code and its state on the blockchain, where anyone can access it and read it. We cannot keep the account information in the blockchain because it would represent a security breach.

When a smart contract state changes, this is recorded on the blockchain as a transaction. The blockchain needs to record the new state, recording it for future interactions. Specific to Ethereum based chains, the smart contract's state and its code reside in the same place. On other chains like Solana, the data sits differently than the code. But even then, the data is on the blockchain, accessible to everyone.

This change of state is why executing smart contracts incurs gas fees. A transaction is incorporated into the blockchain to record this state change. Gas needs to be paid to the nodes to process this record. Not all functions incur gas fees. These are “read” functions that don't change the state of the contract, such as the ERC-20 token function balanceOf() which gives you the token balance of a specific wallet address.

These read only function calls can be used to retrieve the account information safely, because they cannot change the contract's state.

First and foremost, we need to bring a protection layer to authenticate whoever accesses this system. We cannot display a bank account balance to the world, at least not in the traditional financial system.

Using ERC-721 tokens -or NFTs- we can provide an earmark to which wallets could have permission to access this system. This NFT can be minted by the bank and transferred to the wallet that needs access. In addition, this NFT can be limited and non-transferable, avoiding having someone transfer the token out to another wallet.

When the smart contract executes the function, it checks the NFT balance of this wallet. If it sees the proper NFT, it can proceed with the rest of the logic. If not, it returns a grace error, better known in the HTTP world as a 403, explaining that this wallet doesn't have access.

This will only act as a "restricted list" model, where only those wallets with this specific token can access via this method, but it doesn't differentiate between the wallets.

To represent identity, the bank should have a relation of wallets and bank accounts sitting on their systems. The bank account owner can link its web3 wallet to its bank account, and receive an NFT token to prove it.

Then, the smart contract queries the bank system asking for the bank account balance connected to the wallet that initiated the call.

This model ensures that only a specific wallet can ask for the balance of a particular bank account and not other wallets.

In the web3 world, power resides on building automated logic that makes these processes seamless. With this model, we ask the wallet holder to execute the function on the smart contract every time, which creates usability issues. There might be instances where an authorized third-party protocol makes this inquiry.

If a protocol tries to execute the function, it will receive an error response of “restricted access” because it doesn't have the NFT, nor is the wallet inquiring for the balance the correct one.

The bank can issue a specific NFT token to solve this case, allowing this protocol to access the smart contract function.

But the identity piece still makes it hard. When the foreign protocol inquires about a wallet's bank account balance, somehow, we need to make sure the account holder authorizes it.

Here is where a not-so-known standard ERC-725 comes in handy. This protocol enables a "claims" model where the foreign protocol can obtain a claim from the wallet that states "its permission" to access the linked bank account's balance. This claim can be revoked at any time and allows the foreign protocol to call the function safely.

If the address calling the function is different from the address of whom we want to know the balance, then a claim must exist. This claim must be issued by the bank account's linked wallet and validated. The bank can act as the validator of this claim since it issued it in the first place.

Slowly, as web3 gets better defined and blockchain technologies mature, we will see more interactions between this new world and the traditional monetary world.

The more integrations and interactions that become available, the easier it will be for a day to day use of web3 in our lives. However, even when web3 gains enough critical mass of services to become independent of the traditional financial system, there will still be more to interconnect. Anyone can port the example in this article to more industries.