Standard for contractmetav0 fields and usage

[wildework]

This originally was proposed by Naman during the March 21st, 2024 Stellar Developers Meeting on Discord.

User Story

I'm a curious person looking for cool DApps on Stellar. I want to see what's popular on chain. I can go to blockchain explorers and see which Soroban contracts are being invoked, I can see which function is called and maybe arguments. But that's where my journey ends - I don't have an easy way to continue discovery to the actual DApp that's the front-end of this contract I'm looking at.

Solution

DApp discovery is a big deal and we should use the blockchain to be the source of truth for what's popular and create an easy path for users to follow to the DApps.

We can use do this by creating a standard for linking to the original DApp from the contract code using contractmetav0 custom section of the executable WASM.

More Examples

Besides the DApp link entry, I believe there is a plethora of useful things to store with the WASM.

For one, I'd love to store the Okashi project identifier in the meta. This would allow explorers and other tools to link back to the original Rust source code.

I want to encourage folks to think of more examples of what to store there and how it would benefit the user.

Security

There is no guarantee that data stored in the contractmetav0 custom section will be true, as actors can assign any values they want. As part of this standard we should come up with contract meta data verification methods. Tyler mentioned using a web address to confirm the data as one solution.

[wildework]

My example with Okashi project identifiers is something that's 3rd party tool specific and obviously shouldn't be a part of the standard, but it still makes sense to define how a 3rd party should integrate into the contract spec. For example if a contract has received an audit by Certora, the contract author could put a link to the audit in the meta.

[tupui]

Great idea 👍 An alternative option would be to follow what is done with assets and anchors with the SEP-1 (Stellar info file). Contracts could link to a Stellar info file and there could be a contract section in it. This would offer more flexibility and be friendlier on storage. In terms of security, people could provide a hash/signature for the file itself as to version it. Then external tools could easily verify the integrity of the metadata file.

Some more discussion on discord: https://discord.com/channels/897514728459468821/966788672164855829/1271856012470521857

[leighmcculloch]

We can use do this by creating a standard for linking to the original DApp from the contract code using contractmetav0 custom section of the executable WASM.

+1. This is the type of thing was envisioned the contract meta could be used for. A SEP wouldn't need to broadly define all usage of meta, but could define a key such as og_dapp_url along with a url in the value.

It's worth noting that anyone following untrusted URLs should do so with appropriate caution.