Ethereum

Some thoughts on the Ethereum dApp UX & wallet software. 

Both dApp and wallet developers in the Ethereum ecosystem face unique design challenges. 

dApp interactions must allow proper execution and interfacing with wallet software, while the wallet software itself must allow the former and also keep user funds safe.

Hacker ( Solidity // C/C++ // Python // JS/TS // Everything Linux ) // Shitposter // Psychedelics // Full Anon

The same rule applies for wallet applications, for this reason we have seen the most popular wallet (Metamask) work as a simple browser plugin. 

Wallets such as Metamask allow users to invest the bare minimum necessary effort to start interacting with smart contracts.

Many leading developers of wallet applications have also made an effort to develop & integrate EIP standards into their software, which makes it easier for dApp developers to interface with wallets, because it guarantees common APIs which may be consumed. One of the most important EIPs in this regard is EIP-1193.

In any case, the largest downfalls with the formerly mentioned _status quo_ in regards to UX is the fact that beyond signing operations, all transaction building is dependent on resources and calculations provided by dApps! 

How would traders fare without Uniswap or Cowswap frontends?

If any dApp decides to block a user from interacting with it, the user will only be able to interact with the smart contracts under the conditions that:

1. There is an alternative frontend by which the service may be accessed (see Liquity).

2. There is a locally hostable frontend by which the service may be accessed (many users will not invest the effort to do this, external resources which may be blocked still present a problem, configuration needed).

3. There is some alternative method by which the user can interface with the smart contracts (etherscan, programmatic and so on).

1 is the only scenario in which the user will most likely not have issues interacting with smart contracts, but it is easier for scammers to take advantage of the user. 2 requires some technical, even a minimal amount of know-how by the user and already goes against our simplicity claim that we have made earlier.

3 requires the user to manually build transactions, meaning that a large percentage of users will avoid this.

In essence, this _effectively_ gives Ethereum dApp developers leverage over users which invest time and capital into certain protocols.

Users now need not only concern themselves with basic smart contract safety guarantees, but they now also require availability guarantees when it comes to the services mediating interactions with contracts.

All of the former demonstrates a need for the mainstream UX to undergo further transformations which must both uphold simplicity while at the same time offering strong availability guarantees for interfacing with smart contracts, meaning guaranteeing that users will always be able to build transactions themselves.

The only software solutions which currently allow an acceptable level of safety, in this regard, for the user, are the programmatic ones which allow the user to define their actions in either, currently, Javascript (Ethers/Web3), Rust (Forge/Foundry) or Python (ApeWorx) (Brownie is old).

These frameworks obviously guarantee availability due to all of the execution logic (code) being stored on the user's device. This is obviously similar to actually storing the wallet execution logic (such as deriving public addresses from private keys) on device, via a downloaded browser plugin or desktop app.

What the former implies, is that the next step in dApp UX should be on-device storage of logic regarding transaction building within constrains allowed by wallet apps, standardized with EIPs.

For example, even plugins such as Metamask could offer an API which could allow plugins to be added to the wallet which the user could always access independent of the state of some dApp.

So, wallet devs could develop plugins which would behave according to some EIP standard. Different wallets would as usual simply implement this, and users would download these plugins simply by visiting the webpage of a protocol or entering, for example, the ENS name of the protocol into their wallet.

I wouldn't consider this a far-reach considering the current practice of automatic or manual token addition to wallets. Again, in a similar way protocol actions or protocols (groups of actions) could be enumerated within wallet apps and selected, allowing easier dApp lookup for users.

In any case, if standards like this were to be implemented, an entire risk category for users would be practically eliminated.

The last and final issue, then, would be the necessity of proliferating and encouraging a diverse ecosystem of wallet software. It is my personal belief that many different wallets suited to individual needs will drive adoption. 

Fin

@tynes here it is honestly should have rather been a Medium or Substack post. Maybe I'll make that too. In any case this mostly handles the issue of frontend takedown and other risk, and then privacy is simply dependent on tx broadcasts meaning proxying stuff through something like Tor.

The current status quo is centered around Injected Web3. 

Currently, web apps are the most effective way for dApp developers to expose interfaces by which users may interact with their contracts, since similarly to non-crypto related web apps simplicity is required to capture consumer attention.