ESIP-3: Smart Contract Ethscription Creations
PreviousESIP-2: Safe Trustless Smart Contract Ethscription EscrowNextESIP-5: Bulk Ethscription Transfers from EOAs
Last updated
Last updated
ESIP-3 introduces a mechanism for smart contracts to create ethscriptions using Ethereum events. Start block: 18130000
Add a new smart contract event into the Ethscriptions Protocol:
When a contract emits this event in or after block 18130000, the protocol should register a valid ethscription creation attempt with:
contentURI interpreted as the ethscription's utf-8 encoded dataURI with all null bytes removed.
initialOwner as the created ethscription's initial owner.
The emitting contract as the creator.
Functionally speaking, this event is the equivalent of an EOA hex-encoding contentURI and putting it in the calldata of an Ethereum transaction from itself to initialOwner. As with ethscriptions created via input data, all null bytes are removed from the UTF8 contentURI of ethscriptions created through events.
As with EOA-initiated ethscription creations, ESIP-3 ethscription creations are only valid if contentURI is both unique and .
contentURI formatdata:,1234.
Note: it is utf-8 encoded, not hex-encoded. Note also this specific example is a duplicate and would not result in an ethscription creation.
ESIP-3 does not change the fact that each Ethereum transaction may have only one corresponding ethscription. If multiple aspects of a transaction constitute valid ethscription creations, calldata will be prioritized over events, and events with lower log indices will be prioritized over those with higher indices.
Example 1:
Calldata: valid creation
Event Log Index 1: valid creation
Event Log Index 2: valid creation
In this case, an ethscription will be created according to the calldata and Events 1 and 2 will be ignored.
Example 2:
Calldata: empty (i.e., invalid creation)
Event Log Index 1: valid creation
Event Log Index 2: valid creation
Here, Event 1's log will trigger the ethscription creation. If calldata and Event 1 were both invalid then Event 2's log would trigger the ethscription creation.
Contracts must have the same powers as EOAs and this is the cheapest way to do it.
We propose maintaining the 1-1 correspondence between ethscriptions and Ethereum transactions because the convention that ethscriptionId = transactionHash has proven useful.
For example, instead of forcing a user to bulk create ethscriptions of this form:
We should capture the user's intent with a single ethscription containing the command mint(50).
Unlike calldata, events have no size limit (aside from the 30M block gas limit). Practically this means that ESIP-3 expands ethscriptions' file size limit to beyond 3.5MB.
Multiple ethscriptions in a transaction are also an inefficient way of capturing a user's intent. Creating multiple ethscriptions in a transaction will always have an underlying purpose and structure, and we should be capturing this structure using .