RFC: alternative contract-creation of ethscription (similar to esip3)

[tunnckoCore]

We can introduce event ethscriptions_protocol_CreateEthscriptionFrom(initialOwner, dataURI) or similarly named event for contract initiated creations.

Currently with ESIP-3, the creator is always the contract address, eg. the transaction.to.

The purpose of this proposal is to have a similar event to ESIP-3, but where the indexer sets the creator as the transaction.from - the caller of method which emits that event.

I need that ASAP and would be good to have it.

The idea is that i'm building on top of Ethcriptions, but solely as a storage layer ONLY. Minters of that new thing will be able to trade and track ownership through EVM contract, because from Ethscriptions protocol perspective they never own it and the ownership never changes - it's always the contract that created/minted the thing. Currently, with ESIP-3 they are not able to even be respected as "creators" of the underlying Ethscription because there's no such creation and support in the protocol.

With the introducion of this new type of creation, user would at least be made "creators" of the underlying Ethscription when they mint that new thing/collection. With this event, they will be the creators and the minter contract will be the initial owner.

I'm back on working on a sick collection that uses esip3, but i need ONLY the contract to be the initial owner not the creator, cuz i need to "freeze" the ethscription transfers (by making the contract the initial owner and never actually use Ethscription Transfers, thus the contract is the forever currentOwner), eg. it won't allow transferring but would have a built-in market, dao and treasury. Solely using Ethscriptions as just storage. But would be nice the actual creators, the minters, the be respected on Ethscriptions protocol level as creators, cuz they really are - they are the callers of the method (mint) that creates that asset.

When people mint, an ethscription will be created but currently with ESIP-3 that ethscription would have the contract address as both creator and initial owner.

The needed update is in https://github.com/ethscriptions-protocol/ethscriptions-indexer/blob/75b3bcb15e75bfbe96892c8cfe94aa195de8cf80/app/models/eth_transaction.rb#L148C20-L148C34

• if event == esip25 ? transaction.from : creation_event["address"] :D

Other way would be the API to expose the actual from (msgSender or txOrigin or txCreator) of the contract-initiated creation transaction. Currently with esip3, the creator is always the contract.

For the meme, we can call it CREATE2 even though it's nothing to do with it 😆

---

edits:

Even if not my current case (i have a lot, I've been thinking about such creation for over a year), it's still useful and helpful, because contracts may choose to ethscribe something for users, but be in control of that item/ethscription from the start. Eg, it's saving users an additional "deposit transaction".

Opens the doors to use Ethscriptions as storage even for NFTs. They currently could still be, but.. a bit trickier and an additional transfer.

---

Another use-case is "contract created collections". Early on, even before ESIP-3, we came up to that that "collection means, items with same creator", so you can search by creator for all collection items.

With this, we'd be able to define who is for example the "project creator" (an EOA for example), or royalties receiver, not necessarily the contract he deployed for his colldction.

[RogerPodacter]

Can you give an example usecase? Does this allow the contract to "spoof" arbitrary users? Is that an issue or maybe I'm reading this wrong.

[tunnckoCore]

Don't think so. Rules remains the same. If ethscription with that content already exists than the event is ignored.

example

• if createFrom(from, to, "data:,foo not-existent bar") exists ignore, if not - create
• if the same is emitted again, ignore
• if data is th same and from is different, ignore cuz ethscription already exists

with esip6:

• if createFrom(from, to, "data:text/plain;esip6=true,foo not-existent bar") - always create even if the from is different, since it's esip6 and it's normal for it to have different creators and initial owners.

what am i missing? 🤔

[tunnckoCore]

@RogerPodacter ping pong

[tunnckoCore]

@RogerPodacter

OH! or it could just be the transaction.from not the transaction.to as it is with ESIP-3.

[RogerPodacter]

Can you give a concrete example? If the contract can set "from" then how do you know if the "from" ACTUALLY did it or whether some random contract just set them as the "from"?

[tunnckoCore]

@RogerPodacter

I'm fine with my last reply approach too, the contract won't set anything, the indexer will - instead of setting creator to the to (esip3) it will use the from of the transaction (which is the caller of the contract call).

[tunnckoCore]

Still tho, to answer the question:

what's the problem of random contract setting someone as the creator?

it's not like that the contract will replace the creator of already created Ethscription. the standard indexer rules apply - of ethscription exist - ignore, if not -create, if esip6 - it always creates anyway.

[tunnckoCore]

updated

[tunnckoCore]

Even just the simplest use-case: general purpose ethscriber. You have a basic app that helps users ethscribe, but they need to be respected and assigned the creator, and initialOwner whoever the want it to be. Just like self-ethscribe, or EOA to EOA.

With this new creation event, it would be as if it's self-ethscribe but with all the EVM capabilities of checking mint prices, other logic, and what not.

It's not cool that currently such service will always be assigned as the creator, if using esip3. That's why we should have a new event that uses the transaction.from instead of the transaction.to.

I have such basic ethscriber contract - 2 collections were ethscribed with it. It's cool that you can track everything ethscribed from it cuz it's marked as the creator but..

It would be even cooler anyone who calls that ethscribe method to be respected as creator, thus opening the door multiple collections/projects to use the same basic call instead of dealing with EOA ethscribers, queueing, & weirdness that the contract has multiple collections.

Heck, we can have such (eventually upgradeable) contract that allows for configurable launches, and that is used in a launchpad.