Oftentimes you will hear the term trustless in web3. What it really means is that instead of trusting strangers, institutions, and other 3rd parties, a user would trust in the code or protocol, ie trust is built into the code.

This is the main reasoning behind the design principles of transparency of code for web3 Dapps.

— for a Dapp to be trusted, it’s code needs to be trusted.

— for code to be somewhat trusted, it needs to be transparent, independently executable and verifiable.

As designers, we should be aware of the importance of code transparency when designing the Dapp front end.

Users should be aware of which blockchain their data is being stored on. Knowing this, allows users to also know the technical differences and where to verify the data.

Similarly, users should be made aware of the smart contract's addresses that are used in read/write operations. This is important as it allows users to verify the contract and its operations via independent Blockchain explorers such as etherscan, tokenview, etc. Using independent blockchain explorers, users can view the contract's code, see its transaction history, and check its balance and other key metrics.

There are two main ways in which code can be run in a Dapp: locally, on the user's device, or remotely, on a server controlled by the Dapp developer. Local code execution is generally considered to be more secure and private, as it means that users' data and assets are stored and processed on their own devices, rather than on a remote server.

Regardless of whether the code is run locally or remotely, it is important that you show where the code is being run in the Dapp’s UI to clarify. At the very least, have a page that explains what is being run remotely and the reasoning behind this approach.

Web3 embraces transparency from both a technical and cultural perspective, which is why quite a lot of projects are built on open source solutions and code.

As users are entrusting you with their assets, you can demonstrate your commitment to transparency and help build trust with users by showing what parts of your Dapp are open source and what parts are not and where to find the open source code (Git repos, etc.)

Dapps connect to web3 providers, also known as a Blockchain node, to access the blockchain and interact with smart contracts. Depending on the node or provider, the user will be exposed to various risks.

Local nodes allow the user to maintain full control over the node and the data that it processes as it is run on the user’s machine. However, it also means that the responsibility of maintaining the node is on the user.

Dapp-controlled nodes, on the other hand, are more convenient for users as the Dapp is responsible for the node. The tradeoff is the loss of control from the user side.

MetaMask is also a web3 provider for Dapps, allowing users to connect directly from their browser. However, it also means that the user has to trust the MetaMask team with their data, which can be a privacy risk.

It's important to clarify which web3 provider you’re using, as this can help users understand the risks involved in using your Dapp.

In the Ethereum ecosystem, there are two main networks: the MainNet and the TestNet. It's essential for users to be aware of the Dapp is running on MainNet or TestNet as it affects the value of the assets involved in the transaction.

The MainNet is the main Ethereum network, where the real value is used in transactions. Any assets involved in a transaction on the MainNet have real value.

On the other hand, the TestNet is a testing network where transactions do not involve real value. It’s used mainly for testing and development purposes, so is not suitable for transactions involving real assets.

By being aware of what network the Dapp is running on, users can ensure that they are using the appropriate network for their intended purpose and avoid any potential losses due to using the wrong network.

As smart contracts are stored on the blockchain, they cannot access or interact with Off-chain data.

If a smart contract needs to access or use off-chain data, they would require the use of data from Oracles which are essentially middlemen that can fetch or validate off-chain data and bring it onto the blockchain for use by a smart contract.

It's important to clarify what data is from Oracles, so that users can confirm and verify the data being used by a smart contract.

While it might seem contradictory in that a frontend UI is supposed to simplify the technical aspects of a Dapp, having the ability to view the transaction function call prior to sending it can help build trust with more advanced users and demonstrate your commitment to transparency and accountability.

Allowing advanced users to view the transaction function call prior to sending it is a form of radical transparency that can help build trust with users. By showing the transaction code, users can see exactly what the code is doing and how it will be executed on the blockchain, allowing them to verify that the code is correct and will do what they expect it to do.

In addition, by allowing users to view the transaction code, you are effectively saying "Don't Trust. Verify" to the user. This means that you are not asking the user to blindly trust you, but rather, you are encouraging them to verify the code for themselves and make sure that it is correct.

Smart contracts often utilize large numbers with many zeros. However, these large numbers can be difficult for users to read, so they are often simplified into smaller numbers between 0 and 100.

While this simplification can make it easier for users to understand the numbers, it's crucial for transparency's sake to make it clear when this is being done.

By explicitly stating that the numbers are being simplified and providing the actual inputs, users can see exactly what the numbers represent and can verify that the simplification is accurate.

Code transparency is a radical approach to creating trust because it involves making your Dapp’s technical aspects open and accessible to anyone who wants to verify it. By doing this, Dapp developers are effectively saying, "Don't trust us, verify the code for yourself to their users. This helps build trust with your users and by extension, establish the trust in the Dapp itself.

Oftentimes you will hear the term trustless in web3. What it really means is that instead of trusting strangers, institutions, and other 3rd parties, a user would trust in the code or protocol, ie trust is built into the code.

This is the main reasoning behind the design principles of transparency of code for web3 Dapps.

— for a Dapp to be trusted, it’s code needs to be trusted.

— for code to be somewhat trusted, it needs to be transparent, independently executable and verifiable.

As designers, we should be aware of the importance of code transparency when designing the Dapp front end.

Users should be aware of which blockchain their data is being stored on. Knowing this, allows users to also know the technical differences and where to verify the data.

Similarly, users should be made aware of the smart contract's addresses that are used in read/write operations. This is important as it allows users to verify the contract and its operations via independent Blockchain explorers such as etherscan, tokenview, etc. Using independent blockchain explorers, users can view the contract's code, see its transaction history, and check its balance and other key metrics.

There are two main ways in which code can be run in a Dapp: locally, on the user's device, or remotely, on a server controlled by the Dapp developer. Local code execution is generally considered to be more secure and private, as it means that users' data and assets are stored and processed on their own devices, rather than on a remote server.

Regardless of whether the code is run locally or remotely, it is important that you show where the code is being run in the Dapp’s UI to clarify. At the very least, have a page that explains what is being run remotely and the reasoning behind this approach.

Web3 embraces transparency from both a technical and cultural perspective, which is why quite a lot of projects are built on open source solutions and code.

As users are entrusting you with their assets, you can demonstrate your commitment to transparency and help build trust with users by showing what parts of your Dapp are open source and what parts are not and where to find the open source code (Git repos, etc.)

Dapps connect to web3 providers, also known as a Blockchain node, to access the blockchain and interact with smart contracts. Depending on the node or provider, the user will be exposed to various risks.

Local nodes allow the user to maintain full control over the node and the data that it processes as it is run on the user’s machine. However, it also means that the responsibility of maintaining the node is on the user.

Dapp-controlled nodes, on the other hand, are more convenient for users as the Dapp is responsible for the node. The tradeoff is the loss of control from the user side.

MetaMask is also a web3 provider for Dapps, allowing users to connect directly from their browser. However, it also means that the user has to trust the MetaMask team with their data, which can be a privacy risk.

It's important to clarify which web3 provider you’re using, as this can help users understand the risks involved in using your Dapp.

In the Ethereum ecosystem, there are two main networks: the MainNet and the TestNet. It's essential for users to be aware of the Dapp is running on MainNet or TestNet as it affects the value of the assets involved in the transaction.

The MainNet is the main Ethereum network, where the real value is used in transactions. Any assets involved in a transaction on the MainNet have real value.

On the other hand, the TestNet is a testing network where transactions do not involve real value. It’s used mainly for testing and development purposes, so is not suitable for transactions involving real assets.

By being aware of what network the Dapp is running on, users can ensure that they are using the appropriate network for their intended purpose and avoid any potential losses due to using the wrong network.

As smart contracts are stored on the blockchain, they cannot access or interact with Off-chain data.

If a smart contract needs to access or use off-chain data, they would require the use of data from Oracles which are essentially middlemen that can fetch or validate off-chain data and bring it onto the blockchain for use by a smart contract.

It's important to clarify what data is from Oracles, so that users can confirm and verify the data being used by a smart contract.

While it might seem contradictory in that a frontend UI is supposed to simplify the technical aspects of a Dapp, having the ability to view the transaction function call prior to sending it can help build trust with more advanced users and demonstrate your commitment to transparency and accountability.

Allowing advanced users to view the transaction function call prior to sending it is a form of radical transparency that can help build trust with users. By showing the transaction code, users can see exactly what the code is doing and how it will be executed on the blockchain, allowing them to verify that the code is correct and will do what they expect it to do.

In addition, by allowing users to view the transaction code, you are effectively saying "Don't Trust. Verify" to the user. This means that you are not asking the user to blindly trust you, but rather, you are encouraging them to verify the code for themselves and make sure that it is correct.

Smart contracts often utilize large numbers with many zeros. However, these large numbers can be difficult for users to read, so they are often simplified into smaller numbers between 0 and 100.

While this simplification can make it easier for users to understand the numbers, it's crucial for transparency's sake to make it clear when this is being done.

By explicitly stating that the numbers are being simplified and providing the actual inputs, users can see exactly what the numbers represent and can verify that the simplification is accurate.

Code transparency is a radical approach to creating trust because it involves making your Dapp’s technical aspects open and accessible to anyone who wants to verify it. By doing this, Dapp developers are effectively saying, "Don't trust us, verify the code for yourself to their users. This helps build trust with your users and by extension, establish the trust in the Dapp itself.