> For the complete documentation index, see [llms.txt](https://docs.ethscriptions.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethscriptions.com/esips/accepted-esips/esip-3-smart-contract-ethscription-creations.md).

# ESIP-3: Smart Contract Ethscription Creations

## Abstract

ESIP-3 introduces a mechanism for smart contracts to create ethscriptions using Ethereum events. Start block: `18130000`

## Specification

Add a new smart contract event into the Ethscriptions Protocol:

```solidity
event ethscriptions_protocol_CreateEthscription(
    address indexed initialOwner,
    string contentURI
);
```

When a contract emits this event in or after block `18130000`, the protocol should register a valid ethscription creation attempt with:

1. `contentURI` interpreted as the ethscription's utf-8 encoded dataURI with all null bytes removed.
2. `initialOwner` as the created ethscription's initial owner.
3. 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 [a syntactically valid dataURI](https://docs.ethscriptions.com/overview/how-ethscriptions-work#how-to-validate-a-datauri).

#### Example `contentURI` format

`data:,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.

#### Ethscriptions and Ethereum Transactions remain 1-1

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:

1. Calldata: valid creation
2. Event Log Index 1: valid creation
3. 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:

1. Calldata: empty (i.e., invalid creation)
2. Event Log Index 1: valid creation
3. 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.

## Rationale

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.

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 [ESIP-4](https://docs.ethscriptions.com/esips/esip-4-the-ethscriptions-virtual-machine).

For example, instead of forcing a user to bulk create ethscriptions of this form:

```
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17560","amt":"1000"}
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17561","amt":"1000"}
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17562","amt":"1000"}
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17563","amt":"1000"}
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17564","amt":"1000"}
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17565","amt":"1000"}
data:,{"p":"erc-20","op":"mint","tick":"fair","id":"17566","amt":"1000"}
...
```

We should capture the user's intent with a single ethscription containing the command `mint(50)`.

#### File size

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ethscriptions.com/esips/accepted-esips/esip-3-smart-contract-ethscription-creations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.