Feel free to hit me up here with any questions on the topic. Happy to answer any that I can.
Ordinals NFTs on Bitcoin have driven interest in #ethscriptions, but low cost storage and data propagation from the L2 are why #ethscriptions matter. Learn about their use cases and how they work: https://stephencaudill.com/blog/2023/understanding-inscriptions.html
I'm not convinced this is the right way, but as evidenced here, I'm very interested in figuring out where the dividing line between data, schema and application can be placed and how much of that makes sense to store on-chain in an inscribed transaction scenario.
Here's a little elaboration on the hex-encoded format I mentioned: https://warpcast.com/mrmemes/0xa7d75a
...and the full output from decoding it: ``` src/ethscriptions-stream λ ./bin/decode [hex code elided] (address,address,uint256) 0x9e1E2Bc60E0fdC756704d18346D511Bba7543E9a 0x9e1E2Bc60E0fdC756704d18346D511Bba7543E9a 100 ```
Here's what encoding it looks like: ``` src/ethscriptions-stream λ ./bin/encode "(address,address,uint256)" 0x9e1E2Bc60E0fdC756704d18346D511Bba7543E9a 0x9e1E2Bc60E0fdC756704d18346D511Bba7543E9a 100 ```
For the curious, here's an example inscribed transaction that uses the binary data format I've been playing with: https://goerli.arbiscan.io/tx/0xb6846bb0269a32209643484bdfee9a8bc4ce9ad23cff1c2764374ffdf217cd71 ... view the input data as UTF-8, the payload portion of that data URI encodes both schema and data.
... that way your protocol contract could say: "okay, this ethscription is in my data format and I expect the bytes of the body to be in this format"... keeps the data on-chain and lets the schema be defined in a contract, in a format that's de-serializable on-chain as well.
This format: `data:,1320.ethmap" target="_blank" rel="noopener">1320.ethmap` which is just the data uri representation of the plain text "1320.ethmap". Riffing on this idea, one possible path forward would be to inject custom mime types for your protocol implementation, e.g. `data:myprotocol,`... this would disambiguate compatible ethscriptions.
I'm seeing a lot of plain text ethscriptions coming through... currently there are a number that look like this: https://ethscriptions.com/ethscriptions/0xcc14844ea6b93e1ec40f552f4c71f6ef9b9263d39aaca3f44a809f27970e65d0
You could definitely get that through structured JSON and it seems like some usages of ethscriptions are going down this path currently. Unfortunately, this means that you can't really have portions of your application on-chain though, since reading JSON from any EVM-compatible language would be prohibitively expensive
ultimately, what I'd like is that if "the application" lives off-chain while "the data" lives on-chain, applications should be able to introspect the data to know whether they can operate on it. This would allow standards to emerge.
Maybe dynamically typed JSON is sufficient? Or perhaps using JSON Schema would be simpler even if it's very verbose?
I've been playing with hex-encoding data using a brief front matter that takes inspiration from the Foundry approach to ABI encoding, but by the time you encode the body to hex, append `data:application/octet-stream,` and then convert that all to hex, it ends up being pretty lengthy.
I'm late to the party, but ethscriptions are really interesting. The possibility of having "contractless" functionality is the thing that really captures my imagination... it seems like you need not just data, but a way to describe its schema. Anyone working on this?
Handy links: * EIP-6551 draft status proposal: https://eips.ethereum.org/EIPS/eip-6551 * EIP-6551 info site: https://tokenbound.org * This thread: https://warpcast.com/mrmemes/0xfe4471
I would personally not hold anything that was either valuable or irreplaceable in a TBA as it is currently specified. If it were an EIP-4337 smart account that implemented social recovery, it would go a long way toward allaying my concerns.
All that said, for having an identity (like an ENS) own a series of NFTs that spoke to achievements/attendance (POAPS) or even professional certifications all collected together for you to point to and say "this is my web3 persona", it goes a long way toward being an interesting component for reputation systems.
For those suggesting you could have your (B|M)AYC hold your BAKCs, OtherDeeds and HVY-MTLs... I can only say that I hope your opsec is pretty top notch.
As to the potential for danger: I think the existential problem for this proposal is that it puts the entire onus of on-chain security on a single NFT. If someone steals/phishes/scams your NFT, you lose everything associated with the account owned by the NFT too.
You could implement an EIP-4337 smart account that delegated to the `isValidSignature` function on the TBA's EIP-1271 implementation, but then you've got an EOA (wallet) that owns an NFT that has a 1271 smart account that a 4337 smart account can interact with. Hardly the essence of simplicity.
Digging into how the TBA validates transactions: it makes use of `isValidSignature` from EIP-1271, which is on par with the current generation of smart accounts (ala Argent or Gnosis). It does not natively supported `validateUserOp` from EIP-4337 so it isn't natively compatible with Account Abstraction.
I was initially thinking this might be an interesting way to get neophytes an on-chain account: here's your NFT, you're now on-chain! ...but you have to already have an account (wallet) to own the NFT to get the Token Bound Account, so it doesn't work in that scenario. That's okay, they don't say it's for that.