---
# System prepended metadata

title: Living in a Post-YOLO signing world

---

# Living in a Post-YOLO signing world

## A matter of faith

<img style="float: left; margin-right: 20px; height: 500px" src="https://i.imgur.com/raWJaJj.png"> 

Interacting with a smart contract has always been a matter of faith, right now wallets successfully display only the hex data. Some attempts have been made to display more information, but the UI seems slow or bugged from the user's prospective.

If human-readable transactions are still lacking today, it is because, before showing something to the user, you need reliable and useful information. Today the most famous data providers are centralized block explorers with closed database and closed source, and the data they provide is not even complete, they just offer the ABI while inside the `metadata.json` (a file generated by default from the solidity compiler) you can find much more!

Another key reason is the lack of modular systems for wallets, right now there are no wallets that allow the user to install 3rd party plugins. Thus the wallets functionalies have remained stagnant all these years.

<br style="clear:both" />

## Trust the decentralized and open ecosystem

One thing we have all learned in these early years of web3 is that decentralization and trust go hand in hand, so let's stop having faith and let's start trusting open source and decentralized technologies.

There are several problems to tackle to achieve post-YOLO signing, but the solutions are already there.

### Sourcify: verification, IPFS data availability, metadata in the bytecode

Sourcify is a project with three main objectives:

- **[Verifying smart contracts](https://docs.sourcify.dev/docs/full-vs-partial-match/)** in a better way: centralized block explorers's verification is partial, it just checks the executional part of the bytecode but not the `metadata.json`.
- **[Data availability on IPFS](https://docs.sourcify.dev/docs/repository/)**: all the files of a verified smart contract are pinned by Sourcify on IPFS, this means that the wallet developer willing to fetch the ABI can now trust an open and decentralized database instead of calling a closed API. Plus, since IPFS is content addressed, you know the file you are getting is the file you requested.
- **[Metadata (ABI, userdoc, ...) in the bytecode](https://playground.sourcify.dev/)**: seems more like a creed then a Solidity feature. I saw with my eyes people crumble down and start crying after discovering that you can find the metadata in the bytecode _(it's just a metaphor)_.

_Please click the links above to learn more about each topic._

### Metamask Snaps

They are not yet among us, but they are coming. Metamask releases the Snaps functionality for their developer experimental playground: Flask. Few days ago the Metamask team finally released the [pre-transaction window feature](https://docs.metamask.io/guide/snaps.html#populate-metamask-s-pre-transaction-window-with-custom-transaction-insights-%E2%80%A2-learn-more), this will allow developer to add custom tabs other than details, data and hex.

Many interesting projects are already emerging:

* **[Transaction simulation snap](https://twitter.com/FrederikBolding/status/1587970892264611841)** by [@FrederikBolding](https://twitter.com/FrederikBolding): it allows the user to simulate the transaction in the browser to foresee what will actually happen on chain.
* **[Trust score snap](https://twitter.com/Tbaut/status/1586805954405928967)** by [@Tbaut](https://twitter.com/Tbaut): it checks several information on chain and gives provide a trust score.
* **[Human readable transaction snap](https://twitter.com/CastignoliMarco/status/1583370178112671745)** by [@SourcifyEth](https://twitter.com/SourcifyEth): it displays the `@notice` parameter in NatSpec.
* **[AI code explainer snap](https://twitter.com/ChainPrompter/status/1577385716123738114)** by [@ChainPrompter](https://twitter.com/ChainPrompter): it uses an AI to read the smart contract code and display a human readable sentence describing what is going to happen.

## Different levels of trust

Signing a transaction should preferably be fast, secure and clear (from the human point of view). But as the Scalability trilemma tought us, we cannot always get the best out of each property, we must use the right tool for each occasion.

In particular, as I already stated above, the most important step is the gathering of the information.
_E.g. if I want to display nicely formatted tx arguments, I need the ABI, how am I getting it?_

* **Fast**, or the _centralized way_: if we want to sign a low-risk transaction we can fetch from centralized sources the information used to provide post-YOLO transaction.
* **Balanced**, or the _federated way_: trust multiple entities that do the same thing. For example, instead of fetching the information from one auditor, you can fetch the information from 100 auditors. Of course it will become slower, but _the more heterogeneous the sources, the more reliable the information_.
* **Secure**, or the _decentralized way_: don't trust anyone, do it by yourself. For example, instead of trusting Sourcify's repository, just fetch the contract's sources from IPFS and do an edge verification inside the Metamask Snap.

## A brighter, modular future

<img style="float: right; margin-left: 20px; height: 500px" src="https://i.imgur.com/Gv9VVav.png"> 

In the future, wallets will have much more powerful plugin systems ([they are in development](https://docs.metamask.io/guide/snaps.html#custom-ui-in-metamask-using-a-defined-set-of-components)), this will allow developers to create interactive tools that fits the right _level of trust_ for each transaction.

Future transactions will likely include:
* contract verification
* [userdoc](https://docs.soliditylang.org/en/latest/natspec-format.html#user-documentation) written directly by the developer
* a simulation of the transaction
* audits
* some trust score based on previous contract interaction
* AI analysis

The signing view will instantly load all the information from _centralized_ sources, warning the user to wait until the _balanced_ and _secure_ information are fetched and elaborated.

