seb
@seb
Food for thought Every smart contract is kinda its own app, with every function / feature being a button you can press Some buttons are put on websites, miniapps, etc., but the large majority of them are never(or no longer) surfaced There should be some sort of universal markup language for every smart contract (that isn't an ABI) that allows anyone to easily interact onchain. Wonder if this is solved via a smart contract markup language + generative AI, or just plainly via LLMs Publishing an app to the onchain app store becomes simply deploying a smart contract
10 replies
3 recasts
43 reactions
Brian Flynn
@flynn.eth
have you seen what @herd.eth is building? it's the closest to that (by just making it easy to read and understand contracts and compile any UI on top)
1 reply
0 recast
6 reactions
0xOmen
@0x-omen.eth
Similar to what @developerjesse.eth said, if the contract is verified on an etherscan then this functionality already exists Contract -> Read Contract / Write Contract Connect a web3 wallet and if you know what you are doing you can skip the frontend. I've rescued funds many times doing this when frontends are down/broken Of course, this is for advanced users that understand discrete math / floating point numbers, hashing, etc
1 reply
0 recast
2 reactions
DeveloperJesse
@developerjesse.eth
Of the contract is verified on an explorer then that is a good first step. A lot of times that gets you access to the “hidden” methods that exist in the contracts. If it isn’t verified, then it’s a different story. Is it possible to reverse engineer byte code? Perhaps to what the compiler did, but not back to the source.
1 reply
0 recast
1 reaction
Steve
@stevedylandev.eth
Technically the ABI is the universal language for smart contracts but you’re right that it’s missing the context as to what each function or state does. Even with the original code you can only get so far. You need instructions left by the creator to truly understand. A natspec gets you halfway there in that the developer can leave comments in the code explaining how it all works, but since that’s not included in the ABI it’s only half way there. Extending ABI would be awesome. On a related note we are building some tooling around the concept of easy contract interaction which you can check out here: https://farcaster.xyz/stevedylandev.eth/0xcbd728a6
1 reply
0 recast
2 reactions
Matt
@mattlee
Zapper is the obvious place for this feature to live
0 reply
0 recast
2 reactions
jp 🎩
@jpfraneto.eth
yes
0 reply
0 recast
1 reaction
thaykor
@darren.eth
This would be great. Think of all the pre 2021 contracts that have “dust” you can recover with a click.
0 reply
0 recast
1 reaction
Tony D’Addeo
@deodad
fun thought reality though the useful smart contracts are usually very low level building blocks and aren’t generally usable or legible without a huge amount of additional context built on top they feel more like specialized hardened low level software modules than apps
0 reply
0 recast
0 reaction
James
@theref.eth
Open Zeppellin have a great tool for building UI components based on smart contract functions https://builder.openzeppelin.com/
0 reply
0 recast
0 reaction
Martin Harrigan
@harrigan
The trace data stored in the blockchain from previous invocations could be useful. What are the common flows? Is that address a token or account?
0 reply
0 recast
0 reaction
