ESIP-5: Bulk Ethscription Transfers from EOAs

Abstract

Bulk transferring means transferring more than one ethscription in a single Ethereum transaction.

ESIP-1 and ESIP-2 gave Smart Contracts the ability to transfer ethscriptions through events. Because multiple events can be emitted in a single transaction, ESIP-1 and ESIP-2 also gave Smart Contracts the ability to bulk transfer ethscriptions.

ESIP-5 brings EOAs to the level of Smart Contracts by introducing a mechanism for EOAs to bulk transfer ethscriptions.

Specification

Pre-ESIP-5, this was the rule for EOAs transferring an ethscription:

Any Ethereum transaction whose input data is an ethscription id [...] is a valid Ethscription transfer, provided the transaction sender is the Ethscription’s owner.

ESIP-5 retains the spirit of this rule, but allows users to add multiple ordered ethscription ids as input data.

If the input data of a transaction (without its leading 0x) is a sequence of 1 or more valid ethscription ids (without their leading 0x), that transaction will constitute a valid transfer for each ethscription that is owned by the transaction's creator.

An Example

Suppose a transaction has the input data:

0x8ad5dc6c7a6133eb1c42b2a1443125b57913c9d63376825e310e4d1222a91e24533c5e38d1b8bf75166bd6443a443cd25bd36c087e1a5b8b0881b388fa1a942c

We first remove the leading 0x:

8ad5dc6c7a6133eb1c42b2a1443125b57913c9d63376825e310e4d1222a91e24533c5e38d1b8bf75166bd6443a443cd25bd36c087e1a5b8b0881b388fa1a942c

Now we observe that this hex string's length is 128, which is an even multiple of 64, which is the length of an ethscription id with its leading 0x removed.

Now we split the hex string into two chunks of 64 characters and determine whether these chunks are valid ethscription ids. We prepend the 0x and check for ethscriptions. Now we find:

1. 0x8ad5dc6c7a6133eb1c42b2a1443125b57913c9d63376825e310e4d1222a91e24 is Ethscription #2.

2. 0x533c5e38d1b8bf75166bd6443a443cd25bd36c087e1a5b8b0881b388fa1a942c is Ethscription #1.

Because both ids correspond to valid ethscriptions, we proceed. If one or more weren't valid ethscriptions, we would ignore the invalid ethscriptions and continue processing.

Now we look at the ids in the order they were listed in calldata, and register in order:

1. A valid transfer for 0x8ad5dc6c7a6133eb1c42b2a1443125b57913c9d63376825e310e4d1222a91e24 if the "from" of the transaction is the owner of this ethscription as of this moment.

2. A valid transfer for 0x533c5e38d1b8bf75166bd6443a443cd25bd36c087e1a5b8b0881b388fa1a942c is "from" of the transaction is the owner of this ethscription as of this moment.

If the "from" of the transaction is not the owner of the ethscription, we skip that transfer and continue processing. This means that if the "from" is the owner on some, but not all, ethscriptions some of the transfers will be valid and some will not.

Rationale

The goal is to reduce the question of bulk transferring to a sequence of individual transfers. This is why there can be partially valid bulk transfers—creating a notion of bulk validity is additional complexity.

However, we must enforce a notion of global validity for all ethscription ids, otherwise we introduce too much potential for unintentional transfers and confusion.