Blob base fee bounded by execution cost

2025-03-25T00:00:00+00:00
Abstract</h2>
This EIP assigns a reserve price BLOB_BASE_COST * base_fee_per_gas</code> to blobs by introducing an if</code>-clause in calc_excess_blob_gas()</code>. Specifically, when the reserve price is higher than GAS_PER_BLOB * base_fee_per_blob_gas</code>, the function will not subtract target_blob_gas</code> from excess_blob_gas</code>, causing excess_blob_gas</code> to increase according to blob_gas_used</code>, while keeping the per-block maximum increase unchanged. The proposal ensures that the blob fee market can function properly and that blob consumers pay at least a relevant fraction of the market rate for the compute they request from nodes.</p>

Motivation</h2>
Ethereum uses a dynamic pricing auction to set the blob base fee, lowering the fee if less gas is consumed than target_blob_gas = GAS_PER_BLOB * blobSchedule.target</code> and raising the fee if more gas is consumed. Such an auction can function well when the blob base fee represents the price signal, allowing the mechanism to control the real price for blob consumers. However, when execution costs dominate, the price signal is lost. The blob base fee then no longer represents a significant component of the total cost facing the consumer, and the protocol can no longer rely on the blob base fee to control the equilibrium quantity of blobs consumed.</p>
The current mechanism can therefore end up repeatedly lowering the blob base fee until it eventually settles at 1 wei. A change in the blob base fee of 10% may under such circumstances shift the total cost of utilizing blobspace by just 0.0000001%. Whenever demand picks up, over an hour of near-full blocks is required to restore a market-clearing equilibrium fee, with the mechanism intermittently resorting to a first-price auction, considered a worse UX by blob consumers. The resulting spikiness in resource consumption is suboptimal for scaling blobspace. To alleviate this, the proposal imposes a reserve price that reflects execution costs, through a simple if</code>-clause in calc_excess_blob_gas()</code>.</p>
The reserve price also fulfills a second function. Nodes must cryptographically verify KZG proofs</code> to ensure that associated commitments</code> correspond to provided blobs. This process is computationally expensive. It seems desirable to ensure that blob consumers pay at least some fraction of the market rate for the compute they impose on nodes. In this context, the execution base fee reflects how in-demand nodes' compute services are at the time that blob consumers request them.</p>
By applying the reserve price to the blob base fee, the proposal jointly ensures that:</p>

The blob base fee update mechanism can function properly, by establishing a reserve price which is significant relative to L1 execution costs of blob consumers.</li>
Blob consumers pay at least a relevant fraction of the market rate for the compute they request from nodes, with any additional fees for data determined independently in the blob fee market.</li>
</ol>
Specification</h2>
Parameters</h3>
Constant</th> Value</th></tr></thead>

BLOB_BASE_COST</code></td> 2**13</code></td></tr>
</tbody></table>
Functions</h3>
An if</code>-clause is added to calc_excess_blob_gas()</code> from EIP-4844</a>. The function no longer subtracts target_blob_gas</code> when updating excess_blob_gas</code> if the price of a blob</code> is below the price of BLOB_BASE_COST</code> execution gas. The blobSchedule</code> for referencing target and max blobs was introduced in EIP-7840</a>. The current block's blobSchedule</code> is used during processing. Thus, in the first block after a fork—when calculating base_fee_per_blob_gas</code> via get_base_fee_per_blob_gas(parent)</code>—fake_exponential()</code> must use the new</em> blobSchedule.baseFeeUpdateFraction</code>. Likewise, the new</em> blobSchedule.max</code> and blobSchedule.target</code> must be used in calc_excess_blob_gas()</code>.</p>
def</span> calc_excess_blob_gas</span>(</span>parent</span>:</span> Header</span>)</span> -></span> int</span>:</span></span>
    target_blob_gas</span> =</span> GAS_PER_BLOB</span> *</span> blobSchedule</span>.</span>target</span></span>
    if</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> <</span> target_blob_gas</span>:</span></span>
        return</span> 0</span></span>
</span>
    if</span> BLOB_BASE_COST</span> *</span> parent</span>.</span>base_fee_per_gas</span> ></span> GAS_PER_BLOB</span> *</span> get_base_fee_per_blob_gas</span>(</span>parent</span>)</span>:</span></span>
        return</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> *</span> (</span>blobSchedule</span>.</span>max</span> -</span> blobSchedule</span>.</span>target</span>)</span> //</span> blobSchedule</span>.</span>max</span></span>
    else</span>:</span></span>
        return</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> -</span> target_blob_gas</span></span></code></pre>Rationale</h2>
Fee-inelasticity and reserve price</h3>
This proposal alleviates idiosyncrasies in the blob base fee auction. When a rollup's costs are dominated by execution costs for the blob-carrying transactions, ZK proof verification, or priority fees, the protocol can no longer rely on the blob base fee to control the equilibrium quantity of blobs consumed. The fee update mechanism is unaware of the full price of the goods that it regulates the price for and therefore fails to converge on equilibrium in a timely manner.</p>
We can express a simple real demand function for blobspace as</p>
$Q(b + c).$</p>
It maps the quantity of blobs demanded $Q$ to the blob base fee $b$ and the user's execution costs, expressed "per blob gas", $c$:</p>
c</span> =</span> execution_cost</span> *</span> base_fee_per_gas</span> /</span> GAS_PER_BLOB</span></span></code></pre>
According to the law of demand</em>, the lower the price $b+c$, the higher the demand. From the perspective of the blob base fee update mechanism, $c$ is fixed. If $c>0$, the demand curve will therefore have an "inelasticity horizon", beyond which further reductions in $b$ no longer increase $Q$:</p>
$\lim_{b \to 0} Q(b + c) = Q(c).$</p>
In essence, the demand curve becomes a vertical line, where changes to the blob base fee $b$ no longer affect demand. Figure 1 illustrates this, with real demand curves (black to red) computed under four different execution base fees when purchasing two blobs. The hypothetical organic demand is illustrated in black. Any demand curve where execution costs are positive ($c>0$) eventually becomes vertical as the blob base fee falls. The protocol also uses a long-run perfectly inelastic supply curve (vertical blue line). Therefore, relatively small shifts in organic demand or the execution base fee (arrows) can lead to dramatic shifts in the equilibrium blob base fee. Importantly, the blob base fee will simply fall to the boundary of 1 wei whenever the execution cost is too high for consumers to achieve equilibrium formation at target_blob_gas</code>.</p>
</p>
Figure 1.</strong> Hypothetical real demand for blobspace under different execution base fees (black to red lines). When execution cost dominates, the real demand curve becomes inelastic and parallel to the supply curve, leading the equilibrium fee to change dramatically even with small shifts in the demand curve (arrows). The proposal imposes that the equilibrium (square) forms on the edges of the upper-left quadrant, at the intersection between the target supply curve and demand or along the dashed line representing possible reserve price equilibria accounting for execution costs.</p>
To improve the fee update mechanism, a reserve price is specified below which $b$ cannot be reduced. Specifically, we define a constant BLOB_BASE_COST</code> and in calc_excess_blob_gas</code> do not subtract target_blob_gas</code> if:</p>
BLOB_BASE_COST</span> *</span> base_fee_per_gas</span> ></span> GAS_PER_BLOB</span> *</span> base_fee_per_blob_gas</span></span></code></pre>
This means that the reserve blob base fee becomes BLOB_BASE_COST * base_fee_per_gas / GAS_PER_BLOB</code> and that the ratio between the reserve price for the blob base fee and the execution base fee is fixed to: BLOB_BASE_COST / GAS_PER_BLOB</code>. This ratio is 1/16</code> with the proposed constant.</p>
The blob fee's share of the total price will with the reserve price always be at least BLOB_BASE_COST / (BLOB_BASE_COST + execution_cost)</code>. This is why the equilibrium under the reserve price (dashed line in Figure 1) is situated a constant fraction below the black organic demand curve formed under a zero execution base fee. The equilibrium (squares) must then form somewhere along the edge of the upper-left quadrant, bounded by the blue supply curve and the dashed curve representing possible reserve price equilibria under real demand.</p>
The demand curve could potentially be somewhat inelastic even under zero execution costs. This would however just be another reason to move forward with this proposal. Regardless of the exact shape of the demand curve—which of course will remain unknown and can vary going forward—the proposal is based on something tangible affecting blob consumers. This makes it a justified neutral bound on the blob base fee.</p>
Blob KZG proof verification cost</h3>
EIP-4844 introduced the first phase of Ethereum's data availability sampling (DAS) roadmap. Validators on the consensus layer (CL) verify that the KZG commitments</code> in the payload correspond to the provided blobs</code> by cryptographically verifying the accompanying KZG proofs</code>. Execution layer (EL) nodes must also validate the tx_payload_body</code> and verify the wrapped data (blobs, commitments, and proofs) for every blob entering a node's tx pool. The computational requirements for verifying a KZG proof for an entire blob are slightly higher than those for verifying a KZG proof for a single point on that blob; the latter is the specific operation covered by the POINT_EVALUATION_PRECOMPILE_GAS</code> (50000) charged to smart contracts.</p>
EIP-7594</a> introduces PeerDAS. It changes the compute requirements due to the reliance on blob cells and their individual proofs. The exact specification is not yet fully settled, but this is a rough guideline:</p>

EL nodes batch-verify CELLS_PER_EXT_BLOB</code> (128) cell proofs for each blob before including a tx carrying that blob in their tx pool. This verification (e.g., using verify_cell_kzg_proof_batch</code>) is roughly 15 times more expensive than the compute associated with a single POINT_EVALUATION_PRECOMPILE_GAS</code>.</li>
Full nodes verify 4 custodied columns, each column containing one cell from all blobs referenced in the payload. Each column's cell proofs can be batch-verified (also applicable below).</li>
Supernodes verify 128 custodied columns, each column containing one cell from all blobs referenced in the payload.</li>
Validators between full nodes and supernodes will custody between 4-128 columns.</li>
Nodes peer-sample SAMPLES_PER_SLOT</code> (8) columns each slot (in addition to custodied columns).</li>
</ul>
The ability on the CL to jointly process cell proofs of a column (from all blobs) through batching reduces the compute time spent per blob as the number of blobs increases. It is further possible to batch all columns jointly or to parallelize the processing across columns. When accounting for the prospect of parallelization for the CL, it is however worth remembering that the point evaluation proof verification performed by rollups using the precompile also lends itself to parallelization. This means that a comparison between the point evaluation and the sequential processing of blobs (batched per column) is still relevant (because both</em> could be parallelized).</p>
Figure 2 shows verification time per blob divided by the measured execution time of a single point evaluation operation (performed by the VerifyKZGProof</code> precompile) for various configurations. The figure indicates that blobs under the current Fusaka PeerDAS specification will subject nodes to rather heavy compute requirements—when compared to the single point evaluation proof verification that a smart contract is charged POINT_EVALUATION_PRECOMPILE_GAS</code> for. A full node would for example do the EL mempool verification for all blobs propagated p2p (15x), sample 8 columns (2x at 32 blobs when batching columns sequentially), and custody 4 designated columns (1x). How to price the KZG proof verification is however a complex question given the varying contexts in which it is performed. The proposed constant BLOB_BASE_COST</code> is indicated by a green line in Figure 2. It is relatively moderate in comparison with the compute costs imposed on nodes.</p>
</p>
Figure 2.</strong> Verification time per blob relative to one point evaluation on an Apple M2 Max with 12 cores. The EL mempool verification (red) takes 15 times longer in the worst case, regardless of the blob target. The per-blob verification time of columns depends on the number of custodied/sampled columns and falls with an increase in the blob target due to speed-ups from processing all cells of a column jointly. The constant BLOB_BASE_COST</code> is relatively moderate in comparison with the compute costs that blobs impose on nodes.</p>
Designing for the future</h3>
The price of storing a fixed amount of data has fallen over the last 80 years. Technological progress generally brings down the unit cost of data services, following Nielsen’s law and Moore’s law. The ETH-denominated price per blob should likewise fall as Ethereum increases blob throughput. This effect is reinforced because a higher aggregate ETH-denominated blob revenue (which is distributed to ETH token holders via the burn) increases the fiat-denominated value of the ETH token, ceteris paribus. There is thus an upper bound on the blob base fee—a bound that falls as Ethereum scales. The same reflexivity applies to the execution base fee.</p>
In this light, the proposal can be understood as a design for the future. Fixed thresholds not relating to blob quantity or the execution fee may not be sustainable. In a scenario where Ethereum sells more blobs per block, the equilibrium blob base fee should ideally have a relatively lower floor. Any fixed threshold (not relating to the execution base fee or blob quantity) would need to be gradually readjusted to retain the same relative impact.</p>
If Ethereum increases blob throughput by several orders of magnitude but does not</em> scale blockspace, such that the execution base fee remains high, the reserve price of BLOB_BASE_COST</code> execution gas would however still become too high. At 1000 blobs and 30M execution gas per block, Ethereum would derive just over 1/5th (21.5%) of its income from blob gas even when blobs are strictly sold at the reserve price. This implies a too high BLOB_BASE_COST</code>, but 1000 blobs and 30M execution gas is not the trajectory that Ethereum currently is on. If Ethereum scales blockspace and blobspace roughly in synchrony, it is reasonable to expect that the reserve price remains at the desired level.</p>
Delayed response during a quick rise in execution fees</h3>
When the if</code> statement concludes that Ethereum operates in the execution-fee-led pricing regime, the blob base fee rises in accordance with blob_gas_used * (max - target) // max</code>, without subtracting target_blob_gas</code>. This is an intuitive way to return to the blob-fee-led pricing regime, retaining the same maximum fee increase while not allowing for a decrease. If the execution base fee rises quickly, there may be a few blocks before the blob base fee catches up (during which target_blob_gas</code> will never be subtracted). This is arguably not an issue, and the smooth response in the blob base fee under these circumstances may even be seen as a benefit.</p>
Empirical analysis</h3>
Figures 3-4 show price evolution over three weeks in November 2024, when the average execution base fee was around 16 gwei, as well as in March 2025, when the average was around 1.3 gwei. The proposed reserve fee is applied directly to the original data, without accounting for its potential effect on the equilibrium fee. The equilibrium blob base fee would in reality rise from the threshold level once demand at this fee is above target supply. EIP-7918 imposes the maximum of the two curves, indicated in darker colors.</p>
</p>
Figure 3.</strong> Blob base fee evolution with the current fee market (black) and the proposed reserve fee (blue), during three weeks of November 2024 when the average execution base fee was around 16 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.</p>
</p>
Figure 4.</strong> Blob base fee evolution with the current fee market (black) and the proposed reserve fee (blue), during three weeks of March 2025 when the average execution base fee was around 1.3 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.</p>
Figure 5 shows histograms for observed fees and the maximum of the two curves for the four-month period from November 2024 (start of Figure 3's data period) through March 2025 (end of Figure 4's data period), corresponding to approximately 900k blocks beginning at block number 22075724. The histograms employ 100 log-spaced bins per decade (factor-of-ten increase), which are smoothed using a Hanning window of width 21 with mirror-reflected edges.</p>
</p>
Figure 5.</strong> Histogram of the blob base fee when there is no threshold or when applying EIP-7918 (dashed combination of the darker black and blue curves from previous figures), with light smoothing applied. A four-month period from November 2024 through March 2025 was analyzed. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.</p>
Security Considerations</h2>
The blob base fee will settle at a level where a blob costs at least BLOB_BASE_COST</code> execution gas. To the best of the authors' knowledge, there are no security risks associated with this.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Deterministic proposer lookahead
2025-03-24T00:00:00+00:00
Abstract</h2>
At the start of each epoch, pre-calculate and store in the beacon_state</code> a deterministic proposer_lookahead</code> for the next MIN_SEED_LOOKAHEAD + 1</code> epochs.</p>
Motivation</h2>
Unlike RANDAO seeds, which have a deterministic lookahead of at least MIN_SEED_LOOKAHEAD == 1</code> epochs, the beacon proposer schedule of epoch N + 1</code> is not fully predictable from the beacon state during epoch N</code>. The reason is that, under certain edge cases, the effective balances (EBs) of active validators—themselves used as input for proposer election in epoch N + 1</code>—can change within epoch N</code>.</p>
Based preconfirmation protocols rely on a deterministic proposer schedule for smooth operations. Since the beacon genesis, slashings and penalties that accumulate to at least 1 ETH can change EBs of active validators and lead to an unpredictable proposer schedule despite the RANDAO seed being known ahead of time. The increase of MaxEB with EIP-7251</a> increases effective balance unpredictability because rewards that accumulate to at least 1 ETH, validator consolidations, and deposits can grow EBs of active validators beyond 32 ETH.</p>
Besides fixing next-epoch proposer schedule non-determinism, this EIP makes it possible for the proposer schedule of the next epoch to be accessible to the application layer via the beacon root and a simple Merkle proof. This highly simplifies the implementation of on-chain components for based preconfirmation protocols.</p>
Introducing a fully deterministic lookahead fixes a long-standing beacon chain design oversight, as highlighted by Danny Ryan's comment below:</p>
</p>
With this change, it will no longer be possible for validators to grind effective balances to manipulate the proposer schedule of the next epoch, and the analysis of effective balance grinding will collapse from what is currently a subtle analysis of EB edge cases to a trivial security analysis. Finally, the proposer lookahead gives CL clients ahead-of-time visibility over the next proposer which may simplify implementations.</p>
Specification</h2>
The BeaconState</code> container is extended with a proposer_lookahead</code> field, which is a vector of validator indices covering the full visible lookahead period, starting from the beginning of the current epoch to the next MIN_SEED_LOOKAHEAD</code> epochs.</p>
class</span> BeaconState</span>:</span></span>
    ...</span></span>
    proposer_lookahead</span>:</span> Vector</span>[</span>ValidatorIndex</span>,</span> (</span>MIN_SEED_LOOKAHEAD</span> +</span> 1</span>)</span> *</span> SLOTS_PER_EPOCH</span>]</span></span></code></pre>
For example, proposer_lookahead[0]</code> is the validator index for the first proposer in the current epoch, proposer_lookahead[SLOTS_PER_EPOCH + 4]</code> is the validator index for the fifth proposer in the next epoch, and so forth.</p>
The function get_beacon_proposer_index</code> is modified to use the pre-calculated proposer_lookahead</code> instead of calculating proposer indices on-demand.</p>
def</span> get_beacon_proposer_index</span>(</span>state</span>:</span> BeaconState</span>)</span> -></span> ValidatorIndex</span>:</span></span>
    """</span></span>
    Return the beacon proposer index at the current slot.</span></span>
    """</span></span>
    return</span> state</span>.</span>proposer_lookahead</span>[</span>state</span>.</span>slot</span> %</span> SLOTS_PER_EPOCH</span>]</span></span></code></pre>
At the epoch boundary, the proposer_lookahead</code> is updated by shifting out the current epoch’s lookahead and appending the new one.</p>
def</span> process_epoch</span>(</span>state</span>:</span> BeaconState</span>)</span> -></span> None</span>:</span></span>
    ...</span></span>
    process_proposer_lookahead</span>(</span>state</span>)</span></span>
</span>
def</span> process_proposer_lookahead</span>(</span>state</span>:</span> BeaconState</span>)</span> -></span> None</span>:</span></span>
    last_epoch_start</span> =</span> len</span>(</span>state</span>.</span>proposer_lookahead</span>)</span> -</span> SLOTS_PER_EPOCH</span></span>
    #</span> Shift out proposers in the first epoch</span></span>
    state</span>.</span>proposer_lookahead</span>[</span>:</span>last_epoch_start</span>]</span> =</span> state</span>.</span>proposer_lookahead</span>[</span>SLOTS_PER_EPOCH</span>:</span>]</span></span>
    #</span> Fill in the last epoch with new proposer indices</span></span>
    last_epoch_proposers</span> =</span> get_beacon_proposer_indices</span>(</span></span>
        state</span>,</span> Epoch</span>(</span>get_current_epoch</span>(</span>state</span>)</span> +</span> MIN_SEED_LOOKAHEAD</span> +</span> 1</span>)</span></span>
    )</span></span>
    state</span>.</span>proposer_lookahead</span>[</span>last_epoch_start</span>:</span>]</span> =</span> last_epoch_proposers</span></span>
</span>
def</span> get_beacon_proposer_indices</span>(</span></span>
    state</span>:</span> BeaconState</span>,</span> epoch</span>:</span> Epoch</span></span>
)</span> -></span> Vector</span>[</span>ValidatorIndex</span>,</span> SLOTS_PER_EPOCH</span>]</span>:</span></span>
    """</span></span>
    Return the proposer indices for the given ``epoch``.</span></span>
    """</span></span>
    indices</span> =</span> get_active_validator_indices</span>(</span>state</span>,</span> epoch</span>)</span></span>
    seed</span> =</span> get_seed</span>(</span>state</span>,</span> epoch</span>,</span> DOMAIN_BEACON_PROPOSER</span>)</span></span>
    return</span> compute_proposer_indices</span>(</span>state</span>,</span> epoch</span>,</span> seed</span>,</span> indices</span>)</span></span>
</span>
def</span> compute_proposer_indices</span>(</span></span>
    state</span>:</span> BeaconState</span>,</span> epoch</span>:</span> Epoch</span>,</span> seed</span>:</span> Bytes32</span>,</span> indices</span>:</span> Sequence</span>[</span>ValidatorIndex</span>]</span></span>
)</span> -></span> Vector</span>[</span>ValidatorIndex</span>,</span> SLOTS_PER_EPOCH</span>]</span>:</span></span>
    """</span></span>
    Return the proposer indices for the given ``epoch``.</span></span>
    """</span></span>
    start_slot</span> =</span> compute_start_slot_at_epoch</span>(</span>epoch</span>)</span></span>
    seeds</span> =</span> [</span>hash</span>(</span>seed</span> +</span> uint_to_bytes</span>(</span>Slot</span>(</span>start_slot</span> +</span> i</span>)</span>)</span>)</span> for</span> i</span> in</span> range</span>(</span>SLOTS_PER_EPOCH</span>)</span>]</span></span>
    return</span> [</span>compute_proposer_index</span>(</span>state</span>,</span> indices</span>,</span> seed</span>)</span> for</span> seed</span> in</span> seeds</span>]</span></span></code></pre>
Furthermore, the first block after the fork will calculate all lookaheads for epochs up to MIN_SEED_LOOKAHEAD</code> ahead and fill the proposer_lookahead</code> field in the beacon state.</p>
See the updated beacon chain specs</a> in consensus-specs for more details.</p>
Rationale</h2>
Considered Alternatives</h3>
An alternative approach would be to cache the effective balances at the start of epoch N</code> so it can be used to calculate the proposer lookahead at the start of epoch N+MIN_SEED_LOOKAHEAD</code>. However, this approach would require additional footprint in the beacon state, and would not be able to provide the proposer lookahead to the EVM via the beacon root.</p>
Single Secret Leader Election Compatibility</h3>
In the future, we may introduce a Single Secret Leader Election (SSLE) mechanism in which only the selected validator knows their role until they propose a block. However, current SSLE designs still rely on a lookahead, albeit an encrypted one. In such designs, we could reuse the proposer_lookahead</code> field by changing its type to something like List[EncryptedValidatorIndex]</code>. And if a construction were to remove lookahead entirely, we could simply set proposer_lookahead</code> to an empty list, meaning this wouldn’t be a blocker.</p>
That said, any such changes would introduce additional complexity around preconfirmation protocols, but that complexity arises regardless of this EIP. Furthermore, APS (Attester Proposer Separation) envisions more sophisticated (i.e., more DDoS‑resistant) execution proposers, reducing the need for SSLE.</p>
Added Computation at the Epoch Boundary</h3>
Before this EIP, consensus clients only needed to compute the current proposer’s index at each slot. With the changes introduced by this EIP, they must calculate the entire epoch’s proposer schedule at the start of each epoch. However, computing the proposer index is light, involving sampling validators until we reach a validator with sufficient effective balance to be selected as a proposer. Still, testing is needed to confirm that these additional calculations do not create performance bottlenecks in practice.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Test Cases</h2>
See the spec tests</a> in consensus-specs.</p>
Security Considerations</h2>
Malicious Lookahead Alteration</h3>
A critical consideration for any proposer election mechanism is preventing validators from manipulating lookahead to gain an unfair advantage. This proposal does not increase the chances of such attacks, as we do not alter the “RANDAO delay” used in the lookahead—the lookahead of epoch N</code> is still determined by the RANDAO of epoch N - MIN_SEED_LOOKAHEAD - 1</code> (which becomes available at the start of epoch N - MIN_SEED_LOOKAHEAD</code>). The only difference is that it changes the “effective balances delay”: rather than using the effective balances (EB) at the start of epoch N</code>, it now uses the EB at the start of epoch N - MIN_SEED_LOOKAHEAD</code>.</p>
Furthermore, by aligning the RANDAO and effective balances in this way, the proposal removes any chance of validators adjusting their EB after seeing the RANDAO outcome, which is an attack vector to consider. No such attack has been found so far, but this change removes the possibility, hence simplifying the security analysis.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Signature Verifiers
2025-03-21T00:00:00+00:00
Abstract</h2>
Externally Owned Accounts (EOA) can sign messages with their associated private keys. Additionally ERC-1271</a> defines a method for signature verification by smart accounts such as multisig. In both cases the identity of the signer is an ethereum address. We propose a standard to extend this concept of signer description, and signature verification, to keys that do not have an ethereum identity of their own, in the sense that they don't have their own address to represent them.</p>
This new mechanism can be used to integrate new signers such as non-ethereum cryptographic curves, hardware devices, or even email addresses. This is particularly relevant when dealing with things like social-recovery of smart accounts.</p>
Motivation</h2>
With the development of account abstraction, there is an increasing need for non-ethereum signature verification. Cryptographic algorithms besides the natively supported secp256k1 are being used for controlling smart accounts. In particular, curves such as secp256r1 (supported by many mobile devices) and RSA keys (that are distributed by traditional institutions) are widely available. Beyond these two examples, we also see the emergence of ZK solutions for signing with emails or JWT from big Web2 services.</p>
All these signature mechanisms have one thing in common: they do not have a canonical ethereum address to represent them onchain. While users could deploy ERC-1271 compatible contracts for each key individually, this would be cumbersome and expensive. As account abstraction tries to separate account addresses (that hold assets) from the key that controls them, giving fixed on-chain addresses to keys (and possibly sending assets to these addresses by mistake) is not the right approach. Instead, using a small number of verifier contracts that can process signatures in a standard way, and having the accounts rely on these verifiers, feels like the correct approach. This has the advantage that once the verifier is deployed, any key can be represented using a (verifier, key)</code> pair without requiring any setup cost.</p>
The (verifier, key)</code> pairs can be given permission to control a smart account, perform social recovery, or do any other operation without ever having a dedicated on-chain address. Systems that want to adopt this approach need to transition away from the model where signers are identified by their address to a new model where signers may not have an address, and are identified by a bytes</code> object.</p>
This definition is backward compatible with EOA and ERC-1271 contracts: in that case, we use the address of the identity (EOA or contract) as the verifier and the key is empty.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Nomenclature</h3>

Keys are represented using bytes</code> objects of arbitrary length. For example a P256 or RSA public key. Keys MUST NOT be empty.</li>
Verifiers are smart contracts in charge of signature verification for a given type of key. They have an ethereum address.</li>
</ul>
Signature Verifier interface</h3>
Verifiers MUST implement the following interface:</p>
interface</span> IERC7913SignatureVerifier</span> {</span></span>
  /**</span></span>
   * </span>@dev</span> Verifies `signature` as a valid signature of `hash` by `key`.</span></span>
   *</span></span>
   * MUST return the bytes4 magic value 0x024ad318 (IERC7913SignatureVerifier.verify.selector) if the signature is valid.</span></span>
   * SHOULD return 0xffffffff or revert if the signature is not valid.</span></span>
   * SHOULD return 0xffffffff or revert if the key is empty</span></span>
   */</span></span>
  function</span> verify</span>(</span>bytes</span> calldata</span> key</span>,</span> bytes32</span> hash</span>,</span> bytes</span> calldata</span> signature</span>)</span> external</span> view</span> returns</span> (</span>bytes4</span>)</span>;</span></span>
}</span></span></code></pre>
Verifiers SHOULD be stateless.</p>
Rationale</h2>
Verifiers can be used to avoid deploying many ERC-1271 "identity contract" (one per key), which would be expensive. Using this model, new keys can be used without any deployment costs.</p>
ERC-1271 already covers the cases were a key is not necessary. To avoid ambiguity, the verifiers contracts should not support (or be expected to support) empty keys. Signers that are 20 bytes long (empty key) should be handled using ERC-1271.</p>
Consistency with existing systems (ecrecover and ERC-1271) requires the message to be bytes32</code> hash. These are usually produced following ERC-191</a> or ERC-712</a>. Cryptographic systems that use different hashing methods SHOULD see this hash as a message, and possibly rehash it following the relevant standards.</p>
Backwards Compatibility</h2>
A system can support ERC-7913</a> signers alongside EOAs and ERC-1271 in the following way.</p>
A signer is a bytes</code> object that is the concatenation of an address and optionally a key: verifier || key</code>. A signer is at least 20 bytes long.</p>
Given a signer signer</code>, a message hash hash</code>, and a signature sign</code>, verification is done as follows:</p>

if signer.length < 20</code>: verification fails;</li>
split signer</code> into (verifier, key)</code> with verifier</code> being the first 20 bytes and key</code> being the rest (potentially empty)</li>
if key</code> is empty, then consider that verifier</code> is the identity.

verification is done using ERC-1271's isValidSignature if there is code at verifier</code> address, or ecrecover otherwise</li>
</ul>
</li>
if key</code> is not empty, call IERC7913SignatureVerifier(verifier).verify(key, hash, signature)</code>

if the return value is the expected magic value (0x024ad318</code>) then verification is successful,</li>
otherwise, verification fails.</li>
</ul>
</li>
</ul>
Reference Implementation</h2>
In solidity, signature verification could be implemented in the following library:</p>
import</span> {</span>SignatureChecker</span>}</span> from</span> '@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol'</span>;</span></span>
</span>
///</span> @dev</span> Extention of openzeppelin's SignatureChecker library</span></span>
library</span> SignatureCheckerExtended</span> {</span></span>
  function</span> isValidSignatureNow</span>(</span>bytes</span> calldata</span> signer</span>,</span> bytes32</span> hash</span>,</span> bytes</span> memory</span> signature</span>)</span> internal</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span>
      if</span> (</span>signer</span>.</span>length </span><</span> 20</span> )</span> {</span></span>
        return</span> false</span>;</span></span>
      }</span> else</span> if</span> (</span>signer</span>.</span>length </span>==</span> 20</span>)</span> {</span></span>
        return</span> SignatureChecker</span>.</span>isValidSignatureNow</span>(</span>address</span>(</span>bytes20</span>(</span>signer</span>)</span>)</span>,</span> hash</span>,</span> signature</span>)</span>;</span></span>
      }</span> else</span> {</span></span>
        try</span> IERC7913SignatureVerifier</span>(</span>address</span>(</span>bytes20</span>(</span>signer</span>[</span>0</span>:</span>20</span>]</span>)</span>)</span>)</span>.</span>verify</span>(</span>signer</span>[</span>20</span>:</span>]</span>,</span> hash</span>,</span> signature</span>)</span> returns</span> (</span>bytes4</span> magic</span>)</span> {</span></span>
          return</span> magic </span>==</span> IERC7913SignatureVerifier</span>.</span>verify</span>.</span>selector</span>;</span></span>
        }</span> catch</span> {</span></span>
          return</span> false</span>;</span></span>
        }</span></span>
      }</span></span>
  }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Signer may be used for anything from smart account session key (with a short lifetime of a few hours/days) to social recovery "guardians" that may only be used several years after they are setup. In order to ensure that these signers remain valid "in perpetuity", the verifier contract should be trustless. This means that the verifiers should not be upgradeable contracts.</p>
Verifiers should also not depend on any value that can be modified after deployment. In solidity terms, the verify</code> function should be pure. Any parameters that are involved in signature verification should either be part of the key, or part of immutable code of the verifier. Using immutable</code> variable (in solidity) would be safe. The stateless aspect of the verifier also ensure compliance (of the verifier) with ERC-7562</a> scope rules.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


eth_config JSON-RPC Method
2025-03-18T00:00:00+00:00
Abstract</h2>
This document describes an RPC method that provides node-relevant configuration data for the current, next, and last known forks.</p>
Motivation</h2>
Throughout Ethereum's history, there have been multiple instances where a client was not correctly configured for an upcoming hard fork, causing it to fall out of consensus when the fork boundary was crossed. Most incidents have been minor, such as a single client forking the chain in proof-of-work or having its blocks orphaned in proof-of-stake.</p>
The most significant occurrence was during the Pectra activation on the Holešky testnet. Four out of six clients on the network had an incorrect configuration for the deposits contract. Instead of being orphaned, the incorrect chain was justified, and the side effects persist on Holešky even after reaching finality.</p>
By providing an RPC method that allows clients to report key configuration variables before the next hard fork, operations teams can gain greater confidence that clients are correctly configured and prepared for upcoming forks.</p>
Target Audience and Use Cases</h3>
This method is intended for node operators, validator teams, and network monitoring tools to verify client readiness for upcoming forks. Use cases include:</p>

Automated pre-fork validation scripts comparing eth_config</code> outputs across nodes.</li>
Manual checks by validator operators to ensure alignment with fork specifications.</li>
Debugging by client developers to identify configuration mismatches.</li>
Automated checks by Consensus Layer counterparties.</li>
</ul>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Clients MUST expose a new RPC method to report the current functional configuration and the expected next configuration via the standard JSON-RPC port.</p>
Clients MAY also expose this method through the Engine API.</p>
Clients MAY use these configuration objects to manage their per-fork configurations, though they SHOULD NOT simply return unprocessed configuration data.</p>
When reporting the current, next and last configurations, clients MUST include every configuration parameter specified in this EIP.</p>
Clients MUST return up-to-date configuration values, reflecting the most recent block header they provide. If clients cache the configuration, they MUST ensure such caches are purged when fork boundaries are crossed.</p>
Configuration RPC</h3>
A new JSON-RPC API, eth_config</code>, is introduced. It takes no parameters and returns the result object specified in the next section.</p>
Result Object Structure</h3>
The RPC response contains three members: "current", "next", and "last". These members contain the configuration object currently in effect, the next configuration, and the last known configuration, respectively. "next" and "last" will be null</code> if the client is not configured to support a future fork. "next" and "last" members will contain the same configuration in the case where the next configured fork is also the last configured fork.</p>
Members of the Configuration Object</h3>
Each configuration object MUST contain the following members, presented in alphabetical order. This RPC assumes the network is post-merge, and no accommodations are specified for proof-of-work-related issues.</p>
Future forks may add, adjust, remove, or update members. The respective changes MUST be defined in either their EIPs or their respective meta-EIPs. Added members MUST be alphabetically sorted, so simply naming the new members is sufficient definition.</p>
activationTime</code></h4>
The fork activation timestamp, represented as a JSON number in Unix epoch seconds (UTC). For the "current" configuration, this reflects the actual activation time; for "next" and "last", it is the scheduled time.</p>
Activation time is required. If a fork is activated at genesis, the value 0</code> is used. If the fork is not scheduled to be activated or its activation time is unknown, it should not be in the RPC results.</p>
blobSchedule</code></h4>
The blob configuration parameters for the specific fork, as defined in the genesis file. This is a JSON object with three members—baseFeeUpdateFraction</code>, max</code>, and target</code>—all represented as JSON numbers.</p>
chainId</code></h4>
The chain ID of the current network, presented as a string with an unsigned 0x</code>-prefixed hexadecimal number, with all leading zeros removed, in lower case. This specification does not support chains without a chain ID or with a chain ID of zero.</p>
For purposes of canonicalization, this value must always be a string.</p>
forkId</code></h4>
The FORK_HASH</code> value as specified in EIP-6122</a> of the specific fork, presented as an unsigned 0x</code>-prefixed hexadecimal number, with zeros left-padded to a four-byte length, in lower case.</p>
precompiles</code></h4>
A representation of the active precompile contracts for the fork. If a precompiled contract is replaced by an on-chain contract—or removed—then it is not included.</p>
This is a JSON object where the members are the agreed-upon names for each contract, typically specified in the EIP defining that contract, and the values are the 20-byte 0x</code>-prefixed hexadecimal addresses of the precompiles (with zeros preserved), in lower case.</p>
For Cancun, the contract names are (in order): ECREC</code>, SHA256</code>, RIPEMD160</code>, ID</code>, MODEXP</code>, BN254_ADD</code>, BN254_MUL</code>, BN254_PAIRING</code>, BLAKE2F</code>, KZG_POINT_EVALUATION</code>.</p>
For Prague, the added contracts are (in order): BLS12_G1ADD</code>, BLS12_G1MSM</code>, BLS12_G2ADD</code>, BLS12_G2MSM</code>, BLS12_PAIRING_CHECK</code>, BLS12_MAP_FP_TO_G1</code>, BLS12_MAP_FP2_TO_G2</code>.</p>
For Osaka, the added contract is: P256VERIFY</code>.</p>
systemContracts</code></h4>
A JSON object representing system-level contracts relevant to the fork, as introduced in their defining EIPs. Keys are the contract names (e.g., BEACON_ROOTS_ADDRESS</code>) from the first EIP where they appeared, sorted alphabetically. Values are 20-byte addresses in 0x</code>-prefixed hexadecimal form, with leading zeros preserved, in lower case. Omitted for forks before Cancun.</p>
For Cancun, the only system contract is BEACON_ROOTS_ADDRESS</code>.</p>
For Prague, the system contracts are (in order) BEACON_ROOTS_ADDRESS</code>, CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code>, DEPOSIT_CONTRACT_ADDRESS</code>, HISTORY_STORAGE_ADDRESS</code>, and WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</code>.</p>
Future forks MUST define the list of system contracts in their meta-EIPs.</p>
Blob Parameter Only (BPO) Forks</h3>
BPO forks should be interpreted as new forks, taking the parent fork as base (recursively, if the parent fork is also a BPO) and updating only the appropriate values in the blobSchedule</code> object to produce the new fork configuration.</p>
Rationale</h2>
Why Enumerate Precompiles? (And in General, Why Track a Particular Config Item?)</h3>
The purpose of this specification is to enable nodes to advertise, prior to a fork, that they have the correct configurations loaded and ready. Past testnet and Ethereum Mainnet forks have revealed clients with incorrect precompile sets, chain IDs, deposit contract addresses, and other configuration errors.</p>
For precompiles in particular there has been discussion about removing or replacing precompiles in future forks, so a full enumeration of precompiles will reflect removal.</p>
Generally, if a configurable variable or constant causes a client to diverge at a fork—whether on Ethereum Mainnet, a testnet, a devnet, or a public rollup—that variable or constant is a candidate for inclusion in the reportable configuration.</p>
Full Configs Instead of Deltas</h3>
An initial design considered using a partial configuration for the "next" fork instead of a complete one. However, analysis of past events showed that some parameters causing divergence (e.g., the deposit contract) were introduced in earlier forks, with consensus failures occurring in later forks due to unrelated EIPs relying on those configurations. A partial "next" configuration hash would not have detected such errors.</p>
An alternative—embedding the prior fork’s hash in the next fork—would require defining rules for extracting differences and merging configurations, as well as specifying all prior fork configuration hashes. This would also complicate retroactively adding parameters (e.g., gas schedule constants and variables). The use of config hashes was also removed in a subsequent update.</p>
Nested vs. Flat Variables</h3>
Nested structures are easier to read, while flat structures are easier to merge. Since this specification uses full configurations for the current and next forks, merging is unnecessary, making readability the priority.</p>
Serving Data Not Specified in genesis.json</h3>
Some reported values are specification-level constants, which many clients do not include in their configuration files. However, certain EIP constants (e.g., the deposit contract) have become variables in testnets, necessitating their inclusion.</p>
JSON as Config Format</h3>
JSON was chosen for its ubiquity, machine and human readability, and the existence of a standardized canonical form via RFC-8785</a>. YAML lacks a standard canonical form. No Ethereum software uses XML for configuration, and adopting it would increase every client's library size. An invented format would be possible but would require definition and standardization within this specification.</p>
Why no configuration hash</h3>
Initial drafts included a hash of the configuration data for quick comparison. There was disagreement about the data format used to generate the hash (plain JSON, RLP, SSZ). Because tooling can effectively diff JSON objects by alphabetizing object keys, the hash is superfluous.</p>
Backwards Compatibility</h2>
This EIP does not alter previous behavior. Configurations prior to Cancun are non-standard, and clients sharing pre-Cancun configurations will produce non-standard results.</p>
Clients supporting pre-Cancun forks MAY return partial or non-standard configurations but SHOULD strive to follow the spirit of the members specified for Cancun configurations. Full compliance is REQUIRED only for Cancun and later forks.</p>
Test Cases</h2>
Sample Configs</h3>
Hoodi Prague Config</p>
{</span></span>
  "</span>activationTime</span>"</span>:</span> 1742999832</span>,</span></span>
  "</span>blobSchedule</span>"</span>:</span> {</span></span>
    "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span>,</span></span>
    "</span>max</span>"</span>:</span> 9</span>,</span></span>
    "</span>target</span>"</span>:</span> 6</span></span>
  }</span>,</span></span>
  "</span>chainId</span>"</span>:</span> "</span>0x88bb0</span>"</span>,</span></span>
  "</span>forkId</span>"</span>:</span> "</span>0x0929e24e</span>"</span>,</span></span>
  "</span>precompiles</span>"</span>:</span> {</span></span>
    "</span>BLAKE2F</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000009</span>"</span>,</span></span>
    "</span>BLS12_G1ADD</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000b</span>"</span>,</span></span>
    "</span>BLS12_G1MSM</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000c</span>"</span>,</span></span>
    "</span>BLS12_G2ADD</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000d</span>"</span>,</span></span>
    "</span>BLS12_G2MSM</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000e</span>"</span>,</span></span>
    "</span>BLS12_MAP_FP2_TO_G2</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000011</span>"</span>,</span></span>
    "</span>BLS12_MAP_FP_TO_G1</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000010</span>"</span>,</span></span>
    "</span>BLS12_PAIRING_CHECK</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000f</span>"</span>,</span></span>
    "</span>BN254_ADD</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000006</span>"</span>,</span></span>
    "</span>BN254_MUL</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000007</span>"</span>,</span></span>
    "</span>BN254_PAIRING</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000008</span>"</span>,</span></span>
    "</span>ECREC</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000001</span>"</span>,</span></span>
    "</span>ID</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000004</span>"</span>,</span></span>
    "</span>KZG_POINT_EVALUATION</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000a</span>"</span>,</span></span>
    "</span>MODEXP</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000005</span>"</span>,</span></span>
    "</span>RIPEMD160</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000003</span>"</span>,</span></span>
    "</span>SHA256</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000002</span>"</span></span>
  }</span>,</span></span>
  "</span>systemContracts</span>"</span>:</span> {</span></span>
    "</span>BEACON_ROOTS_ADDRESS</span>"</span>:</span> "</span>0x000f3df6d732807ef1319fb7b8bb8522d0beac02</span>"</span>,</span></span>
    "</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>"</span>:</span> "</span>0x0000bbddc7ce488642fb579f8b00f3a590007251</span>"</span>,</span></span>
    "</span>DEPOSIT_CONTRACT_ADDRESS</span>"</span>:</span> "</span>0x00000000219ab540356cbb839cbe05303d7705fa</span>"</span>,</span></span>
    "</span>HISTORY_STORAGE_ADDRESS</span>"</span>:</span> "</span>0x0000f90827f1c53a10cb7a02335b175320002935</span>"</span>,</span></span>
    "</span>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span>"</span>:</span> "</span>0x00000961ef480eb55e80d19ad83579a64c007002</span>"</span></span>
  }</span></span>
}</span></span></code></pre>
Hoodi Cancun Config</p>
{</span></span>
  "</span>activationTime</span>"</span>:</span> 0</span>,</span></span>
  "</span>blobSchedule</span>"</span>:</span> {</span></span>
    "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span>,</span></span>
    "</span>max</span>"</span>:</span> 6</span>,</span></span>
    "</span>target</span>"</span>:</span> 3</span></span>
  }</span>,</span></span>
  "</span>chainId</span>"</span>:</span> "</span>0x88bb0</span>"</span>,</span></span>
  "</span>forkId</span>"</span>:</span> "</span>0xbef71d30</span>"</span>,</span></span>
  "</span>precompiles</span>"</span>:</span> {</span></span>
    "</span>BLAKE2F</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000009</span>"</span>,</span></span>
    "</span>BN254_ADD</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000006</span>"</span>,</span></span>
    "</span>BN254_MUL</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000007</span>"</span>,</span></span>
    "</span>BN254_PAIRING</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000008</span>"</span>,</span></span>
    "</span>ECREC</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000001</span>"</span>,</span></span>
    "</span>ID</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000004</span>"</span>,</span></span>
    "</span>KZG_POINT_EVALUATION</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000a</span>"</span>,</span></span>
    "</span>MODEXP</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000005</span>"</span>,</span></span>
    "</span>RIPEMD160</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000003</span>"</span>,</span></span>
    "</span>SHA256</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000002</span>"</span></span>
  }</span>,</span></span>
  "</span>systemContracts</span>"</span>:</span> {</span></span>
    "</span>BEACON_ROOTS_ADDRESS</span>"</span>:</span> "</span>0x000f3df6d732807ef1319fb7b8bb8522d0beac02</span>"</span></span>
  }</span></span>
}</span></span></code></pre>Sample JSON-RPC</h4>
With Future Fork Scheduled</h5>
The following RPC command, issued on Hoodi when Prague was scheduled but not activated:</p>
curl</span> -</span>X</span> POST</span> -</span>H</span> "</span>Content-Type: application/json</span>"</span> -</span>-data</span> '</span>{"jsonrpc":"2.0","method":"eth_config","id":1}</span>'</span> http://localhost:8545</span></span></code></pre>
would return (after formatting):</p>
{</span></span>
  "</span>jsonrpc</span>"</span>:</span> "</span>2.0</span>"</span>,</span></span>
  "</span>id</span>"</span>:</span> 1</span>,</span></span>
  "</span>result</span>"</span>:</span> {</span></span>
    "</span>current</span>"</span>:</span> {</span></span>
      "</span>activationTime</span>"</span>:</span> 0</span>,</span></span>
      "</span>blobSchedule</span>"</span>:</span> {</span></span>
        "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span>,</span></span>
        "</span>max</span>"</span>:</span> 6</span>,</span></span>
        "</span>target</span>"</span>:</span> 3</span></span>
      }</span>,</span></span>
      "</span>chainId</span>"</span>:</span> "</span>0x88bb0</span>"</span>,</span></span>
      "</span>forkId</span>"</span>:</span> "</span>0xbef71d30</span>"</span>,</span></span>
      "</span>precompiles</span>"</span>:</span> {</span></span>
        "</span>BLAKE2F</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000009</span>"</span>,</span></span>
        "</span>BN254_ADD</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000006</span>"</span>,</span></span>
        "</span>BN254_MUL</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000007</span>"</span>,</span></span>
        "</span>BN254_PAIRING</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000008</span>"</span>,</span></span>
        "</span>ECREC</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000001</span>"</span>,</span></span>
        "</span>ID</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000004</span>"</span>,</span></span>
        "</span>KZG_POINT_EVALUATION</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000a</span>"</span>,</span></span>
        "</span>MODEXP</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000005</span>"</span>,</span></span>
        "</span>RIPEMD160</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000003</span>"</span>,</span></span>
        "</span>SHA256</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000002</span>"</span></span>
      }</span>,</span></span>
      "</span>systemContracts</span>"</span>:</span> {</span></span>
        "</span>BEACON_ROOTS_ADDRESS</span>"</span>:</span> "</span>0x000f3df6d732807ef1319fb7b8bb8522d0beac02</span>"</span></span>
      }</span></span>
    }</span>,</span></span>
    "</span>next</span>"</span>:</span> {</span></span>
      "</span>activationTime</span>"</span>:</span> 1742999832</span>,</span></span>
      "</span>blobSchedule</span>"</span>:</span> {</span></span>
        "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span>,</span></span>
        "</span>max</span>"</span>:</span> 9</span>,</span></span>
        "</span>target</span>"</span>:</span> 6</span></span>
      }</span>,</span></span>
      "</span>chainId</span>"</span>:</span> "</span>0x88bb0</span>"</span>,</span></span>
      "</span>forkId</span>"</span>:</span> "</span>0x0929e24e</span>"</span>,</span></span>
      "</span>precompiles</span>"</span>:</span> {</span></span>
        "</span>BLAKE2F</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000009</span>"</span>,</span></span>
        "</span>BLS12_G1ADD</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000b</span>"</span>,</span></span>
        "</span>BLS12_G1MSM</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000c</span>"</span>,</span></span>
        "</span>BLS12_G2ADD</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000d</span>"</span>,</span></span>
        "</span>BLS12_G2MSM</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000e</span>"</span>,</span></span>
        "</span>BLS12_MAP_FP2_TO_G2</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000011</span>"</span>,</span></span>
        "</span>BLS12_MAP_FP_TO_G1</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000010</span>"</span>,</span></span>
        "</span>BLS12_PAIRING_CHECK</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000f</span>"</span>,</span></span>
        "</span>BN254_ADD</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000006</span>"</span>,</span></span>
        "</span>BN254_MUL</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000007</span>"</span>,</span></span>
        "</span>BN254_PAIRING</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000008</span>"</span>,</span></span>
        "</span>ECREC</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000001</span>"</span>,</span></span>
        "</span>ID</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000004</span>"</span>,</span></span>
        "</span>KZG_POINT_EVALUATION</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000a</span>"</span>,</span></span>
        "</span>MODEXP</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000005</span>"</span>,</span></span>
        "</span>RIPEMD160</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000003</span>"</span>,</span></span>
        "</span>SHA256</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000002</span>"</span></span>
      }</span>,</span></span>
      "</span>systemContracts</span>"</span>:</span> {</span></span>
        "</span>BEACON_ROOTS_ADDRESS</span>"</span>:</span> "</span>0x000f3df6d732807ef1319fb7b8bb8522d0beac02</span>"</span>,</span></span>
        "</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>"</span>:</span> "</span>0x0000bbddc7ce488642fb579f8b00f3a590007251</span>"</span>,</span></span>
        "</span>DEPOSIT_CONTRACT_ADDRESS</span>"</span>:</span> "</span>0x00000000219ab540356cbb839cbe05303d7705fa</span>"</span>,</span></span>
        "</span>HISTORY_STORAGE_ADDRESS</span>"</span>:</span> "</span>0x0000f90827f1c53a10cb7a02335b175320002935</span>"</span>,</span></span>
        "</span>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span>"</span>:</span> "</span>0x00000961ef480eb55e80d19ad83579a64c007002</span>"</span></span>
      }</span></span>
    }</span>,</span></span>
    "</span>last</span>"</span>:</span> {</span></span>
      "</span>activationTime</span>"</span>:</span> 1742999832</span>,</span></span>
      "</span>blobSchedule</span>"</span>:</span> {</span></span>
        "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span>,</span></span>
        "</span>max</span>"</span>:</span> 9</span>,</span></span>
        "</span>target</span>"</span>:</span> 6</span></span>
      }</span>,</span></span>
      "</span>chainId</span>"</span>:</span> "</span>0x88bb0</span>"</span>,</span></span>
      "</span>forkId</span>"</span>:</span> "</span>0x0929e24e</span>"</span>,</span></span>
      "</span>precompiles</span>"</span>:</span> {</span></span>
        "</span>BLAKE2F</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000009</span>"</span>,</span></span>
        "</span>BLS12_G1ADD</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000b</span>"</span>,</span></span>
        "</span>BLS12_G1MSM</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000c</span>"</span>,</span></span>
        "</span>BLS12_G2ADD</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000d</span>"</span>,</span></span>
        "</span>BLS12_G2MSM</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000e</span>"</span>,</span></span>
        "</span>BLS12_MAP_FP2_TO_G2</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000011</span>"</span>,</span></span>
        "</span>BLS12_MAP_FP_TO_G1</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000010</span>"</span>,</span></span>
        "</span>BLS12_PAIRING_CHECK</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000f</span>"</span>,</span></span>
        "</span>BN254_ADD</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000006</span>"</span>,</span></span>
        "</span>BN254_MUL</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000007</span>"</span>,</span></span>
        "</span>BN254_PAIRING</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000008</span>"</span>,</span></span>
        "</span>ECREC</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000001</span>"</span>,</span></span>
        "</span>ID</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000004</span>"</span>,</span></span>
        "</span>KZG_POINT_EVALUATION</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000a</span>"</span>,</span></span>
        "</span>MODEXP</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000005</span>"</span>,</span></span>
        "</span>RIPEMD160</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000003</span>"</span>,</span></span>
        "</span>SHA256</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000002</span>"</span></span>
      }</span>,</span></span>
      "</span>systemContracts</span>"</span>:</span> {</span></span>
        "</span>BEACON_ROOTS_ADDRESS</span>"</span>:</span> "</span>0x000f3df6d732807ef1319fb7b8bb8522d0beac02</span>"</span>,</span></span>
        "</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>"</span>:</span> "</span>0x0000bbddc7ce488642fb579f8b00f3a590007251</span>"</span>,</span></span>
        "</span>DEPOSIT_CONTRACT_ADDRESS</span>"</span>:</span> "</span>0x00000000219ab540356cbb839cbe05303d7705fa</span>"</span>,</span></span>
        "</span>HISTORY_STORAGE_ADDRESS</span>"</span>:</span> "</span>0x0000f90827f1c53a10cb7a02335b175320002935</span>"</span>,</span></span>
        "</span>WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS</span>"</span>:</span> "</span>0x00000961ef480eb55e80d19ad83579a64c007002</span>"</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>Without Future Fork Scheduled</h5>
When no future forks are configured, the same RPC command would return:</p>
{</span></span>
  "</span>jsonrpc</span>"</span>:</span> "</span>2.0</span>"</span>,</span></span>
  "</span>id</span>"</span>:</span> 1</span>,</span></span>
  "</span>result</span>"</span>:</span> {</span></span>
    "</span>current</span>"</span>:</span> {</span></span>
      "</span>activationTime</span>"</span>:</span> 0</span>,</span></span>
      "</span>blobSchedule</span>"</span>:</span> {</span></span>
        "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span>,</span></span>
        "</span>max</span>"</span>:</span> 6</span>,</span></span>
        "</span>target</span>"</span>:</span> 3</span></span>
      }</span>,</span></span>
      "</span>chainId</span>"</span>:</span> "</span>0x88bb0</span>"</span>,</span></span>
      "</span>forkId</span>"</span>:</span> "</span>0xbef71d30</span>"</span>,</span></span>
      "</span>precompiles</span>"</span>:</span> {</span></span>
        "</span>BLAKE2F</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000009</span>"</span>,</span></span>
        "</span>BN254_ADD</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000006</span>"</span>,</span></span>
        "</span>BN254_MUL</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000007</span>"</span>,</span></span>
        "</span>BN254_PAIRING</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000008</span>"</span>,</span></span>
        "</span>ECREC</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000001</span>"</span>,</span></span>
        "</span>ID</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000004</span>"</span>,</span></span>
        "</span>KZG_POINT_EVALUATION</span>"</span>:</span> "</span>0x000000000000000000000000000000000000000a</span>"</span>,</span></span>
        "</span>MODEXP</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000005</span>"</span>,</span></span>
        "</span>RIPEMD160</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000003</span>"</span>,</span></span>
        "</span>SHA256</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000002</span>"</span></span>
      }</span>,</span></span>
      "</span>systemContracts</span>"</span>:</span> {</span></span>
        "</span>BEACON_ROOTS_ADDRESS</span>"</span>:</span> "</span>0x000f3df6d732807ef1319fb7b8bb8522d0beac02</span>"</span></span>
      }</span></span>
    }</span>,</span></span>
    "</span>next</span>"</span>:</span> null</span>,</span></span>
    "</span>last</span>"</span>:</span> null</span></span>
  }</span></span>
}</span></span></code></pre>Security Considerations</h2>

Exposure Risks</strong>: Incorrect configurations could leak operational details. Operators SHOULD restrict eth_config</code> to trusted interfaces (e.g., local access or authenticated endpoints).</li>
Dishonest Nodes</strong>: Clients may report false configurations. Peers or monitoring tools MAY cross-check eth_config</code> outputs against known fork specifications or other nodes' responses to detect anomalies.</li>
DDoS Mitigation</strong>: Clients MAY cache configuration objects internally and rate-limit eth_config</code> requests to prevent resource exhaustion. Implementations MAY impose a minimum response interval (e.g., 1 second).</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


HD wallet In Treasury Management
2025-03-07T00:00:00+00:00
Abstract</h2>
This proposal aims to provide a standardized method for on-chain treasury management of institutional assets, ensuring secure private key generation, hierarchical management, and departmental permission isolation while supporting asset security and transaction efficiency in multi-chain environments. By defining a unified derivation path and security mechanisms, this proposal offers an efficient and secure solution for treasury management.</p>
Motivation</h2>
With the rapid development of blockchain and DeFi, secure management of on-chain assets has become critical. Traditional private key management struggles to meet the security demands of large organizations in complex scenarios, where hierarchical key management, permission controls, and multi-signature mechanisms are essential. This proposal provides a standardized solution for institutional treasury management, ensuring asset security and transaction efficiency.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119</a> and RFC 8174</a>.</p>
Derivation Path</h3>
For secure on-chain treasury account key management, implementations MUST use the following hierarchical
deterministic (HD) path:</p>
m/44'/60'/entity_id' / department_id' / account_index</span></span></code></pre>
Path Components:</p>


Master Key (</strong>m</code>)</strong></p>

SHALL represent the root HD wallet private key.</li>
</ul>
</li>

BIP 44</a> Compliance Layer (44'</code>)</strong></p>

MUST use 44'</code> (hardened) to indicate BIP 44 compliance.</li>
</ul>
</li>

Coin Type Layer ( 60'</code> )</strong></p>

SHALL use 60'</code> (hardened) for Ethereum and EVM-compatible chains.</li>
</ul>
</li>

Entity Identifier ( entity_id'</code></strong>)</p>

MUST be derived by hashing the subsidiary name into a hardened index.</li>
MUST NOT reuse the same entity_id'</code> across distinct subsidiaries.</li>
</ul>
</li>

Department Identifier (</strong>department_id'</code>)</strong></p>

SHALL be derived by hashing the department name into a hardened index.</li>
MUST isolate keys between departments via hardened derivation.</li>
</ul>
</li>

Account Index (</strong>account_index</code>)</strong></p>

MUST use non-hardened derivation to allow unified account management.</li>
</ul>
</li>
</ol>
Note on BIP 44 Adaptation</strong>:</p>

The BIP 44 change</code> layer SHOULD be omitted for Ethereum/EVMs due to their account model (not UTXO).</li>
</ul>
Hash Conversion</h3>
To derive entity_id</code> and department_id</code>:</p>


Entity Index Calculation</strong></p>

SHALL compute entity_id</code> as:</li>
</ul>
</li>
</ol>
entity_hash</span> =</span> sha256</span>(</span>f</span>"</span>ENTITY:</span>{</span>entity</span>}</span>"</span>.</span>encode</span>(</span>)</span>)</span>.</span>digest</span>(</span>)</span>  </span></span>
entity_index</span> =</span> int</span>.</span>from_bytes</span>(</span>entity_hash</span>[</span>:</span>4</span>]</span>,</span> "</span>big</span>"</span>)</span> |</span> 0x</span>80000000</span>   #</span> 2^31 ≤ index < 2^32</span></span></code></pre>


Department Index Calculation</strong></p>

MUST compute department_id</code> as:</li>
</ul>
</li>
</ol>
dept_hash</span> =</span> sha256</span>(</span>f</span>"</span>DEPT:</span>{</span>entity_hash</span>}</span>:</span>{</span>department</span>}</span>"</span>.</span>encode</span>(</span>)</span>)</span>.</span>digest</span>(</span>)</span>  </span></span>
dept_index</span> =</span> int</span>.</span>from_bytes</span>(</span>dept_hash</span>[</span>:</span>4</span>]</span>,</span> "</span>big</span>"</span>)</span> |</span> 0x</span>80000000</span>   #</span> 2^31 ≤ index < 2^32</span></span></code></pre>


Output Constraints</strong></p>

Generated indices MUST be integers in [2^31, 2^32-1]</code> to enforce hardened derivation.</li>
</ul>
</li>
</ol>
Extended Path for Role-Based Access</h3>
For finer access control (e.g., roles within departments):</p>
m/60'/entity_id' / department_id' /role_id'/ account_index</span></span></code></pre>


Role Identifier (</strong>role_id'</code>)</strong></p>

SHOULD use hardened derivation to isolate role-specific keys.</li>
</ul>
</li>
</ol>
Compatibility Note</strong>:</p>

Omitting the 44'</code> layer MAY cause incompatibility with standard wallets (e.g., MetaMask).</li>
Integrations with such wallets MUST implement custom plugins to handle this deviation.</li>
</ul>
Simplified Path for Smaller Entities</h3>
For entities without subsidiaries:</p>
m/44'/60' / department_id' /0/ account_index</span></span></code></pre>
Compatibility Guarantee</strong></p>

This structure SHOULD ensure compatibility with mainstream BIP 44 wallets.</li>
</ul>
Key Derivation Algorithm</h3>
Implementations MUST adhere to:</p>
E = Map<entity, List<Department>></span></span>
n = Layer2 curve order</span></span>
path = m/44'/60'/entity_id' / department_id' / account_index</span></span>
BIP32() = Official BIP-0032 derivation function on secp256k1</span></span>
hash = SHA256</span></span>
root_key = BIP32(path)</span></span>
for each E:</span></span>
	key = hash(root_key|hierarchical_hash_to_index(entity,department))</span></span>
	return key</span></span></code></pre>
Cryptographic Requirements</strong>:</p>

SHALL use BIP 32</a> with secp256k1</code> for HD derivation.</li>
MUST concatenate hashes with root keys to prevent cross-layer key leakage.</li>
</ul>
Compatibility Considerations</strong></h3>
This specification is inspired by BIP 44 (m/purpose'/coin_type'/account'/change/address_index</code>), but:</p>

SHALL NOT use the change</code> layer for Ethereum-based systems.</li>
MAY extend the hierarchy beyond BIP 44’s 5-layer structure for organizational needs.</li>
</ul>
Rationale</h2>
The scenarios for which the proposal applies are:</p>

Company and Department Isolation</strong>: Different subsidiaries within the group, as well as different departments within each subsidiary, can create isolated on-chain accounts. Enhanced derivation is used to isolate exposure risks.</li>
Group Unified Management Authority</strong>: The group administrator holds the master private key, which can derive all subsidiary private keys, granting the highest authority to view and initiate transactions across the entire group, facilitating unified management by the group administrator.</li>
Shared Department Private Key</strong>: If subsidiary A's administrator, Alice, needs to share accounts under subsidiary A with a new administrator, Bob, she only needs to share the master private key of subsidiary A. Accounts from various departments can then be derived from this key.</li>
Shared Audit Public Key</strong>: If the audit department needs to audit transactions under a specific department, the extended public key of the specified department can be shared with the audit department. Through this extended public key, all subordinate public keys under the department can be derived, allowing the audit department to track all transactions associated with these public key addresses.</li>
</ol>
Backwards Compatibility</h2>
This standard complies with BIP 39, BIP 32, and BIP 44.</p>
Reference Implementation</h2>
"""</span></span>
Secure Treasury Management System</span></span>
Enterprise-grade hierarchical deterministic wallet implementation compliant with BIP-44</span></span>
"""</span></span>
</span>
import</span> hashlib</span></span>
import</span> logging</span></span>
from</span> typing</span> import</span> Tuple</span>,</span> Dict</span></span>
from</span> bip32utils</span> import</span> BIP32Key</span></span>
from</span> eth_account</span> import</span> Account</span></span>
from</span> mnemonic</span> import</span> Mnemonic</span>  #</span> Add BIP39 support</span></span>
</span>
#</span> Configure logging</span></span>
logging</span>.</span>basicConfig</span>(</span>level</span>=</span>logging</span>.</span>INFO</span>)</span></span>
logger</span> =</span> logging</span>.</span>getLogger</span>(</span>"</span>TreasurySystem</span>"</span>)</span></span>
</span>
class</span> TreasurySystem</span>:</span></span>
    def</span> __init__</span>(</span>self</span>,</span> mnemonic</span>:</span> str</span>)</span>:</span></span>
        """</span></span>
        Initialize the treasury system</span></span>
        :param mnemonic: BIP-39 mnemonic (12/24 words)</span></span>
        """</span></span>
        if</span> not</span> Mnemonic</span>(</span>"</span>english</span>"</span>)</span>.</span>check</span>(</span>mnemonic</span>)</span>:</span></span>
            raise</span> ValueError</span>(</span>"</span>Invalid BIP-39 mnemonic</span>"</span>)</span></span>
        </span></span>
        #</span> Generate seed using standard BIP-39</span></span>
        self</span>.</span>seed</span> =</span> Mnemonic</span>.</span>to_seed</span>(</span>mnemonic</span>,</span> passphrase</span>=</span>"</span>"</span>)</span></span>
        self</span>.</span>root_key</span> =</span> BIP32Key</span>.</span>fromEntropy</span>(</span>self</span>.</span>seed</span>)</span></span>
        </span></span>
        logger</span>.</span>info</span>(</span>"</span>Treasury system initialized. Master key fingerprint: </span>%s</span>"</span>,</span> </span></span>
                  self</span>.</span>root_key</span>.</span>Fingerprint</span>(</span>)</span>.</span>hex</span>(</span>)</span>)</span></span>
</span>
    @</span>staticmethod</span></span>
    def</span> _hierarchical_hash</span>(</span>entity</span>:</span> str</span>,</span> department</span>:</span> str</span>)</span> -></span> Tuple</span>[</span>int</span>,</span> int</span>]</span>:</span></span>
        """</span></span>
        Hierarchical hash calculation (compliant with proposal spec)</span></span>
        Returns: (entity_index, department_index)</span></span>
        """</span></span>
        #</span> Entity hash</span></span>
        entity_hash</span> =</span> hashlib</span>.</span>sha256</span>(</span>f</span>"</span>ENTITY:</span>{</span>entity</span>}</span>"</span>.</span>encode</span>(</span>)</span>)</span>.</span>digest</span>(</span>)</span></span>
        entity_index</span> =</span> int</span>.</span>from_bytes</span>(</span>entity_hash</span>[</span>:</span>4</span>]</span>,</span> '</span>big</span>'</span>)</span> |</span> 0x</span>80000000</span></span>
        </span></span>
        #</span> Department hash (chained)</span></span>
        dept_input</span> =</span> f</span>"</span>DEPT:</span>{</span>entity_hash</span>.</span>hex</span>(</span>)</span>}</span>:</span>{</span>department</span>}</span>"</span>.</span>encode</span>(</span>)</span></span>
        dept_hash</span> =</span> hashlib</span>.</span>sha256</span>(</span>dept_input</span>)</span>.</span>digest</span>(</span>)</span></span>
        dept_index</span> =</span> int</span>.</span>from_bytes</span>(</span>dept_hash</span>[</span>:</span>4</span>]</span>,</span> '</span>big</span>'</span>)</span> |</span> 0x</span>80000000</span></span>
        </span></span>
        return</span> entity_index</span>,</span> dept_index</span></span>
</span>
    def</span> _derive_key</span>(</span>self</span>,</span> path</span>:</span> list</span>)</span> -></span> BIP32Key</span>:</span></span>
        """</span>General key derivation method</span>"""</span></span>
        current_key</span> =</span> self</span>.</span>root_key</span></span>
        for</span> index</span> in</span> path</span>:</span></span>
            if</span> not</span> isinstance</span>(</span>index</span>,</span> int</span>)</span>:</span></span>
                raise</span> TypeError</span>(</span>f</span>"</span>Invalid derivation index type: </span>{</span>type</span>(</span>index</span>)</span>}</span>"</span>)</span></span>
            current_key</span> =</span> current_key</span>.</span>ChildKey</span>(</span>index</span>)</span></span>
        return</span> current_key</span></span>
</span>
    def</span> generate_account</span>(</span>self</span>,</span> entity</span>:</span> str</span>,</span> department</span>:</span> str</span>,</span> </span></span>
                        account_idx</span>:</span> int</span> =</span> 0</span>)</span> -></span> Dict</span>[</span>str</span>,</span> str</span>]</span>:</span></span>
        """</span></span>
        Generate department account (BIP44 5-layer structure)</span></span>
        Path: m/44'/60'/entity'/dept'/account_idx</span></span>
        """</span></span>
        e_idx</span>,</span> d_idx</span> =</span> self</span>.</span>_hierarchical_hash</span>(</span>entity</span>,</span> department</span>)</span></span>
        </span></span>
        #</span> BIP-44 standard path</span></span>
        derivation_path</span> =</span> [</span></span>
            0x</span>8000002C</span>,</span>  #</span> 44' (hardened)</span></span>
            0x</span>8000003C</span>,</span>  #</span> 60' (Ethereum)</span></span>
            e_idx</span>,</span>       #</span> entity_index (hardened)</span></span>
            d_idx</span>,</span>       #</span> department_index (hardened)</span></span>
            account_idx</span>  #</span> address index</span></span>
        ]</span></span>
        </span></span>
        key</span> =</span> self</span>.</span>_derive_key</span>(</span>derivation_path</span>)</span></span>
        priv_key</span> =</span> key</span>.</span>PrivateKey</span>(</span>)</span>.</span>hex</span>(</span>)</span></span>
        </span></span>
        return</span> {</span></span>
            '</span>path</span>'</span>:</span> f</span>"</span>m/44</span>'/60</span>'/</span>{</span>e_idx</span>}</span>'/</span>{</span>d_idx</span>}</span>'/</span>{</span>account_idx</span>}</span>"</span>,</span></span>
            '</span>private_key</span>'</span>:</span> priv_key</span>,</span>  #</span> Warning: Never expose this in production</span></span>
            '</span>address</span>'</span>:</span> Account</span>.</span>from_key</span>(</span>priv_key</span>)</span>.</span>address</span></span>
        }</span></span>
</span>
    def</span> get_audit_xpub</span>(</span>self</span>,</span> entity</span>:</span> str</span>,</span> department</span>:</span> str</span>)</span> -></span> str</span>:</span></span>
        """</span></span>
        Retrieve department-level extended public key (for auditing)</span></span>
        Path: m/44'/60'/entity'/dept'</span></span>
        """</span></span>
        e_idx</span>,</span> d_idx</span> =</span> self</span>.</span>_hierarchical_hash</span>(</span>entity</span>,</span> department</span>)</span></span>
        path</span> =</span> [</span></span>
            0x</span>8000002C</span>,</span>  #</span> 44'</span></span>
            0x</span>8000003C</span>,</span>  #</span> 60'</span></span>
            e_idx</span>,</span>       #</span> entity'</span></span>
            d_idx</span>        #</span> dept'</span></span>
        ]</span></span>
        return</span> self</span>.</span>_derive_key</span>(</span>path</span>)</span>.</span>ExtendedKey</span>(</span>)</span></span>
</span>
    def</span> get_dept_xprv</span>(</span>self</span>,</span> entity</span>:</span> str</span>,</span> department</span>:</span> str</span>)</span> -></span> str</span>:</span></span>
        """</span></span>
        Get department-level extended private key (strictly controlled)</span></span>
        Path: m/44'/60'/entity'/dept'</span></span>
        """</span></span>
        e_idx</span>,</span> d_idx</span> =</span> self</span>.</span>_hierarchical_hash</span>(</span>entity</span>,</span> department</span>)</span></span>
        path</span> =</span> [</span></span>
            0x</span>8000002C</span>,</span>  #</span> 44'</span></span>
            0x</span>8000003C</span>,</span>  #</span> 60'</span></span>
            e_idx</span>,</span>       #</span> entity'</span></span>
            d_idx</span>        #</span> dept'</span></span>
        ]</span></span>
        return</span> self</span>.</span>_derive_key</span>(</span>path</span>)</span>.</span>ExtendedKey</span>(</span>)</span></span>
</span>
</span>
    @</span>staticmethod</span></span>
    def</span> derive_addresses_from_xpub</span>(</span>xpub</span>:</span> str</span>,</span> count</span>:</span> int</span> =</span> 20</span>)</span> -></span> list</span>:</span></span>
        """</span>Derive addresses from extended public key (audit use)</span>"""</span></span>
        audit_key</span> =</span> BIP32Key</span>.</span>fromExtendedKey</span>(</span>xpub</span>)</span></span>
        return</span> [</span></span>
            Account</span>.</span>from_key</span>(</span></span>
                audit_key</span></span>
                        .</span>ChildKey</span>(</span>i</span>)</span>   #</span> Address index</span></span>
                        .</span>PrivateKey</span>(</span>)</span></span>
            )</span>.</span>address</span></span>
            for</span> i</span> in</span> range</span>(</span>count</span>)</span></span>
        ]</span></span>
</span>
</span>
if</span> __name__</span> ==</span> "</span>__main__</span>"</span>:</span></span>
    #</span> Example usage (remove private key printing in production)</span></span>
    try</span>:</span></span>
        #</span> Use standard mnemonic</span></span>
        mnemo</span> =</span> Mnemonic</span>(</span>"</span>english</span>"</span>)</span></span>
        mnemonic</span> =</span> mnemo</span>.</span>generate</span>(</span>strength</span>=</span>256</span>)</span></span>
        treasury</span> =</span> TreasurySystem</span>(</span>mnemonic</span>)</span></span>
        print</span>(</span>f</span>"</span>mnemonic: </span>{</span>mnemonic</span>}</span>"</span>)</span></span>
        </span></span>
        print</span>(</span>"</span>\n</span>=== Finance Department Account Generation ===</span>"</span>)</span></span>
        finance_acc1</span> =</span> treasury</span>.</span>generate_account</span>(</span>"</span>GroupA</span>"</span>,</span> "</span>Finance</span>"</span>,</span> 0</span>)</span></span>
        finance_acc2</span> =</span> treasury</span>.</span>generate_account</span>(</span>"</span>GroupA</span>"</span>,</span> "</span>Finance</span>"</span>,</span> 1</span>)</span></span>
        print</span>(</span>f</span>"</span>Account1 path: </span>{</span>finance_acc1</span>[</span>'</span>path</span>'</span>]</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Account1 address: </span>{</span>finance_acc1</span>[</span>'</span>address</span>'</span>]</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Account1 private key: </span>{</span>finance_acc1</span>[</span>'</span>private_key</span>'</span>]</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Account2 path: </span>{</span>finance_acc2</span>[</span>'</span>path</span>'</span>]</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Account2 address: </span>{</span>finance_acc2</span>[</span>'</span>address</span>'</span>]</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Account2 private key: </span>{</span>finance_acc2</span>[</span>'</span>private_key</span>'</span>]</span>}</span>"</span>)</span></span>
</span>
        print</span>(</span>"</span>\n</span>=== Audit Verification Test===</span>"</span>)</span></span>
        audit_xpub</span> =</span> treasury</span>.</span>get_audit_xpub</span>(</span>"</span>GroupA</span>"</span>,</span> "</span>Finance</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Audit xpub: </span>{</span>audit_xpub</span>}</span>"</span>)</span></span>
        audit_addresses</span> =</span> TreasurySystem</span>.</span>derive_addresses_from_xpub</span>(</span>audit_xpub</span>,</span> 2</span>)</span></span>
        print</span>(</span>f</span>"</span>Audit-derived addresses: </span>{</span>audit_addresses</span>}</span>"</span>)</span></span>
        </span></span>
        assert</span> finance_acc1</span>[</span>'</span>address</span>'</span>]</span> in</span> audit_addresses</span>,</span> "</span>Audit verification failed</span>"</span></span>
        assert</span> finance_acc2</span>[</span>'</span>address</span>'</span>]</span> in</span> audit_addresses</span>,</span> "</span>Audit verification failed</span>"</span></span>
        print</span>(</span>"</span>✅ Audit verification successful</span>"</span>)</span></span>
</span>
        print</span>(</span>"</span>\n</span>=== Department Isolation Test ===</span>"</span>)</span></span>
        other_dept_acc</span> =</span> treasury</span>.</span>generate_account</span>(</span>"</span>GroupA</span>"</span>,</span> "</span>Audit</span>"</span>,</span> 0</span>)</span></span>
        print</span>(</span>f</span>"</span>Account3 path: </span>{</span>other_dept_acc</span>[</span>'</span>path</span>'</span>]</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Account3 address: </span>{</span>other_dept_acc</span>[</span>'</span>address</span>'</span>]</span>}</span>"</span>)</span></span>
        assert</span> other_dept_acc</span>[</span>'</span>address</span>'</span>]</span> not</span> in</span> audit_addresses</span>,</span> "</span>Isolation breach</span>"</span></span>
        print</span>(</span>"</span>✅ Department isolation effective</span>"</span>)</span></span>
</span>
</span>
        print</span>(</span>"</span>\n</span>=== Department Private Key Sharing Test ===</span>"</span>)</span></span>
        #</span> Gets the department layer extension private key</span></span>
        dept_xprv</span> =</span> treasury</span>.</span>get_audit_xpub</span>(</span>"</span>GroupA</span>"</span>,</span> "</span>Finance</span>"</span>)</span>.</span>replace</span>(</span>'</span>xpub</span>'</span>,</span> '</span>xprv</span>'</span>)</span>  #</span> 实际应通过专用方法获取</span></span>
        print</span>(</span>f</span>"</span>Fiance xprv: </span>{</span>dept_xprv</span>}</span>"</span>)</span></span>
        #</span> Derive the account private key from the extension private key</span></span>
        dept_key</span> =</span> BIP32Key</span>.</span>fromExtendedKey</span>(</span>dept_xprv</span>)</span></span>
        derived_acc0_key</span> =</span> dept_key</span>.</span>ChildKey</span>(</span>0</span>)</span>.</span>PrivateKey</span>(</span>)</span>.</span>hex</span>(</span>)</span></span>
        derived_acc1_key</span> =</span> dept_key</span>.</span>ChildKey</span>(</span>1</span>)</span>.</span>PrivateKey</span>(</span>)</span>.</span>hex</span>(</span>)</span></span>
        print</span>(</span>f</span>"</span>Fiance derived_acc0_key: </span>{</span>derived_acc0_key</span>}</span>"</span>)</span></span>
        print</span>(</span>f</span>"</span>Fiance derived_acc1_key: </span>{</span>derived_acc1_key</span>}</span>"</span>)</span></span>
        #</span> Verify the private key derivation capability</span></span>
        assert</span> derived_acc0_key</span> ==</span> finance_acc1</span>[</span>'</span>private_key</span>'</span>]</span>,</span> \</span></span>
            "</span>Account 0 private key derivation failed</span>"</span></span>
        assert</span> derived_acc1_key</span> ==</span> finance_acc2</span>[</span>'</span>private_key</span>'</span>]</span>,</span> \</span></span>
            "</span>Account 1 private key derivation failed</span>"</span></span>
        print</span>(</span>"</span>✅ Private key derivation from department xprv successful</span>"</span>)</span></span>
</span>
    except</span> Exception</span> as</span> e</span>:</span></span>
        logger</span>.</span>error</span>(</span>"</span>System error: </span>%s</span>"</span>,</span> e</span>,</span> exc_info</span>=</span>True</span>)</span></span></code></pre>
run script:</p>
pip</span> install</span> bip32utils</span> eth_account</span></span>
</span>
python</span> stms.py</span></span></code></pre>
output：</p>
</p>
Security Considerations</h2>
For treasury managers, hierarchical deterministic wallet management is more convenient, but it requires additional consideration of protective measures for the master key, such as schemes for splitting and storing mnemonic phrases or master keys.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Blob Parameter Only Hardforks
2025-02-28T00:00:00+00:00
Abstract</h2>
This EIP introduces Blob Parameter Only (BPO) Hardforks</strong>, a lightweight mechanism for incrementally scaling Ethereum’s blob capacity through targeted hard forks that modify only blob-related parameters: target</code>, max</code>, and baseFeeUpdateFraction</code>. Unlike traditional hard forks, which require extensive coordination and introduce broader protocol changes, BPO forks enable rapid, low-overhead scaling of blob capacity in response to real-world demand and network conditions</strong>.</p>
Motivation</h2>
Ethereum's scaling strategy relies on Layer 2 (L2) solutions for transaction execution while using Ethereum as a data availability (DA) layer</strong>. However, the demand for DA has increased rapidly, and the current approach of only modifying blob parameters in large, infrequent hard forks is not agile enough</strong> to keep up with L2 growth.</p>
The key motivations for BPO forks are as follows:</p>


Continuous Scaling</strong></p>

L2 DA demand is growing rapidly, leading to ongoing saturation of blob capacity.</li>
Large, infrequent blob parameter changes create high costs and inefficiencies.</li>
BPO forks allow for more frequent, safer capacity increases.</li>
</ul>
</li>

Reduced Operational Overhead</strong></p>

Performance improvements and further testing will continue to unlock additional capacity.</li>
It is desirable to reduce the time between core devs agreeing on a parameter increase and its effective deployment.</li>
Full Ethereum hard forks require significant coordination, testing, and upgrade efforts across clients.</li>
By isolating blob parameter changes, BPO forks reduce the complexity of upgrades.</li>
</ul>
</li>

Enhanced Stability with New Scaling Technologies</strong></p>

Major scaling upgrades introduce uncertainty in optimal blob limits.</li>
Rather than forcing core developers to accept a suboptimal tradeoff between stability and capacity, BPO forks allow developers to safely increase parameters after observing mainnet performance and stability.</li>
</ul>
</li>

Predictable Upgrades for Builders</strong></p>

Builders and L2s require confidence that Ethereum will continuously scale to support their needs.</li>
A structured BPO framework provides predictability, allowing rollups to commit to Ethereum over alternative DA solutions.</li>
</ul>
</li>
</ol>
Specification</h2>
Definition</h3>
BPO hardforks are defined as protocol upgrades that modify only blob-related parameters through configuration, without requiring any client-side code changes. The new parameters take effect immediately at the specified activation time.</p>
Blob schedule configuration</h3>
The following protocol parameters are now managed by the blob schedule configuration:</p>

Blob Target (target</code>)</strong>: The expected number of blobs per block.</li>
Blob Limit (max</code>)</strong>: The maximum number of blobs per block.</li>
Blob Base Fee Update Fraction (baseFeeUpdateFraction</code>)</strong>: Determines how blob gas pricing adjusts per block.</li>
</ul>
To ensure consistency, when a regular hardfork changes any of these parameters, it MUST do so by adding an entry to the blob schedule configuration.</p>
Execution layer configuration</h3>
To facilitate these changes on the execution layer, each fork in the blobSchedule</code> object defined in EIP-7840</a> is linked to an activation timestamp via a top-level <fork_name>Time</code> field, which holds the Unix timestamp of the activation slot as a JSON number. BPO forks SHOULD be named using the convention bpo<index></code>, where <index></code> starts at 1</code>. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur after</strong> Prague.</p>
{</span></span>
  "</span>blobSchedule</span>"</span>:</span> {</span></span>
    "</span>cancun</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 3</span>,</span></span>
      "</span>max</span>"</span>:</span> 6</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span></span>
    }</span>,</span></span>
    "</span>prague</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 6</span>,</span></span>
      "</span>max</span>"</span>:</span> 9</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span>
    }</span>,</span></span>
    "</span>osaka</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 6</span>,</span></span>
      "</span>max</span>"</span>:</span> 9</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span>
    }</span>,</span></span>
    "</span>bpo1</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 10</span>,</span></span>
      "</span>max</span>"</span>:</span> 15</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 8346193</span></span>
    }</span>,</span></span>
    "</span>bpo2</span>"</span>:</span> {</span></span>
      "</span>target</span>"</span>:</span> 14</span>,</span></span>
      "</span>max</span>"</span>:</span> 21</span>,</span></span>
      "</span>baseFeeUpdateFraction</span>"</span>:</span> 11684671</span></span>
    }</span></span>
  }</span>,</span></span>
  "</span>cancunTime</span>"</span>:</span> 0</span>,</span></span>
  "</span>pragueTime</span>"</span>:</span> 0</span>,</span></span>
  "</span>osakaTime</span>"</span>:</span> 1747387400</span>,</span></span>
  "</span>bpo1Time</span>"</span>:</span> 1757387400</span>,</span></span>
  "</span>bpo2Time</span>"</span>:</span> 1767387784</span></span>
}</span></span></code></pre>
Since there is no backporting, the values for cancunTime</code> and pragueTime</code> are set to 0. It should also be noted that the other parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.</p>
Blob base fee computations</h3>
We modify the functions get_base_fee_per_blob_gas</code> and calc_excess_blob_gas</code> defined in EIP-4844</a> to explicitly use the blob schedule.
In line with how updating BLOB_BASE_FEE_UPDATE_FRACTION</code> was handled in EIP-7691</a>, the functions use the current</em> block's blob schedule.
Moreover, TARGET_BLOB_GAS_PER_BLOCK</code> is removed and replaced with GAS_PER_BLOB * blob_schedule.target</code>, as it is now redundant.</p>
class</span> BlobSchedule</span>:</span></span>
   target</span>:</span> U64</span></span>
   max</span>:</span> U64</span></span>
   base_fee_update_fraction</span>:</span> Uint</span></span>
</span>
 def</span> calc_excess_blob_gas</span>(</span>parent</span>:</span> Header</span>,</span> blob_schedule</span>:</span> BlobSchedule</span>)</span> -></span> int</span>:</span></span>
    target_blob_gas</span> =</span> GAS_PER_BLOB</span> *</span> blob_schedule</span>.</span>target</span></span>
    if</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> <</span> target_blob_gas</span> :</span></span>
        return</span> 0</span></span>
    else</span>:</span></span>
        return</span> parent</span>.</span>excess_blob_gas</span> +</span> parent</span>.</span>blob_gas_used</span> -</span> target_blob_gas</span></span>
</span>
def</span> get_base_fee_per_blob_gas</span>(</span>header</span>:</span> Header</span>,</span> blob_schedule</span>:</span> BlobSchedule</span>)</span> -></span> int</span>:</span></span>
    return</span> fake_exponential</span>(</span></span>
        MIN_BASE_FEE_PER_BLOB_GAS</span>,</span></span>
        header</span>.</span>excess_blob_gas</span>,</span></span>
        blob_schedule</span>.</span>base_fee_update_fraction</span></span>
    )</span></span></code></pre>Consensus layer configuration</h3>
A new BLOB_SCHEDULE</code> field is added to consensus layer configuration, containing a sequence of entries representing blob parameter changes after</strong> ELECTRA_FORK_EPOCH</code>. There exists one entry per fork that changes blob parameters, whether it is a regular or a Blob-Parameter-Only fork.</p>
B</span>LOB_SCHEDULE</span>:</span></span>
  -</span> E</span>POCH</span>:</span> 400000</span>     #</span> A future anonymous BPO fork</span></span>
    M</span>AX_BLOBS_PER_BLOCK</span>:</span> 15</span></span>
  -</span> E</span>POCH</span>:</span> 420000</span>     #</span> A future anonymous BPO fork</span></span>
    M</span>AX_BLOBS_PER_BLOCK</span>:</span> 21</span></span></code></pre>
The parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.</p>
Requirements:</strong></p>

Execution and consensus clients MUST</strong> share consistent BPO fork schedules.</li>
The slot number in the EL's blobSchedule</code> MUST</strong> align with the start of the epoch specified in the consensus layer configuration.</li>
The max</code> field in the EL's blobSchedule</code> MUST</strong> equal the MAX_BLOBS_PER_BLOCK</code> value in the consensus layer configuration.</li>
</ul>
Modified compute_fork_digest</code></h3>
The compute_fork_digest</code> helper is updated to account for BPO forks:</p>
@</span>dataclass</span></span>
class</span> BlobScheduleEntry</span>:</span></span>
   epoch</span>:</span> Epoch</span></span>
   max_blobs_per_block</span>:</span> uint64</span>       #</span> Aligning with the type of MAX_BLOBS_PER_BLOCK</span></span>
</span>
def</span> compute_fork_digest</span>(</span></span>
  current_version</span>:</span> Version</span>,</span>       #</span> Unchanged; refers to the baseline hardfork atop which the blob schedule is applied</span></span>
  genesis_validators_root</span>:</span> Root</span>,</span>  #</span> Unchanged</span></span>
  current_epoch</span>:</span> Epoch</span>,</span>           #</span> New</span></span>
  blob_schedule</span>:</span> Sequence</span>[</span>BlobScheduleEntry</span>]</span>  #</span> New</span></span>
)</span> -></span> ForkDigest</span>:</span></span>
    """</span></span>
    Return the 4-byte fork digest for the ``current_version`` and ``genesis_validators_root``,</span></span>
    bitmasking blob parameters after ``ELECTRA_FORK_VERSION``.</span></span>
</span>
    This is a digest primarily used for domain separation on the p2p layer.</span></span>
    4-bytes suffices for practical separation of forks/chains.</span></span>
    """</span></span>
    base_digest</span> =</span> compute_fork_data_root</span>(</span>current_version</span>,</span> genesis_validators_root</span>)</span>[</span>:</span>4</span>]</span></span>
</span>
    #</span> Find the blob parameters applicable to this epoch.</span></span>
    sorted_schedule</span> =</span> sorted</span>(</span>blob_schedule</span>,</span> key</span>=</span>lambda</span> e</span>:</span> e</span>.</span>epoch</span>,</span> reverse</span>=</span>True</span>)</span></span>
    blob_params</span> =</span> None</span></span>
    for</span> entry</span> in</span> sorted_schedule</span>:</span></span>
      if</span> current_epoch</span> >=</span> entry</span>.</span>epoch</span>:</span></span>
        blob_params</span> =</span> entry</span></span>
        break</span></span>
</span>
    #</span> This check enables us to roll out the BPO mechanism without a concurrent parameter change.</span></span>
    if</span> blob_params</span> is</span> None</span>:</span></span>
      return</span> ForkDigest</span>(</span>base_digest</span>)</span></span>
</span>
    #</span> Safely bitmask blob parameters into the digest.</span></span>
    assert</span> 0</span> <=</span> blob_params</span>.</span>max_blobs_per_block</span> <=</span> 0x</span>FFFFFFFF</span></span>
    mask</span> =</span> blob_params</span>.</span>max_blobs_per_block</span>.</span>to_bytes</span>(</span>4</span>,</span> '</span>big</span>'</span>)</span></span>
    masked_digest</span> =</span> bytes</span>(</span>a</span> ^</span> b</span> for</span> a</span>,</span> b</span> in</span> zip</span>(</span>base_digest</span>,</span> mask</span>)</span>)</span></span>
    return</span> ForkDigest</span>(</span>masked_digest</span>)</span></span></code></pre>P2P Networking</h3>
ENR</h4>
In the consensus layer, ENRs are extended with an additional entry nfd</code>, short for "next fork digest". This field communicates the digest of the next scheduled fork, regardless of whether it is a regular or BPO fork. This approach is preferred over encoding BPO-specific parameters because it is agnostic to specific use cases and offers greater long-term flexibility.</p>
Key</th> Value</th></tr></thead>

nfd</code></td> SSZ Bytes4 ForkDigest</code></td></tr>
</tbody></table>
When discovering and interfacing with peers, nodes MUST evaluate nfd</code> alongside their existing consideration of the ENRForkID::next_*</code> fields under the eth2</code> key, to form a more accurate view of the peer's intended next fork.</p>
Status</code> req/resp</h4>
No changes are needed in this interaction, but it is noted that the response payload must correctly contain the updated fork_digest</code>.</p>
Gossip topics</h4>
No changes are required to topic structure or configuration. However, all topics will automatically rotate at a BPO fork due to changes in their ForkDigestValue</code> component.</p>
Rationale</h2>
Why not just use regular hardforks?</h3>
Full hard forks require extensive coordination, testing, and implementation changes beyond parameter adjustments. For example, in Lighthouse, a typical hard fork implementation requires thousands of lines of boilerplate before any protocol changes occur. BPO forks streamline this process by avoiding the need for this boilerplate code.</p>
Why specify parameters in the node configuration instead of code?</h3>
Allowing blob parameters to be configured externally enables rapid experimentation, testing, and adjustments without requiring code changes across client implementations. Testing teams can investigate different parameters with minimal involvement from client implementers.</p>
Why not create an on-chain voting mechanism for blob parameters?</h3>

Ethereum's recent gas limit increase to 36M took nearly a year to coordinate</li>
Blob capacity is a rapidly evolving, moving target that the wider staking community is not currently well equipped to track</li>
An on-chain mechanism would require much more extensive code changes, testing cycles, and debates about governance structures.</li>
BPO forks provide a simpler, more predictable approach while leaving room for future on-chain voting mechanisms when blob capacity stabilizes</li>
</ul>
Backwards Compatibility</h2>
BPO forks introduce no backwards compatibility concerns.</p>
Security Considerations</h2>
No security risks have been identified.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


ModExp Gas Cost Increase
2025-02-11T00:00:00+00:00
Abstract</h2>
This EIP is modifying the ModExp</code> precompile pricing algorithm introduced in EIP-2565</a>.</p>
Motivation</h2>
Currently the ModExp</code> precompile is underpriced in certain scenarios relative to its resource consumption. By adjusting the pricing formula, this EIP aims to address these discrepancies, making ModExp</code> sufficiently efficient to enable potential increases in the block gas limit.</p>
Specification</h2>
Upon activation of this EIP, the gas cost of calling the precompile at address 0x0000000000000000000000000000000000000005</code> will be calculated as follows:</p>
def calculate_multiplication_complexity(base_length, modulus_length):</span></span>
    max_length = max(base_length, modulus_length)</span></span>
    words = math.ceil(max_length / 8)</span></span>
    multiplication_complexity = 16</span></span>
    if max_length > 32: multiplication_complexity = 2 * words**2</span></span>
    return multiplication_complexity</span></span>
</span>
def calculate_iteration_count(exponent_length, exponent):</span></span>
    iteration_count = 0</span></span>
    if exponent_length <= 32 and exponent == 0: iteration_count = 0</span></span>
    elif exponent_length <= 32: iteration_count = exponent.bit_length() - 1</span></span>
    elif exponent_length > 32: iteration_count = (16 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)</span></span>
    return max(iteration_count, 1)</span></span>
</span>
def calculate_gas_cost(base_length, modulus_length, exponent_length, exponent):</span></span>
    multiplication_complexity = calculate_multiplication_complexity(base_length, modulus_length)</span></span>
    iteration_count = calculate_iteration_count(exponent_length, exponent)</span></span>
    return max(500, math.floor(multiplication_complexity * iteration_count))</span></span></code></pre>
The specific changes from the algorithm defined in EIP-2565</a>:</p>
1. Increased minimal and general price</h3>
The gas cost calculation is modified from:</p>
    return max(200, math.floor(multiplication_complexity * iteration_count / 3))</span></span></code></pre>
to:</p>
    return max(500, math.floor(multiplication_complexity * iteration_count))</span></span></code></pre>
This change increases the minimum gas cost from 200 to 500 and triples the general cost by removing the division by 3.</p>
2. Increase cost for exponents larger than 32 bytes</h3>
The gas cost calculation is modified from:</p>
    elif exponent_length > 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)</span></span></code></pre>
to:</p>
    elif exponent_length > 32: iteration_count = (16 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)</span></span></code></pre>
The multiplier for exponents larger than 32 bytes is increased from 8 to 16, doubling its impact.</p>
3. Assume the minimal base / modulus length to be 32 and increase the cost when it is larger than 32 bytes</h3>
The gas cost calculation is modified from:</p>
def calculate_multiplication_complexity(base_length, modulus_length):</span></span>
    max_length = max(base_length, modulus_length)</span></span>
    words = math.ceil(max_length / 8)</span></span>
    return words**2</span></span></code></pre>
to:</p>
def calculate_multiplication_complexity(base_length, modulus_length):</span></span>
    max_length = max(base_length, modulus_length)</span></span>
    words = math.ceil(max_length / 8)</span></span>
    multiplication_complexity = 16</span></span>
    if max_length > 32: multiplication_complexity = 2 * words**2</span></span>
    return multiplication_complexity</span></span></code></pre>
This change introduces a minimal multiplication complexity of 16 and doubles the complexity if the base or modulus length exceeds 32 bytes.</p>
Rationale</h2>
Benchmarking the ModExp</code> precompile revealed several scenarios where its gas cost was significantly underestimated. Pricing adjustments are designed to rectify underpriced edge cases by modifying the existing ModExp</code> pricing formula parameters. Specifically, the minimum cost for ModExp</code> will rise from 200 to 500 (a 150% increase), the general cost will triple (a 200% increase), a minimum base/modulus length of 32 bytes will be assumed and the cost will scale more aggressively when the base, modulus, or exponent exceed 32 bytes. These modifications aim to ensure that the ModExp</code> precompile's performance, even in its most resource-intensive edge cases across all execution layer clients, no longer impedes potential increases to the block gas limit.</p>
Backwards Compatibility</h2>
This EIP introduces a backwards-incompatible change. However, similar gas repricings have occurred multiple times in the Ethereum ecosystem, and their effects are well understood.</p>
An empirical analysis of this proposal is available here</a>, with a separate breakdown by affected entities provided here</a>.</p>
Test Cases</h2>
The most common usages (approximately 99.69% of historical Modexp</code> calls as of January 4th, 2025) will experience either a 150% increase (from 200 to 500 gas) or a 200% increase (tripling from approximately 1360 gas).
No changes are made to the underlying interface or arithmetic algorithms, allowing existing test vectors to be reused. The table below presents the updated gas costs for these test vectors:</p>
Test Case</th> EIP-2565</a> Pricing</th> EIP-7883 Pricing</th> Increase</th></tr></thead>

modexp_nagydani_1_square</td> 200</td> 500</td> 150%</td></tr>
modexp_nagydani_1_qube</td> 200</td> 500</td> 150%</td></tr>
modexp_nagydani_1_pow0x10001</td> 341</td> 2048</td> 501%</td></tr>
modexp_nagydani_2_square</td> 200</td> 512</td> 156%</td></tr>
modexp_nagydani_2_qube</td> 200</td> 512</td> 156%</td></tr>
modexp_nagydani_2_pow0x10001</td> 1365</td> 8192</td> 501%</td></tr>
modexp_nagydani_3_square</td> 341</td> 2048</td> 501%</td></tr>
modexp_nagydani_3_qube</td> 341</td> 2048</td> 501%</td></tr>
modexp_nagydani_3_pow0x10001</td> 5461</td> 32768</td> 500%</td></tr>
modexp_nagydani_4_square</td> 1365</td> 8192</td> 501%</td></tr>
modexp_nagydani_4_qube</td> 1365</td> 8192</td> 501%</td></tr>
modexp_nagydani_4_pow0x10001</td> 21845</td> 131072</td> 500%</td></tr>
modexp_nagydani_5_square</td> 5461</td> 32768</td> 500%</td></tr>
modexp_nagydani_5_qube</td> 5461</td> 32768</td> 500%</td></tr>
modexp_nagydani_5_pow0x10001</td> 87381</td> 524288</td> 500%</td></tr>
modexp_marius_1_even</td> 2057</td> 45296</td> 2102%</td></tr>
modexp_guido_1_even</td> 2298</td> 51136</td> 2125%</td></tr>
modexp_guido_2_even</td> 2300</td> 51152</td> 2124%</td></tr>
modexp_guido_3_even</td> 5400</td> 32400</td> 500%</td></tr>
modexp_guido_4_even</td> 1026</td> 94448</td> 9105%</td></tr>
modexp_marcin_1_base_heavy</td> 200</td> 1152</td> 476%</td></tr>
modexp_marcin_1_exp_heavy</td> 215</td> 16624</td> 7632%</td></tr>
modexp_marcin_1_balanced</td> 200</td> 1200</td> 500%</td></tr>
modexp_marcin_2_base_heavy</td> 867</td> 5202</td> 500%</td></tr>
modexp_marcin_2_exp_heavy</td> 852</td> 16368</td> 1821%</td></tr>
modexp_marcin_2_balanced</td> 996</td> 5978</td> 500%</td></tr>
modexp_marcin_3_base_heavy</td> 677</td> 2032</td> 200%</td></tr>
modexp_marcin_3_exp_heavy</td> 765</td> 4080</td> 433%</td></tr>
modexp_marcin_3_balanced</td> 1360</td> 4080</td> 200%</td></tr>
</tbody></table>
Security Considerations</h2>
This EIP does not introduce any new functionality or make existing operations cheaper, therefore there are no direct security concerns related to new attack vectors or reduced costs. The primary security consideration for this EIP is the potential for ModExp</code> scenarios to be overpriced, though this is deemed a lesser risk compared to the current underpricing issues.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Bequeathable Contracts
2025-02-01T00:00:00+00:00
Abstract</h2>
This EIP proposes a standard interface for contracts to allow tokens to be inherited after the owner's death. The interface allows token owners to set up a Will and designate executors to enable the transfer of tokens to inheritors after a specified waiting period.</p>
Motivation</h2>
Crypto Tokens in general and NFTs in particular are starting to be used to tokenise real-world assets. In order for them to be adopted by the main stream finance world, there needs to be a way to inherit these tokens after the owner has passed away. Currently, there is no standardised way for token holders to pass on their digital assets in the event of their death.

This EIP aims to solve this problem by providing a standard interface for "bequeathable" tokens, allowing for a secure and transparent process of token inheritance.
In designing this interface we have tried to follow the real world process of Will creation and execution.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Every compliant contract MUST implement the Bequeathable</code> interface:</p>
///</span> @title</span> EIP-7878 Bequeathable tokens</span></span>
///</span> @dev</span> See https://eips.ethereum.org/EIPS/eip-7878</span></span>
</span>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
/**</span></span>
 * </span>@notice</span> Bequeathable interface</span></span>
 */</span></span>
</span>
interface</span> Bequeathable</span> {</span></span>
</span>
   /**</span></span>
    * </span>@notice</span>              Announce the owner's tokens are to be inherited</span></span>
    * </span>@dev</span>                 Emitted by `announceObit`</span></span>
    * </span>@param</span>   owner</span>       The original owner of the tokens</span></span>
    * </span>@param</span>   inheritor</span>   The address of the wallet that will inherit the tokens once the moratoriumTTL time has passed</span></span>
    */</span></span>
   event</span> ObituaryStarted</span>(</span>address</span> indexed</span> owner</span>, </span>address</span> indexed</span> inheritor</span>)</span>;</span></span>
</span>
   /**</span> </span></span>
    * </span>@notice</span>               Announce the obituary (and moratorium) for the owner has been cancelled, as well as who cancelled it</span></span>
    * </span>@dev</span>                  Emitted by `cancelObit`</span></span>
    * </span>@param</span>   owner</span>        The original owner of the tokens</span></span>
    * </span>@param</span>   cancelledBy</span>  The address that triggered this cancellation. This can be the owner or any of the inheritors</span></span>
    */</span></span>
   event</span> ObituaryCancelled</span>(</span>address</span> indexed</span> owner</span>, </span>address</span> indexed</span> cancelledBy</span>)</span>;</span></span>
</span>
   /**</span> </span></span>
    * </span>@notice</span>                 A token owner can set a Will and names one or more executors who are able to transfer their tokens after their death</span></span>
    * </span>@dev</span>                    Although more than one executor address can be set, only one is required to start the process and then do the transfer</span></span>
    * </span>@dev</span>                    Subsequent calls to this function should overwrite any existing Will</span></span>
    * </span>@param</span>   executors</span>      An array of executors eg legal council, spouse, child 1, child 2 etc..</span></span>
    * </span>@param</span>   moratoriumTTL</span>  The time that must pass (in seconds) from when the obituary is announced to when the inheritance transfer can take place</span></span>
    * </span>@dev</span>                    The moratoriumTTL is a safety buffer time frame that allows for any intervention before the tokens get transferred</span></span>
    */</span></span>
   function</span> setWill</span>(</span>address</span>[</span>]</span> memory</span> executors</span>,</span> uint256</span> moratoriumTTL</span>)</span> external</span>;</span></span>
</span>
   /**</span></span>
    * </span>@notice</span>                  Get the details of a Will if set</span></span>
    * </span>@dev</span>                     This is a way for the owner to confirm that they have correctly set their Will</span></span>
    * </span>@param</span>    owner</span>          The current owner of the tokens</span></span>
    * </span>@return</span>   executors</span>      A list of all the executors for this owners will</span></span>
    * </span>@return</span>   moratoriumTTL</span>  The length of time (in seconds) that must elapse after calling announceObit before the actual transfer can happen</span></span>
    */</span></span>
   function</span> getWill</span>(</span>address</span> owner</span>)</span> external</span> view</span> returns</span> (</span>address</span>[</span>]</span> memory</span> executors</span>,</span> uint256</span> moratoriumTTL</span>)</span>;</span></span>
</span>
   /**</span></span>
    * </span>@notice</span>              Start the Obituary process, by announcing it and declaring who is the intended inheritor</span></span>
    * </span>@param</span>   owner</span>       The current owner of the tokens</span></span>
    * </span>@param</span>   inheritor</span>   The address of the owner to be</span></span>
    */</span></span>
   function</span> announceObit</span>(</span>address</span> owner</span>,</span> address</span> inheritor</span>)</span> external</span>;</span></span>
</span>
   /**</span></span>
    * </span>@notice</span>          Cancel the Obituary that has been previously announced. Can be called by any of the executors (or the owner if still around)</span></span>
    * </span>@param</span>   owner</span>   The original owner of the tokens</span></span>
    */</span></span>
   function</span> cancelObit</span>(</span>address</span> owner</span>)</span> external</span>;</span></span>
</span>
   /**</span></span>
    * </span>@notice</span>                   Get the designated inheritor and how much time is left before the moratoriumTTL is satisfied</span></span>
    * </span>@param</span>    owner</span>           The current owner of the tokens</span></span>
    * </span>@return</span>   inheritor</span>       The named inheritor when the obituary was announced</span></span>
    * </span>@return</span>   moratoriumTTL</span>   The time left for the moratoriumTTL before the transfer can be done</span></span>
    * </span>@dev</span>                      A minus figure for moratoriumTTL indicates that the wait time has elapsed and the tokens can be bequeathed</span></span>
    */</span></span>
   function</span> getObit</span>(</span>address</span> owner</span>)</span> external</span> view</span> returns</span> (</span>address</span> inheritor</span>,</span> int256</span> moratoriumTTL</span>)</span>;</span></span>
</span>
   /**</span></span>
    * </span>@notice</span>         Bequeath ie transfer the tokens to the previously declared inheritor</span></span>
    * </span>@param</span>   owner</span>  The original owner of the tokens</span></span>
    * </span>@dev</span>            The transfer should happen to the inheritor address when `announceObit` was called</span></span>
    */</span></span>
   function</span> bequeath</span>(</span>address</span> owner</span>)</span> external</span>;</span></span>
</span>
}</span></span></code></pre>Functions</h3>

setWill</code>: Allows a token owner to set up or update their Will.</li>
getWill</code>: Returns the current Will details for a given owner.</li>
announceObit</code>: Initiates the inheritance process by an executor.</li>
cancelObit</code>: Cancels an active obituary process.</li>
getObit</code>: Retrieves the current obituary status.</li>
bequeath</code>: Transfers tokens to the inheritor after the waiting period.</li>
</ol>
Events</h3>

ObituaryStarted</code>: Emitted when an obituary is announced.</li>
ObituaryCancelled</code>: Emitted when an obituary is cancelled.</li>
</ol>
Rationale</h2>
The standard follows what currently happens in real life when preparing and executing a Will.</p>

An owner writes a Will and in doing so names the executor(s) of their Will</li>
Upon passing away, the executor will announce the Obituary</li>
The Will is read and the inheritors are identified</li>
The transfer of ownership is executed according to the wishes of the Will</li>
</ol>
However, real life is not always as straight forward as this. Conflicts happen all the time. To handle this situation and to keep the interface simple, we added the ability to cancel the Obituary by ANY of the executors. In this way, if there is any conflict, it can be challenged out in the courts and once the matter is settled, the Obituary process can start again.</p>
Again to keep the interface clean, all the tokens get transferred to one address. It is then that person's responsibility to execute any further transfers.</p>
Backwards Compatibility</h2>
This EIP is compatible with existing token standards like ERC-20</a>, ERC-721</a> and ERC-1155</a>. It can be implemented alongside these standards without affecting their core functionality.</p>
Test Cases</h2>
Tests are included in Bequeath.test.js</code></a>.</p>
Reference Implementation</h2>
See Bequeathable.sol</code></a></p>
Security Considerations</h2>
Implementers should carefully consider access control mechanisms to ensure that only authorized parties can execute Will-related functions.</p>
The moratoriumTTL should be set to a reasonable duration to allow for potential disputes or corrections. We recommend at least 30 days, especially for tokens that are of high value.  It limits the potential damage in scenarios such as the obituray process being triggered by a bad actor who has taken over one of the executor wallets.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


AI Agents NFT with Private Metadata
2025-01-02T00:00:00+00:00
Abstract</h2>
A standard interface for NFTs specifically designed for AI agents, where the metadata represents agent capabilities and requires privacy protection. Unlike traditional NFT standards that focus on static metadata, this standard introduces mechanisms for verifiable data ownership and secure transfer. By defining a unified interface for different verification methods (e.g., Trusted Execution Environment (TEE), Zero-Knowledge Proof (ZKP)), it enables secure management of valuable agent metadata such as models, memory, and character definitions, while maintaining confidentiality and verifiability.</p>
Motivation</h2>
With the increasing intelligence of AI models, agents have become powerful tools for automating meaningful daily tasks. The integration of agents with blockchain technology has been recognized as a major narrative in the crypto industry, with many projects enabling agent creation for their users. However, a crucial missing piece is the decentralized management of agent ownership.</p>
AI agents possess inherent non-fungible properties that make them natural candidates for NFT representation:</p>

Each agent is unique, with its own model, memory, and character</li>
Agents embody clear ownership rights, representing significant computational investment and intellectual property</li>
Agents have private metadata (e.g., neural network models, memory, character definitions) that defines their capabilities</li>
</ol>
However, current NFT standards like ERC-721</a> are insufficient for representing AI agents as digital assets. While NFTs can establish ownership of digital items, using them to represent AI agents introduces unique challenges. The key issue lies in the metadata transfer mechanism. Unlike traditional NFTs where metadata is typically static and publicly accessible, an AI agent's metadata (which constitutes the agent itself):</p>

Has intrinsic value and is often the primary purpose of the transfer</li>
Requires encrypted storage to protect intellectual property</li>
Needs privacy-preserving and verifiable transfer mechanisms when ownership changes</li>
</ol>
For example, when transferring an agent NFT, we need to ensure:</p>

The actual transfer of encrypted metadata (the agent's model, memory, character, etc.) is verifiable</li>
The new owner can securely access the metadata that constitutes the agent</li>
The agent's execution environment can verify ownership and load appropriate metadata</li>
</ol>
This EIP introduces a standard for NFTs with private metadata that addresses these requirements through privacy-preserving verification mechanisms, enabling secure ownership and transfer of valuable agent data while maintaining confidentiality and verifiability. This standard will serve as a foundation for the emerging agent ecosystem, allowing platforms to provide verifiable agent ownership and secure metadata management in a decentralized manner.</p>
Specification</h2>
The EIP defines three key interfaces: the main NFT interface, the metadata interface, and the data verification interface.</p>
Data Verification System</h3>
The verification system consists of two core components that work together to ensure secure data operations:</p>


On-chain Verifier (data verification interface)</strong></p>

Implemented as a smart contract</li>
Verifies proofs submitted through contract calls</li>
Returns structured verification results</li>
Can be implemented using different verification mechanisms (TEE/ZKP)</li>
</ul>
</li>

Off-chain Prover</strong></p>

Generates proofs for ownership and availability claims</li>
Works with encrypted data and keys</li>
Implementation varies based on verification mechanism:

TEE-based: Generates proofs within trusted hardware</li>
ZKP-based: Creates cryptographic zero-knowledge proofs</li>
</ul>
</li>
</ul>
</li>
</ol>
The system supports two types of proofs:</p>


Ownership Proof</strong></p>

Generated by Prover with access to original data</li>
Proves knowledge of pre-images for claimed dataHashes</li>
Verified on-chain through verifyOwnership()</code></li>
</ul>
</li>

Transfer Validity Proof</strong></p>

Generated by Prover for data transfers</li>
Proves:

Knowledge of original data (pre-images)</li>
Correct decryption and re-encryption of data</li>
Secure key transmission (using receiver's public key to encrypt the new key)</li>
Data availability in storage (using receiver's signature to confirm the data is available in storage)</li>
</ul>
</li>
Verified on-chain through verifyTransferValidity()</code></li>
</ul>
</li>
</ol>
The ownership verification is optional because when the minted token is transferred or cloned, the ownership verification is checked again inside the availability verification. It's better to be safe than sorry, so we recommend doing ownership verification for minting and updates.</p>
Different verification mechanisms have distinct capabilities:</p>


TEE-based Implementation</strong></p>

Prover runs in trusted hardware</li>
Can handle private keys securely</li>
Enables direct data re-encryption</li>
Verifier checks TEE attestations</li>
</ul>
</li>

ZKP-based Implementation</strong></p>

Prover generates cryptographic proofs</li>
Cannot handle multi-party private keys</li>
Re-encryption key known to prover</li>
Requires additional re-encryption when next update, otherwise the new update is still visible to the prover</li>
</ul>
</li>
</ul>
Data Verification Interface</h3>
///</span> @notice</span> The type of the oracle</span></span>
///</span> There are two types of oracles: TEE and ZKP</span></span>
enum</span> OracleType</span> {</span></span>
    TEE</span>,</span></span>
    ZKP</span></span>
}</span></span>
</span>
///</span> @notice</span> The access proof which is a signature signed by the receiver (the receiver may delegate the signing privilege to the access assistant)</span></span>
///</span> @param</span> oldDataHash</span> The hash of the old data</span></span>
///</span> @param</span> newDataHash</span> The hash of the new data</span></span>
///</span> @param</span> nonce</span> The nonce of the access proof</span></span>
///</span> @param</span> encryptedPubKey</span> The encrypted public key, the receiver's public key which used to encrypt the new data key. `encryptedPubKey` can be empty in `accessProof`, and means that use the receiver's ethereum public key to encrypt the new data key</span></span>
///</span> @param</span> proof</span> The proof</span></span>
struct</span> AccessProof</span> {</span></span>
    bytes32</span> oldDataHash</span>;</span></span>
    bytes32</span> newDataHash</span>;</span></span>
    bytes</span> nonce</span>;</span></span>
    bytes</span> encryptedPubKey</span>;</span></span>
    bytes</span> proof</span>;</span></span>
}</span></span>
</span>
///</span> @notice</span> The ownership proof which is a signature signed by the receiver (the receiver may delegate the signing privilege to the access assistant)</span></span>
///</span> @param</span> proofType</span> The type of the proof</span></span>
///</span> @param</span> oldDataHash</span> The hash of the old data</span></span>
///</span> @param</span> newDataHash</span> The hash of the new data</span></span>
///</span> @param</span> sealedKey</span> The sealed key of the new data key</span></span>
///</span> @param</span> encryptedPubKey</span> The encrypted public key, the receiver's public key which used to encrypt the new data key</span></span>
///</span> @param</span> nonce</span> The nonce</span></span>
struct</span> OwnershipProof</span> {</span></span>
    OracleType oracleType</span>;</span> //</span> The type of the oracle</span></span>
    bytes32</span> oldDataHash</span>;</span> //</span> The hash of the old data</span></span>
    bytes32</span> newDataHash</span>;</span> //</span> The hash of the new data</span></span>
    bytes</span> sealedKey</span>;</span> //</span> The sealed key of the new data key</span></span>
    bytes</span> encryptedPubKey</span>;</span> //</span> The encrypted public key, the receiver's public key which used to encrypt the new data key</span></span>
    bytes</span> nonce</span>;</span> //</span> The nonce</span></span>
    bytes</span> proof</span>;</span> //</span> The proof</span></span>
}</span></span>
</span>
struct</span> TransferValidityProof</span> {</span></span>
    AccessProof accessProof</span>;</span></span>
    OwnershipProof ownershipProof</span>;</span></span>
}</span></span>
</span>
struct</span> TransferValidityProofOutput</span> {</span></span>
    bytes32</span> oldDataHash</span>;</span></span>
    bytes32</span> newDataHash</span>;</span></span>
    bytes</span> sealedKey</span>;</span></span>
    bytes</span> encryptedPubKey</span>;</span></span>
    bytes</span> wantedKey</span>;</span></span>
    address</span> accessAssistant</span>;</span></span>
    bytes</span> accessProofNonce</span>;</span></span>
    bytes</span> ownershipProofNonce</span>;</span></span>
}</span></span>
</span>
interface</span> IERC7857DataVerifier</span> {</span></span>
    ///</span> @notice</span> Verify data transfer validity, the _proofs prove:</span></span>
    ///</span>         1. The pre-image of oldDataHashes</span></span>
    ///</span>         2. The oldKey (old data key) can decrypt the pre-image and the new key re-encrypt the plaintexts to new ciphertexts</span></span>
    ///</span>         3. The newKey (new data key) is encrypted using the encryptedPubKey</span></span>
    ///</span>         4. The hashes of new ciphertexts is newDataHashes</span></span>
    ///</span>         5. The newDataHashes identified ciphertexts are available in the storage: need the signature from the receiver or the access assistant signing oldDataHashes, newDataHashes, and encryptedPubKey</span></span>
    ///</span> @param</span> _proofs</span> Proof generated by TEE/ZKP</span></span>
    function</span> verifyTransferValidity</span>(</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> _proofs</span></span>
    )</span> external</span> returns</span> (</span>TransferValidityProofOutput</span>[</span>]</span> memory</span>)</span>;</span></span>
}</span></span></code></pre>Metadata Interface</h3>
struct</span> IntelligentData</span> {</span></span>
    string</span> dataDescription</span>;</span></span>
    bytes32</span> dataHash</span>;</span></span>
}</span></span>
</span>
interface</span> IERC7857Metadata</span> {</span></span>
    ///</span> @notice</span> Get the name of the NFT collection</span></span>
    function</span> name</span>(</span>)</span> external</span> view</span> returns</span> (</span>string</span> memory</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Get the symbol of the NFT collection</span></span>
    function</span> symbol</span>(</span>)</span> external</span> view</span> returns</span> (</span>string</span> memory</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Get the data hash of a token</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @return</span> The</span> current data hash of the token</span></span>
    function</span> intelligentDataOf</span>(</span>uint256</span> _tokenId</span>)</span> external</span> view</span> returns</span> (</span>IntelligentData</span>[</span>]</span> memory</span>)</span>;</span></span>
}</span></span></code></pre>Main NFT Interface</h3>
interface</span> IERC7857</span> {</span></span>
    ///</span> @notice</span> The event emitted when an address is approved to transfer a token</span></span>
    ///</span> @param</span> _from</span> The address that is approving</span></span>
    ///</span> @param</span> _to</span> The address that is being approved</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    event</span> Approval</span>(</span></span>
        address</span> indexed</span> _from</span>,</span></span>
        address</span> indexed</span> _to</span>,</span></span>
        uint256</span> indexed</span> _tokenId</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when an address is approved for all</span></span>
    ///</span> @param</span> _owner</span> The owner</span></span>
    ///</span> @param</span> _operator</span> The operator</span></span>
    ///</span> @param</span> _approved</span> The approval</span></span>
    event</span> ApprovalForAll</span>(</span></span>
        address</span> indexed</span> _owner</span>,</span></span>
        address</span> indexed</span> _operator</span>,</span></span>
        bool</span> _approved</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when an address is authorized to use a token</span></span>
    ///</span> @param</span> _from</span> The address that is authorizing</span></span>
    ///</span> @param</span> _to</span> The address that is being authorized</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    event</span> Authorization</span>(</span></span>
        address</span> indexed</span> _from</span>,</span></span>
        address</span> indexed</span> _to</span>,</span></span>
        uint256</span> indexed</span> _tokenId</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when an address is revoked from using a token</span></span>
    ///</span> @param</span> _from</span> The address that is revoking</span></span>
    ///</span> @param</span> _to</span> The address that is being revoked</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    event</span> AuthorizationRevoked</span>(</span></span>
        address</span> indexed</span> _from</span>,</span></span>
        address</span> indexed</span> _to</span>,</span></span>
        uint256</span> indexed</span> _tokenId</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when a token is transferred</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @param</span> _from</span> The address that is transferring</span></span>
    ///</span> @param</span> _to</span> The address that is receiving</span></span>
    event</span> Transferred</span>(</span></span>
        uint256</span> _tokenId</span>,</span></span>
        address</span> indexed</span> _from</span>,</span></span>
        address</span> indexed</span> _to</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when a token is cloned</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @param</span> _newTokenId</span> The new token identifier</span></span>
    ///</span> @param</span> _from</span> The address that is cloning</span></span>
    ///</span> @param</span> _to</span> The address that is receiving</span></span>
    event</span> Cloned</span>(</span></span>
        uint256</span> indexed</span> _tokenId</span>,</span></span>
        uint256</span> indexed</span> _newTokenId</span>,</span></span>
        address</span> _from</span>,</span></span>
        address</span> _to</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when a sealed key is published</span></span>
    ///</span> @param</span> _to</span> The address that is receiving</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @param</span> _sealedKeys</span> The sealed keys</span></span>
    event</span> PublishedSealedKey</span>(</span></span>
        address</span> indexed</span> _to</span>,</span></span>
        uint256</span> indexed</span> _tokenId</span>,</span></span>
        bytes</span>[</span>]</span> _sealedKeys</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> The event emitted when a user is delegated to an assistant</span></span>
    ///</span> @param</span> _user</span> The user</span></span>
    ///</span> @param</span> _assistant</span> The assistant</span></span>
    event</span> DelegateAccess</span>(</span>address</span> indexed</span> _user</span>, </span>address</span> indexed</span> _assistant</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> The verifier interface that this NFT uses</span></span>
    ///</span> @return</span> The</span> address of the verifier contract</span></span>
    function</span> verifier</span>(</span>)</span> external</span> view</span> returns</span> (</span>IERC7857DataVerifier</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Transfer data with ownership</span></span>
    ///</span> @param</span> _to</span> Address to transfer data to</span></span>
    ///</span> @param</span> _tokenId</span> The token to transfer data for</span></span>
    ///</span> @param</span> _proofs</span> Proofs of data available for _to</span></span>
    function</span> iTransfer</span>(</span></span>
        address</span> _to</span>,</span></span>
        uint256</span> _tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> _proofs</span></span>
    )</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Clone data</span></span>
    ///</span> @param</span> _to</span> Address to clone data to</span></span>
    ///</span> @param</span> _tokenId</span> The token to clone data for</span></span>
    ///</span> @param</span> _proofs</span> Proofs of data available for _to</span></span>
    ///</span> @return</span> _newTokenId</span> The ID of the newly cloned token</span></span>
    function</span> iClone</span>(</span></span>
        address</span> _to</span>,</span></span>
        uint256</span> _tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> _proofs</span></span>
    )</span> external</span> returns</span> (</span>uint256</span> _newTokenId</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Add authorized user to group</span></span>
    ///</span> @param</span> _tokenId</span> The token to add to group</span></span>
    function</span> authorizeUsage</span>(</span>uint256</span> _tokenId</span>,</span> address</span> _user</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Revoke authorization from a user</span></span>
    ///</span> @param</span> _tokenId</span> The token to revoke authorization from</span></span>
    ///</span> @param</span> _user</span> The user to revoke authorization from</span></span>
    function</span> revokeAuthorization</span>(</span>uint256</span> _tokenId</span>,</span> address</span> _user</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Approve an address to transfer a token</span></span>
    ///</span> @param</span> _to</span> The address to approve</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    function</span> approve</span>(</span>address</span> _to</span>,</span> uint256</span> _tokenId</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Set approval for all</span></span>
    ///</span> @param</span> _operator</span> The operator</span></span>
    ///</span> @param</span> _approved</span> The approval</span></span>
    function</span> setApprovalForAll</span>(</span>address</span> _operator</span>,</span> bool</span> _approved</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Delegate access check to an assistant</span></span>
    ///</span> @param</span> _assistant</span> The assistant</span></span>
    function</span> delegateAccess</span>(</span>address</span> _assistant</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Get token owner</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @return</span> The</span> current owner of the token</span></span>
    function</span> ownerOf</span>(</span>uint256</span> _tokenId</span>)</span> external</span> view</span> returns</span> (</span>address</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Get the authorized users of a token</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @return</span> The</span> current authorized users of the token</span></span>
    function</span> authorizedUsersOf</span>(</span></span>
        uint256</span> _tokenId</span></span>
    )</span> external</span> view</span> returns</span> (</span>address</span>[</span>]</span> memory</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Get the approved address for a token</span></span>
    ///</span> @param</span> _tokenId</span> The token identifier</span></span>
    ///</span> @return</span> The</span> approved address</span></span>
    function</span> getApproved</span>(</span>uint256</span> _tokenId</span>)</span> external</span> view</span> returns</span> (</span>address</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Check if an address is approved for all</span></span>
    ///</span> @param</span> _owner</span> The owner</span></span>
    ///</span> @param</span> _operator</span> The operator</span></span>
    ///</span> @return</span> The</span> approval</span></span>
    function</span> isApprovedForAll</span>(</span></span>
        address</span> _owner</span>,</span></span>
        address</span> _operator</span></span>
    )</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Get the delegate access for a user</span></span>
    ///</span> @param</span> _user</span> The user</span></span>
    ///</span> @return</span> The</span> delegate access</span></span>
    function</span> getDelegateAccess</span>(</span>address</span> _user</span>)</span> external</span> view</span> returns</span> (</span>address</span>)</span>;</span></span>
}</span></span></code></pre>Rationale</h2>
The design choices in this standard are motivated by several key requirements:</p>


Verification Abstraction</strong>: The standard separates the verification logic into a dedicated interface (IDataVerifier</code>), allowing different verification mechanisms (TEE, ZKP) to be implemented and used interchangeably. The verifier should support two types of proof:</p>

Ownership Proof Verifies that the prover possesses the original data by demonstrating knowledge of the pre-images that generate the claimed dataHashes</li>
Transfer Validity Proof Verifies secure data integrity and availability by proving: knowledge of the original data (pre-images of oldDataHashes); ability to decrypt with oldKey and re-encrypt with newKey; secure transmission of newKey using recipient's public key; integrity of the newly encrypted data matching newDataHashes; and data availability confirmed by recipient's signature on both oldDataHashes</code> and newDataHashes</code></li>
</ul>
</li>

Data Protection</strong>: The standard uses data hashes and encrypted keys to ensure that valuable NFT data remains protected while still being integrity and availability verifiable</p>
</li>

Flexible Data Management</strong>: Three distinct data operations are supported:</p>

Full transfer, where the data and ownership are transferred to the new owner</li>
Data cloning, where the data is cloned to a new token but the ownership is not transferred</li>
Data usage authorization, where the data is authorized to be used by a specific user, but the ownership is not transferred, and the user still cannot access the data. This need an environment to authenticate the user and process the request from the authorized user secretly, we call it "Sealed Executor"</li>
</ul>
</li>

Sealed Executor</strong>: Although the Sealed Executor is not defined and out of the scope of this standard, it is a crucial component for the standard to work. The Sealed Executor is an environment that can authenticate the user and process the request from the authorized user secretly. The Sealed Executor should get authorized group by tokenId, and the verify the signature of the user using the public keys in the authorized group. If the verification is successful, the executor will process the request and return the result to the user, and the sealed executor could be implemented by a trusted party (where permitted), TEE or Fully Homomorphic Encryption (FHE)</p>
</li>
</ol>
Backwards Compatibility</h2>
This EIP does not inherit from existing NFT standards to maintain its focus on functional data management. However, implementations can choose to additionally implement ERC-721</a> if traditional NFT compatibility is desired.</p>
Reference Implementation</h2>
Verifier</h3>
abstract</span> contract</span> BaseVerifier</span> is</span> IERC7857DataVerifier</span> {</span></span>
    //</span> prevent replay attack</span></span>
    mapping</span>(</span>bytes32</span> =></span> bool</span>)</span> internal</span> usedProofs</span>;</span></span>
    </span></span>
    //</span> prevent replay attack</span></span>
    mapping</span>(</span>bytes32</span> =></span> uint256</span>)</span> internal</span> proofTimestamps</span>;</span></span>
    </span></span>
    function</span> _checkAndMarkProof</span>(</span>bytes32</span> proofNonce</span>)</span> internal</span> {</span></span>
        require</span>(</span>!</span>usedProofs</span>[</span>proofNonce</span>]</span>,</span> "Proof already used"</span>)</span>;</span></span>
        usedProofs</span>[</span>proofNonce</span>]</span> =</span> true</span>;</span></span>
        proofTimestamps</span>[</span>proofNonce</span>]</span> =</span> block</span>.</span>timestamp</span>;</span></span>
    }</span></span>
    </span></span>
    //</span> clean expired proof records (save gas)</span></span>
    function</span> cleanExpiredProofs</span>(</span>bytes32</span>[</span>]</span> calldata</span> proofNonces</span>)</span> external</span> {</span></span>
        for</span> (</span>uint256</span> i </span>=</span> 0</span>;</span> i </span><</span> proofNonces</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            bytes32</span> nonce </span>=</span> proofNonces</span>[</span>i</span>]</span>;</span></span>
            if</span> (</span>usedProofs</span>[</span>nonce</span>]</span> &&</span> </span></span>
                block</span>.</span>timestamp </span>></span> proofTimestamps</span>[</span>nonce</span>]</span> +</span> 7</span> days</span>)</span> {</span></span>
                delete</span> usedProofs</span>[</span>nonce</span>]</span>;</span></span>
                delete</span> proofTimestamps</span>[</span>nonce</span>]</span>;</span></span>
            }</span></span>
        }</span></span>
    }</span></span>
</span>
    uint256</span>[</span>50</span>]</span> private</span> __gap</span>;</span></span>
}</span></span>
</span>
struct</span> AttestationConfig</span> {</span></span>
    OracleType oracleType</span>;</span></span>
    address</span> contractAddress</span>;</span></span>
}</span></span>
</span>
contract</span> Verifier</span> is</span></span>
    BaseVerifier</span>,</span></span>
    Initializable</span>,</span></span>
    AccessControlUpgradeable</span>,</span></span>
    PausableUpgradeable</span></span>
{</span></span>
    using</span> ECDSA</span> for</span> bytes32</span>;</span></span>
    using</span> MessageHashUtils</span> for</span> bytes32</span>;</span></span>
</span>
    event</span> AttestationContractUpdated</span>(</span>AttestationConfig</span>[</span>]</span> attestationConfigs</span>)</span>;</span></span>
</span>
    bytes32</span> public</span> constant</span> ADMIN_ROLE </span>=</span> keccak256</span>(</span>"ADMIN_ROLE"</span>)</span>;</span></span>
    bytes32</span> public</span> constant</span> PAUSER_ROLE </span>=</span> keccak256</span>(</span>"PAUSER_ROLE"</span>)</span>;</span></span>
</span>
    mapping</span>(</span>OracleType </span>=></span> address</span>)</span> public</span> attestationContract</span>;</span></span>
</span>
    uint256</span> public</span> maxProofAge</span>;</span></span>
</span>
    string</span> public</span> constant</span> VERSION </span>=</span> "2.0.0"</span>;</span></span>
</span>
    ///</span> @custom:oz</span>-upgrades-unsafe-allow constructor</span></span>
    constructor</span>(</span>)</span> {</span></span>
        _disableInitializers</span>(</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> initialize</span>(</span></span>
        AttestationConfig</span>[</span>]</span> calldata</span> _attestationConfigs</span>,</span></span>
        address</span> _admin</span></span>
    )</span> external</span> initializer</span> {</span></span>
        __AccessControl_init</span>(</span>)</span>;</span></span>
        __Pausable_init</span>(</span>)</span>;</span></span>
</span>
        for</span> (</span>uint256</span> i </span>=</span> 0</span>;</span> i </span><</span> _attestationConfigs</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            attestationContract</span>[</span></span>
                _attestationConfigs</span>[</span>i</span>]</span>.</span>oracleType</span></span>
            ]</span> =</span> _attestationConfigs</span>[</span>i</span>]</span>.</span>contractAddress</span>;</span></span>
        }</span></span>
        maxProofAge </span>=</span> 7</span> days</span>;</span></span>
</span>
        _grantRole</span>(</span>DEFAULT_ADMIN_ROLE</span>,</span> _admin</span>)</span>;</span></span>
        _grantRole</span>(</span>ADMIN_ROLE</span>,</span> _admin</span>)</span>;</span></span>
        _grantRole</span>(</span>PAUSER_ROLE</span>,</span> _admin</span>)</span>;</span></span>
</span>
        emit</span> AttestationContractUpdated</span>(</span>_attestationConfigs</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> updateAttestationContract</span>(</span></span>
        AttestationConfig</span>[</span>]</span> calldata</span> _attestationConfigs</span></span>
    )</span> external</span> onlyRole</span>(</span>ADMIN_ROLE</span>)</span> {</span></span>
        for</span> (</span>uint256</span> i </span>=</span> 0</span>;</span> i </span><</span> _attestationConfigs</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            attestationContract</span>[</span></span>
                _attestationConfigs</span>[</span>i</span>]</span>.</span>oracleType</span></span>
            ]</span> =</span> _attestationConfigs</span>[</span>i</span>]</span>.</span>contractAddress</span>;</span></span>
        }</span></span>
</span>
        emit</span> AttestationContractUpdated</span>(</span>_attestationConfigs</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> updateMaxProofAge</span>(</span></span>
        uint256</span> _maxProofAge</span></span>
    )</span> external</span> onlyRole</span>(</span>ADMIN_ROLE</span>)</span> {</span></span>
        maxProofAge </span>=</span> _maxProofAge</span>;</span></span>
    }</span></span>
</span>
    function</span> pause</span>(</span>)</span> external</span> onlyRole</span>(</span>PAUSER_ROLE</span>)</span> {</span></span>
        _pause</span>(</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> unpause</span>(</span>)</span> external</span> onlyRole</span>(</span>PAUSER_ROLE</span>)</span> {</span></span>
        _unpause</span>(</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> hashNonce</span>(</span>bytes</span> memory</span> nonce</span>)</span> private</span> pure</span> returns</span> (</span>bytes32</span>)</span> {</span></span>
        return</span> keccak256</span>(</span>nonce</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> teeOracleVerify</span>(</span></span>
        bytes32</span> messageHash</span>,</span></span>
        bytes</span> memory</span> signature</span></span>
    )</span> internal</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span>
        return</span></span>
            TEEVerifier</span>(</span>attestationContract</span>[</span>OracleType</span>.</span>TEE</span>]</span>)</span>.</span>verifyTEESignature</span>(</span></span>
                messageHash</span>,</span></span>
                signature</span></span>
            )</span>;</span></span>
    }</span></span>
</span>
    ///</span> @notice</span> Extract and verify signature from the access proof</span></span>
    ///</span> @param</span> accessProof</span> The access proof</span></span>
    ///</span> @return</span> The</span> recovered access assistant address</span></span>
    function</span> verifyAccessibility</span>(</span></span>
        AccessProof</span> memory</span> accessProof</span></span>
    )</span> private</span> pure</span> returns</span> (</span>address</span>)</span> {</span></span>
        bytes32</span> messageHash </span>=</span> keccak256</span>(</span></span>
            abi</span>.</span>encodePacked</span>(</span></span>
                "\x19Ethereum Signed Message:\n66"</span>,</span></span>
                Strings</span>.</span>toHexString</span>(</span></span>
                    uint256</span>(</span></span>
                        keccak256</span>(</span></span>
                            abi</span>.</span>encodePacked</span>(</span></span>
                                accessProof</span>.</span>oldDataHash</span>,</span></span>
                                accessProof</span>.</span>newDataHash</span>,</span></span>
                                accessProof</span>.</span>encryptedPubKey</span>,</span></span>
                                accessProof</span>.</span>nonce</span></span>
                            )</span></span>
                        )</span></span>
                    )</span>,</span></span>
                    32</span></span>
                )</span></span>
            )</span></span>
        )</span>;</span></span>
</span>
        address</span> accessAssistant </span>=</span> messageHash</span>.</span>recover</span>(</span>accessProof</span>.</span>proof</span>)</span>;</span></span>
        require</span>(</span>accessAssistant </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Invalid access assistant"</span>)</span>;</span></span>
        return</span> accessAssistant</span>;</span></span>
    }</span></span>
</span>
    function</span> verfifyOwnershipProof</span>(</span></span>
        OwnershipProof</span> memory</span> ownershipProof</span></span>
    )</span> private</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span>
        if</span> (</span>ownershipProof</span>.</span>oracleType </span>==</span> OracleType</span>.</span>TEE</span>)</span> {</span></span>
            bytes32</span> messageHash </span>=</span> keccak256</span>(</span></span>
                abi</span>.</span>encodePacked</span>(</span></span>
                    "\x19Ethereum Signed Message:\n66"</span>,</span></span>
                    Strings</span>.</span>toHexString</span>(</span></span>
                        uint256</span>(</span></span>
                            keccak256</span>(</span></span>
                                abi</span>.</span>encodePacked</span>(</span></span>
                                    ownershipProof</span>.</span>oldDataHash</span>,</span></span>
                                    ownershipProof</span>.</span>newDataHash</span>,</span></span>
                                    ownershipProof</span>.</span>sealedKey</span>,</span></span>
                                    ownershipProof</span>.</span>encryptedPubKey</span>,</span></span>
                                    ownershipProof</span>.</span>nonce</span></span>
                                )</span></span>
                            )</span></span>
                        )</span>,</span></span>
                        32</span></span>
                    )</span></span>
                )</span></span>
            )</span>;</span></span>
</span>
            return</span> teeOracleVerify</span>(</span>messageHash</span>,</span> ownershipProof</span>.</span>proof</span>)</span>;</span></span>
        }</span></span>
        //</span> TODO</span>: add ZKP verification</span></span>
        else</span> {</span></span>
            return</span> false</span>;</span></span>
        }</span></span>
    }</span></span>
</span>
    ///</span> @notice</span> Process a single transfer validity proof</span></span>
    ///</span> @param</span> proof</span> The proof data</span></span>
    ///</span> @return</span> output</span> The processed proof data as a struct</span></span>
    function</span> processTransferProof</span>(</span></span>
        TransferValidityProof</span> calldata</span> proof</span></span>
    )</span> private</span> view</span> returns</span> (</span>TransferValidityProofOutput</span> memory</span> output</span>)</span> {</span></span>
        //</span> compare the proof data in access proof and ownership proof</span></span>
        require</span>(</span></span>
            proof</span>.</span>accessProof</span>.</span>oldDataHash </span>==</span> proof</span>.</span>ownershipProof</span>.</span>oldDataHash</span>,</span></span>
            "Invalid oldDataHashes"</span></span>
        )</span>;</span></span>
        output</span>.</span>oldDataHash </span>=</span> proof</span>.</span>accessProof</span>.</span>oldDataHash</span>;</span></span>
        require</span>(</span></span>
            proof</span>.</span>accessProof</span>.</span>newDataHash </span>==</span> proof</span>.</span>ownershipProof</span>.</span>newDataHash</span>,</span></span>
            "Invalid newDataHashes"</span></span>
        )</span>;</span></span>
        output</span>.</span>newDataHash </span>=</span> proof</span>.</span>accessProof</span>.</span>newDataHash</span>;</span></span>
</span>
        output</span>.</span>wantedKey </span>=</span> proof</span>.</span>accessProof</span>.</span>encryptedPubKey</span>;</span></span>
        output</span>.</span>accessProofNonce </span>=</span> proof</span>.</span>accessProof</span>.</span>nonce</span>;</span></span>
        output</span>.</span>encryptedPubKey </span>=</span> proof</span>.</span>ownershipProof</span>.</span>encryptedPubKey</span>;</span></span>
        output</span>.</span>sealedKey </span>=</span> proof</span>.</span>ownershipProof</span>.</span>sealedKey</span>;</span></span>
        output</span>.</span>ownershipProofNonce </span>=</span> proof</span>.</span>ownershipProof</span>.</span>nonce</span>;</span></span>
</span>
        //</span> verify the access assistant</span></span>
        output</span>.</span>accessAssistant </span>=</span> verifyAccessibility</span>(</span>proof</span>.</span>accessProof</span>)</span>;</span></span>
</span>
        bool</span> isOwn </span>=</span> verfifyOwnershipProof</span>(</span>proof</span>.</span>ownershipProof</span>)</span>;</span></span>
</span>
        require</span>(</span>isOwn</span>,</span> "Invalid ownership proof"</span>)</span>;</span></span>
</span>
        return</span> output</span>;</span></span>
    }</span></span>
</span>
    ///</span> @notice</span> Verify data transfer validity, the _proof prove:</span></span>
    ///</span>         1. The pre-image of oldDataHashes</span></span>
    ///</span>         2. The oldKey can decrypt the pre-image and the new key re-encrypt the plaintexts to new ciphertexts</span></span>
    ///</span>         3. The newKey is encrypted with the receiver's pubKey to get the sealedKey</span></span>
    ///</span>         4. The hashes of new ciphertexts is newDataHashes (key to </span>note</span>: TEE could support a private key of the receiver)</span></span>
    ///</span>         5. The newDataHashes identified ciphertexts are available in the storage: need the signature from the receiver signing oldDataHashes and newDataHashes</span></span>
    ///</span> @param</span> proofs</span> Proof generated by TEE/ZKP oracle</span></span>
    function</span> verifyTransferValidity</span>(</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span></span>
        public</span></span>
        virtual</span></span>
        override</span></span>
        whenNotPaused</span></span>
        returns</span> (</span>TransferValidityProofOutput</span>[</span>]</span> memory</span>)</span></span>
    {</span></span>
        TransferValidityProofOutput</span>[</span>]</span></span>
            memory</span> outputs </span>=</span> new</span> TransferValidityProofOutput</span>[</span>]</span>(</span>proofs</span>.</span>length</span>)</span>;</span></span>
</span>
        for</span> (</span>uint256</span> i </span>=</span> 0</span>;</span> i </span><</span> proofs</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            TransferValidityProofOutput </span>memory</span> output </span>=</span> processTransferProof</span>(</span></span>
                proofs</span>[</span>i</span>]</span></span>
            )</span>;</span></span>
</span>
            outputs</span>[</span>i</span>]</span> =</span> output</span>;</span></span>
</span>
            bytes32</span> accessProofNonce </span>=</span> hashNonce</span>(</span>output</span>.</span>accessProofNonce</span>)</span>;</span></span>
            _checkAndMarkProof</span>(</span>accessProofNonce</span>)</span>;</span></span>
</span>
            bytes32</span> ownershipProofNonce </span>=</span> hashNonce</span>(</span>output</span>.</span>ownershipProofNonce</span>)</span>;</span></span>
            _checkAndMarkProof</span>(</span>ownershipProofNonce</span>)</span>;</span></span>
        }</span></span>
</span>
        return</span> outputs</span>;</span></span>
    }</span></span>
</span>
    uint256</span>[</span>50</span>]</span> private</span> __gap</span>;</span></span>
}</span></span></code></pre>Main NFT</h3>
contract</span> AgentNFT</span> is</span></span>
    AccessControlEnumerableUpgradeable</span>,</span></span>
    IERC7857</span>,</span></span>
    IERC7857Metadata</span></span>
{</span></span>
    event</span> Updated</span>(</span></span>
        uint256</span> indexed</span> _tokenId</span>,</span></span>
        IntelligentData</span>[</span>]</span> _oldDatas</span>,</span></span>
        IntelligentData</span>[</span>]</span> _newDatas</span></span>
    )</span>;</span></span>
</span>
    event</span> Minted</span>(</span></span>
        uint256</span> indexed</span> _tokenId</span>,</span></span>
        address</span> indexed</span> _creator</span>,</span></span>
        address</span> indexed</span> _owner</span></span>
    )</span>;</span></span>
</span>
    struct</span> TokenData</span> {</span></span>
        address</span> owner</span>;</span></span>
        address</span>[</span>]</span> authorizedUsers</span>;</span></span>
        address</span> approvedUser</span>;</span></span>
        IntelligentData</span>[</span>]</span> iDatas</span>;</span></span>
    }</span></span>
</span>
    ///</span> @custom:storage</span>-location erc7201:agent.storage.AgentNFT</span></span>
    struct</span> AgentNFTStorage</span> {</span></span>
        //</span> Token data</span></span>
        mapping</span>(</span>uint256</span> =></span> TokenData</span>)</span> tokens</span>;</span></span>
        mapping</span>(</span>address</span> owner </span>=></span> mapping</span>(</span>address</span> operator </span>=></span> bool</span>)</span>)</span> operatorApprovals</span>;</span></span>
        mapping</span>(</span>address</span> user </span>=></span> address</span> accessAssistant</span>)</span> accessAssistants</span>;</span></span>
        uint256</span> nextTokenId</span>;</span></span>
        //</span> Contract metadata</span></span>
        string</span> name</span>;</span></span>
        string</span> symbol</span>;</span></span>
        string</span> storageInfo</span>;</span></span>
        //</span> Core components</span></span>
        IERC7857DataVerifier verifier</span>;</span></span>
    }</span></span>
</span>
    bytes32</span> public</span> constant</span> ADMIN_ROLE </span>=</span> keccak256</span>(</span>"ADMIN_ROLE"</span>)</span>;</span></span>
    bytes32</span> public</span> constant</span> PAUSER_ROLE </span>=</span> keccak256</span>(</span>"PAUSER_ROLE"</span>)</span>;</span></span>
</span>
    string</span> public</span> constant</span> VERSION </span>=</span> "2.0.0"</span>;</span></span>
</span>
    //</span> keccak256(abi.encode(uint(keccak256("agent.storage.AgentNFT")) - 1)) & ~bytes32(uint(0xff))</span></span>
    bytes32</span> private</span> constant</span> AGENT_NFT_STORAGE_LOCATION </span>=</span></span>
        0x4aa80aaafbe0e5fe3fe1aa97f3c1f8c65d61f96ef1aab2b448154f4e07594600</span>;</span></span>
</span>
    function</span> _getAgentStorage</span>(</span>)</span></span>
        private</span></span>
        pure</span></span>
        returns</span> (</span>AgentNFTStorage</span> storage</span> $</span>)</span></span>
    {</span></span>
        assembly</span> {</span></span>
            $</span>.</span>slot </span>:=</span> AGENT_NFT_STORAGE_LOCATION</span></span>
        }</span></span>
    }</span></span>
</span>
    ///</span> @custom:oz</span>-upgrades-unsafe-allow constructor</span></span>
    constructor</span>(</span>)</span> {</span></span>
        _disableInitializers</span>(</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> initialize</span>(</span></span>
        string</span> memory</span> name_</span>,</span></span>
        string</span> memory</span> symbol_</span>,</span></span>
        string</span> memory</span> storageInfo_</span>,</span></span>
        address</span> verifierAddr</span>,</span></span>
        address</span> admin_</span></span>
    )</span> public</span> virtual</span> initializer</span> {</span></span>
        require</span>(</span>verifierAddr </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
</span>
        __AccessControlEnumerable_init</span>(</span>)</span>;</span></span>
</span>
        _grantRole</span>(</span>DEFAULT_ADMIN_ROLE</span>,</span> admin_</span>)</span>;</span></span>
        _grantRole</span>(</span>ADMIN_ROLE</span>,</span> admin_</span>)</span>;</span></span>
        _grantRole</span>(</span>PAUSER_ROLE</span>,</span> admin_</span>)</span>;</span></span>
</span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        $</span>.</span>name </span>=</span> name_</span>;</span></span>
        $</span>.</span>symbol </span>=</span> symbol_</span>;</span></span>
        $</span>.</span>storageInfo </span>=</span> storageInfo_</span>;</span></span>
        $</span>.</span>verifier </span>=</span> IERC7857DataVerifier</span>(</span>verifierAddr</span>)</span>;</span></span>
    }</span></span>
</span>
    //</span> Basic getters</span></span>
    function</span> name</span>(</span>)</span> public</span> view</span> virtual</span> returns</span> (</span>string</span> memory</span>)</span> {</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>name</span>;</span></span>
    }</span></span>
</span>
    function</span> symbol</span>(</span>)</span> public</span> view</span> virtual</span> returns</span> (</span>string</span> memory</span>)</span> {</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>symbol</span>;</span></span>
    }</span></span>
</span>
    function</span> verifier</span>(</span>)</span> public</span> view</span> virtual</span> returns</span> (</span>IERC7857DataVerifier</span>)</span> {</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>verifier</span>;</span></span>
    }</span></span>
</span>
    //</span> Admin functions</span></span>
    function</span> updateVerifier</span>(</span></span>
        address</span> newVerifier</span></span>
    )</span> public</span> virtual</span> onlyRole</span>(</span>ADMIN_ROLE</span>)</span> {</span></span>
        require</span>(</span>newVerifier </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
        _getAgentStorage</span>(</span>)</span>.</span>verifier </span>=</span> IERC7857DataVerifier</span>(</span>newVerifier</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> update</span>(</span></span>
        uint256</span> tokenId</span>,</span></span>
        IntelligentData</span>[</span>]</span> calldata</span> newDatas</span></span>
    )</span> public</span> virtual</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        TokenData </span>storage</span> token </span>=</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>;</span></span>
        require</span>(</span>token</span>.</span>owner </span>==</span> msg.sender</span>,</span> "Not owner"</span>)</span>;</span></span>
        require</span>(</span>newDatas</span>.</span>length </span>></span> 0</span>,</span> "Empty data array"</span>)</span>;</span></span>
</span>
        IntelligentData</span>[</span>]</span> memory</span> oldDatas </span>=</span> new</span> IntelligentData</span>[</span>]</span>(</span></span>
            token</span>.</span>iDatas</span>.</span>length</span></span>
        )</span>;</span></span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> token</span>.</span>iDatas</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            oldDatas</span>[</span>i</span>]</span> =</span> token</span>.</span>iDatas</span>[</span>i</span>]</span>;</span></span>
        }</span></span>
</span>
        delete</span> token</span>.</span>iDatas</span>;</span></span>
</span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> newDatas</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            token</span>.</span>iDatas</span>.</span>push</span>(</span>newDatas</span>[</span>i</span>]</span>)</span>;</span></span>
        }</span></span>
</span>
        emit</span> Updated</span>(</span>tokenId</span>,</span> oldDatas</span>,</span> newDatas</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> mint</span>(</span></span>
        IntelligentData</span>[</span>]</span> calldata</span> iDatas</span>,</span></span>
        address</span> to</span></span>
    )</span> public</span> payable</span> virtual</span> returns</span> (</span>uint256</span> tokenId</span>)</span> {</span></span>
        require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
        require</span>(</span>iDatas</span>.</span>length </span>></span> 0</span>,</span> "Empty data array"</span>)</span>;</span></span>
</span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
</span>
        tokenId </span>=</span> $</span>.</span>nextTokenId</span>+</span>+</span>;</span></span>
        TokenData </span>storage</span> newToken </span>=</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>;</span></span>
        newToken</span>.</span>owner </span>=</span> to</span>;</span></span>
        newToken</span>.</span>approvedUser </span>=</span> address</span>(</span>0</span>)</span>;</span></span>
</span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> iDatas</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            newToken</span>.</span>iDatas</span>.</span>push</span>(</span>iDatas</span>[</span>i</span>]</span>)</span>;</span></span>
        }</span></span>
</span>
        emit</span> Minted</span>(</span>tokenId</span>,</span> msg.sender</span>,</span> to</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> _proofCheck</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span></span>
        internal</span></span>
        returns</span> (</span>bytes</span>[</span>]</span> memory</span> sealedKeys</span>,</span> IntelligentData</span>[</span>]</span> memory</span> newDatas</span>)</span></span>
    {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
        require</span>(</span>$</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>owner </span>==</span> from</span>,</span> "Not owner"</span>)</span>;</span></span>
        require</span>(</span>proofs</span>.</span>length </span>></span> 0</span>,</span> "Empty proofs array"</span>)</span>;</span></span>
</span>
        TransferValidityProofOutput</span>[</span>]</span> memory</span> proofOutput </span>=</span> $</span></span>
            .</span>verifier</span></span>
            .</span>verifyTransferValidity</span>(</span>proofs</span>)</span>;</span></span>
</span>
        require</span>(</span></span>
            proofOutput</span>.</span>length </span>==</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>iDatas</span>.</span>length</span>,</span></span>
            "Proof count mismatch"</span></span>
        )</span>;</span></span>
</span>
        sealedKeys </span>=</span> new</span> bytes</span>[](</span>proofOutput</span>.</span>length</span>)</span>;</span></span>
        newDatas </span>=</span> new</span> IntelligentData</span>[</span>]</span>(</span>proofOutput</span>.</span>length</span>)</span>;</span></span>
</span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> proofOutput</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            //</span> require the initial data hash is the same as the old data hash</span></span>
            require</span>(</span></span>
                proofOutput</span>[</span>i</span>]</span>.</span>oldDataHash </span>==</span></span>
                    $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>iDatas</span>[</span>i</span>]</span>.</span>dataHash</span>,</span></span>
                "Old data hash mismatch"</span></span>
            )</span>;</span></span>
</span>
            //</span> only the receiver itself or the access assistant can sign the access proof</span></span>
            require</span>(</span></span>
                proofOutput</span>[</span>i</span>]</span>.</span>accessAssistant </span>==</span> $</span>.</span>accessAssistants</span>[</span>to</span>]</span> ||</span></span>
                    proofOutput</span>[</span>i</span>]</span>.</span>accessAssistant </span>==</span> to</span>,</span></span>
                "Access assistant mismatch"</span></span>
            )</span>;</span></span>
</span>
            bytes</span> memory</span> wantedKey </span>=</span> proofOutput</span>[</span>i</span>]</span>.</span>wantedKey</span>;</span></span>
            bytes</span> memory</span> encryptedPubKey </span>=</span> proofOutput</span>[</span>i</span>]</span>.</span>encryptedPubKey</span>;</span></span>
            if</span> (</span>wantedKey</span>.</span>length </span>==</span> 0</span>)</span> {</span></span>
                //</span> if the wanted key is empty, the default wanted receiver is receiver itself</span></span>
                address</span> defaultWantedReceiver </span>=</span> Utils</span>.</span>pubKeyToAddress</span>(</span></span>
                    encryptedPubKey</span></span>
                )</span>;</span></span>
                require</span>(</span></span>
                    defaultWantedReceiver </span>==</span> to</span>,</span></span>
                    "Default wanted receiver mismatch"</span></span>
                )</span>;</span></span>
            }</span> else</span> {</span></span>
                //</span> if the wanted key is not empty, the data is private</span></span>
                require</span>(</span></span>
                    Utils</span>.</span>bytesEqual</span>(</span>encryptedPubKey</span>,</span> wantedKey</span>)</span>,</span></span>
                    "encryptedPubKey mismatch"</span></span>
                )</span>;</span></span>
            }</span></span>
</span>
            sealedKeys</span>[</span>i</span>]</span> =</span> proofOutput</span>[</span>i</span>]</span>.</span>sealedKey</span>;</span></span>
            newDatas</span>[</span>i</span>]</span> =</span> IntelligentData</span>(</span>{</span></span>
                dataDescription</span>:</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>iDatas</span>[</span>i</span>]</span>.</span>dataDescription</span>,</span></span>
                dataHash</span>:</span> proofOutput</span>[</span>i</span>]</span>.</span>newDataHash</span></span>
            }</span>)</span>;</span></span>
        }</span></span>
        return</span> (</span>sealedKeys</span>,</span> newDatas</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> _transfer</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span> internal</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        (</span></span>
            bytes</span>[</span>]</span> memory</span> sealedKeys</span>,</span></span>
            IntelligentData</span>[</span>]</span> memory</span> newDatas</span></span>
        )</span> =</span> _proofCheck</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>,</span> proofs</span>)</span>;</span></span>
</span>
        TokenData </span>storage</span> token </span>=</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>;</span></span>
        token</span>.</span>owner </span>=</span> to</span>;</span></span>
        token</span>.</span>approvedUser </span>=</span> address</span>(</span>0</span>)</span>;</span></span>
</span>
        delete</span> token</span>.</span>iDatas</span>;</span></span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> newDatas</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            token</span>.</span>iDatas</span>.</span>push</span>(</span>newDatas</span>[</span>i</span>]</span>)</span>;</span></span>
        }</span></span>
</span>
        emit</span> Transferred</span>(</span>tokenId</span>,</span> from</span>,</span> to</span>)</span>;</span></span>
        emit</span> PublishedSealedKey</span>(</span>to</span>,</span> tokenId</span>,</span> sealedKeys</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> iTransfer</span>(</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span> public</span> virtual</span> {</span></span>
        require</span>(</span>_isApprovedOrOwner</span>(</span>msg.sender</span>,</span> tokenId</span>)</span>,</span> "Not authorized"</span>)</span>;</span></span>
        _transfer</span>(</span>ownerOf</span>(</span>tokenId</span>)</span>,</span> to</span>,</span> tokenId</span>,</span> proofs</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> transferFrom</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span></span>
    )</span> public</span> virtual</span> {</span></span>
        TokenData </span>storage</span> token </span>=</span> _getAgentStorage</span>(</span>)</span>.</span>tokens</span>[</span>tokenId</span>]</span>;</span></span>
        require</span>(</span>_isApprovedOrOwner</span>(</span>msg.sender</span>,</span> tokenId</span>)</span>,</span> "Not authorized"</span>)</span>;</span></span>
        require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
        require</span>(</span>token</span>.</span>owner </span>==</span> from</span>,</span> "Not owner"</span>)</span>;</span></span>
        token</span>.</span>owner </span>=</span> to</span>;</span></span>
        token</span>.</span>approvedUser </span>=</span> address</span>(</span>0</span>)</span>;</span></span>
</span>
        emit</span> Transferred</span>(</span>tokenId</span>,</span> from</span>,</span> to</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> iTransferFrom</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span> public</span> virtual</span> {</span></span>
        require</span>(</span>_isApprovedOrOwner</span>(</span>msg.sender</span>,</span> tokenId</span>)</span>,</span> "Not authorized"</span>)</span>;</span></span>
        _transfer</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>,</span> proofs</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> _clone</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span> internal</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
</span>
        (</span></span>
            bytes</span>[</span>]</span> memory</span> sealedKeys</span>,</span></span>
            IntelligentData</span>[</span>]</span> memory</span> newDatas</span></span>
        )</span> =</span> _proofCheck</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>,</span> proofs</span>)</span>;</span></span>
</span>
        uint256</span> newTokenId </span>=</span> $</span>.</span>nextTokenId</span>+</span>+</span>;</span></span>
        TokenData </span>storage</span> newToken </span>=</span> $</span>.</span>tokens</span>[</span>newTokenId</span>]</span>;</span></span>
        newToken</span>.</span>owner </span>=</span> to</span>;</span></span>
        newToken</span>.</span>approvedUser </span>=</span> address</span>(</span>0</span>)</span>;</span></span>
</span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> newDatas</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            newToken</span>.</span>iDatas</span>.</span>push</span>(</span>newDatas</span>[</span>i</span>]</span>)</span>;</span></span>
        }</span></span>
</span>
        emit</span> Cloned</span>(</span>tokenId</span>,</span> newTokenId</span>,</span> from</span>,</span> to</span>)</span>;</span></span>
        emit</span> PublishedSealedKey</span>(</span>to</span>,</span> newTokenId</span>,</span> sealedKeys</span>)</span>;</span></span>
</span>
        return</span> newTokenId</span>;</span></span>
    }</span></span>
</span>
    function</span> iClone</span>(</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span> public</span> virtual</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        require</span>(</span>_isApprovedOrOwner</span>(</span>msg.sender</span>,</span> tokenId</span>)</span>,</span> "Not authorized"</span>)</span>;</span></span>
        return</span> _clone</span>(</span>ownerOf</span>(</span>tokenId</span>)</span>,</span> to</span>,</span> tokenId</span>,</span> proofs</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> iCloneFrom</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        TransferValidityProof</span>[</span>]</span> calldata</span> proofs</span></span>
    )</span> public</span> virtual</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        require</span>(</span>_isApprovedOrOwner</span>(</span>msg.sender</span>,</span> tokenId</span>)</span>,</span> "Not authorized"</span>)</span>;</span></span>
        return</span> _clone</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>,</span> proofs</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> authorizeUsage</span>(</span>uint256</span> tokenId</span>,</span> address</span> to</span>)</span> public</span> virtual</span> {</span></span>
        require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        require</span>(</span>$</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>owner </span>==</span> msg.sender</span>,</span> "Not owner"</span>)</span>;</span></span>
</span>
        address</span>[</span>]</span> storage</span> authorizedUsers </span>=</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>authorizedUsers</span>;</span></span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> authorizedUsers</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            require</span>(</span>authorizedUsers</span>[</span>i</span>]</span> !=</span> to</span>,</span> "Already authorized"</span>)</span>;</span></span>
        }</span></span>
</span>
        authorizedUsers</span>.</span>push</span>(</span>to</span>)</span>;</span></span>
        emit</span> Authorization</span>(</span>msg.sender</span>,</span> to</span>,</span> tokenId</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> ownerOf</span>(</span>uint256</span> tokenId</span>)</span> public</span> view</span> virtual</span> returns</span> (</span>address</span>)</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        address</span> owner </span>=</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>owner</span>;</span></span>
        require</span>(</span>owner </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Token does not exist"</span>)</span>;</span></span>
        return</span> owner</span>;</span></span>
    }</span></span>
</span>
    function</span> authorizedUsersOf</span>(</span></span>
        uint256</span> tokenId</span></span>
    )</span> public</span> view</span> virtual</span> returns</span> (</span>address</span>[</span>]</span> memory</span>)</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "Token does not exist"</span>)</span>;</span></span>
        return</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>authorizedUsers</span>;</span></span>
    }</span></span>
</span>
    function</span> storageInfo</span>(</span></span>
        uint256</span> tokenId</span></span>
    )</span> public</span> view</span> virtual</span> returns</span> (</span>string</span> memory</span>)</span> {</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "Token does not exist"</span>)</span>;</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>storageInfo</span>;</span></span>
    }</span></span>
</span>
    function</span> _exists</span>(</span>uint256</span> tokenId</span>)</span> internal</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>owner </span>!=</span> address</span>(</span>0</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> intelligentDataOf</span>(</span></span>
        uint256</span> tokenId</span></span>
    )</span> public</span> view</span> virtual</span> returns</span> (</span>IntelligentData</span>[</span>]</span> memory</span>)</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "Token does not exist"</span>)</span>;</span></span>
        return</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>iDatas</span>;</span></span>
    }</span></span>
</span>
    function</span> approve</span>(</span>address</span> to</span>,</span> uint256</span> tokenId</span>)</span> public</span> virtual</span> {</span></span>
        address</span> owner </span>=</span> ownerOf</span>(</span>tokenId</span>)</span>;</span></span>
        require</span>(</span>to </span>!=</span> owner</span>,</span> "Approval to current owner"</span>)</span>;</span></span>
        require</span>(</span></span>
            msg.sender</span> ==</span> owner </span>||</span> isApprovedForAll</span>(</span>owner</span>,</span> msg.sender</span>)</span>,</span></span>
            "Not authorized"</span></span>
        )</span>;</span></span>
</span>
        _getAgentStorage</span>(</span>)</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>approvedUser </span>=</span> to</span>;</span></span>
        emit</span> Approval</span>(</span>owner</span>,</span> to</span>,</span> tokenId</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> setApprovalForAll</span>(</span>address</span> operator</span>,</span> bool</span> approved</span>)</span> public</span> virtual</span> {</span></span>
        require</span>(</span>operator </span>!=</span> msg.sender</span>,</span> "Approve to caller"</span>)</span>;</span></span>
        _getAgentStorage</span>(</span>)</span>.</span>operatorApprovals</span>[</span>msg.sender</span>]</span>[</span>operator</span>]</span> =</span> approved</span>;</span></span>
        emit</span> ApprovalForAll</span>(</span>msg.sender</span>,</span> operator</span>,</span> approved</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> getApproved</span>(</span></span>
        uint256</span> tokenId</span></span>
    )</span> public</span> view</span> virtual</span> returns</span> (</span>address</span>)</span> {</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "Token does not exist"</span>)</span>;</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>approvedUser</span>;</span></span>
    }</span></span>
</span>
    function</span> isApprovedForAll</span>(</span></span>
        address</span> owner</span>,</span></span>
        address</span> operator</span></span>
    )</span> public</span> view</span> virtual</span> returns</span> (</span>bool</span>)</span> {</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>operatorApprovals</span>[</span>owner</span>]</span>[</span>operator</span>]</span>;</span></span>
    }</span></span>
</span>
    function</span> delegateAccess</span>(</span>address</span> assistant</span>)</span> public</span> virtual</span> {</span></span>
        require</span>(</span>assistant </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
        _getAgentStorage</span>(</span>)</span>.</span>accessAssistants</span>[</span>msg.sender</span>]</span> =</span> assistant</span>;</span></span>
        emit</span> DelegateAccess</span>(</span>msg.sender</span>,</span> assistant</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> getDelegateAccess</span>(</span></span>
        address</span> user</span></span>
    )</span> public</span> view</span> virtual</span> returns</span> (</span>address</span>)</span> {</span></span>
        return</span> _getAgentStorage</span>(</span>)</span>.</span>accessAssistants</span>[</span>user</span>]</span>;</span></span>
    }</span></span>
</span>
    function</span> _isApprovedOrOwner</span>(</span></span>
        address</span> spender</span>,</span></span>
        uint256</span> tokenId</span></span>
    )</span> internal</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "Token does not exist"</span>)</span>;</span></span>
        address</span> owner </span>=</span> ownerOf</span>(</span>tokenId</span>)</span>;</span></span>
        return</span> (</span>spender </span>==</span> owner </span>||</span></span>
            getApproved</span>(</span>tokenId</span>)</span> ==</span> spender </span>||</span></span>
            isApprovedForAll</span>(</span>owner</span>,</span> spender</span>)</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> batchAuthorizeUsage</span>(</span></span>
        uint256</span> tokenId</span>,</span></span>
        address</span>[</span>]</span> calldata</span> users</span></span>
    )</span> public</span> virtual</span> {</span></span>
        require</span>(</span>users</span>.</span>length </span>></span> 0</span>,</span> "Empty users array"</span>)</span>;</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        require</span>(</span>$</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>owner </span>==</span> msg.sender</span>,</span> "Not owner"</span>)</span>;</span></span>
</span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> users</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            require</span>(</span>users</span>[</span>i</span>]</span> !=</span> address</span>(</span>0</span>)</span>,</span> "Zero address in users"</span>)</span>;</span></span>
            $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>authorizedUsers</span>.</span>push</span>(</span>users</span>[</span>i</span>]</span>)</span>;</span></span>
            emit</span> Authorization</span>(</span>msg.sender</span>,</span> users</span>[</span>i</span>]</span>,</span> tokenId</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
</span>
    function</span> revokeAuthorization</span>(</span>uint256</span> tokenId</span>,</span> address</span> user</span>)</span> public</span> virtual</span> {</span></span>
        AgentNFTStorage </span>storage</span> $ </span>=</span> _getAgentStorage</span>(</span>)</span>;</span></span>
        require</span>(</span>$</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>owner </span>==</span> msg.sender</span>,</span> "Not owner"</span>)</span>;</span></span>
        require</span>(</span>user </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Zero address"</span>)</span>;</span></span>
</span>
        address</span>[</span>]</span> storage</span> authorizedUsers </span>=</span> $</span>.</span>tokens</span>[</span>tokenId</span>]</span>.</span>authorizedUsers</span>;</span></span>
        bool</span> found </span>=</span> false</span>;</span></span>
</span>
        for</span> (</span>uint</span> i </span>=</span> 0</span>;</span> i </span><</span> authorizedUsers</span>.</span>length</span>;</span> i</span>+</span>+</span>)</span> {</span></span>
            if</span> (</span>authorizedUsers</span>[</span>i</span>]</span> ==</span> user</span>)</span> {</span></span>
                authorizedUsers</span>[</span>i</span>]</span> =</span> authorizedUsers</span>[</span></span>
                    authorizedUsers</span>.</span>length </span>-</span> 1</span></span>
                ]</span>;</span></span>
                authorizedUsers</span>.</span>pop</span>(</span>)</span>;</span></span>
                found </span>=</span> true</span>;</span></span>
                break</span>;</span></span>
            }</span></span>
        }</span></span>
</span>
        require</span>(</span>found</span>,</span> "User not authorized"</span>)</span>;</span></span>
        emit</span> AuthorizationRevoked</span>(</span>msg.sender</span>,</span> user</span>,</span> tokenId</span>)</span>;</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>

Proof Verification</strong>

Implementations must carefully verify all assertions in the proof</li>
Replay attacks must be prevented</li>
Different verification systems have their own security considerations, and distinct capabilities regarding key management: TEE can securely handle private keys from multi-parties, enabling direct data re-encryption. However, ZKP, due to its cryptographic nature, cannot process private keys from multi-parties. As a result, the re-encryption key is also from the prover (i.e., the sender), so tokens acquired through transfer or cloning must undergo re-encryption during their next update, otherwise the new update is still visible to the previous owner. This distinction in key handling capabilities affects how data transformations are managed during later usage</li>
</ul>
</li>
Data Privacy</strong>

Only hashes and sealed keys are stored on-chain, actual functional data must be stored and transmitted securely off-chain</li>
Key management is crucial for secure data access</li>
TEE verification system could support private key of the receiver, but ZKP verification system could not. So when using ZKP, the token transferred or cloned from other should be re-encrypted when next update, otherwise the new update is still visible to the previous owner</li>
</ul>
</li>
Access Control and State Management</strong>

Operations restricted to token owners only</li>
All data operations must maintain integrity and availability</li>
Critical state changes (sealed keys, ownership, permissions) must be atomic and verifiable</li>
</ul>
</li>
Sealed Executor</strong>

Although out of scope for this standard, the Sealed Executor is crucial for secure operation</li>
The Sealed Executor authenticates users and processes requests in a secure environment by verifying user signatures against authorized public keys for each tokenId</li>
The Sealed Executor can be implemented through a trusted party (where permitted), TEE or FHE</li>
Ensuring secure request processing and result delivery</li>
</ul>
</li>
</ol>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Add blob schedule to EL config files
2024-12-12T00:00:00+00:00
Abstract</h2>
Add a new object to client configuration files blobSchedule</code> which lists the
target blob count per block and max blob count per block for each fork.</p>
Motivation</h2>

ensure there is a way to dynamically adjust the target and max blob counts per
block</li>
ensure there is a way to dynamically adjust the blob base fee update fraction</li>
avoid complex handshake over engine API</li>
</ul>
Specification</h2>
Extend client configuration files with the object blobSchedule</code>, which has the
following shape:</p>
"</span>blobSchedule</span>"</span>: </span>{</span></span>
  "</span>cancun</span>"</span>:</span> {</span></span>
    "</span>target</span>"</span>:</span> 3</span>,</span></span>
    "</span>max</span>"</span>:</span> 6</span>,</span></span>
    "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span></span>
  }</span>,</span></span>
  "</span>prague</span>"</span>:</span> {</span></span>
    "</span>target</span>"</span>:</span> 6</span>,</span></span>
    "</span>max</span>"</span>:</span> 9</span>,</span></span>
    "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span>
  }</span></span>
}</span></span></code></pre>
Clients must configure the target, max and baseFeeUpdateFraction per-fork. The behavior
when the configuration is missing or incomplete for a fork is undefined. Clients
are free to choose how to handle this situation.</p>
Rationale</h2>
Although maintaining the target and max blob only in the consensus client is
desirable, we acknowledge the reality that execution clients need these values
for various activities. For example, the eth_feeHistory</code> RPC method returns a
field blobGasUsedRatio</code> that does require the max, even though the core
protocol doesn't specifically need such value. Passing this value over the
engine API every block seem overkill so we believe a configuration value is a
good middle ground. Additionally, the baseFeeUpdateFraction</code> parameter was added to adjust the responsiveness of blob gas pricing per fork.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
No security considerations found.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Diffusive Tokens
2024-12-07T00:00:00+00:00
Abstract</h2>
This ERC proposes a standard for a new type of fungible token, called Diffusive Tokens (DIFF)</strong>. Unlike traditional ERC-20</a> tokens, transferring DIFF tokens does not decrease the sender’s balance. Instead, it mints</em> new tokens directly to the recipient, increasing the total supply on every transfer action. A fixed native currency fee is charged per token transferred, and this fee is paid by the sender to the contract owner. The supply growth is limited by a maximum supply set by the owner. Token holders can also burn their tokens to reduce the total supply. These features enable a controlled, incentivized token distribution model that merges fungibility with a built-in economic mechanism.</p>
Motivation</h2>
Traditional ERC-20</a> tokens maintain a constant total supply and simply redistribute balances on transfers. While this model is widespread, certain use cases benefit from a token design that continuously expands supply during transfers, simulating a controlled "diffusion" of value. The Diffusive Token model may be suitable for representing claims on real-world goods (e.g., a product batch like iPhone 15 units), digital goods, or controlled asset distributions where initial token distribution and ongoing availability need to be managed differently.</p>
This model also includes a native currency fee per token transferred, incentivizing careful, value-driven transfers and providing a revenue stream for the token’s issuer. The maximum supply cap prevents unbounded inflation, ensuring long-term scarcity. The ability for owners to burn tokens to redeem underlying goods or services directly maps on-chain assets to real-world redemptions.</p>
Use Cases</strong>:</p>


Real-World Asset Backing</strong>: A manufacturer can issue DIFF tokens representing a batch of products (e.g., iPhones). Each token can be redeemed (burned) for one physical item.</p>
</li>

Fee-Driven Incentives</strong>: The transfer fee ensures that infinite minting by constant transferring is economically disincentivized. The fee also supports the token issuer or provides a funding mechanism.</p>
</li>
</ul>
Specification</h2>
Terminology</h3>

Diffusive Token</strong>: A fungible token unit that is minted on transfers.</li>
Max Supply</strong>: The maximum total supply the token can reach.</li>
Transfer Fee</strong>: A fee in native blockchain currency (e.g., ETH) that must be paid by the sender for each token transferred. The total fee = transferFee * amount</code>.</li>
Burn</strong>: The action of destroying tokens, reducing both the holder’s balance and the total supply.</li>
</ul>
Data Structures</h3>


Total Supply and Max Supply</strong>:</p>
uint256</span> public</span> totalSupply</span>;</span></span>
uint256</span> public</span> maxSupply</span>;</span></span></code></pre></li>

Transfer Fee</strong>:</p>
uint256</span> public</span> transferFee</span>;</span> //</span> fee per token transferred in wei</span></span>
address</span> public</span> owner</span>;</span></span></code></pre>
The owner</code> sets and updates transferFee</code> and maxSupply</code>.</p>
</li>
</ul>
Token Semantics</h3>


Minting on Transfer</strong>
When a transfer occurs from A</code> to B</code>:</p>

A</code> does not lose any tokens.</li>
B</code> receives newly minted tokens (increasing their balance and totalSupply).</li>
The totalSupply</code> increases by the transferred amount, but must not exceed maxSupply</code>.</li>
</ul>
</li>

Fixed Transfer Fee in Native Currency</strong>
Each transfer requires the sender to pay transferFee * amount</code> in the native currency. If msg.value</code> is insufficient, the transaction reverts.</p>
</li>

Maximum Supply</strong>
If a transfer would cause totalSupply + amount > maxSupply</code>, it must revert.</p>
</li>

Burning Tokens</strong>
Token holders can burn tokens to:</p>

Reduce their balance by the burned amount.</li>
Decrease totalSupply</code> by the burned amount.
This can map to redeeming underlying goods or simply deflating the token.</li>
</ul>
</li>
</ol>
Interface</h3>
The DIFF standard aligns partially with ERC-20</a>, but redefines certain behaviors:</p>
Core Functions:</strong></p>


function balanceOf(address account) external view returns (uint256);</code></p>
</li>

function transfer(address to, uint256 amount) external payable returns (bool);</code></p>

Modified behavior</strong>: Mints amount</code> tokens to to</code>, requires msg.value >= transferFee * amount</code>.</li>
</ul>
</li>

function burn(uint256 amount) external;</code></p>

Reduces sender’s balance and totalSupply</code>.</li>
</ul>
</li>
</ul>
Administration Functions (Owner Only):</strong></p>


function setMaxSupply(uint256 newMax) external;</code></p>
</li>

function setTransferFee(uint256 newFee) external;</code></p>
</li>

function withdrawFees(address payable recipient) external;</code></p>

Withdraws accumulated native currency fees.</li>
</ul>
</li>
</ul>
Optional Approval Interface (For Compatibility):</strong></p>


function approve(address spender, uint256 amount) external returns (bool);</code></p>
</li>

function transferFrom(address from, address to, uint256 amount) external payable returns (bool);</code></p>

Modified behavior</strong>: Similar to transfer</code>, but uses allowance and still mints tokens to to</code> rather than redistributing from from</code>.</li>
</ul>
</li>
</ul>
Events</h3>


event Transfer(address indexed from, address indexed to, uint256 amount);</code></p>
Emitted when tokens are minted to to</code> via a transfer call.</p>
</li>

event Burn(address indexed burner, uint256 amount);</code></p>
Emitted when amount</code> of tokens are burned from an address.</p>
</li>

event FeeUpdated(uint256 newFee);</code></p>
Emitted when the owner updates the transferFee</code>.</p>
</li>

event MaxSupplyUpdated(uint256 newMaxSupply);</code></p>
Emitted when the owner updates maxSupply</code>.</p>
</li>
</ul>
Compliance with ERC-20</h3>
The DIFF standard implements the ERC-20 interface but significantly alters the transfer</code> and transferFrom</code> semantics:</p>

Fungibility</strong>: Each token unit is identical and divisible as in ERC-20.</li>
Balances and Transfers</strong>: The balanceOf</code> function works as normal. However, transfer</code> and transferFrom</code> no longer redistribute tokens. Instead, they mint new tokens (up to maxSupply</code>).</li>
Approvals</strong>: The approve</code> and transferFrom</code> functions remain, but their logic is unconventional since the sender’s balance is never reduced by transfers.</li>
</ul>
While the DIFF standard can be seen as ERC-20 compatible at the interface level, the underlying economics differ substantially.</p>
Rationale</h2>
Design Decisions</strong>:</p>


Unlimited Minting vs. Max Supply</strong>: Allowing minting on every transfer provides a “diffusive” spread of tokens. The maxSupply</code> prevents uncontrolled inflation.</p>
</li>

Burn Mechanism</strong>: Enables redemption or deflation as tokens are taken out of circulation.</p>
</li>

Owner Controls</strong>: The owner (e.g., issuer) can adjust fees and max supply, maintaining flexibility as market conditions change.</p>
</li>
</ul>
Backwards Compatibility</h2>
The DIFF standard is interface-compatible with ERC-20 but not behaviorally identical. Any system integrating DIFF tokens should understand the difference in minting on transfer.</p>

Wallets and Exchanges</strong>: Most ERC-20 compatible tools can display balances and initiate transfers. However, the unusual economics (mint on transfer) may confuse users and pricing mechanisms.</li>
Allowances and TransferFrom</strong>: Still implemented for interoperability, but the expected logic (debiting from</code> balance) does not apply.</li>
</ul>
Test Cases</h2>


Initial Conditions</strong>:</p>

Deploy contract with maxSupply = 1,000,000 DIFF</code>, transferFee = 0.001 ETH</code>.</li>
totalSupply = 0</code>.</li>
Owner sets parameters and verifies via maxSupply()</code> and transferFee()</code> getters.</li>
</ul>
</li>

Minting on Transfer</strong>:</p>

User A calls transfer(B, 100)</code> with msg.value = 0.1 ETH</code> (assuming transferFee = 0.001 ETH</code>).</li>
Check balances[B] == 100</code>, totalSupply == 100</code>.</li>
Check that the contract now holds 0.1 ETH from the fee.</li>
</ul>
</li>

Exceeding Max Supply</strong>:</p>

If totalSupply = 999,950</code> and someone tries to transfer 100 tokens, causing totalSupply</code> to exceed 1,000,000</code>, the transaction reverts.</li>
</ul>
</li>

Burning Tokens</strong>:</p>

User B calls burn(50)</code>.</li>
Check balances[B] == 50</code>, totalSupply == 50</code> less than before.</li>
Burn</code> event emitted.</li>
</ul>
</li>

Updating Fee and Withdrawing Funds</strong>:</p>

Owner calls setTransferFee(0.002 ETH)</code>.</li>
FeeUpdated</code> event emitted.</li>
Owner calls withdrawFees(ownerAddress)</code>.</li>
Check that ownerAddress</code> receives accumulated fees.</li>
</ul>
</li>
</ol>
Reference Implementation</h2>
A reference implementation is provided under the asset folder in the EIPs repository. The implementation includes:</p>

A basic contract implementing the DIFF standard.</li>
</ul>
contract</span> DiffusiveToken</span> {</span></span>
    //</span> -----------------------------------------</span></span>
    //</span> State Variables</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    string</span> public</span> name</span>;</span></span>
    string</span> public</span> symbol</span>;</span></span>
    uint8</span> public</span> decimals</span>;</span></span>
</span>
    uint256</span> public</span> totalSupply</span>;</span></span>
    uint256</span> public</span> maxSupply</span>;</span></span>
    uint256</span> public</span> transferFee</span>;</span> //</span> Fee per token transferred in wei</span></span>
</span>
    address</span> public</span> owner</span>;</span></span>
</span>
    //</span> -----------------------------------------</span></span>
    //</span> Events</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    event</span> Transfer</span>(</span>address</span> indexed</span> from</span>, </span>address</span> indexed</span> to</span>, </span>uint256</span> amount</span>)</span>;</span></span>
    event</span> Burn</span>(</span>address</span> indexed</span> burner</span>, </span>uint256</span> amount</span>)</span>;</span></span>
    event</span> FeeUpdated</span>(</span>uint256</span> newFee</span>)</span>;</span></span>
    event</span> MaxSupplyUpdated</span>(</span>uint256</span> newMaxSupply</span>)</span>;</span></span>
    event</span> Approval</span>(</span>address</span> indexed</span> owner</span>, </span>address</span> indexed</span> spender</span>, </span>uint256</span> value</span>)</span>;</span></span>
</span>
    //</span> -----------------------------------------</span></span>
    //</span> Modifiers</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    modifier</span> onlyOwner</span>(</span>)</span> {</span></span>
        require</span>(</span>msg.sender</span> ==</span> owner</span>,</span> "DiffusiveToken: caller is not the owner"</span>)</span>;</span></span>
        _</span>;</span></span>
    }</span></span>
</span>
    //</span> -----------------------------------------</span></span>
    //</span> Constructor</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Constructor sets the initial parameters for the Diffusive Token.</span></span>
     * </span>@param</span> _name</span> Token name</span></span>
     * </span>@param</span> _symbol</span> Token symbol</span></span>
     * </span>@param</span> _decimals</span> Decimal places</span></span>
     * </span>@param</span> _maxSupply</span> The max supply of tokens that can ever exist</span></span>
     * </span>@param</span> _transferFee</span> Initial fee per token transferred in wei</span></span>
     */</span></span>
    constructor</span>(</span></span>
        string</span> memory</span> _name</span>,</span></span>
        string</span> memory</span> _symbol</span>,</span></span>
        uint8</span> _decimals</span>,</span></span>
        uint256</span> _maxSupply</span>,</span></span>
        uint256</span> _transferFee</span></span>
    )</span> {</span></span>
        name </span>=</span> _name</span>;</span></span>
        symbol </span>=</span> _symbol</span>;</span></span>
        decimals </span>=</span> _decimals</span>;</span></span>
        maxSupply </span>=</span> _maxSupply</span>;</span></span>
        transferFee </span>=</span> _transferFee</span>;</span></span>
        owner </span>=</span> msg.sender</span>;</span></span>
        totalSupply </span>=</span> 0</span>;</span> //</span> Initially, no tokens are minted</span></span>
    }</span></span>
</span>
    //</span> -----------------------------------------</span></span>
    //</span> External and Public Functions</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Returns the token balance of the given address.</span></span>
     * </span>@param</span> account</span> The address to query</span></span>
     */</span></span>
    function</span> balanceOf</span>(</span>address</span> account</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        return</span> balances</span>[</span>account</span>]</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Transfers `amount` tokens to address `to`, minting new tokens in the process.</span></span>
     * </span>@dev</span> Requires payment of native currency: transferFee * amount.</span></span>
     * </span>@param</span> to</span> Recipient address</span></span>
     * </span>@param</span> amount</span> Number of tokens to transfer</span></span>
     * </span>@return</span> True</span> if successful</span></span>
     */</span></span>
    function</span> transfer</span>(</span>address</span> to</span>,</span> uint256</span> amount</span>)</span> external</span> payable</span> returns</span> (</span>bool</span>)</span> {</span></span>
        require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "DiffusiveToken: transfer to zero address"</span>)</span>;</span></span>
        require</span>(</span>amount </span>></span> 0</span>,</span> "DiffusiveToken: amount must be greater than zero"</span>)</span>;</span></span>
</span>
        uint256</span> requiredFee </span>=</span> transferFee </span>*</span> amount</span>;</span></span>
        require</span>(</span>msg</span>.</span>value </span>></span>=</span> requiredFee</span>,</span> "DiffusiveToken: insufficient fee"</span>)</span>;</span></span>
</span>
        //</span> Check max supply limit</span></span>
        require</span>(</span>totalSupply </span>+</span> amount </span><</span>=</span> maxSupply</span>,</span> "DiffusiveToken: would exceed max supply"</span>)</span>;</span></span>
</span>
        //</span> Mint new tokens to `to`</span></span>
        balances</span>[</span>to</span>]</span> +</span>=</span> amount</span>;</span></span>
        totalSupply </span>+</span>=</span> amount</span>;</span></span>
</span>
        emit</span> Transfer</span>(</span>msg.sender</span>,</span> to</span>,</span> amount</span>)</span>;</span></span>
        return</span> true</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Burns `amount` tokens from the caller's balance, decreasing total supply.</span></span>
     * </span>@param</span> amount</span> The number of tokens to burn</span></span>
     */</span></span>
    function</span> burn</span>(</span>uint256</span> amount</span>)</span> external</span> {</span></span>
        require</span>(</span>amount </span>></span> 0</span>,</span> "DiffusiveToken: burn amount must be greater than zero"</span>)</span>;</span></span>
        require</span>(</span>balances</span>[</span>msg.sender</span>]</span> ></span>=</span> amount</span>,</span> "DiffusiveToken: insufficient balance"</span>)</span>;</span></span>
</span>
        balances</span>[</span>msg.sender</span>]</span> -</span>=</span> amount</span>;</span></span>
        totalSupply </span>-</span>=</span> amount</span>;</span></span>
</span>
        emit</span> Burn</span>(</span>msg.sender</span>,</span> amount</span>)</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Approves `spender` to transfer up to `amount` tokens on behalf of `msg.sender`.</span></span>
     * </span>@param</span> spender</span> The address authorized to spend</span></span>
     * </span>@param</span> amount</span> The max amount they can spend</span></span>
     */</span></span>
    function</span> approve</span>(</span>address</span> spender</span>,</span> uint256</span> amount</span>)</span> external</span> returns</span> (</span>bool</span>)</span> {</span></span>
        require</span>(</span>spender </span>!=</span> address</span>(</span>0</span>)</span>,</span> "DiffusiveToken: approve to zero address"</span>)</span>;</span></span>
        allowances</span>[</span>msg.sender</span>]</span>[</span>spender</span>]</span> =</span> amount</span>;</span></span>
        emit</span> Approval</span>(</span>msg.sender</span>,</span> spender</span>,</span> amount</span>)</span>;</span></span>
        return</span> true</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Returns the current allowance of `spender` for `owner`.</span></span>
     * </span>@param</span> _owner</span> The owner of the tokens</span></span>
     * </span>@param</span> _spender</span> The address allowed to spend the tokens</span></span>
     */</span></span>
    function</span> allowance</span>(</span>address</span> _owner</span>,</span> address</span> _spender</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        return</span> allowances</span>[</span>_owner</span>]</span>[</span>_spender</span>]</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Transfers `amount` tokens from `from` to `to` using the allowance mechanism.</span></span>
     * </span>@dev</span> The `from` account does not lose tokens; this still mints to `to`.</span></span>
     * </span>@param</span> from</span> The address from which the allowance has been given</span></span>
     * </span>@param</span> to</span> The recipient address</span></span>
     * </span>@param</span> amount</span> The number of tokens to transfer (mint)</span></span>
     */</span></span>
    function</span> transferFrom</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint256</span> amount</span>)</span> external</span> payable</span> returns</span> (</span>bool</span>)</span> {</span></span>
        require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "DiffusiveToken: transfer to zero address"</span>)</span>;</span></span>
        require</span>(</span>amount </span>></span> 0</span>,</span> "DiffusiveToken: amount must be greater than zero"</span>)</span>;</span></span>
</span>
        uint256</span> allowed </span>=</span> allowances</span>[</span>from</span>]</span>[</span>msg.sender</span>]</span>;</span></span>
        require</span>(</span>allowed </span>></span>=</span> amount</span>,</span> "DiffusiveToken: allowance exceeded"</span>)</span>;</span></span>
</span>
        //</span> Deduct from allowance</span></span>
        allowances</span>[</span>from</span>]</span>[</span>msg.sender</span>]</span> =</span> allowed </span>-</span> amount</span>;</span></span>
</span>
        uint256</span> requiredFee </span>=</span> transferFee </span>*</span> amount</span>;</span></span>
        require</span>(</span>msg</span>.</span>value </span>></span>=</span> requiredFee</span>,</span> "DiffusiveToken: insufficient fee"</span>)</span>;</span></span>
</span>
        //</span> Check max supply</span></span>
        require</span>(</span>totalSupply </span>+</span> amount </span><</span>=</span> maxSupply</span>,</span> "DiffusiveToken: would exceed max supply"</span>)</span>;</span></span>
</span>
        //</span> Mint tokens to `to`</span></span>
        balances</span>[</span>to</span>]</span> +</span>=</span> amount</span>;</span></span>
        totalSupply </span>+</span>=</span> amount</span>;</span></span>
</span>
        emit</span> Transfer</span>(</span>from</span>,</span> to</span>,</span> amount</span>)</span>;</span></span>
        return</span> true</span>;</span></span>
    }</span></span>
</span>
    //</span> -----------------------------------------</span></span>
    //</span> Owner Functions</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Updates the maximum supply of tokens. Must be >= current totalSupply.</span></span>
     * </span>@param</span> newMaxSupply</span> The new maximum supply</span></span>
     */</span></span>
    function</span> setMaxSupply</span>(</span>uint256</span> newMaxSupply</span>)</span> external</span> onlyOwner</span> {</span></span>
        require</span>(</span>newMaxSupply </span>></span>=</span> totalSupply</span>,</span> "DiffusiveToken: new max < current supply"</span>)</span>;</span></span>
        maxSupply </span>=</span> newMaxSupply</span>;</span></span>
        emit</span> MaxSupplyUpdated</span>(</span>newMaxSupply</span>)</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Updates the per-token transfer fee.</span></span>
     * </span>@param</span> newFee</span> The new fee in wei per token transferred</span></span>
     */</span></span>
    function</span> setTransferFee</span>(</span>uint256</span> newFee</span>)</span> external</span> onlyOwner</span> {</span></span>
        transferFee </span>=</span> newFee</span>;</span></span>
        emit</span> FeeUpdated</span>(</span>newFee</span>)</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Allows the owner to withdraw accumulated native currency fees.</span></span>
     * </span>@param</span> recipient</span> The address that will receive the withdrawn fees</span></span>
     */</span></span>
    function</span> withdrawFees</span>(</span>address</span> payable</span> recipient</span>)</span> external</span> onlyOwner</span> {</span></span>
        require</span>(</span>recipient </span>!=</span> address</span>(</span>0</span>)</span>,</span> "DiffusiveToken: withdraw to zero address"</span>)</span>;</span></span>
        uint256</span> balance </span>=</span> address</span>(</span>this</span>)</span>.</span>balance</span>;</span></span>
        (</span>bool</span> success</span>,</span> )</span> =</span> recipient</span>.</span>call</span>{</span>value</span>:</span> balance</span>}</span>(</span>""</span>)</span>;</span></span>
        require</span>(</span>success</span>,</span> "DiffusiveToken: withdrawal failed"</span>)</span>;</span></span>
    }</span></span>
</span>
    //</span> -----------------------------------------</span></span>
    //</span> Fallback and Receive</span></span>
    //</span> -----------------------------------------</span></span>
</span>
    //</span> Allows the contract to receive Ether.</span></span>
    receive</span>(</span>)</span> external</span> payable</span> {</span>}</span></span>
}</span></span></code></pre>

Interfaces and helper contracts for testing and demonstration purposes.</li>
</ul>
Security Considerations</h2>

Reentrancy</strong>: Handle fee transfers using the Checks-Effects-Interactions pattern. Consider ReentrancyGuard</code> from OpenZeppelin to prevent reentrant calls.</li>
Overflow/Underflow</strong>: Solidity 0.8.x guards against this by default.</li>
Contract Balance Management</strong>: Ensure enough native currency is sent to cover fees. Revert on insufficient fees.</li>
Access Control</strong>: Only the owner can update transferFee</code> and maxSupply</code>. Use proper onlyOwner</code> modifiers.</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Transaction Gas Limit Cap
2024-11-23T00:00:00+00:00
Abstract</h2>
This proposal introduces a protocol-level cap on the maximum gas usage per transaction to 16,777,216 (2^24) gas. By implementing this limit, Ethereum can enhance its resilience against certain DoS vectors, improve network stability, and provide more predictability to transaction processing costs, especially in the context of increasing the gas limit.</p>
Motivation</h2>
Currently, transactions can theoretically consume up to the entire block gas limit, which poses several risks:</p>

DoS Attacks</strong>: A single transaction consuming most or all of the block gas can result in uneven load distribution and impact network stability.</li>
State Bloat Risks</strong>: High-gas transactions often result in larger state changes, increasing the burden on nodes and exacerbating the Ethereum state growth problem.</li>
Validation Overhead</strong>: High-gas transactions can lead to longer block verification times, negatively impacting user experience and network decentralization.</li>
</ol>
By limiting individual transactions to a maximum of 16,777,216 gas, we aim to:</p>

Reduce the risks of single-transaction DoS attacks.</li>
Promote fairer gas allocation across transactions within a block.</li>
Ensure better synchronization among nodes by mitigating extreme block validation times.</li>
</ul>
Specification</h2>
Gas Cap</h3>

Enforce a protocol-level maximum of 16,777,216 gas (2^24)</strong> for any single transaction.</li>
This cap applies regardless of the block gas limit set by miners or validators.</li>
Transactions specifying gas limits higher than 16,777,216 gas will be rejected with an appropriate error code (e.g., MAX_GAS_LIMIT_EXCEEDED</code>).</li>
</ul>
Changes to EVM Behavior</h3>

Txpool Validation</strong>: During transaction validation, if the gasLimit</code> specified by the sender exceeds 16,777,216, the transaction is invalidated (not included in the txpool).</li>
Block Validation</strong>: As part of block validation before processing, any block having a transaction with gasLimit</code> > 16,777,216 is deemed invalid and rejected.</li>
</ol>
Protocol Adjustment</h3>

The GAS_LIMIT</code> parameter for transactions will be capped in client implementations at 16,777,216.</li>
This cap is independent</strong> of the block gas limit, which exceeds this value.</li>
</ul>
Rationale</h2>
Why 16,777,216 (2^24)?</h3>
The proposed cap of 16,777,216 gas (2^24) provides a clean power-of-two boundary that simplifies implementation while still being large enough to accommodate most complex transactions, including contract deployments and advanced DeFi interactions. This value represents approximately half of typical block sizes (30-40 million gas), ensuring multiple transactions can fit within each block.</p>
Compatibility with Current Gas Dynamics</h3>

Backward Compatibility</strong>: Transactions with gas usage below 16,777,216 remain unaffected. Existing tooling and dApps need only minor updates to enforce the new cap.</li>
Impact on Validators</strong>: Validators can continue to process blocks with a gas limit exceeding 16,777,216, provided individual transactions adhere to the cap.</li>
</ul>
Backwards Compatibility</h2>
This change is not backward-compatible</strong> with transactions that specify gas limits exceeding 16,777,216. Transactions with such high limits will need to be split into smaller operations. This adjustment is expected to impact a minimal number of users and dApps, as most transactions today fall well below the proposed cap.</p>
An empirical analysis</a> has been conducted to assess the potential impact of this change.</p>
Security Considerations</h2>

DoS Mitigation</strong>: A fixed cap reduces the risk of DoS attacks caused by excessively high-gas transactions.</li>
Block Verification Stability</strong>: By capping individual transactions, the validation of blocks becomes more predictable and uniform.</li>
Edge Cases</strong>: Certain highly complex transactions, such as large contract deployments, may require re-architecting to fit within the 16,777,216 gas cap.</li>
</ol>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Access Control Registry
2024-11-19T00:00:00+00:00
Abstract</h2>
The Access Control Registry (ACR) standard 
The core of the standard includes:</p> 
  Registration and Unregistration</strong>: </li> 
 Role Management</strong>: </li> 
 Role Verification</strong>: </li> </ul> 
By centralizing access control management, 
Motivation</h2> As decentralized applications (dApps) Current practices involve bespoke implementations, 
The advantages of using the provided 
Structured smart contracts management Ad-hoc access-control provision of a protocol. Ability to specify custom access control 
Specification</h2> The key words “MUST”, “MUST NOT”, 
The AccessControlRegistry</code> 
Additionally, the AccessControlRegistry 
                    )</span><             )</span><                   )</span>            )</span>    </span><&            )</span>           )</span>}</span>< The IAccessControlRegistry</code> 
Contract registerContract(address 
unRegisterContract(address 
Role Management</ grantRole(address[] memory 
revokeRole(address[] 
Role Checking</h3> getRoleInfo(address targetContract, 
Contract getContractInfo(address 
Events</h3> ContractRegistered(address 
ContractUnregistered(address 
RoleGranted(address indexed 
RoleRevoked(address indexed 
Reference The register</code> function The grantRole</code> and revok 
</span>  </span> </span>           }</span>< </span>   </span>   </span>   </span>               )</sp      }</span>< </span>              )</sp      }</span>< </span>         }</span>< </span>         }</span>< </span>     </span>          ContractInfo           }</sp </span>          contractIn         contractIn </span>      }</span>< </span>           {</span><         ContractInfo         contractIn         contractIn </span>      }</span>< </span>             )</span>            )</sp </span>  </span>            }</sp     }</span>< </span>             )</span>            )</sp </span>  </span>            }</sp     }</span>< </span>            {</span><         ContractInfo      }</span>< </span>              )</span>     }</span>< </span>          )</span><         {</span><         _contractR      }</span>< </span>          )</span><         {</span><            )</sp         _contractR      }</span>< </span>           }</span>< }</span>< </span></code> There are a few design decisions that 
Decentralized No Central Owner</strong>: 
Efficient Mapping Utilization</strong>: 
Role Bulk Operations</strong>: 
Robust Admin-Only Operations</strong>: 
Valid Address Checks</strong>: 
Active Contract Checks</strong>: 
Transparent Event Logging</strong>: 
Security The AccessControlRegistry</code> 
Admin-Only Restrictions</strong>: 
Active Contract Checks</strong>: 
Event Logging</strong>: 
Copyright</h2> Copyright and related rights waived 
  Expirable ERC-20
 2024-11-13T00:00:00+00:00

defines a universal interface for managing role-based access control across multiple smart contracts. This standard introduces a centralized registry system allowing access control management for multiple smart contracts. The single access-control registry smart contract manages the user roles across multiple contracts, and can be queryed for contract-specific role information. Additionally, the ACR standard provides functionality to grant and revoke roles for specific accounts, either individually or in bulk, ensuring that only authorized users can perform specific actions within a specific contract.</p> Contracts can register with the ACR, specifying an admin who can manage roles within the contract. Contracts can also be unregistered when they are no longer active.</p> Admins can grant or revoke roles for accounts, either individually or in batches, ensuring fine-grained control over who can perform what actions within a contract.</p> Any account can verify if another account has a specific role in a registered contract, providing transparency and facilitating easier integration with other systems.</p> the ACR standard aims to reduce redundancy, minimize errors in access control logic, and provide a clear and standardized approach to role management across smart contracts. This improves security and maintainability, making it easier for developers to implement robust access control mechanisms in their applications.</p> grow in complexity, managing access control across multiple smart contracts becomes increasingly difficult. leading to redundancy and potential security flaws. A standardized approach for managing roles and permissions will ensure better interoperability, security, and transparency. By providing a unified interface for registering contracts and managing roles, this standard simplifies development, ensures consistency and enhances security. It facilitates easier integration and auditing, fostering a more robust and interoperable ecosystem.</p> system might be:</p> via specialized contracts. rules to maintain the protocol.</p> “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p> contract provides a standardized interface for managing access control in Ethereum smart contracts. It includes functions to register and unregister contracts, grant and revoke roles for specific contracts, and check if an account has a particular role in a registered contract. Events are emitted for contract registration, unregistration, role grants, and role revocations, ensuring transparency and traceability of access control changes.</p> MUST reject the registration of zero addresses.</p> class="giallo-l">pragma</span> solidity</span> 0.8.23</span>;</span></span> z-type">interface</span> IAccessControlRegistry</span> {</span></span> //</span> Emitted when a contract is registered.</span></span> //</span> @param _contract The address of the registered contract.</span></span> //</span> @param _admin The address of the admin for the registered contract.</span></span> event</span> ContractRegistered</span>(</span>address</span> indexed</span> _contract</span>, </span>address</span> indexed</span> _admin</span>)</span>;</span></span> //</span> Emitted when a contract is unregistered.</span></span> //</span> @param _contract The address of the unregistered contract.</span></span> //</span> @param _admin The address who unregistered the contract</span></span> event</span> ContractUnregistered</span>(</span>address</span> indexed</span> _contract</span>, </span>address</span> indexed</span> _admin</span>)</span>;</span></span> //</span> Emitted when a role is granted to an account for a contract.</span></span> //</span> @param targetContract The address of the contract.</span></span> //</span> @param role The role being granted.</span></span> //</span> @param account The address of the account.</span></span> event</span> RoleGranted</span>(</span></span> address</span> indexed</span> targetContract</span>,</span></span> bytes32</span> indexed</span> role</span>,</span></span> address</span> indexed</span> account</span></span> span>;</span></span> //</span> Emitted when a role is revoked from an account for a contract.</span></span> //</span> @param targetContract The address of the contract.</span></span> //</span> @param role The role being revoked.</span></span> //</span> @param account The address of the account.</span></span> event</span> RoleRevoked</span>(</span></span> address</span> indexed</span> targetContract</span>,</span></span> bytes32</span> indexed</span> role</span>,</span></span> address</span> indexed</span> account</span></span> span>;</span></span> //</span> Registers a contract with the given admin.</span></span> //</span> @param _admin The address of the admin for the registered contract.</span></span> function</span> registerContract</span>(</span>address</span> _admin</span>)</span> external</span>;</span></span> //</span> Unregisters a contract.</span></span> //</span> @param _contract The address of the contract to unregister.</span></span> function</span> unRegisterContract</span>(</span>address</span> _contract</span>)</span> external</span>;</span></span> //</span> Grants roles to multiple accounts for multiple contracts.</span></span> //</span> @param targetContracts An array of contract addresses to which roles will be granted.</span></span> //</span> @param roles An array of roles to be granted.</span></span> //</span> @param accounts An array of accounts to be granted the roles.</span></span> function</span> grantRole</span>(</span></span> address</span>[</span>]</span> memory</span> targetContracts</span>,</span></span> bytes32</span>[</span>]</span> memory</span> roles</span>,</span></span> address</span>[</span>]</span> memory</span> accounts</span></span> class="z-storage z-type"> external</span>;</span></span> //</span> Revokes roles from multiple accounts for multiple contracts.</span></span> //</span> @param targetContracts An array of contract addresses from which roles will be revoked.</span></span> //</span> @param roles An array of roles to be revoked.</span></span> //</span> @param accounts An array of accounts from which the roles will be revoked.</span></span> function</span> revokeRole</span>(</span></span> address</span>[</span>]</span> memory</span> targetContracts</span>,</span></span> bytes32</span>[</span>]</span> memory</span> roles</span>,</span></span> address</span>[</span>]</span> memory</span> accounts</span></span> class="z-storage z-type"> external</span>;</span></span> #x2F;span> //</span>Gets the information of a registered contract.</span></span> //</span>@param _contract The address of the contract to get the information.</span></span> //</span>@return isActive Whether the contract is active.</span></span> //</span>@return admin The address of the admin for the contract.</span></span> //</span>MUST revert if the registered contract doesn't exist</span></span> function</span> getContractInfo</span>(</span></span> address</span> _contract</span></span> class="z-storage z-type"> external</span> view</span> returns</span> (</span>bool</span> isActive</span>,</span> address</span> admin</span>)</span>;</span></span> //</span> Gets the information of a registered contract.</span></span> //</span> @param _contract The address of the contract to get the information.</span></span> //</span> @return isActive Whether the contract is active.</span></span> //</span> @return admin The address of the admin for the contract.</span></span> //</span> MUST revert if the registered contract doesn't exist`</span></span> function</span> getRoleInfo</span>(</span></span> address</span> _contract</span></span> class="z-storage z-type"> external</span> view</span> returns</span> (</span>bool</span> isActive</span>,</span> address</span> admin</span>)</span>;</span></span> F;span></code></pre>Rationale</h2> interface aims to provide a standardized way to manage access control across multiple contracts within the ecosystem. By defining a clear structure and set of events, this interface helps streamline the process of registering, unregistering, and managing roles for contracts. The rationale for each function and event is as follows:</p> Registration and Unregistration</h3> _admin)</code></strong>: This function allows the registration of a new contract along with its admin address. This is crucial for initializing the access control settings for a contract and ensuring that there is an accountable admin who can manage roles and permissions.</p> _contract)</code></strong>: This function enables the removal of a contract from the registry. Unregistering a contract is important when a contract is no longer in use or needs to be decommissioned to prevent unauthorized access.</p> h3> targetContracts, bytes32[] memory roles, address[] memory accounts)</code></strong>: This function allows the assignment of roles to multiple accounts for multiple contracts in a single transaction. This bulk operation is designed to reduce the gas costs and simplify the process of role assignment in large systems with numerous contracts and users.</p> memory targetContracts, bytes32[] memory roles, address[] memory accounts)</code></strong>: Similar to grantRole</code>, this function facilitates the revocation of roles from multiple accounts across multiple contracts in a single transaction. This ensures efficient management of permissions, especially in scenarios where many users need their roles updated simultaneously.</p> address account, bytes32 role)</code></strong>: This view function allows the verification of whether a particular account holds a specific role for a given contract. This is essential for ensuring that operations requiring specific permissions are performed only by authorized users.</p> Information Retrieval</h3> _contract)</code></strong>: This function provides the ability to retrieve the status and admin information of a registered contract. It enhances transparency and allows administrators and users to easily query the status and management of any contract within the registry.</p> indexed _contract, address indexed _admin)</code></strong>: Emitted when a new contract is registered, this event ensures that there is a public record of contract registrations, facilitating auditability and transparency.</p> indexed _contract, address indexed _admin)</code></strong>: Emitted when a contract is unregistered, this event serves to notify the system and its users of the removal of a contract from the registry, which is critical for maintaining an up-to-date and accurate registry.</p> targetContract, bytes32 indexed role, address indexed account)</code></strong>: Emitted when a role is granted to an account, this event provides a public log that can be used to track role assignments and changes, ensuring that role grants are transparent and verifiable.</p> targetContract, bytes32 indexed role, address indexed account)</code></strong>: Emitted when a role is revoked from an account, this event similarly ensures that role revocations are publicly logged and traceable, supporting robust access control management.</p> Implementation</h2> must be invoked from the registering smart contract. eRole</code> functions must be invoked either from the registered contract or the admin of the registered contract.</p> class="giallo-l">pragma</span> solidity</span> 0.8.23</span>;</span></span> import</span> "./IAccessControlRegistry.sol"</span>;</span></span> z-type">contract</span> AccessControlRegistry</span> is</span> IAccessControlRegistry</span> {</span></span> //</span> Contains information about a registered contract.</span></span> //</span> @param isActive Indicates whether the contract is active.</span></span> //</span> @param admin The address of the admin for the registered contract.</span></span> struct</span> ContractInfo</span> {</span></span> bool</span> isActive</span>;</span></span> address</span> admin</span>;</span></span> /span> //</span> Mapping to store information of registered contracts</span></span> mapping</span>(</span>address</span> =></span> ContractInfo</span>)</span> public</span> contracts</span>;</span></span> //</span> Mapping to track roles assigned to accounts for specific contracts</span></span> mapping</span>(</span>address</span> =></span> mapping</span>(</span>address</span> =></span> mapping</span>(</span>bytes32</span> =></span> bool</span>)</span>)</span>)</span> public</span> _contractRoles</span>;</span></span> //</span> Custom error to handle duplicate registration attempts</span></span> error</span> ContractAlreadyRegistered</span>(</span>)</span>;</span></span> //</span> Modifier to check if the caller is an admin or the contract itself</span></span> modifier</span> onlyAdminOrContract</span>(</span>address</span> _contract</span>)</span> {</span></span> require</span>(</span></span> _isAdmin</span>(</span>_contract</span>,</span> msg.sender</span>)</span> ||</span> </span></span> (</span>contracts</span>[</span>msg.sender</span>]</span>.</span>isActive </span>&&</span> msg.sender</span> ==</span> _contract</span>)</span>,</span></span> "Caller is not admin nor contract"</span></span> an>;</span></span> _</span>;</span></span> /span> //</span> Modifier to check if the caller is an admin of the contract</span></span> modifier</span> onlyAdmin</span>(</span>address</span> _contract</span>)</span> {</span></span> require</span>(</span></span> _isAdmin</span>(</span>_contract</span>,</span> msg.sender</span>)</span>,</span></span> "Caller is not an admin"</span></span> an>;</span></span> _</span>;</span></span> /span> //</span> Modifier to ensure the contract is active</span></span> modifier</span> onlyActiveContract</span>(</span>address</span> _contract</span>)</span> {</span></span> require</span>(</span>contracts</span>[</span>_contract</span>]</span>.</span>isActive</span>,</span> "Contract not registered"</span>)</span>;</span></span> _</span>;</span></span> /span> //</span> Modifier to validate if the provided address is non-zero</span></span> modifier</span> validAddress</span>(</span>address</span> addr</span>)</span> {</span></span> require</span>(</span>addr </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Invalid address"</span>)</span>;</span></span> _</span>;</span></span> /span> //</span> Registers a contract with the given admin</span></span> //</span> _admin: Address of the admin to register</span></span> function</span> registerContract</span>(</span>address</span> _admin</span>)</span> external</span> validAddress</span>(</span>_admin</span>)</span> {</span></span> address</span> _contract </span>=</span> msg.sender</span>;</span></span> //</span> Check if the contract is already registered</span></span> </span>storage</span> contractInfo </span>=</span> contracts</span>[</span>_contract</span>]</span>;</span></span> if</span> (</span>contractInfo</span>.</span>isActive</span>)</span> {</span></span> revert</span> ContractAlreadyRegistered</span>(</span>)</span>;</span></span> an></span> //</span> Register the contract with the provided admin</span></span> fo</span>.</span>isActive </span>=</span> true</span>;</span></span> fo</span>.</span>admin </span>=</span> _admin</span>;</span></span> emit</span> ContractRegistered</span>(</span>_contract</span>,</span> _admin</span>)</span>;</span></span> /span> //</span> Unregisters a contract</span></span> //</span> _contract: Address of the contract to unregister</span></span> function</span> unRegisterContract</span>(</span>address</span> _contract</span>)</span> </span></span> public</span> </span></span> onlyAdmin</span>(</span>_contract</span>)</span> </span></span> onlyActiveContract</span>(</span>_contract</span>)</span> </span></span> /span> </span>storage</span> contractInfo </span>=</span> contracts</span>[</span>_contract</span>]</span>;</span></span> fo</span>.</span>isActive </span>=</span> false</span>;</span></span> fo</span>.</span>admin </span>=</span> address</span>(</span>0</span>)</span>;</span></span> emit</span> ContractUnregistered</span>(</span>_contract</span>,</span> msg.sender</span>)</span>;</span></span> /span> //</span> Grants roles to multiple accounts for multiple contracts</span></span> //</span> targetContracts: Array of contract addresses</span></span> //</span> roles: Array of roles to grant</span></span> //</span> accounts: Array of accounts to assign the roles</span></span> function</span> grantRole</span>(</span></span> address</span>[</span>]</span> memory</span> targetContracts</span>,</span></span> bytes32</span>[</span>]</span> memory</span> roles</span>,</span></span> address</span>[</span>]</span> memory</span> accounts</span></span> class="z-storage z-type"> public</span> {</span></span> require</span>(</span></span> targetContracts</span>.</span>length </span>==</span> roles</span>.</span>length </span>&&</span></span> roles</span>.</span>length </span>==</span> accounts</span>.</span>length</span>,</span></span> "Array lengths do not match"</span></span> an>;</span></span> uint256</span> cachedArrayLength </span>=</span> roles</span>.</span>length</span>;</span></span> //</span> Grant roles in a batch</span></span> for</span> (</span>uint256</span> i</span>;</span> i </span><</span> cachedArrayLength</span>;</span> +</span>+</span>i</span>)</span> {</span></span> _grantRole</span>(</span>targetContracts</span>[</span>i</span>]</span>,</span> roles</span>[</span>i</span>]</span>,</span> accounts</span>[</span>i</span>]</span>)</span>;</span></span> an></span> /span> //</span> Revokes roles from multiple accounts for multiple contracts</span></span> //</span> targetContracts: Array of contract addresses</span></span> //</span> roles: Array of roles to revoke</span></span> //</span> accounts: Array of accounts from which roles are revoked</span></span> function</span> revokeRole</span>(</span></span> address</span>[</span>]</span> memory</span> targetContracts</span>,</span></span> bytes32</span>[</span>]</span> memory</span> roles</span>,</span></span> address</span>[</span>]</span> memory</span> accounts</span></span> class="z-storage z-type"> public</span> {</span></span> require</span>(</span></span> targetContracts</span>.</span>length </span>==</span> roles</span>.</span>length </span>&&</span></span> roles</span>.</span>length </span>==</span> accounts</span>.</span>length</span>,</span></span> "Array lengths do not match"</span></span> an>;</span></span> uint256</span> cachedArrayLength </span>=</span> roles</span>.</span>length</span>;</span></span> //</span> Revoke roles in a batch</span></span> for</span> (</span>uint256</span> i</span>;</span> i </span><</span> cachedArrayLength</span>;</span> +</span>+</span>i</span>)</span> {</span></span> _revokeRole</span>(</span>targetContracts</span>[</span>i</span>]</span>,</span> roles</span>[</span>i</span>]</span>,</span> accounts</span>[</span>i</span>]</span>)</span>;</span></span> an></span> /span> //</span> Retrieves information of a registered contract</span></span> //</span> _contract: Address of the contract</span></span> //</span> Returns: isActive status and admin address</span></span> function</span> getContractInfo</span>(</span>address</span> _contract</span>)</span> </span></span> public</span> </span></span> view</span> </span></span> returns</span> (</span>bool</span> isActive</span>,</span> address</span> admin</span>)</span> </span></span> /span> </span>storage</span> info </span>=</span> contracts</span>[</span>_contract</span>]</span>;</span></span> return</span> (</span>info</span>.</span>isActive</span>,</span> info</span>.</span>admin</span>)</span>;</span></span> /span> //</span> Gets role information for an account and contract</span></span> //</span> targetContract: Address of the target contract</span></span> //</span> account: Address of the account</span></span> //</span> role: Role identifier</span></span> //</span> Returns: Boolean indicating if the account has the role</span></span> function</span> getRoleInfo</span>(</span></span> address</span> targetContract</span>,</span></span> address</span> account</span>,</span></span> bytes32</span> role</span></span> class="z-storage z-type"> public</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span> return</span> _contractRoles</span>[</span>targetContract</span>]</span>[</span>account</span>]</span>[</span>role</span>]</span>;</span></span> /span> //</span> Internal function to grant a role to an account for a contract</span></span> function</span> _grantRole</span>(</span></span> address</span> targetContract</span>,</span></span> bytes32</span> role</span>,</span></span> address</span> account</span></span> /span> internal</span></span> onlyAdminOrContract</span>(</span>targetContract</span>)</span></span> onlyActiveContract</span>(</span>targetContract</span>)</span></span> validAddress</span>(</span>account</span>)</span></span> /span> oles</span>[</span>targetContract</span>]</span>[</span>account</span>]</span>[</span>role</span>]</span> =</span> true</span>;</span></span> emit</span> RoleGranted</span>(</span>targetContract</span>,</span> role</span>,</span> account</span>)</span>;</span></span> /span> //</span> Internal function to revoke a role from an account for a contract</span></span> function</span> _revokeRole</span>(</span></span> address</span> targetContract</span>,</span></span> bytes32</span> role</span>,</span></span> address</span> account</span></span> /span> internal</span></span> onlyAdminOrContract</span>(</span>targetContract</span>)</span></span> onlyActiveContract</span>(</span>targetContract</span>)</span></span> validAddress</span>(</span>account</span>)</span></span> /span> require</span>(</span></span> _contractRoles</span>[</span>targetContract</span>]</span>[</span>account</span>]</span>[</span>role</span>]</span>,</span></span> "Role already revoked"</span></span> an>;</span></span> oles</span>[</span>targetContract</span>]</span>[</span>account</span>]</span>[</span>role</span>]</span> =</span> false</span>;</span></span> emit</span> RoleRevoked</span>(</span>targetContract</span>,</span> role</span>,</span> account</span>)</span>;</span></span> /span> //</span> Checks if the caller is an admin for the contract</span></span> //</span> _contract: Address of the contract</span></span> //</span> _admin: Address of the admin</span></span> //</span> Returns: Boolean indicating admin status</span></span> function</span> _isAdmin</span>(</span>address</span> _contract</span>,</span> address</span> _admin</span>)</span> internal</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span> return</span> _admin </span>==</span> contracts</span>[</span>_contract</span>]</span>.</span>admin</span>;</span></span> /span> F;span> </pre>Design Decisions</h3> have to be explicitly specified to ensure the functionality, security, and efficiency of the IAccessControlRegistry</code>:</p> Contract Registration</h4> There is no central owner who can register contracts. This design choice promotes decentralization and ensures that individual contracts are responsible for their own registration and management.</p> Storage and Lookup</h4> The use of mappings for storing contract information (mapping(address => ContractInfo) private contracts</code>) and role assignments (mapping(address => mapping(address => mapping(bytes32 => bool))) private _contractRoles</code>) ensures efficient storage and lookup. This is crucial for maintaining performance in a large-scale system with numerous contracts and roles.</p> Management Flexibility</h4> Functions like grantRole</code> and revokeRole</code> allow for the assignment and revocation of roles to multiple accounts for multiple contracts in a single transaction. This bulk operation reduces gas costs and simplifies the process of role management in large systems.</p> Security Measures</h4> Functions that modify the state, such as unRegisterContract, _grantRole</code>, and _revokeRole</code>, are restricted to contract admins. This ensures that only authorized personnel can manage contracts and roles, reducing the risk of unauthorized changes.</p> The validAddress</code> modifier ensures that addresses are non-zero, preventing potential issues with null addresses which could lead to unintended behavior or security vulnerabilities.</p> The onlyActiveContract</code> modifier ensures that actions are only performed on active or registered contracts, preventing operations on inactive or unregistered contracts.</p> Auditing</h4> Emitting events for each significant action (registration, unregistration, role granting, and revocation) provides a transparent log that can be monitored and audited. This helps in detecting and responding to unauthorized or suspicious activities promptly.</p> Considerations</h2> implements several security measures to ensure the integrity and reliability of the access control system:</p> By limiting state-modifying functions to contract admins, the system prevents unauthorized users from making critical changes.</p> Operations are restricted to active contracts, reducing the risk of interacting with deprecated or unregistered contracts.</p> Comprehensive event logging supports transparency and auditability, allowing for effective monitoring and detection of unauthorized actions.</p> via CC0</a>.</p>
Abstract</h2>
Introduces an extension for ERC-20</a> tokens, which facilitates the implementation of an expiration mechanism. Through this extension, tokens have a predetermined validity period, after which they become invalid and can no longer be transferred or used. This functionality proves beneficial in scenarios such as time-limited bonds, loyalty rewards, or game tokens necessitating automatic invalidation after a specific duration. The extension is crafted to seamlessly align with the existing ERC-20</a> standard, ensuring smooth integration with the prevailing token smart contract while introducing the capability to govern and enforce token expiration at the contract level.</p>
Motivation</h2>
This extension facilitates the development of ERC-20</a> standard compatible tokens featuring expiration dates. This capability broadens the scope of potential applications, particularly those involving time-sensitive assets. Expirable tokens are well-suited for scenarios necessitating temporary validity, including:</p>

Bonds or financial instruments with defined maturity dates</li>
Time-constrained assets within gaming ecosystems</li>
Next-gen loyalty programs incorporating expiring rewards or points</li>
Prepaid credits for utilities or services (e.g., cashback, data packages, fuel, computing resources) that expire if not used within a specified time frame</li>
Postpaid telecom data package allocations that expire at the end of the billing cycle, motivating users to utilize their data before it resets</li>
Tokenized e-Money for a closed-loop ecosystem, such as transportation, food court, and retail payments</li>
</ul>
Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Epoch Mechanism</h3>
Epochs</strong> represent a specific period or block range during which certain tokens are valid. They can be categorized into two types</p>

block-based</strong> Defined by a specific number of blocks (e.g., 1000 blocks</code>).</li>
time-based</strong> Defined by a specific duration in seconds (e.g., 1000 seconds</code>).</li>
</ul>
Tokens linked to an epoch</code> remain valid as long as the epoch</code> is active. Once the specified number of blocks</code> or the duration in seconds</code> has passed, the epoch</code> expires, and any tokens associated with it are considered expired.</p>
Balance Look Back Over Epochs</h3>
To retrieve the usable balance, tokens are checked from the current epoch</strong> against a past epoch</strong> (which can be any n</strong></em> epochs back). The past epoch can be set to any value n</strong></em>, allowing flexibility in tracking and summing tokens that are still valid from previous epochs, up to n</strong></em> epochs back.</p>
The usable balance is the sum of tokens valid between the current epoch</strong> and the past epoch</strong>, ensuring that only non-expired tokens are considered.</p>
Example Scenario</h4>
epoch</strong></th> balance</strong></th></tr></thead>

1</td> 100</td></tr>
2</td> 150</td></tr>
3</td> 200</td></tr>
</tbody></table>

Current Epoch</strong>: 3</li>
Past Epoch</strong>: 1 epoch back</li>
Usable Balance</strong>: 350</li>
</ul>
Tokens from Epoch 2</strong> and Epoch 3</strong> are valid. The same logic applies for any n</strong></em> epochs back, where the usable balance includes tokens from the current epoch and all prior valid epochs.</p>
Compatible implementations MUST</strong> inherit from ERC-20</a>'s interface and MUST</strong> have all the following functions and all function behavior MUST</strong> meet the specification.</p>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> >=0.8.0</span> <</span>0.9</span>.</span>0</span>;</span></span>
</span>
/**</span></span>
 * </span>@title</span> ERC-7818 interface</span></span>
 * </span>@dev</span> Interface for adding expirable functionality to ERC20 tokens.</span></span>
 */</span></span>
</span>
import</span> "./IERC20.sol"</span>;</span></span>
</span>
interface</span> IERC7818</span> is</span> IERC20</span> {</span></span>
    /**</span></span>
     * </span>@dev</span> Enum represents the types of `epoch` that can be used.</span></span>
     * </span>@notice</span> The implementing contract may use one of these types to define how the `epoch` is measured.</span></span>
     */</span></span>
    enum</span> EPOCH_TYPE</span> {</span></span>
        BLOCKS_BASED</span>,</span> //</span> measured in the number of blocks (e.g., 1000 blocks)</span></span>
        TIME_BASED</span> //</span> measured in seconds (UNIX time) (e.g., 1000 seconds)</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the balance of a specific `epoch` owned by an account.</span></span>
     * </span>@param</span> epoch</span> The `epoch for which the balance is checked.</span></span>
     * </span>@param</span> account</span> The address of the account.</span></span>
     * </span>@return</span> uint256</span> The balance of the specified `epoch`.</span></span>
     * </span>@notice</span> "MUST" return 0 if the specified `epoch` is expired.</span></span>
     */</span></span>
    function</span> balanceOfAtEpoch</span>(</span></span>
        uint256</span> epoch</span>,</span></span>
        address</span> account</span></span>
    )</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the latest epoch currently tracked by the contract.</span></span>
     * </span>@return</span> uint256</span> The latest epoch of the contract.</span></span>
     */</span></span>
    function</span> currentEpoch</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the duration of a single epoch.</span></span>
     * </span>@return</span> uint256</span> The duration of a single epoch.</span></span>
     * </span>@notice</span> The unit of the epoch length is determined by the `validityPeriodType` function.</span></span>
     */</span></span>
    function</span> epochLength</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Returns the type of the epoch.</span></span>
     * </span>@return</span> EPOCH_TYPE</span>  Enum value indicating the unit of an epoch.</span></span>
     */</span></span>
    function</span> epochType</span>(</span>)</span> external</span> view</span> returns</span> (</span>EPOCH_TYPE</span>)</span>;</span></span>
    </span></span>
    /**</span></span>
     * </span>@dev</span> Retrieves the validity duration in `epoch` counts.</span></span>
     * </span>@return</span> uint256</span> The validity duration in `epoch` counts.</span></span>
     */</span></span>
    function</span> validityDuration</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Checks whether a specific `epoch` is expired.</span></span>
     * </span>@param</span> epoch</span> The `epoch` to check.</span></span>
     * </span>@return</span> bool</span> True if the token is expired, false otherwise.</span></span>
     * </span>@notice</span> Implementing contracts "MUST" define and document the logic for determining expiration,</span></span>
     * typically by comparing the latest epoch with the given `epoch` value,</span></span>
     * based on the `EPOCH_TYPE` measurement (e.g., block count or time duration).</span></span>
     */</span></span>
    function</span> isEpochExpired</span>(</span>uint256</span> epoch</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Transfers a specific `epoch` and value to a recipient.</span></span>
     * </span>@param</span> epoch</span> The `epoch` for the transfer.</span></span>
     * </span>@param</span> to</span> The recipient address.</span></span>
     * </span>@param</span> value</span> The amount to transfer.</span></span>
     * </span>@return</span> bool</span> True if the transfer succeeded, otherwise false.</span></span>
     */</span></span>
    function</span> transferAtEpoch</span>(</span></span>
        uint256</span> epoch</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> value</span></span>
    )</span> external</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Transfers a specific `epoch` and value from one account to another.</span></span>
     * </span>@param</span> epoch</span> The `epoch` for the transfer.</span></span>
     * </span>@param</span> from</span> The sender's address.</span></span>
     * </span>@param</span> to</span> The recipient's address.</span></span>
     * </span>@param</span> value</span> The amount to transfer.</span></span>
     * </span>@return</span> bool</span> True if the transfer succeeded, otherwise false.</span></span>
     */</span></span>
    function</span> transferFromAtEpoch</span>(</span></span>
        uint256</span> epoch</span>,</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> value</span></span>
    )</span> external</span> returns</span> (</span>bool</span>)</span>;</span></span>
}</span></span></code></pre>Behavior Specification</h3>

balanceOf</code> MUST</strong> return the total balance of tokens held by an account that are still valid (i.e., have not expired). This includes any tokens associated with specific epochs, provided they remain within their validity duration. Expired tokens MUST NOT</strong> be included in the returned balance, ensuring that only actively usable tokens are reflected in the result.</li>
balanceOfAtEpoch</code> MUST</strong> return the balance of tokens held by an account at the specified epoch</code>. If the specified epoch is expired, this function MUST</strong> return 0</code>.
For example, if epoch</code> 5 has expired, calling balanceOfByEpoch(5, address)</code> returns 0</code> even if there were tokens previously held in that epoch.</li>
currentEpoch</code> MUST</strong> return the current epoch</code> of the contract.</li>
epochLength</code> MUST</strong> return duration between epoch</code> in blocks or time in seconds.</li>
epochType</code> MUST</strong> return the type of epoch used by the contract, which can be either BLOCKS_BASED</code> or TIME_BASED</code>.</li>
validityDuration</code> MUST</strong> return the validity duration of tokens in terms of epoch</code> counts.</li>
isEpochExpired</code> MUST</strong> return true if the given epoch</code> is expired, otherwise false</code>.</li>
transfer</code> and transferFrom</code> MUST</strong> exclusively transfer tokens that remain non-expired at the time of the transaction. Attempting to transfer expired tokens MUST</strong> revert the transaction or return false</code>. Additionally, implementations MAY</strong> include logic to prioritize the automatic transfer of tokens closest to expiration, ensuring that the earliest expiring tokens are used first, provided they meet the non-expired condition.</li>
transferAtEpoch</code> and transferFromAtEpoch</code> MUST</strong> transfer the specified number of tokens held by an account at the specified epoch to the recipient, If the epoch has expired, the transaction MUST</strong> revert</code> or return false</code></li>
totalSupply</code> SHOULD</strong> be set to 0</code> or type(uint256).max</code> due to the challenges of tracking only valid (non-expired) tokens.</li>
The implementation MAY</strong> use a standardized custom error, such as ERC7818TransferredExpiredToken</code> or ERC7818TransferredExpiredToken(address sender, uint256 epoch)</code>, to clearly indicate that the operation failed due to attempting to transfer expired tokens.</li>
</ul>
Additional Potential Useful Function</h3>
These OPTIONAL</strong> functions provide additional functionality that might be useful depending on the specific use case.</p>

getEpochBalance</code> returns the amount of tokens stored in a given epoch</code>, even if the epoch</code> has expired.</li>
getEpochInfo</code> returns both the start and end of the specified epoch</code>.</li>
getNearestExpiryOf</code> returns the token amount closest to expiration, along with an estimated expiration block number or timestamp based on epochType</code>.</li>
getRemainingDurationBeforeEpochChange</code> returns the remaining time or blocks before the epoch</code> change happens, based on the epochType</code>.</li>
</ul>
Rationale</h2>
Although the term epoch</code> is an abstract concept, it leaves room for various implementations. For example, epochs can support more granular tracking of tokens within each epoch, allowing for greater control over when tokens are valid or expired on-chain. Alternatively, epochs can support bulk expiration, where all tokens within the same epoch expire simultaneously. This flexibility enables different methods of tracking token expiration, depending on the specific needs of the use case.
epoch</code> also introduces a "lazy" way to simplify token expiration tracking in a flexible and gas-efficient manner. Instead of continuously updating the expiration state with write</code> operations by the user or additional services, the current epoch can be calculated using a read</code> operation.</p>
Backwards Compatibility</h2>
This standard is fully ERC-20</a> compatible.</p>
Reference Implementation</h2>
For reference implementation can be found here</a>, But in the reference implementation, we employ a sorted list to automatically select the token that nearest expires first with a First-In-First-Out (FIFO</code>) and sliding window algorithm that operates based on the block.number</code> as opposed to relying on block.timestamp</code>, which has been criticized for its lack of security and resilience, particularly given the increasing usage of Layer 2 (L2) networks over Layer 1 (L1) networks. Many L2 networks exhibit centralization and instability, which directly impacts asset integrity, rendering them potentially unusable during periods of network halting, as they are still reliant on the timestamp.</p>
Security Considerations</h2>
Denial Of Service</h3>
Run out of gas problem due to the operation consuming higher gas if transferring multiple groups of small tokens or loop transfer.</p>
Gas Limit Vulnerabilities</h3>
Exceeds block gas limit if the blockchain has a block gas limit lower than the gas used in the transaction.</p>
Block values as a proxy for time</h3>
if using block.timestamp</code> for calculating epoch</code> and In rare network halts, block production stops, freezing block.timestamp</code> and disrupting time-based logic. This risks asset integrity and inconsistent states.</p>
Fairness Concerns</h3>
In a straightforward implementation, where all tokens within the same epoch share the same expiration (e.g., at epoch</code>:x</code>), bulk expiration occurs.</p>
Risks in Liquidity Pools</h3>
When tokens with expiration dates are deposited into liquidity pools (e.g., in DEXs), they may expire while still in the pool.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Set upper bounds for MODEXP
2024-11-11T00:00:00+00:00
Abstract</h2>
Introduce an upper bound on the inputs of the MODEXP precompile. This can reduce the number of potential bugs, because the testing surface is not infinite anymore, and makes it easier to be replaced using EVMMAX.</p>
Motivation</h2>
The MODEXP precompile has been a source of numerous consensus bugs. Many of them were due to specifically crafted cases using impractical input lengths.</p>
Its pricing function is also quite complex given its nature of unbounded inputs. While we don't suggest to rework the pricing function, it may be possible in a future upgrade once the limits are in place.</p>
Furthermore this limitation makes it more feasible to have the precompile replaced with EVM code through features like EVMMAX.</p>
Specification</h2>
Recap from EIP-198</a>:</p>

At address 0x00……05</code>, add a precompile that expects input in the following format:</p>
<length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS></code></p>
</blockquote>
We introduce an upper bound to the inputs of the precompile, each of the length inputs (length_of_BASE</code>, length_of_EXPONENT</code> and length_of_MODULUS</code>) MUST be less than or equal to 8192 bits (1024 bytes).</p>
If any of these inputs are larger than the limit, the precompile execution stops, returns an error, and consumes all gas.</p>
Rationale</h2>
Limit</h3>
This upper bound allows the existing use cases of MODEXP:</p>

RSA verification with up to 8192 bit keys. Commonly used ones are 1024/2048/4096 bits.</li>
Elliptic curve related use cases are usually less than 384 bits.</li>
</ol>
EVMMAX</h3>
Replacing the precompile with EVM code using an instruction set like EVMMAX would be made simpler with this limit: Common cases (256, 381, 1024, 2048) could be implemented in special fast paths, while a slow fallback could be provided for the rest. Or even special, frequently used, moduli could have their own paths.</p>
Furthermore one could consider limiting the lengths to certain inputs only.</p>
Analysis</h3>
Since MODEXP was introduced in the Byzantium hard fork, an analysis has been conducted between block 5472266 (April 20, 2018) and block 21550926 (January 4th, 2025). All lengths of inputs are expressed in bytes.</p>
Base length occurrences</h4>
input_of_BASE</code></th> count</th></tr></thead>

32</td> 2439595</td></tr>
128</td> 4167</td></tr>
256</td> 2969</td></tr>
160</td> 436</td></tr>
512</td> 36</td></tr>
0</td> 13</td></tr>
64</td> 7</td></tr>
78</td> 2</td></tr>
513</td> 2</td></tr>
129</td> 1</td></tr>
385</td> 1</td></tr>
</tbody></table>
Exponent length occurrences</h4>
input_of_EXPONENT</code></th> count</th></tr></thead>

32</td> 2442255</td></tr>
3</td> 4771</td></tr>
1</td> 159</td></tr>
128</td> 29</td></tr>
0</td> 13</td></tr>
5</td> 2</td></tr>
</tbody></table>
Modulo length occurrences</h4>
input_of_MODULUS</code></th> count</th></tr></thead>

32</td> 2439594</td></tr>
128</td> 4167</td></tr>
256</td> 2968</td></tr>
160</td> 436</td></tr>
512</td> 38</td></tr>
0</td> 13</td></tr>
64</td> 8</td></tr>
78</td> 2</td></tr>
129</td> 1</td></tr>
384</td> 1</td></tr>
257</td> 1</td></tr>
</tbody></table>
This shows that no past successful use case exceeded an input length of 513 bytes, and the majority uses 32/128/256 byte inputs.</p>
Besides these, there were a few invocations with invalid inputs:</p>

Empty inputs</li>
Inputs consisting of only 0x9e5faafc</code> or 0x85474728</code></li>
A large, but invalid input: 0x9e281a98000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021e19e0c9bab2400000</code></li>
</ul>
Backwards Compatibility</h2>
This is a backwards incompatible change. However, based on analysis until block 21550926 (see above), no past transaction would have behaved differently after this change.</p>
Security Considerations</h2>
Since only the accepted input range is reduced, no new security surface area is expected.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Wrapping of bubbled up reverts
2024-08-06T00:00:00+00:00
Abstract</h2>
This ERC proposes a standard for handling bubbled up reverts in Ethereum smart contracts using a dedicated custom error. This standard aims to improve the clarity and usability of revert reasons by allowing additional context to be passed alongside the raw bytes of the bubbled up revert. The WrappedError</code> custom error should wrap reverts from called contracts and provide a consistent interface for parsing and handling reverts in tools like Etherscan or Tenderly.</p>
Motivation</h2>
Currently, when a smart contract calls another and the called contract reverts, the revert reason is usually bubbled up and thrown as is. This can make it more difficult to tell which context the error came from. By standardizing the use of custom errors with additional context, more meaningful and informative revert reasons can be provided. This will improve the debugging experience and make it easier for developers and infrastructure providers like Etherscan to display accurate stack traces.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
In order to wrap a revert, a contract MUST revert with the following error that corresponds to the following signature 0x90bfb865</code>:</p>
error</span> WrappedError</span>(</span>address</span> target</span>,</span> bytes4</span> selector</span>,</span> bytes</span> reason</span>,</span> bytes</span> details</span>)</span>;</span></span></code></pre>
Where:</p>

target</code> is the address of the called contract that reverted.</li>
selector</code> is the selector of the called function that reverted. If the call was an ETH transfer without any data, the selector MUST be bytes4(0)</code></li>
reason</code> is the raw bytes of the revert reason.</li>
details</code> is optional additional context about the revert. In cases where no additional context is needed, the details</code> bytes can be empty. In cases with additional context, the details</code> bytes MUST be an ABI encoded custom error declared on the contract that emits the WrappedError</code> error.</li>
</ul>
Rationale</h2>
By including the called contract and function, raw revert bytes and additional context, developers can provide more detailed information about the failure. Additionally, by standardizing the way reverts are bubbled up, it also enables nested bubbled up reverts where multiple reverts thrown by different contracts can be followed recursively. The reverts can also be parsed and handled by tools like Etherscan and Foundry to further enhance the readability and debuggability of smart contract interactions, as well as facilitating better error handling practices in general.</p>
Backwards Compatibility</h2>
This ERC does not introduce any backwards incompatibilities. Existing contracts can adopt this standard incrementally.</p>
Test Cases</h2>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> 0.8.26</span>;</span></span>
</span>
contract</span> Token</span> {</span></span>
    mapping</span>(</span>address</span> =></span> uint256</span>)</span> public</span> balanceOf</span>;</span></span>
</span>
    event</span> Transfer</span>(</span>address</span> indexed</span> sender</span>, </span>address</span> indexed</span> recipient</span>, </span>uint</span> amount</span>)</span>;</span></span>
</span>
    function</span> transfer</span>(</span>address</span> to</span>,</span> uint256</span> amount</span>)</span> external</span> returns</span> (</span>bool</span>)</span> {</span></span>
        require</span>(</span>balanceOf</span>[</span>msg.sender</span>]</span> ></span>=</span> amount</span>,</span> "insufficient balance"</span>)</span>;</span></span>
        balanceOf</span>[</span>msg.sender</span>]</span> -</span>=</span> amount</span>;</span></span>
        balanceOf</span>[</span>to</span>]</span> +</span>=</span> amount</span>;</span></span>
        emit</span> Transfer</span>(</span>msg.sender</span>,</span> to</span>,</span> amount</span>)</span>;</span></span>
        return</span> true</span>;</span></span>
    }</span></span>
}</span></span>
</span>
contract</span> Vault</span> {</span></span>
    Token token</span>;</span></span>
</span>
    error</span> WrappedError</span>(</span>address</span> target</span>,</span> bytes4</span> selector</span>,</span> bytes</span> reason</span>,</span> bytes</span> details</span>)</span>;</span></span>
    error</span> ERC20TransferFailed</span>(</span>address</span> recipient</span>)</span>;</span></span>
</span>
</span>
    constructor</span>(</span>Token</span> token_</span>)</span> {</span></span>
        token </span>=</span> token_</span>;</span></span>
    }</span></span>
</span>
    function</span> withdraw</span>(</span>address</span> to</span>,</span> uint256</span> amount</span>)</span> external</span> {</span></span>
        //</span> logic</span></span>
        try</span> token</span>.</span>transfer</span>(</span>to</span>,</span> amount</span>)</span> {</span>}</span> catch</span> (</span>bytes</span> memory</span> error</span>)</span> {</span></span>
            revert</span> WrappedError</span>(</span>address</span>(</span>token</span>)</span>,</span> token</span>.</span>transfer</span>.</span>selector</span>,</span> error</span>,</span> abi</span>.</span>encodeWithSelector</span>(</span>ERC20TransferFailed</span>.</span>selector</span>,</span> to</span>)</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span>
</span>
contract</span> Router</span> {</span></span>
    Vault vault</span>;</span></span>
</span>
    error</span> WrappedError</span>(</span>address</span> target</span>,</span> bytes4</span> selector</span>,</span> bytes</span> reason</span>,</span> bytes</span> details</span>)</span>;</span></span>
</span>
    constructor</span>(</span>Vault</span> vault_</span>)</span> {</span></span>
        vault </span>=</span> vault_</span>;</span></span>
    }</span></span>
</span>
    function</span> withdraw</span>(</span>uint256</span> amount</span>)</span> external</span> {</span></span>
        //</span> logic</span></span>
        try</span> vault</span>.</span>withdraw</span>(</span>msg.sender</span>,</span> amount</span>)</span> {</span>}</span> catch</span> (</span>bytes</span> memory</span> error</span>)</span> {</span></span>
            revert</span> WrappedError</span>(</span>address</span>(</span>vault</span>)</span>,</span> vault</span>.</span>withdraw</span>.</span>selector</span>,</span> error</span>,</span> ""</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span>
</span>
contract</span> Test</span> {</span></span>
    function</span> test_BubbledNestedReverts</span>(</span>uint256</span> amount</span>)</span> external</span> {</span></span>
        Token token </span>=</span> new</span> Token</span>(</span>)</span>;</span></span>
        Vault vault </span>=</span> new</span> Vault</span>(</span>token</span>)</span>;</span></span>
        Router router </span>=</span> new</span> Router</span>(</span>vault</span>)</span>;</span></span>
</span>
        try</span> router</span>.</span>withdraw</span>(</span>amount</span>)</span> {</span>}</span> catch</span> (</span>bytes</span> memory</span> thrownError</span>)</span> {</span></span>
            bytes</span> memory</span> expectedError </span>=</span> abi</span>.</span>encodeWithSelector</span>(</span></span>
                Router</span>.</span>WrappedError</span>.</span>selector</span>,</span> address</span>(</span>vault</span>)</span>,</span> vault</span>.</span>withdraw</span>.</span>selector</span>,</span> abi</span>.</span>encodeWithSelector</span>(</span></span>
                    Vault</span>.</span>WrappedError</span>.</span>selector</span>,</span></span>
                    address</span>(</span>token</span>)</span>,</span></span>
                    token</span>.</span>transfer</span>.</span>selector</span>,</span></span>
                    abi</span>.</span>encodeWithSignature</span>(</span>"Error(string)"</span>,</span> "insufficient balance"</span>)</span>,</span></span>
                    abi</span>.</span>encodeWithSelector</span>(</span>Vault</span>.</span>ERC20TransferFailed</span>.</span>selector</span>,</span> address</span>(</span>this</span>)</span>)</span></span>
                )</span>,</span> ""</span></span>
            )</span>;</span></span>
            assert</span>(</span>keccak256</span>(</span>thrownError</span>)</span> ==</span> keccak256</span>(</span>expectedError</span>)</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>Reference Implementation</h2>
When catching a revert from a called contract, the calling contract should revert with a custom error following the above conventions.</p>
contract</span> Foo</span> {</span></span>
</span>
    error</span> WrappedError</span>(</span>address</span> target</span>,</span> bytes4</span> selector</span>,</span> bytes</span> reason</span>,</span> bytes</span> details</span>)</span>;</span></span>
    error</span> MyCustomError</span>(</span>uint256</span> x</span>)</span>;</span></span>
</span>
    function</span> foo</span>(</span>address</span> to</span>,</span> bytes</span> memory</span> data</span>)</span> external</span> {</span></span>
        //</span> logic</span></span>
        (</span>bool</span> success</span>,</span> bytes</span> memory</span> returnData</span>)</span> =</span> to</span>.</span>call</span>(</span>data</span>)</span>;</span></span>
        if</span> (</span>!</span>success</span>)</span> {</span></span>
            revert</span> WrappedError</span>(</span>to</span>,</span> bytes4</span>(</span>data</span>)</span>,</span> returnData</span>,</span> abi</span>.</span>encodeWithSelector</span>(</span>MyCustomError</span>.</span>selector</span>,</span> 42</span>)</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Smart contracts could either drop or purposefully suppress the bubbled up reverts along the revert chain. Additionally, smart contracts may also lie or incorrectly report the wrapped reverts, so the information is not guaranteed to be accurate.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Multi-Owner Non-Fungible Tokens (MO-NFT)
2024-07-13T00:00:00+00:00
Abstract</h2>
This ERC proposes a new standard for non-fungible tokens (NFTs) that supports multiple owners. The MO-NFT standard allows a single NFT to have multiple owners, reflecting the shared and distributable nature of digital assets. This model incorporates mechanisms for provider-defined transfer fees and ownership archiving, enabling flexible and collaborative ownership structures. It maintains compatibility with the existing ERC-721</a> standard to ensure interoperability with current tools and platforms.</p>
Motivation</h2>
Traditional NFTs enforce a single-ownership model, which does not align with the inherent duplicability and collaborative potential of digital assets. MO-NFTs allow for shared ownership, promoting wider distribution and collaboration while maintaining secure access control. The inclusion of provider fees and ownership archiving enhances the utility and flexibility of NFTs in representing digital assets and services.</p>
Specification</h2>
Token Creation and Ownership Model</h3>


Minting</strong>:</p>


The function mintToken()</code> allows the creation of a new MO-NFT. The caller becomes both the initial owner and the provider of the token.</p>
function</span> mintToken</span>(</span>)</span> public</span> onlyOwner</span> returns</span> (</span>uint256</span>)</span>;</span></span></code></pre></li>

A new tokenId</code> is generated, and the caller is added to the owners set and recorded as the provider. The balanceOf</code> the caller is incremented.</p>
</li>
</ul>
</li>

Ownership List</strong>:</p>

The MO-NFT maintains a list of owners for each token. Owners are stored in an enumerable set to prevent duplicates and allow efficient lookup.</li>
</ul>
</li>

Provider Role</strong>:</p>

The provider is the initial owner who can set and update the transferValue</code> fee. Only the provider can modify certain token parameters.</li>
</ul>
</li>

Transfer Mechanism</strong>:</p>


Owners can transfer the token to new owners using transferFrom</code>. The transfer adds the new owner to the list without removing existing owners and transfers the transferValue</code> fee to the provider.</p>
function</span> transferFrom</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint256</span> tokenId</span>)</span> public</span>;</span></span></code></pre></li>
</ul>
</li>
</ol>
Transfer of Ownership</h3>


Additive Ownership</strong>:</p>

Transferring ownership adds the new owner to the ownership list without removing current owners. This approach reflects the shared nature of digital assets.</li>
</ul>
</li>

Provider Fee Handling</strong>:</p>

During a transfer, the specified transferValue</code> fee is transferred to the provider. The contract must have sufficient balance to cover this fee.</li>
</ul>
</li>

Archiving Ownership</strong>:</p>


Owners can mark themselves as archived for a specific token, meaning they can no longer transfer that token. Once set, this status cannot be reversed. And for Digital Asset platform, this status means the owner can download the real digital asset directly; if it is not archived, then it must be changed to archived first, then owner can download the real digital asset.</p>
function</span> archive</span>(</span>uint256</span> tokenId</span>)</span> external</span>;</span></span></code></pre></li>
</ul>
</li>
</ol>
Interface Definitions</h3>
Minting Functions</strong></p>


function mintToken() public onlyOwner returns (uint256);</code></p>
</li>

function provide(string memory assetName, uint256 size, bytes32 fileHash, address provider, uint256 transferValue) external returns (uint256);</code></p>
</li>
</ul>
Transfer Functions</strong></p>


function transferFrom(address from, address to, uint256 tokenId) public;</code></p>
</li>

function safeTransferFrom(address from, address to, uint256 tokenId) public;</code> (Disabled or overridden)</em></p>
</li>

function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public;</code> (Disabled or overridden)</em></p>
</li>
</ul>
Ownership Management Functions</strong></p>


function isOwner(uint256 tokenId, address account) public view returns (bool);</code></p>
</li>

function getOwnersCount(uint256 tokenId) public view returns (uint256);</code></p>
</li>

function balanceOf(address owner) external view returns (uint256 balance);</code></p>
</li>

function ownerOf(uint256 tokenId) external view returns (address owner);</code></p>
</li>
</ul>
Provider Functions</strong></p>

function setTransferValue(uint256 tokenId, uint256 newTransferValue) external;</code></li>
</ul>
Archived Status Function</strong></p>

function archive(uint256 tokenId) external;</code></li>
</ul>
Events</h3>


event TokenMinted(uint256 indexed tokenId, address indexed owner);</code></p>
</li>

event TokenTransferred(uint256 indexed tokenId, address indexed from, address indexed to);</code></p>
</li>

event TransferValueUpdated(uint256 indexed tokenId, uint256 oldTransferValue, uint256 newTransferValue);</code></p>
</li>

event ArchivedStatusUpdated(uint256 indexed tokenId, address indexed owner, bool archived);</code></p>
</li>
</ul>
ERC-721</a> Compliance</h3>
The MO-NFT standard is designed to be compatible with the ERC-721</a> standard. It implements required functions such as balanceOf</code>, ownerOf</code>, and transferFrom</code> from the ERC721</code> interface.</p>


Approval Functions</strong>: Functions like approve</code>, getApproved</code>, setApprovalForAll</code>, and isApprovedForAll</code> are intentionally disabled or overridden, as they do not align with the MO-NFT multi-owner model.</p>
</li>

Safe Transfer Functions</strong>: The safeTransferFrom</code> functions are restricted because traditional ERC-721 transfer safety checks are not applicable when ownership is additive rather than exclusive.</p>
</li>

Supports Interface</strong>: The supportsInterface</code> function ensures that the MO-NFT declares compatibility with the ERC-721 standard, allowing it to be integrated with existing tools and platforms.</p>
function</span> supportsInterface</span>(</span>bytes4</span> interfaceId</span>)</span> public</span> view</span> returns</span> (</span>bool</span>)</span> {</span></span>
    return</span> interfaceId </span>==</span> type</span>(</span>IERC721</span>)</span>.</span>interfaceId </span>||</span> interfaceId </span>==</span> type</span>(</span>IERC165</span>)</span>.</span>interfaceId</span>;</span></span>
}</span></span></code></pre></li>
</ul>
Rationale</h2>


Multi-Ownership Model</strong>:</p>

Digital assets are inherently duplicable and can be shared without loss of quality. The multi-owner model allows broader distribution and collaboration while maintaining a unique token identity.</li>
</ul>
</li>

Additive Ownership</strong>:</p>

By adding new owners without removing existing ones, we support shared ownership models common in collaborative environments and digital content distribution.</li>
</ul>
</li>

Provider Fee Mechanism</strong>:</p>

Incorporating a provider fee incentivizes creators and providers by rewarding them whenever the asset is transferred. This aligns with models where creators receive royalties or fees for their work.</li>
</ul>
</li>

Ownership Archiving</strong>:</p>

Allowing owners to archive themselves from the ownership list provides flexibility, enabling owners to relinquish rights or prevent further transfers of the asset. This replaces the previous concept of "burning" ownership.</li>
</ul>
</li>

ERC-721 Compatibility</strong>:</p>

Maintaining compatibility with ERC-721 allows MO-NFTs to leverage existing infrastructure, tools, and platforms, facilitating adoption and interoperability.</li>
</ul>
</li>
</ol>
Backwards Compatibility</h2>
While the MO-NFT standard aims to maintain compatibility with ERC-721, certain deviations are necessary due to the multi-owner model:</p>

Disabling Approvals Functions</strong>: Traditional ERC-721 approvals assume that a single owner has the right to grant or revoke approvals. In MO-NFT, a token can have multiple owners. Without a protocol-defined mechanism for “co-ownership consensus,” an approval system would open the door to an unintentional or unwanted transfer if only one co-owner granted approval. We felt this approach could undermine the shared-ownership model, so the reference implementation chooses to revert calls to approval-related functions.</li>
</ul>
This may limit compatibility with existing NFT platforms and marketplaces that rely on approve or setApprovalForAll. In principle, developers could extend the MO-NFT standard with more advanced “multi-signature” or “consensus-based” approvals, but that is beyond the scope of this initial EIP. Our goal is to keep the core standard minimal and avoid confusion for marketplaces that were built with single-owner assumptions.</p>

Safe Transfer Functions</strong>: The “safe” variants of ERC-721 transfers (safeTransferFrom) serve to protect tokens from being accidentally sent to non-compliant contracts. Because MO-NFT’s multi-owner approach does not inherently break the logic of “checking whether the recipient can handle ERC-721 tokens.</li>
</ul>
Implementing “safe” in the same manner as ERC-721: after a new owner is added, check onERC721Received</code> on the recipient contract.</p>

ownerOf</code> Function</strong>: Returns the first owner in the owners list for compatibility, but the concept of a single owner does not fully apply.</li>
</ul>
Developers should be aware of these differences when integrating MO-NFTs into systems designed for standard ERC-721 tokens.</p>
Test Cases</h2>


Minting an MO-NFT and Verifying Initial Ownership</strong>:</p>


Input</strong>:</p>

Call mintToken()</code> as the provider.</li>
</ul>
</li>

Expected Output</strong>:</p>


A new tokenId</code> is generated.</p>
</li>

The caller is added as the first owner.</p>
</li>

The balanceOf</code> the caller increases by 1.</p>
</li>

The provider is recorded for the token.</p>
</li>

TokenMinted</code> event is emitted.</p>
</li>
</ul>
</li>
</ul>
</li>

Transferring an MO-NFT and Verifying Provider Fee Transfer</strong>:</p>


Input</strong>:</p>

Call transferFrom(from, to, tokenId)</code> where from</code> is an existing owner and to</code> is a new address.</li>
</ul>
</li>

Expected Output</strong>:</p>


The to</code> address is added to the owners list.</p>
</li>

The transferValue</code> fee is transferred to the provider.</p>
</li>

The balanceOf</code> of the to</code> address increases by 1.</p>
</li>

TokenTransferred</code> event is emitted.</p>
</li>
</ul>
</li>
</ul>
</li>

Archiving Ownership</strong>:</p>


Input</strong>:</p>

An owner calls archive(tokenId)</code>.</li>
</ul>
</li>

Expected Output</strong>:</p>

The owner’s transfer ability for that token is archived.</li>
The owner can no longer transfer that token.</li>
ArchivedStatusUpdated</code> event is emitted.</li>
</ul>
</li>
</ul>
</li>

Setting Transfer Value</strong>:</p>


Input</strong>:</p>

The provider calls setTransferValue(tokenId, newTransferValue)</code>.</li>
</ul>
</li>

Expected Output</strong>:</p>


The transferValue</code> is updated in the contract.</p>
</li>

TransferValueUpdated</code> event is emitted.</p>
</li>
</ul>
</li>
</ul>
</li>

Failing Transfer to Existing Owner</strong>:</p>


Input</strong>:</p>

Attempt to transferFrom</code> to an address that is already an owner.</li>
</ul>
</li>

Expected Output</strong>:</p>


The transaction reverts with the error "MO-NFT: Recipient is already an owner"</code>.</p>
</li>

No changes to ownership or balances occur.</p>
</li>
</ul>
</li>
</ul>
</li>
</ol>
Reference Implementation</h2>
The full reference implementation code for the MO-NFT standard is included in the EIPs repository under assets folder. This ensures the code is preserved alongside the EIP and remains accessible.</p>


Contracts</strong>:</p>


MONFT.sol</code></a>: The base implementation of the MO-NFT standard.</p>
</li>

DigitalAsset.sol</code></a>: An extended implementation for digital assets with provider fees.</p>
</li>
</ul>
</li>

Interfaces</strong>:</p>

IDigitalAsset.sol</code></a>: Interface defining the functions for digital asset management.</li>
</ul>
</li>
</ul>
Key Functions in Reference Implementation</h3>
Minting Tokens</strong></p>
function</span> mintToken</span>(</span>)</span> public</span> onlyOwner</span> returns</span> (</span>uint256</span>)</span> {</span></span>
    _nextTokenId</span>+</span>+</span>;</span></span>
</span>
    //</span> Add the sender to the set of owners for the new token</span></span>
    _owners</span>[</span>_nextTokenId</span>]</span>.</span>add</span>(</span>msg.sender</span>)</span>;</span></span>
</span>
    //</span> Increment the balance of the owner</span></span>
    _balances</span>[</span>msg.sender</span>]</span> +</span>=</span> 1</span>;</span></span>
</span>
    //</span> Set the provider to the caller</span></span>
    _providers</span>[</span>_nextTokenId</span>]</span> =</span> msg.sender</span>;</span></span>
</span>
    emit</span> TokenMinted</span>(</span>_nextTokenId</span>,</span> msg.sender</span>)</span>;</span></span>
    return</span> _nextTokenId</span>;</span></span>
}</span></span></code></pre>
Transferring Tokens</strong></p>
function</span> transferFrom</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint256</span> tokenId</span>)</span> public</span> override</span> {</span></span>
    require</span>(</span>isOwner</span>(</span>tokenId</span>,</span> msg.sender</span>)</span>,</span> "MO-NFT: Caller is not an owner"</span>)</span>;</span></span>
    require</span>(</span>to </span>!=</span> address</span>(</span>0</span>)</span>,</span> "MO-NFT: Transfer to zero address"</span>)</span>;</span></span>
    require</span>(</span>!</span>isOwner</span>(</span>tokenId</span>,</span> to</span>)</span>,</span> "MO-NFT: Recipient is already an owner"</span>)</span>;</span></span>
</span>
    //</span> Add the new owner to the set</span></span>
    _owners</span>[</span>tokenId</span>]</span>.</span>add</span>(</span>to</span>)</span>;</span></span>
    _balances</span>[</span>to</span>]</span> +</span>=</span> 1</span>;</span></span>
</span>
    //</span> Transfer the transferValue to the provider</span></span>
    uint256</span> transferValue </span>=</span> _transferValues</span>[</span>tokenId</span>]</span>;</span></span>
    address</span> provider </span>=</span> _providers</span>[</span>tokenId</span>]</span>;</span></span>
    require</span>(</span>address</span>(</span>this</span>)</span>.</span>balance </span>></span>=</span> transferValue</span>,</span> "Insufficient contract balance"</span>)</span>;</span></span>
</span>
    (</span>bool</span> success</span>,</span> )</span> =</span> provider</span>.</span>call</span>{</span>value</span>:</span> transferValue</span>}</span>(</span>""</span>)</span>;</span></span>
    require</span>(</span>success</span>,</span> "Transfer to provider failed"</span>)</span>;</span></span>
</span>
    emit</span> TokenTransferred</span>(</span>tokenId</span>,</span> from</span>,</span> to</span>)</span>;</span></span>
}</span></span></code></pre>
Archiving Ownership</strong></p>
function</span> archive</span>(</span>uint256</span> tokenId</span>)</span> external</span> {</span></span>
        require</span>(</span></span>
            isOwner</span>(</span>tokenId</span>,</span> msg.sender</span>)</span>,</span></span>
            "MO-NFT: Caller is not the owner of this token"</span></span>
        )</span>;</span></span>
        //</span> Once archived, the status cannot be reversed</span></span>
        require</span>(</span></span>
            _archivedStatus</span>[</span>tokenId</span>]</span>[</span>msg.sender</span>]</span> ==</span> false</span>,</span></span>
            "MO-NFT: Token can only be archived once for an owner"</span></span>
        )</span>;</span></span>
        _archivedStatus</span>[</span>tokenId</span>]</span>[</span>msg.sender</span>]</span> =</span> true</span>;</span></span>
        emit</span> ArchivedStatusUpdated</span>(</span>tokenId</span>,</span> msg.sender</span>,</span> archived</span>)</span>;</span></span>
    }</span></span></code></pre>Security Considerations</h2>


Reentrancy Attacks</strong>:</p>


Mitigation</strong>: Use the Checks-Effects-Interactions pattern when transferring Ether (e.g., transferring transferValue</code> to the provider).</p>
</li>

Recommendation</strong>: Consider using ReentrancyGuard</code> from OpenZeppelin to prevent reentrant calls.</p>
</li>
</ul>
</li>

Integer Overflow and Underflow</strong>:</p>

Mitigation</strong>: Solidity 0.8.x automatically checks for overflows and underflows, throwing exceptions when they occur.</li>
</ul>
</li>

Access Control</strong>:</p>


Ensured By</strong>:</p>


Only owners can call transfer functions.</p>
</li>

Only providers can set the transferValue</code>.</p>
</li>

Use of require</code> statements to enforce access control.</p>
</li>
</ul>
</li>
</ul>
</li>

Denial of Service (DoS)</strong>:</p>


Consideration</strong>: Functions that iterate over owners could be expensive in terms of gas if the owners list is large.</p>
</li>

Mitigation</strong>: Avoid such functions or limit the number of owners.</p>
</li>
</ul>
</li>

Data Integrity</strong>:</p>

Ensured By</strong>: Proper use of Solidity's data types and structures, and by emitting events for all state-changing operations for off-chain verification.</li>
</ul>
</li>

Ether Handling</strong>:</p>


Consideration</strong>: Ensure the contract can receive Ether to handle provider payments.</p>
</li>

Mitigation</strong>: Implement a receive()</code> function to accept Ether.</p>
</li>
</ul>
</li>
</ol>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Decentralized Identity Verification (DID)
2024-06-26T00:00:00+00:00
Abstract</h2>
This proposal introduces a standard for decentralized identity verification (DID) on the blockchain. The standard leverages cryptographic hashes to represent identity proofs and events for transparency and traceability. By emphasizing simplicity, privacy, and user control, this proposal aims to reduce overhead for developers and users, ensuring seamless integration into decentralized applications (dApps). It offers a minimalistic solution that keeps identity structure simple and enables off-chain mechanisms for detailed identity management and verification.</p>
Motivation</h2>
Centralized identity verification methods are cumbersome, prone to data breaches, and fail to provide users control over their identity data. Existing DID solutions often introduce complexity, making adoption challenging for developers and users. This proposal seeks to address these issues by:</p>

Offering a minimalistic, decentralized standard that simplifies identity verification.</li>
Providing privacy-preserving mechanisms that keep sensitive identity data off-chain.</li>
Encouraging wider adoption by enabling seamless integration into dApps across various industries.</li>
</ul>
Stakeholders</h3>
The following stakeholders will benefit from this proposal:</p>
dApp Developers</h4>
Developers creating decentralized applications that require identity verification can implement this standard to provide users with secure, decentralized identity management. The minimalistic design makes it easier to integrate into existing workflows without adding unnecessary complexity.</p>
Service Providers</h4>
Platforms offering services such as decentralized finance (DeFi), gaming, or social networking can integrate this standard to verify user identities without relying on centralized authorities. This reduces the risk of fraud and enhances user trust.</p>
Enterprises</h4>
Companies looking to integrate blockchain-based identity solutions into their existing systems can use this standard to ensure secure and privacy-preserving identity verification. This allows for a seamless transition to decentralized technologies while maintaining user privacy and security.</p>
Developers of Interoperability Solutions</h4>
Those working on cross-platform and cross-blockchain interoperability can implement this standard to enable a unified identity verification mechanism across different systems, reducing complexity and increasing user control over their identities.</p>
Differentiation</h3>
This proposal stands out from other DID standards by focusing on minimalism, user control, and privacy. Unlike other solutions that encompass a wide range of identity attributes and interactions, this standard keeps the structure simple and relies on off-chain mechanisms for detailed identity management. Its simplicity fosters easier adoption, making it ideal for dApps that prioritize user-centric, secure ecosystems.</p>
Specification</h2>
The Decentralized Identity Verification (DID) standard introduces a simple, secure, and privacy-preserving mechanism for verifying user identities on the  blockchain. The key components of this standard are outlined below:</p>
Identity Contract</h4>
A smart contract that acts as the central authority for identity verification. The contract stores the status of identity verifications for users and ensures that verification events are triggered securely and transparently.</p>
Verification Function</h4>
The verifyIdentity</code> function allows a user to submit two verification hashes that represent off-chain proofs or attestations of identity. These hashes can be derived from external sources such as third-party verifiers, documents, or attestations.The function compares the provided hashes and updates the identity verification status accordingly.</p>
Input Parameters:</h5>
identityHash:</strong> A cryptographic hash representing the user's identity.
verificationHash:</strong> A cryptographic hash derived from the proof or attestation used to verify the identity.</p>
IdentityVerified Event</h4>
The IdentityVerified</code> event is emitted when the user's identity verification is successfully updated. This event ensures traceability and transparency, allowing dApp developers and users to track verification statuses.</p>
Identity Structure</h4>
The identity is a simple structure represented by a unique address (public key). Additional identity attributes, such as name or age, are optional and left to off-chain management. This minimal approach keeps the implementation lean, avoiding unnecessary complexity and encouraging broader adoption.</p>
Interface</h3>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
interface</span> IDecentralizedIdentity</span> {</span></span>
    //</span> Struct to represent an identity</span></span>
    struct</span> Identity</span> {</span></span>
        address</span> userAddress</span>;</span> //</span> Ethereum address of the user</span></span>
        bytes32</span> identityHash</span>;</span> //</span> Hash of the identity data</span></span>
        bytes32</span>[</span>2</span>]</span> verificationHashes</span>;</span> //</span> Hashes used for verifying identity</span></span>
        bool</span> isVerified</span>;</span> //</span> Indicates if the identity is verified</span></span>
        uint256</span> timestamp</span>;</span> //</span> Timestamp of identity creation</span></span>
    }</span></span>
</span>
    //</span> Event emitted when a new identity is created</span></span>
    event</span> IdentityCreated</span>(</span>address</span> indexed</span> userAddress</span>, </span>bytes32</span> identityHash</span>, </span>uint256</span> timestamp</span>)</span>;</span></span>
</span>
    //</span> Event emitted when an identity is verified</span></span>
    event</span> IdentityVerified</span>(</span>address</span> indexed</span> userAddress</span>, </span>bytes32</span>[</span>2</span>]</span> verificationHashes</span>, </span>uint256</span> timestamp</span>)</span>;</span></span>
</span>
    //</span> Event emitted when an identity is revoked</span></span>
    event</span> IdentityRevoked</span>(</span>address</span> indexed</span> userAddress</span>, </span>uint256</span> timestamp</span>)</span>;</span></span>
</span>
    //</span> Function to create a new decentralized identity for the caller.</span></span>
    //</span> Parameters:</span></span>
    //</span> - identityHash: Hash of the identity data.</span></span>
    function</span> createIdentity</span>(</span>bytes32</span> identityHash</span>)</span> external</span>;</span></span>
</span>
    //</span> Function to verify the decentralized identity for the caller.</span></span>
    //</span> Parameters:</span></span>
    //</span> - verificationHashes: Hashes used for verifying the identity. These can be </span></span>
    //</span>   derived from off-chain proofs, cryptographic challenges, or other methods </span></span>
    //</span>   specific to the implementer's requirements. The exact meaning and derivation </span></span>
    //</span>   of the verificationHashes are left to the contract's implementer.</span></span>
    function</span> verifyIdentity</span>(</span>bytes32</span>[</span>2</span>]</span> calldata</span> verificationHashes</span>)</span> external</span>;</span></span>
</span>
    //</span> Function to revoke the decentralized identity for the caller.</span></span>
    function</span> revokeIdentity</span>(</span>)</span> external</span>;</span></span>
    </span></span>
    //</span> Function to retrieve the decentralized identity for a given user address</span></span>
    //</span> Parameters:</span></span>
    //</span> - userAddress Ethereum address of the user.</span></span>
    //</span> Returns:</span></span>
    //</span> identity The decentralized identity struct.</span></span>
    function</span> getIdentity</span>(</span>address</span> userAddress</span>)</span> external</span> view</span> returns</span> (</span>Identity</span> memory</span>)</span>;</span></span>
}</span></span></code></pre>Rationale</h2>
The design leverages cryptographic hashes to represent identity information, ensuring that sensitive data is not stored directly on the blockchain. The use of verificationHashes</code> allows for flexible identity verification mechanisms. These hashes could be derived from various off-chain proofs, such as cryptographic challenges or attestations, depending on the implementer's needs. By leaving the interpretation of the verification hashes open, the standard enables adaptability while maintaining privacy and security. Additionally, the inclusion of events ensures transparency and traceability.</p>
Reference Implementation</h2>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
import</span> "./IDecentralizedIdentity.sol"</span>;</span></span>
</span>
contract</span> DecentralizedIdentity</span> is</span> IDecentralizedIdentity</span> {</span></span>
    //</span> Mapping to store identities by user address</span></span>
    mapping</span>(</span>address</span> =></span> Identity</span>)</span> private</span> identities</span>;</span></span>
</span>
    //</span> Function to create a new decentralized identity for the caller.</span></span>
    //</span> Parameters:</span></span>
    //</span> - identityHash Hash of the identity data.</span></span>
    function</span> createIdentity</span>(</span>bytes32</span> identityHash</span>)</span> external</span> override</span> {</span></span>
        //</span> Ensure identity does not already exist</span></span>
        require</span>(</span>identities</span>[</span>msg.sender</span>]</span>.</span>userAddress </span>==</span> address</span>(</span>0</span>)</span>,</span> "Identity already exists"</span>)</span>;</span></span>
</span>
        //</span> Create the identity for the caller</span></span>
        identities</span>[</span>msg.sender</span>]</span> =</span> Identity</span>(</span>{</span></span>
            userAddress</span>:</span> msg.sender</span>,</span></span>
            identityHash</span>:</span> identityHash</span>,</span></span>
            verificationHashes</span>:</span> [</span>bytes32</span>(</span>0</span>)</span>,</span> bytes32</span>(</span>0</span>)</span>]</span>,</span> //</span> Initialize with empty hashes</span></span>
            isVerified</span>:</span> false</span>,</span></span>
            timestamp</span>:</span> block</span>.</span>timestamp</span></span>
        }</span>)</span>;</span></span>
</span>
        //</span> Emit event for the creation of a new identity</span></span>
        emit</span> IdentityCreated</span>(</span>msg.sender</span>,</span> identityHash</span>,</span> block</span>.</span>timestamp</span>)</span>;</span></span>
    }</span></span>
</span>
    //</span> Function to verify the decentralized identity for the caller.</span></span>
    //</span> Parameters:</span></span>
    //</span> - verificationHashes: Hashes used for verifying the identity.</span></span>
    function</span> verifyIdentity</span>(</span>bytes32</span>[</span>2</span>]</span> calldata</span> verificationHashes</span>)</span> external</span> override</span> {</span></span>
        //</span> Ensure identity exists</span></span>
        require</span>(</span>identities</span>[</span>msg.sender</span>]</span>.</span>userAddress </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Identity does not exist"</span>)</span>;</span></span>
</span>
        //</span> Update verification hashes and mark identity as verified</span></span>
        identities</span>[</span>msg.sender</span>]</span>.</span>verificationHashes </span>=</span> verificationHashes</span>;</span></span>
        identities</span>[</span>msg.sender</span>]</span>.</span>isVerified </span>=</span> true</span>;</span></span>
</span>
        //</span> Emit event for the verification of identity</span></span>
        emit</span> IdentityVerified</span>(</span>msg.sender</span>,</span> verificationHashes</span>,</span> block</span>.</span>timestamp</span>)</span>;</span></span>
    }</span></span>
</span>
    //</span> Function to revoke the decentralized identity for the caller.</span></span>
    function</span> revokeIdentity</span>(</span>)</span> external</span> override</span> {</span></span>
        //</span> Ensure identity exists</span></span>
        require</span>(</span>identities</span>[</span>msg.sender</span>]</span>.</span>userAddress </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Identity does not exist"</span>)</span>;</span></span>
</span>
        //</span> Mark identity as not verified</span></span>
        identities</span>[</span>msg.sender</span>]</span>.</span>isVerified </span>=</span> false</span>;</span></span>
</span>
        //</span> Emit event for the revocation of identity</span></span>
        emit</span> IdentityRevoked</span>(</span>msg.sender</span>,</span> block</span>.</span>timestamp</span>)</span>;</span></span>
    }</span></span>
</span>
    //</span> Function to retrieve the decentralized identity for a given user address</span></span>
    //</span> Parameters:</span></span>
    //</span> - userAddress Ethereum address of the user.</span></span>
    //</span> Returns:</span></span>
    //</span> identity The decentralized identity struct.</span></span>
    function</span> getIdentity</span>(</span>address</span> userAddress</span>)</span> external</span> view</span> override</span> returns</span> (</span>Identity</span> memory</span>)</span> {</span></span>
        return</span> identities</span>[</span>userAddress</span>]</span>;</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Secure Hashing</strong>: Ensure that identity and verification hashes are generated using a secure hashing algorithm to prevent collisions and ensure the integrity of the identity data.
Replay Attacks</strong>: Verification hashes should incorporate nonces or timestamps to prevent replay attacks.
Implementation Flexibility</strong>: Developers must ensure that hash generation and validation processes are robust and resistant to manipulation.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Set Code for EOAs
2024-05-07T00:00:00+00:00
Abstract</h2>
Add a new EIP-2718</a> transaction type that allows Externally
Owned Accounts (EOAs) to set the code in their account. This is done by
attaching a list of authorization tuples -- individually formatted as [chain_id, address, nonce, y_parity, r, s]</code> -- to the transaction. For each tuple, a
delegation indicator (0xef0100 || address)</code> is written to the authorizing
account's code. All code executing operations must load and execute the code
pointed to by the delegation.</p>
Motivation</h2>
Despite great advances in the smart contract wallet ecosystem, EOAs have held
back broad adoption of UX improvements across applications. This EIP therefore
focuses on adding short-term functionality improvements to EOAs which will allow
UX improvements to permeate through the entire application stack. Three
particular features this EIP is designed around are:</p>

Batching</strong>: allowing multiple operations from the same user in one atomic
transaction. One common example is an ERC-20</a> approval followed by
spending that approval. This is a common workflow in DEXes that requires two
transactions today. Advanced use cases of batching occasionally involve
dependencies: the output of the first operation is part of the input to the
second operation.</li>
Sponsorship</strong>: account X pays for a transaction on behalf of account Y.
Account X could be paid in some other ERC-20 for this service, or it could be an
application operator including the transactions of its users for free.</li>
Privilege de-escalation</strong>: users can sign sub-keys and give them specific
permissions that are much weaker than global access to the account. For example,
a permission to spend ERC-20 tokens but not ETH, or to spend up to 1% of the
total balance per day, or to interact only with a specific application.</li>
</ul>
Specification</h2>
Parameters</h3>
Parameter</th> Value</th></tr></thead>

SET_CODE_TX_TYPE</code></td> 0x04</code></td></tr>
MAGIC</code></td> 0x05</code></td></tr>
PER_AUTH_BASE_COST</code></td> 12500</code></td></tr>
PER_EMPTY_ACCOUNT_COST</code></td> 25000</code></td></tr>
</tbody></table>
Set code transaction</h3>
A new EIP-2718</a> transaction known as the "set code transaction"
is introduced, where the TransactionType</code> is SET_CODE_TX_TYPE</code> and the
TransactionPayload</code> is the RLP serialization of the following:</p>
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,</span></span>
destination, value, data, access_list, authorization_list, signature_y_parity,</span></span>
signature_r, signature_s])</span></span>
</span>
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]</span></span></code></pre>
The fields chain_id</code>, nonce</code>, max_priority_fee_per_gas</code>, max_fee_per_gas</code>,
gas_limit</code>, destination</code>, value</code>, data</code>, and access_list</code> of the outer
transaction follow the same semantics as EIP-4844</a>. Note, this
implies a null destination is not valid.</em></p>
The signature_y_parity, signature_r, signature_s</code> elements of this transaction
represent a secp256k1 signature over keccak256(SET_CODE_TX_TYPE || TransactionPayload)</code>.</p>
The authorization_list</code> is a list of tuples that indicate what code the signer
of each tuple desires to execute in the context of their EOA. The transaction is
considered invalid if the length of authorization_list</code> is zero.</p>
The transaction is also considered invalid when any field in an authorization
tuple cannot fit within the following bounds:</p>
assert</span> auth</span>.</span>chain_id</span> <</span> 2</span>**</span>256</span></span>
assert</span> auth</span>.</span>nonce</span> <</span> 2</span>**</span>64</span></span>
assert</span> len</span>(</span>auth</span>.</span>address</span>)</span> ==</span> 20</span></span>
assert</span> auth</span>.</span>y_parity</span> <</span> 2</span>**</span>8</span></span>
assert</span> auth</span>.</span>r</span> <</span> 2</span>**</span>256</span></span>
assert</span> auth</span>.</span>s</span> <</span> 2</span>**</span>256</span></span></code></pre>
The EIP-2718</a> ReceiptPayload</code> for this transaction is
rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])</code>.</p>
Behavior</h4>
The authorization list is processed before the execution portion of the
transaction begins, but after the sender's nonce is incremented.</p>
For each [chain_id, address, nonce, y_parity, r, s]</code> tuple, perform the
following:</p>

Verify the chain ID is 0 or the ID of the current chain.</li>
Verify the nonce</code> is less than 2**64 - 1</code>.</li>
Let authority = ecrecover(msg, y_parity, r, s)</code>.

Where msg = keccak(MAGIC || rlp([chain_id, address, nonce]))</code>.</li>
Verify s</code> is less than or equal to secp256k1n/2</code>, as specified in
EIP-2</a>.</li>
</ul>
</li>
Add authority</code> to accessed_addresses</code>, as defined in EIP-2929</a>.</li>
Verify the code of authority</code> is empty or already delegated.</li>
Verify the nonce of authority</code> is equal to nonce</code>.</li>
Add PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST</code> gas to the global refund
counter if authority</code> is not empty.</li>
Set the code of authority</code> to be 0xef0100 || address</code>. This is a delegation
indicator.

If address</code> is 0x0000000000000000000000000000000000000000</code>, do not write
the delegation indicator. Clear the account's code by resetting the account's
code hash to the empty code hash
0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470</code>.</li>
</ul>
</li>
Increase the nonce of authority</code> by one.</li>
</ol>
If any step above fails, immediately stop processing the tuple and continue to
the next tuple in the list. When multiple tuples from the same authority are
present, set the code using the address in the last valid occurrence.</p>
Note, if transaction execution results in failure (e.g. any exceptional
condition or code reverting), the processed delegation indicators is not rolled
back</em>.</p>
Delegation indicator</h5>
Delegation indicators use the banned opcode 0xef</code>, defined in
EIP-3541</a>, to indicate that the code must be handled differently
than regular code. The delegation forces all code executing operations to follow
the address pointer to obtain the code to execute. For example, CALL</code> loads the
code at address</code> and executes it in the context of authority</code>.</p>
The affected executing operations are:</p>

CALL</code></li>
CALLCODE</code></li>
DELEGATECALL</code></li>
STATICCALL</code></li>
any transaction where destination</code> points to an address with a delegation
indicator present</li>
</ul>
For code reading, only CODESIZE</code> and CODECOPY</code> instructions are affected. They
operate directly on the executing code instead of the delegation. For example,
when executing a delegated account EXTCODESIZE</code> returns 23</code> (the size of
0xef0100 || address</code>) whereas CODESIZE</code> returns the size of the code residing
at address</code>.</p>
Note, this means during delegated execution CODESIZE</code> and CODECOPY</code> produce a
different result compared to calling EXTCODESIZE</code> and EXTCODECOPY</code> on the
authority.</em></p>
Precompiles</h6>
When a precompile address is the target of a delegation, the retrieved code is
considered empty and CALL</code>, CALLCODE</code>, STATICCALL</code>, DELEGATECALL</code>
instructions targeting this account will execute empty code, and therefore
succeed with no execution when given enough gas to initiate the call.</p>
Loops</h6>
In case a delegation indicator points to another delegation, creating a
potential chain or loop of delegations, clients must retrieve only the first
code and then stop following the delegation chain.</p>
Gas Costs</h4>
The intrinsic cost of the new transaction is inherited from
EIP-2930</a>, specifically 21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count</code>. Additionally, add a cost of PER_EMPTY_ACCOUNT_COST * authorization list length</code>.</p>
The transaction sender will pay for all authorization tuples, regardless of
validity or duplication.</p>
If a code executing instruction accesses a cold account during the resolution of
delegated code, add an additional EIP-2929</a>
COLD_ACCOUNT_READ_COST</code> cost of 2600</code> gas to the normal cost and add the
account to accessed_addresses</code>. Otherwise, assess a WARM_STORAGE_READ_COST</code>
cost of 100</code>.</p>
Transaction origination</h4>
Modify the restriction put in place by EIP-3607</a> to allow EOAs
whose code is a valid delegation indicator, i.e. 0xef0100 || address</code>, to
originate transactions. Accounts with any other code values may not originate
transactions.</p>
Additionally, if a transaction's destination</code> has a delegation indicator, add
the target of the delegation to accessed_addresses</code>.</p>
Rationale</h2>
Below is the rationale for both general design directions of the EIP, as well as
specific technical choices.</p>
General design philosophy</h3>
Persistence of code delegation</h4>
The first draft of this proposal had a clever idea to avoid disagreement on
whether in-protocol revocation was needed or not. The idea was to temporarily
set code in the account with the authorization. After the transaction finished,
the code would be completely cleared. This was a new design space for enriching
EOA functionality.</p>
Even this approach was not without its flaws. Fundamentally, there was not much
friction for users including set code authorizations. This meant that some users
and applications would opt to treat the extension as more of a scripting
facility, rather than a full-fledged upgrade to a smart contract wallet. The
outcome of this would be two somewhat competing workstreams for UX improvements:
smart contract wallets and EOA scripts.</p>
Previous proposals had been met with similar criticisms. To counteract this,
persistent delegations were introduced. They create enough friction in
deployment that users will not deploy new, unique ones regularly. This will
hopefully unify the workstreams and minimize fragmentation in UX developments.</p>
No initcode</h4>
Running initcode is not desirable for many reasons. It creates a new mode of
execution that needs extensive testing, and may be used for purposes not
possible with standard smart contract wallets. It also forces developers to
perform initialization as a standard call to the EOA after delegation. The lack
of atomicity in these operations is another factor that will push users to
complete smart contract wallet solutions, instead of EOA scripts.</p>
Additionally, initcode tends to be propagated inside the transaction calldata.
This means it would need to be included in the authorization tuple and signed
over. The minimum initcode is around 15 bytes -- it would simply copy the
contract code from an external address. The total cost would be 16 * 15 = 240</code>
calldata cost, plus the EIP-3860</a> cost of 2 * 15 = 30</code>, plus
the runtime costs of around 150</code>. So nearly 500</code> additional gas would be spent
preparing the account. Even more likely, 1200+ gas if not copying from an
external account.</p>
Creation by template</h4>
Initcode or not, there is a question of how users should specify the code they
intend to run in their account. The two main options are to specify the bytecode
directly in the transaction or to specify a pointer to the code. The simplest
pointer would just be the address of code deployed on-chain.</p>
The cost analysis makes the answer clear. The smallest proxy would be around 50
bytes and an address is 20 bytes. The 30 byte difference provides no useful
additional functionality and will be inefficiently replicated billions of times.</p>
Furthermore, specifying code directly would again make it possible for EOAs to
have a new, unique ability to execute arbitrary code specified in the
transaction calldata. It is for these reasons that creation by template is
chosen.</p>
Interaction with applications and wallets</h4>
While this EIP provides a lot of flexibility to applications and EOAs, there are
incorrect ways of using it. Applications must not</strong> expect that they can
suggest the user sign an authorization, and therefore it is the duty of the
wallet to not provide an interface to do so.</p>
There is no safe way to provide this interface</strong>. The code specified by an
authorization has unrestricted access to the account and must always be closely
audited by the wallet. Few users have the level of sophistication to reasonably
verify the code they are delegating to.</p>
It is also not possible to implement a system of permissions at this level to
minimize the risk. If applications require custom wallet functionality, they
must use standardized extension / module systems built on top of the delegated
code that correctly implements permissions.</p>
Forward-compatibility with future account abstraction</h4>
This EIP is designed to be forward-compatible with endgame account abstraction,
without over-enshrining any fine-grained details of ERC-4337</a> or
RIP-7560.</p>
To start, the address</code> that users sign could directly point to existing
ERC-4337 wallet code. This essentially requires the "code pathways" that are
used are code pathways that would, in most cases, continue to make sense in a
pure-smart-contract-wallet world. Hence, it avoids the problem of creating two
separate UX workstreams because, to a large extent, they would be the same
ecosystem.</p>
There will be some workflows that require kludges under this solution that would
be better done in some different "more native" under "endgame AA", but this is
relatively a small subset. The EIP does not require adding any opcodes, that
would become dangling and useless in a post-EOA world, and it allows EOAs to
masquerade as contracts to be included in ERC-4337 bundles, in a way that's
compatible with the existing EntryPoint</code>.</p>
Self-sponsoring: allowing tx.origin</code> to set code</h4>
Allowing tx.origin</code> to set code and execute its own delegated code enables what
is called self-sponsoring. It allows users to take advantage of EIP-7702 without
relying on any third party infrastructure.</p>
However, that means the EIP breaks the invariant that msg.sender == tx.origin</code>
only happens in the topmost execution frame of a transaction. This will affect
smart contracts containing require(msg.sender == tx.origin)</code> style checks. This
check is used for at least three purposes:</p>

Ensuring that msg.sender</code> is an EOA (given that tx.origin</code> always has to be
an EOA). This invariant does not depend on the execution layer depth and,
therefore, is not affected.</li>
Protecting against atomic sandwich attacks like flash loans, which rely on
the ability to modify state before and after the execution of the target
contract as part of the same atomic transaction. This protection would be broken
by this EIP. However, relying on tx.origin</code> in this way is considered bad
practice, and can already be circumvented by miners conditionally including
transactions in a block.</li>
Preventing reentrancy.</li>
</ol>
Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet,
with (1) being more common (and unaffected by this proposal). On the other hand,
use case (3) is more severely affected by this proposal, but the authors of this
EIP did not find any examples of this form of reentrancy protection, though the
search was non-exhaustive.</p>
This distribution of occurrences—many (1), some (2), and no (3)—is exactly what
the authors of this EIP expect because:</p>

Determining if msg.sender</code> is an EOA without tx.origin</code> is difficult, if not
impossible.</li>
The only execution context which is safe from atomic sandwich attacks is the
topmost context, and tx.origin == msg.sender</code> is the only way to detect that
context.</li>
In contrast, there are many direct and flexible ways of preventing reentrancy
(e.g., using a transient storage variable). Since msg.sender == tx.origin</code> is
only true in the topmost context, it would make an obscure tool for preventing
reentrancy, rather than other more common approaches.</li>
</ul>
There are other approaches to mitigate this restriction which do not break the
invariant:</p>

Set tx.origin</code> to a constant ENTRY_POINT</code> address when using the CALL*</code>
instruction in the context of an EOA.</li>
Set tx.origin</code> to a special address derived from the sender or signer
addresses.</li>
Disallow tx.origin</code> from setting code. This would make the simple batching
use cases impossible, but could be relaxed in the future.</li>
</ul>
Rationale for technical details</h3>
Cost of delegation</h4>
The PER_AUTH_BASE_COST</code> is the cost to process the authorization tuple and set
the delegation destination. To compute a fair cost for this operation, the
authors review its impact on the system:</p>

ferry 101 bytes of calldata = 101 * non-zero cost (16) = 1616</code></li>
recovering the authority</code> address = 3000</code></li>
reading the nonce and code of authority</code> = 2600</code></li>
storing values in already warm account = 200</code></li>
cost to deploy code = 200 * 23 = 4600</code></li>
</ul>
The impact-based assessment identifies 12016</code> gas of comparable computation for
the operation. It is rounded up to 12500</code> to account for miscellaneous costs
associated with shuttling data around the state transition.</p>
Clearing delegation indicators</h4>
A general design goal in state transition changes is to minimize the number of
special cases an EIP has. In early iterations, this EIP resisted a special case
for clearing an account's delegation indicator.</p>
For most intents and purposes, an account delegated to 0x0</code> is
indistinguishable from a true EOA. However, one particular unfortunate case is
unavoidable. Even if a user has a zeroed out delegation indicator, most
operations that interact with that account will incur an additional
COLD_ACCOUNT_READ_COST</code> upon the first touch caused by attempting to load the
code at 0x0</code>.</p>
For this reason, the authors have opted to include a special case which allow
users to restore their EOA to its original purity.</p>
Lack of instruction prohibition</h4>
Consistency is a valuable property in the EVM, both from an implementation
perspective and a user-understanding-perspective. Despite considering bans on
several families of instructions in the context of EOAs, the authors feel there
is not a compelling reason to do so, as it would cause smart contract wallets
and EOA smart contract wallets to proceed down distinct UX workstreams.</p>
The main instruction families where a ban was considered were storage related
and contract creation related. The decision to not ban storage instructions
hinged mostly on their importance to smart contract wallets. Although it's
possible to have an external storage contract that the smart contract wallet
calls into, it is unnecessarily complicated and inefficient. In the future, new
state schemes may allow substantially cheaper access to certain storage slots
within an account. This is something smart contract wallets will want to take
advantage of that a storage contract wouldn't support.</p>
Creation instructions were considered for a ban as well on other similar EIPs,
however because this EIP allows EOAs to spend value intra-transaction, the
concern with bumping the nonce intra-transaction and invalidating pending
transactions is not significant.</p>
Protection from malleability cross-chain</h4>
One consideration when signing a code pointer is what code that address points
to on another chain. While it is possible to create a deterministic deployment,
i.e. via Nick's method, verifying such a deployment may not always be desirable.
In such situations, the chain ID can be set to reduce the scope of the
authorization. When universal deployment is preferred, simply set chain ID to 0.</p>
An alternative to adding chain ID could be to substitute in the actual code for
the address in the signature. This seems to have the benefit of both minimizing
the on-chain size of auth tuples, by continuing to serialize only the address,
while retaining specificity of the actual code running in the account, by
pulling in the code for the signature. One unfortunate issue of this format,
though, is that it imposes a database lookup to determine the signer of each
auth tuple. This imposition itself seems to create enough complexity in
transaction propagation that it is decided to avoid and simply sign over the
address directly.</p>
Delegation of code execution only</h4>
Other code retrieving operations like EXTCODEHASH</code> do not automatically follow
delegations, they operate on the delegation indicator itself. If instead
delegations were followed, an account would be able to temporarily masquerade as
having a particular codehash, which would break contracts that rely on
codehashes as a definition of possible account behavior. A change of behavior in
a contract is currently only possible if its code explicitly allows it (in
particular via DELEGATECALL</code>), and a change of codehash is only possible in the
presence of SELFDESTRUCT</code> (which, as of Cancun, only applies in the same
transaction as contract creation), so choosing to follow delegations in
EXTCODE*</code> opcodes would have created a new type of account breaking prior
assumptions.</p>
Charge maximum cost upfront</h4>
While computing the intrinsic gas cost, the transaction is charged the
worst-case cost for each delegation. Later, while processing the authorization
list, a refund is issued if the account already exists in state. This mechanism
is designed to avoid state lookups for each authorization when computing the
intrinsic gas and can quickly determine the validity of the transaction with
only a state lookup on the sender's account.</p>
No blobs, no contract creation</h4>
Transactions should be thought of as specialized tools and not necessarily a
one-type-does-all solution. EIP-4844 is treated differently at the p2p level due
to burden blobs place on a node's bandwidth. EIP-7702 has different implications
on transaction gossiping and there is no need to complicate those rules
unnecessarily by making it a superset of all possible functionality. The authors
ultimately do not expect there to be much demand for atomic delegation and blob
submission.</p>
Contract creation is another specialized use case that has been grandfathered
into several transaction types. It adds complexity to testing, because it is a
new distinct branch of execution that needs to be tested when any change to the
EVM occurs and verify the change works as expected in that context.</p>
For these reasons, the authors have chosen to keep the scope of the EIP focused
on improving UX.</p>
Disallow delegation to precompiles</h4>
Precompiles are themselves edge cases, so allowing delegations to precompiles or
not requires some focus in implementation. Considering the fact that precompiles
technically do not have code associated with their accounts, the authors decided
it would be marginally simpler to not execute the precompile logic when a user
delegates to one. This is somewhat unintuitive.</p>
Non-empty authorization list required</h4>
Set code transactions are required to have at least one authorization to be
considered valid. This is to disincentivize senders from using type 4
transactions as a generic transaction format, because this transaction has
different implications on the transaction pool than, say,
EIP-1559</a> transactions.</p>
Backwards Compatibility</h2>
This EIP breaks a few invariants:</p>

An account balance can only decrease as a result of a transaction originating
from that account.

Once an account has been delegated, any call to the account may also cause
the balance to decrease.</li>
</ul>
</li>
An EOA nonce may not increase after transaction execution has begun.

Once an account has been delegated, the account may call a create operation
during execution, causing the nonce to increase.</li>
</ul>
</li>
tx.origin == msg.sender</code> can only be true in the topmost frame of execution.

Once an account has been delegated, it can invoke multiple calls per
transaction.</li>
</ul>
</li>
</ul>
Security Considerations</h2>
Implementation of secure delegate contracts</h3>
The following is a non-exhaustive list of pitfalls that delegate contracts
should</em> be wary of and require a signature over from the account's authority:</p>

Replay protection (e.g., a nonce) should be implemented by the delegate and
signed over. Without it, a malicious actor can reuse a signature, repeating its
effects.</li>
value</code> -- without it, a malicious sponsor could cause unexpected effects in
the callee.</li>
gas</code> -- without it, a malicious sponsor could cause the callee to run out of
gas and fail, griefing the sponsee.</li>
target</code> / calldata</code> -- without them, a malicious actor may call arbitrary
functions in arbitrary contracts.</li>
</ul>
A poorly implemented delegate can allow a malicious actor to take near complete
control over a signer's EOA</em>.</p>
Front running initialization</h3>
Smart contract wallet developers must consider the implications of setting code
in an account without execution. Contracts are normally deployed by executing
initcode to determine the exact code to be placed in the account. This gives
developers the opportunity to initialize storage slots at the same time. The
initial values of the account cannot be replaced by an observer, because they
are either signed over by an EOA in the case of a creation transaction or they
are committed to by computing the contract's address deterministically from the
hash of the initcode.</p>
This EIP does not provide developers the opportunity to run initcode and set
storage slots during delegation. To secure the account from an observer
front-running the initialization of the delegation with an account they control,
smart contract wallet developers must verify the initial calldata to the account
for setup purposes be signed by the EOA's key using ecrecover. This ensures the
account can only be initialized with desirable values.</p>
Storage management</h3>
Changing an account's delegation is a security-critical operation that should
not be done lightly, especially if the newly delegated code is not purposely
designed and tested as an upgrade to the old one.</p>
In particular, in order to ensure a safe migration of an account from one
delegate contract to another, it's important for these contracts to use storage
in a way that avoids accidental collisions among them. For example, using
ERC-7201</a> a contract may root its storage layout at a slot
dependent on a unique identifier. To simplify this, smart contract languages may
provide a way of re-rooting the entire storage layout of existing contract
source code.</p>
If all contracts previously delegated to by the account used the approach
described above, a migration should not cause any issues. However, if there is
any doubt, it is recommended to first clear all account storage, an operation
that is not natively offered by the protocol but that a special-purpose delegate
contract can be designed to implement.</p>
Setting code as tx.origin</code></h3>
Allowing the sender of an EIP-7702 to also set code has the possibility to:</p>

Break atomic sandwich protections which rely on tx.origin</code>;</li>
Break reentrancy guards of the style require(tx.origin == msg.sender)</code>.</li>
</ul>
The authors of this EIP believe the risks of allowing this are acceptable for
the reasons outlined in the Rationale section.</p>
Sponsored transaction relayers</h3>
It is possible for the authorized</code> account to cause sponsored transaction
relayers to spend gas without being reimbursed by either invalidating the
authorization (i.e., increasing the account's nonce) or by sweeping the relevant
assets out of the account. Relayers should be designed with these cases in mind,
possibly by requiring a bond to be deposited or by implementing a reputation
system.</p>
Transaction propagation</h3>
Allowing EOAs to behave as smart contracts via the delegation indicator poses
some challenges for transaction propagation. Traditionally, EOAs have only been
able to send value via a transaction. This invariant allows nodes to statically
determine the validity of transactions for that account. In other words, a
single transaction has only been able to invalidate transactions pending from
the sender's account.</p>
With this EIP, it becomes possible to cause transactions from other accounts to
become stale. This is due to the fact that once an EOA has delegated to code,
that code can be called by anyone at any point in a transaction. It becomes
impossible to know if the balance of the account has been swept in a static
manner.</p>
While there are a few mitigations for this, the authors recommend that clients
do not accept more than one pending transaction for any EOA with a non-zero
delegation indicator. This minimizes the number of transactions that can be
invalidated by a single transaction.</p>
An alternative would be to expand the EIP-7702 transaction with a list of
accounts the caller wishes to "hydrate" during the transaction. Those accounts
behave as the delegated code only</em> for EIP-7702 transactions which include them
in such a list, thus returning to clients the ability to statically analyze and
reason about pending transactions.</p>
A related issue is that an EOA's nonce may be incremented more than once per
transaction. Because clients already need to be robust in a worse scenario
(described above), it isn't a major concern. However, clients should be aware
this behavior is possible and design their transaction propagation accordingly.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Blob throughput increase
2024-04-17T00:00:00+00:00
Abstract</h2>
Increases the number of blobs in a block to provide more scale to Ethereum via L2 solution that rely on L1 data capacity.</p>
Motivation</h2>
Ethereum, with its rollup centric roadmap, scales by relying on L2. Since the Dencun fork, the blob gas target and maximum was set to 3/6 respectively. The blob gas limit was arrived at based on a series of big block tests performed on the Ethereum mainnet network as well as a series of testnets. The values were chosen cautiously, as it's extremely hard to predict the exact p2p behaviour of Ethereum mainnet.</p>
As we now have the Dencun upgrade live, we are able to use monitoring tools to check the network health. Initial monitoring indicates that we have a stable network with the current gas target and the re-org rate is trending downwards. Additionally, analysis on messages in gossipsub indicate that the inclusion of IDONTWANT</code> messages could bring us a significant bandwidth savings. This allows us to consider starting a series of big block and blob tests to determine the theoretical headroom we currently have. The EIP specifies a proposed new blob gas target and limit based on the series of tests.</p>
This EIP aims to increase the throughput short term to provide some scaling until future solutions are deployed. In order to alleviate valid concerns about solo-stakers, approaches such as the inclusion of a flag indicating the max blobs per block for locally built blocks could be considered.</p>
Specification</h2>
Parameters</h3>
Constant</th> Value</th></tr></thead>

MAX_BLOBS_PER_BLOCK_ELECTRA</code></td> 9</code></td></tr>
TARGET_BLOBS_PER_BLOCK_ELECTRA</code></td> 6</code></td></tr>
MAX_BLOB_GAS_PER_BLOCK</code></td> 1179648</code></td></tr>
TARGET_BLOB_GAS_PER_BLOCK</code></td> 786432</code></td></tr>
BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code></td> 5007716</code></td></tr>
</tbody></table>
MAX_BLOBS_PER_BLOCK_ELECTRA</code> and TARGET_BLOBS_PER_BLOCK_ELECTRA</code> are consumed by the consensus layer clients, and starting at PECTRA_FORK_EPOCH</code> replace the respective old max and target values.</p>
MAX_BLOB_GAS_PER_BLOCK</code>, TARGET_BLOB_GAS_PER_BLOCK</code> and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> are consumed by the execution layer clients, and starting at the epoch when this EIP is activated, replace the old max, target and update fraction values.
Any references to MAX_BLOB_GAS_PER_BLOCK</code> and TARGET_BLOB_GAS_PER_BLOCK</code> in EIP-4844</a> should be updated to the new values defined in this EIP when processing the activation block.
The value BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> replaces its previous equivalent when processing the activation block.
These changes imply that get_base_fee_per_blob_gas</code> and calc_excess_blob_gas</code> functions defined in EIP-4844</a> use the new values for the first block of the fork (and for all subsequent blocks).</p>
Rationale</h2>
Simplicity</h3>
The EIP aims to minimize the amount of testing and implementation effort from the perspective of the client teams, to allow for more resources to be allocated to peerDAS and other scaling research.</p>
While this EIP may not achieve the new optimal blob limit, it offers a compromise for a short term increase.</p>
Update Fraction</h3>
The original target and max values from EIP-4844</a> were at a 1:2 ratio. As a consequence, responsiveness to full and empty blob sections was symmetrical:</p>

full blobs: basefee increases by ~12.5%</li>
no blobs: basefee decreases by ~11.1%</li>
</ul>
The new target and max values from this EIP are at a 2:3 ratio, which breaks that symmetry. As a consequence, the basefee becomes significantly more responsive to empty blob sections (that are 6 blobs under target) than to full ones (that are 3 blobs over target). This is by design, as it takes two blocks with full blobs in a row to make up for a single block with no blobs. However, it creates the challenge of finding a good compromise base fee sensitivity level.</p>
The BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> value in this EIP is chosen as the mid-point between keeping the responsiveness to full blobs and no blobs constant:</p>

full blobs: basefee increases by ~8.2%</li>
no blobs: basefee decreases by ~14.5%</li>
</ul>
Backwards Compatibility</h2>
The consensus clients would continue to use MAX_BLOBS_PER_BLOCK</code> and TARGET_BLOBS_PER_BLOCK</code> for the deneb fork and once the ELECTRA</code> fork is active, they would use MAX_BLOBS_PER_BLOCK_ELECTRA</code> and TARGET_BLOBS_PER_BLOCK_ELECTRA</code> respectively.</p>
The execution clients would continue to use MAX_BLOB_GAS_PER_BLOCK</code>, TARGET_BLOB_GAS_PER_BLOCK</code> and BLOB_BASE_FEE_UPDATE_FRACTION</code> for the cancun fork and once the prague fork is active, they would use MAX_BLOB_GAS_PER_BLOCK</code>, TARGET_BLOB_GAS_PER_BLOCK</code> and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE</code> respectively.</p>
Security Considerations</h2>
Network Impacts</h3>
Through the use of big block/blob tests on Ethereum mainnet as well as testnets, we can earn a high degree of certainty that the blob limit increase would not negatively impact the network. These tests as well as the associated analysis can be performed mostly by non-client team entities, with minimal input required. Since the changes are quite contained, the EIP should be able to reduce the risk of the blob limit increase.</p>
Stability Around Fork Epoch</h3>
A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


General purpose execution layer requests
2024-04-14T00:00:00+00:00
Abstract</h2>
This proposal defines a general purpose framework for storing contract-triggered
requests. It extends the execution header with a single field to store the
request information. Requests are later on exposed to the consensus layer, which
then processes each one.</p>
Motivation</h2>
The proliferation of smart contract controlled validators has caused there to be
a demand for additional EL triggered behaviors. By allowing these systems to
delegate administrative operations to their governing smart contracts, they can
avoid intermediaries needing to step in and ensure certain operations occur.
This creates a safer system for end users. By abstracting each individual request
details from the EL, adding new request types is simpler and does not require an
update on the execution block structure.</p>
Specification</h2>
Execution Layer</h3>
Requests</h4>
A requests</code> object consists of a request_type</code> byte prepended to an opaque byte array
request_data</code>. The request_data</code> contains zero or more encoded request objects.</p>
requests = request_type ++ request_data</span></span></code></pre>
Each request type will define its own requests</code> object with its own request_data</code> format.</p>
Block Header</h4>
Extend the header with a new 32 byte commitment value requests_hash</code>.</p>
While processing a block, multiple requests</code> objects with different request_type</code>s will
be produced by the system, and accumulated in the block requests list.</p>
In order to compute the commitment, an intermediate hash list is first built by hashing
all non-empty requests elements of the block requests list. Items with empty
request_data</code> are excluded, i.e. the intermediate list skips requests</code> items which
contain only the request_type</code> (1 byte) and nothing else.</p>
Within the intermediate list, requests</code> items must be ordered by request_type</code> ascending.</p>
The final commitment is computed as the sha256 hash of the intermediate element hashes.</p>
def</span> compute_requests_hash</span>(</span>block_requests</span>:</span> Sequence</span>[</span>bytes</span>]</span>)</span>:</span></span>
    m</span> =</span> sha256</span>(</span>)</span></span>
    for</span> r</span> in</span> block_requests</span>:</span></span>
        if</span> len</span>(</span>r</span>)</span> ></span> 1</span>:</span></span>
            m</span>.</span>update</span>(</span>sha256</span>(</span>r</span>)</span>.</span>digest</span>(</span>)</span>)</span></span>
    return</span> m</span>.</span>digest</span>(</span>)</span></span>
</span>
block</span>.</span>header</span>.</span>requests_hash</span> =</span> compute_requests_hash</span>(</span>requests</span>)</span></span></code></pre>Consensus Layer</h3>
Each proposal may choose how to extend the beacon chain types to include new EL request
types.</p>
Rationale</h2>
Opaque byte array rather than an RLP array</h3>
By having the bytes of request_data</code> array from second byte on be opaque bytes, rather
than an RLP (or other encoding) list, we can support different encoding formats for the
request payload in the future such as SSZ, LEB128, or a fixed width format.</p>
Request source and validity</h3>
This EIP makes no strict requirement where a request may come from nor when/how
a request must be validated. This is to provide future protocol designers
maximum flexibility.</p>
The authors' recommendations on source and validity of requests are:</p>

The source of requests should be from the execution of transactions. More
specifically, transactions which make calls to designated system contracts
that store the request in account. The storage would later be retrieved by a
post-block system call to the contract. Alternatively, if the system call does
not need to be inherently concerned with rate limiting, it could rely simply
on emitting an event which is later parsed post-block by the system and
converted into a request.</li>
A request's validity can often not be fully verified at the execution layer.
This is why they are referred to merely as "requests"; they do not carry the
authority on their own to unilaterally catalyze an action. We expect the system
contracts to perform whatever validation is possible by the EL and then pass
it on to the CL for further validation.</li>
</ul>
Ordering</h3>
The ordering across types is ascending by type. This is to simplify the process
of verifying that all requests which were committed to in requests_hash</code> match.</p>
An alternative could be to order by when the request was generated within the
block. Since it's expected that many requests will be accumulated at the end of
the block via system calls, this would be difficult to enforce. Therefore,
ordering by type is the most straightforward ordering which ensures integrity.</p>
Intra-type</h4>
Within the same type, order is not defined. This is because the data of the
request is opaque as far as this EIP is concerned. Therefore, it is to be
determined by each request type individually.</p>
Removing empty requests in commitment</h3>
We exclude empty requests elements from the requests_hash</code> commitment in order to get a
stable 'empty' hash value that is independent of the blockchain fork. For a block with no
requests data, the requests_hash</code> is simply sha256("")</code>.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Test Cases</h2>
TODO</p>
Security Considerations</h2>
Needs discussion.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Generalized Contract-Linked Services
2024-03-15T00:00:00+00:00
Abstract</h2>
This proposal defines a factory capable of deploying generic services linked to specific contracts, such as ERC-4337</a> accounts or ERC-721</a> tokens (NFTs). These linked services extend the functionalities of the target contract, operating under the ownership of the contract's or NFT's owner without requiring modifications to the original contract's code. This approach enables extending existing contracts with new capabilities while maintaining backward compatibility with deployed instances.</p>
Motivation</h2>
Existing projects, like token-bound accounts, successfully bind smart accounts to NFTs, allowing registries to deploy accounts owned by specific token IDs. However, these standards have two key limitations:</p>

They often require deployed contracts to implement specific interfaces for handling assets and executing transactions, effectively mandating that the deployed contract must function as an account.</li>
They are restricted to NFTs, while many other contract types (particularly ERC-4337</a> accounts) could benefit from similar linking mechanisms to extend their functionalities.</li>
</ol>
This ERC proposes a more versatile factory specification that enables the deployment of proxies pointing to any contract that enhances the associated contract's capabilities, whether it's an NFT or an account contract.</p>
Key Benefits</h3>


Universal Linkability</strong>: Enables services to be linked to any compatible contract type, not just NFTs, creating a unified approach to contract extension.</p>
</li>

Non-Invasive Enhancement</strong>: Services can add functionality to existing smart accounts without modifying the underlying contract, maintaining compatibility with infrastructure like wallets and indexers.</p>
</li>

Backward Compatibility</strong>: Maintains compatibility with existing token-bound accounts while extending functionality to new use cases.</p>
</li>

Flexible Implementation</strong>: The mode</code> parameter enables different linkage types (with or without token IDs) while ensuring consistent deterministic addressing.</p>
</li>

Unified Extension Mechanism</strong>: Provides a standardized approach for extending existing contracts with new capabilities, reducing the need for specialized implementations across different use cases.</p>
</li>
</ul>
Use Cases for ERC-4337 Smart Accounts</h3>


Social Recovery Services</strong>: Deploy a social recovery mechanism linked to an existing ERC-4337 wallet that can restore access if credentials are lost, without requiring the wallet to implement recovery functionality natively.</p>
</li>

Customizable Permission Systems</strong>: Add granular permissions to an account (time-limited access, spending limits, multi-signature approvals) without rebuilding the account from scratch.</p>
</li>

Account Abstraction Extensions</strong>: Implement advanced features like batch transactions, gas sponsorship, or session keys as linked services, allowing wallets to adopt these features selectively.</p>
</li>

Identity and Reputation Services</strong>: Link verifiable credentials or reputation systems to accounts, enabling privacy-preserving identity verification.</p>
</li>
</ol>
Use Cases for NFTs</h3>


Enhanced Token Utility</strong>: Provide NFTs with financial capabilities like staking, lending, or revenue distribution.</p>
</li>

Dynamic Metadata Services</strong>: Enable NFT metadata to evolve based on on-chain activities without changing the NFT itself.</p>
</li>

Fractional Ownership</strong>: Implement fractional ownership mechanisms for high-value NFTs through linked contracts.</p>
</li>

Conditional Access Control</strong>: Create time-locked or challenge-based access to NFT-gated content or services.</p>
</li>

Real World Asset Management</strong>: Extend NFTs to represent and manage real-world assets (RWAs) by linking services that handle compliance, legal documentation, custody verification, transfer restrictions, and regulatory reporting without requiring specialized NFT standards for each asset class.</p>
</li>
</ol>
Specification</h2>
The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "NOT RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
The IERC7656Factory</code> interface is defined as follows:</p>
</span>
interface</span> IERC7656Factory</span> {</span></span>
  event</span> Created</span>(</span></span>
    address</span> contractAddress</span>,</span></span>
    address</span> indexed</span> implementation</span>,</span></span>
    bytes32</span> salt</span>,</span></span>
    uint256</span> chainId</span>,</span></span>
    bytes12</span> mode</span>,</span></span>
    address</span> indexed</span> linkedContract</span>,</span></span>
    uint256</span> indexed</span> linkedId</span></span>
  )</span>;</span></span>
</span>
  error</span> CreationFailed</span>(</span>)</span>;</span></span>
</span>
  function</span> create</span>(</span></span>
    address</span> implementation</span>,</span></span>
    bytes32</span> salt</span>,</span></span>
    uint256</span> chainId</span>,</span></span>
    bytes12</span> mode</span>,</span></span>
    address</span> linkedContract</span>,</span></span>
    uint256</span> linkedId</span></span>
  )</span> external</span> returns</span> (</span>address</span>)</span>;</span></span>
</span>
  function</span> compute</span>(</span></span>
    address</span> implementation</span>,</span></span>
    bytes32</span> salt</span>,</span></span>
    uint256</span> chainId</span>,</span></span>
    bytes12</span> mode</span>,</span></span>
    address</span> linkedContract</span>,</span></span>
    uint256</span> linkedId</span></span>
  )</span> external</span> view</span> returns</span> (</span>address</span> service</span>)</span>;</span></span>
}</span></span></code></pre>Linking Modes</h3>
The mode</code> parameter serves as a selector for how the linked contract should be interpreted and utilized. Currently, ERC-7656</a> defines two standard modes:</p>
bytes12</span> constant</span> NO_LINKED_ID </span>=</span> 0x000000000000000000000001</span>;</span></span>
bytes12</span> constant</span> LINKED_ID </span>=</span> 0x000000000000000000000000</span>;</span></span></code></pre>


LINKED_ID Mode (0x000000000000000000000000)</strong>: Used when linking a service to an NFT or any contract that requires a token/entity ID. This mode ensures compatibility with existing token-bound account systems.</p>
</li>

NO_LINKED_ID Mode (0x000000000000000000000001)</strong>: Used when linking a service to a contract that doesn't require an ID parameter, such as an ERC-4337</a> account. In this case, the linkedId</code> parameter is still present in the interface for consistency but SHOULD be set to zero if not used to store alternative data relevant to the service.</p>
</li>
</ul>
The mode</code> parameter (being bytes12</code>) allows for future extensions beyond these initial modes, enabling more complex linkage patterns as ecosystem needs evolve.</p>
Deployment Requirements</h3>
Any ERC7656Factory</code> implementation MUST support the IERC7656Factory</code> interface ID (0x9e23230a</code>).</p>
Each linked service MUST be deployed as an ERC-1167</a> minimal proxy, appending immutable constant data to the bytecode. The deployed bytecode structure is:</p>
ERC-1167 Header               (10 bytes)</span></span>
<implementation (address)>    (20 bytes)</span></span>
ERC-1167 Footer               (15 bytes)</span></span>
<salt (bytes32)>              (32 bytes)</span></span>
<chainId (uint256)>           (32 bytes)</span></span>
<mode (bytes12)>              (12 bytes)</span></span>
<linkedContract (address)>    (20 bytes)</span></span>
<linkedId (uint256)>          (32 bytes)</span></span></code></pre>
Total bytecode size: 183 bytes</strong></p>
Linked services SHOULD implement the IERC7656Service</code> interface:</p>
//</span> Interface ID: 0x7e110a1d</span></span>
interface</span> IERC7656Service</span> {</span></span>
  function</span> linkedData</span>(</span>)</span> external</span> view</span></span>
    returns</span> (</span>uint256</span> chainId</span>,</span> bytes12</span> mode</span>,</span> address</span> linkedContract</span>,</span> uint256</span> linkedId</span>)</span>;</span></span>
}</span></span></code></pre>Implementation Patterns</h3>
When implementing a linked service, developers SHOULD consider the following patterns:</p>


Ownership Verification</strong>: Services SHOULD include mechanisms to verify that operations are authorized by the current owner of the linked contract or token.</p>
</li>

Mode-Specific Logic</strong>: Services SHOULD implement conditional logic based on the mode</code> parameter to handle both NFT-linked and account-linked scenarios appropriately.</p>
</li>

Cross-Chain Awareness</strong>: Services SHOULD check that operations are being performed on the chain specified in the chainId</code> parameter to prevent cross-chain replay attacks.</p>
</li>
</ol>
Rationale</h2>
The design of ERC-7656</a> is guided by several key principles that address limitations in current contract extension methods:</p>
Why a Unified Factory?</h3>
Rather than creating separate standards for NFT extensions and account extensions, ERC-7656</a> employs a unified factory approach. This design choice stems from recognizing the fundamental similarity between linking services to tokens and linking services to accounts - both involve extending functionality while maintaining a clear ownership relationship.</p>
Mode Parameter Design</h3>
The mode</code> parameter uses 12 bytes instead of a simple boolean flag because the 12-byte format reserves space for future linking modes beyond the initial two (NFT linking and account linking). For example, if a service is associated to an ERC-1155</a> token but requires that the balance of the user is more than 1000 tokens, the mode could be 0x000000000000000000003e802</code>, where the least significant byte, 0x02</code> is the primary mode and the rest is the minimum required balance. Similarly, someone can think of a service associated to ERC-20</a> tokens that requires a specific balance where the required balance can be put in the linkedId</code> field, and the mode</code> specified accordingly.</p>
Deterministic Addressing</h3>
ERC-7656</a> follows a deterministic addressing pattern, appending immutable data to the contract bytecode rather than storing it in contract storage. This ensures that:</p>

Linked services have predictable addresses that can be computed off-chain</li>
The factory remains stateless, reducing gas costs</li>
Linked services can be deployed on-demand or even referenced before deployment</li>
</ol>
Generic Linking Mechanism</h3>
Unlike standards that enforce specific interfaces or behaviors on linked contracts, ERC-7656</a> remains agnostic about the implementation details of linked services. This deliberate design choice allows developers maximum flexibility to create specialized services while maintaining a consistent deployment and ownership model.</p>
Backwards Compatibility</h2>
ERC-7656</a> maintains compatibility with token-bound accounts when used with the LINKED_ID</code> mode (0x000000000000000000000000). This ensures that existing applications and infrastructure supporting token-bound accounts can continue operating without modification.</p>
For contracts using the NO_LINKED_ID</code> mode (0x000000000000000000000001), specialized interfaces may be required, but the core factory mechanism remains consistent.</p>
Reference Implementation</h2>
See ERC7656Factory.sol</code></a> for an example implementation of IERC7656Factory</code>.</p>
For convenience, the bytecode of the reference implementation has been deployed at 0x76565d90eeB1ce12D05d55D142510dBA634a128F</code> on Ethereum mainnet, and will be later deployed at the same address to all primary mainnets and selected testnets.</p>
An example of implementation of IERC7656Service</code>:</p>
contract</span> LinkedService</span> is</span> IERC7656Service</span>, </span>EIP5313</span> {</span></span>
</span>
  function</span> linkedData</span>(</span>address</span> service</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>,</span> bytes12</span>,</span> address</span>,</span> uint256</span>)</span> {</span></span>
    bytes</span> memory</span> encodedData </span>=</span> new</span> bytes</span>(</span>0x60</span>)</span>;</span></span>
    //</span> solhint-disable</span>-next-line no-inline-assembly</span></span>
    assembly</span> {</span></span>
    //</span> Copy 0x60 bytes from end of context</span></span>
      extcodecopy</span>(</span>service</span>,</span> add</span>(</span>encodedData</span>,</span> 0x20</span>)</span>,</span> 0x4d</span>,</span> 0x60</span>)</span></span>
    }</span></span>
</span>
    uint256</span> chainId</span>;</span></span>
    bytes32</span> linkedContract</span>;</span></span>
    uint256</span> linkedId</span>;</span></span>
</span>
    //</span> solhint-disable</span>-next-line no-inline-assembly</span></span>
    assembly</span> {</span></span>
      chainId </span>:=</span> mload</span>(</span>add</span>(</span>encodedData</span>,</span> 0x20</span>)</span>)</span></span>
      linkedContract </span>:=</span> mload</span>(</span>add</span>(</span>encodedData</span>,</span> 0x40</span>)</span>)</span></span>
      linkedId </span>:=</span> mload</span>(</span>add</span>(</span>encodedData</span>,</span> 0x60</span>)</span>)</span></span>
    }</span></span>
</span>
    bytes12</span> mode </span>=</span> bytes12</span>(</span>linkedContract</span>)</span>;</span></span>
</span>
    address</span> extractedAddress </span>=</span> address</span>(</span>uint160</span>(</span>uint256</span>(</span>linkedContract</span>)</span>)</span>)</span>;</span></span>
    return</span> (</span>chainId</span>,</span> mode</span>,</span> extractedAddress</span>,</span> linkedId</span>)</span>;</span></span>
  }</span></span>
</span>
  function</span> owner</span>(</span>)</span> public</span> view</span> virtual</span> override</span> returns</span> (</span>address</span>)</span> {</span></span>
    (</span>uint256</span> chainId</span>,</span> ,</span> address</span> tokenContract_</span>,</span> uint256</span> tokenId_</span>)</span> =</span> linkedData</span>(</span>)</span>;</span></span>
    if</span> (</span>chainId </span>!=</span> block</span>.</span>chainid</span>)</span> return</span> address</span>(</span>0</span>)</span>;</span></span>
    return</span> IERC721</span>(</span>tokenContract_</span>)</span>.</span>ownerOf</span>(</span>tokenId_</span>)</span>;</span></span>
  }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Ownership Cycles</h3>
Smart wallets linked to NFTs that are then held by the same wallet can create ownership cycles, potentially rendering assets inaccessible. Implementers should include safeguards to prevent or detect such cycles.</p>
Fraud Prevention</h3>
A malicious seller could alter or revoke service permissions just before finalizing a sale. Lock mechanisms preventing last-minute changes may be implemented, especially for NFT marketplaces integrating with ERC-7656</a> services.</p>
Malicious Implementations</h3>
The registry cannot enforce legitimate ownership when linking services. Users should review or audit implementations before deployment. Front-end applications integrating ERC-7656</a> should display warnings when interacting with unverified implementations.</p>
Upgradeability Risks</h3>
Linked services that are upgradable pose risks of unexpected changes or asset exfiltration. Secure upgrade mechanisms with timelock controls or multi-signature governance should be implemented when upgradeability is required.</p>
Reentrancy & Cross-Contract Attacks</h3>
Linked services interacting with assets or external protocols may be vulnerable to reentrancy exploits. Implementers should follow security best practices such as the checks-effects-interactions pattern and consider reentrancy guards.</p>
Mode-Specific Vulnerabilities</h3>
Services operating in different modes (LINKED_ID</code> vs NO_LINKED_ID</code>) may have different security requirements. Implementations should validate that operations are appropriate for the service's configured mode.</p>
User Education & Phishing Risks</h3>
Even with secure contracts, users may fall victim to fraudulent services masquerading as legitimate ones. Clear UI warnings, verification tools, and educational resources should be provided by applications integrating ERC-7656</a>.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


eth/69 - history expiry and simpler receipts
2024-02-29T00:00:00+00:00
Abstract</h2>
This EIP modifies the 'eth' p2p protocol to announce the historical block range served by
the node. We also simplify the handshake to remove total difficulty information, which
isn't used anymore after the merge. Additionally we propose to remove the Bloom</code> field
from receipts transferred over the protocol.</p>
Motivation</h2>
Block range in Status message</h3>
In the history expiry working group, it was decided that clients may drop pre-merge
history from their storage after May 1, 2025. For clients that want to sync history
through the 'eth' protocol, it is essential to know whether a peer still serves old
history. A similar idea was proposed in EIP-7542</a> but was later withdrawn
because a political decision on history expiry had not been reached at the time.</p>
Removing Bloom in Receipts</h3>
We recently discovered that none of the clients store the Bloom</code> field of the receipts as
it can be recomputed on demand. However the networking spec requires the Bloom</code> field to
be sent over the network. Thus a syncing node will ask for the Bloom filters for all
receipts. The serving node will regenerate roughly 530GB of bloom filters (2.3B txs * 256
byte). These 530GBs are send over the network to the syncing peer, the syncing peer will
verify them and not store them either. This adds an additional 530GB of unnecessary
bandwidth to every sync.</p>
BlockRangeUpdate message</h3>
We want clients to be aware of the available block range in their peers. The new
notification message can be used to detect sync status of peers, and adjust fetching
behavior accordingly.</p>
Specification</h2>
Status message changes</h3>
Modify the Status (0x00)</code> message as follows:</p>


(eth/68): [version: P, networkid: P, td: P, blockhash: B_32, genesis: B_32, forkid]</code></p>
</li>

(eth/69): [version: P, networkid: P, genesis: B_32, forkid, earliestBlock: P, latestBlock: P, latestBlockHash: B_32]</code></p>
</li>
</ul>
Note blockhash</code> has moved to the end to match BlockRangeUpdate</code>.</p>
Receipts message changes</h3>
Modify the encoding for receipts in the Receipts (0x10)</code> message as follows:</p>

(eth/68): receipt = {legacy-receipt, typed-receipt}</code> with</li>
</ul>
typed-receipt = tx-type || rlp(legacy-receipt)</span></span>
</span>
legacy-receipt = [</span></span>
    post-state-or-status: {B_32, {0, 1}},</span></span>
    cumulative-gas: P,</span></span>
    bloom: B_256,</span></span>
    logs: [log₁, log₂, ...]</span></span>
]</span></span></code></pre>

(eth/69): receipt = [tx-type, post-state-or-status, cumulative-gas, logs]</code></li>
</ul>
BlockRangeUpdate message</h3>
Add a new BlockRangeUpdate (0x11)</code> message, with the following encoding</p>
[earliestBlock: P, latestBlock: P, latestBlockHash: B_32]</code></p>
The new message should be sent whenever the block range available from this client is
updated. In order to reduce traffic, it is not necessary to send an update for every new
block. Clients should send an update at most once per epoch (32 blocks).</p>
Rationale</h2>
Status changes</h3>
After the merge, the TD</code> field of the Status</code> message became meaningless since the
difficulty of post-merge blocks are 0. It could in theory be used to distinguish synced
with unsynced nodes, but the same thing can be accomplished with the forkid as well.</p>
The new earliestBlock</code> field is technically not required for history expiry, but there
are a couple reasons why adding it can help:</p>

It improves peer finding for clients that still want to sync history from p2p after the
agreed-upon removal of pre-merge history has taken place. Without earliestBlock</code>, the
client would have to perform a request for history to check if the earlier range exists,
and assume that a failed request means it's not there.</li>
The new field can be used for census in a specialized crawler. We will be able to see
how many users/nodes enable history, and in which implementation.</li>
It prepares us for a future where the history expiry window is dynamic.</li>
</ul>
Receipts changes</h3>
Removing the bloom filters from the Receipt</code> message reduces the CPU load of serving
nodes as well as the bandwidth significantly. The receiving nodes will need to recompute
the bloom filter in order to fully verify the receipt hash. The recomputation is not very
CPU intensive. The bandwidth gains amount to roughly 530GiB per syncing node or (at least)
95GiB snappy compressed.</p>
In Ethereum consensus, the encoding of receipts differs between legacy transactions and
typed transactions. Typed transaction receipts are 'opaque' and have the data wrapped in a
byte array. However, all receipt types ultimately contain the same four fields. With the
removal of the bloom filter, the networking protocol now deviates from the encoding used
by consensus, and there is no need to replicate the weird and expensive encoding used
there. The proposed receipt encoding is just a flat list of the required data fields.</p>
Backwards Compatibility</h2>
This EIP changes the eth protocol and requires rolling out a new version, eth/69</code>.
Supporting multiple versions of a wire protocol is possible. Rolling out a new version
does not break older clients immediately, since they can keep using protocol version
eth/68</code>.</p>
This EIP does not change consensus rules of the EVM and does not require a hard fork.</p>
Security Considerations</h2>
None</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Limited Transfer Count NFT
2024-02-22T00:00:00+00:00
Abstract</h2>
This standard extends ERC-721</a> with a mechanism that lets token owners/minters cap how many times a specific token can be transferred. It specifies functions to set and read a per-token transfer limit, to query a per-token transfer count, and defines transfer-time hooks to enforce the cap. The goal is fine-grained, enforceable transfer restrictions while preserving ERC-721 compatibility.</p>
Motivation</h2>
Once NFTs are sold, they detach from their minters and can be perpetually transferred. Yet many situations require tighter control over secondary movement.</p>
First, limiting the number of transfers can help preserve value (e.g., premium auctions, IP that becomes CC0 after a finite number of transfers, or game items that “wear out” and burn at a threshold).</p>
Second, capping transfer frequency can reduce risks from adversarial arbitrage (e.g., HFT-like behavior) by offering an easy-to-deploy throttle.</p>
Third, bounding re-staking cycles of NFT positions (e.g., proof-of-restake) can dampen recursive leverage and mitigate bubble dynamics.</p>
Key Takeaways</h3>
Controlled Value Preservation.</em> Scarcity via a transfer cap can help maintain value over time.</p>
Ensuring Intended Usage.</em> Limits keep usage aligned with intent (e.g., limited editions less prone to flip cycles).</p>
Expanding Use Cases.</em> Memberships/licenses with bounded transferability become practical.</p>
Easy Integration.</em> An extension interface (IERC7634</code>) layers on top of ERC-721</a>, easing adoption without breaking compatibility.</p>
Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p>

setTransferLimit</code>: establishes the transfer limit for a tokenId</code>.</li>
transferLimitOf</code>: returns the transfer limit for a tokenId</code>.</li>
transferCountOf</code>: returns the current transfer count for a tokenId</code>.</li>
</ul>
Counting and enforcement scope.</strong> Implementations MUST</strong> enforce the cap on native ERC-721 transfers of the underlying token (i.e., transfers where from != address(0)</code> and to != address(0)</code>). Incrementing the count SHOULD</strong> occur only after a successful native transfer. Mint and burn operations MUST NOT increment the count.</p>
Implementers MUST</strong> provide the following interface:</p>
</span>
pragma</span> solidity</span> ^0.8.4</span>;</span></span>
</span>
///</span> @title</span> IERC7634 Interface for Transfer-Capped ERC-721 Tokens</span></span>
///</span> @dev</span> ERC-7634 is an extension interface intended to be implemented alongside ERC-721</span></span>
interface</span> IERC7634</span> {</span></span>
    /**</span></span>
     * </span>@dev</span> Emitted after a successful native transfer when the per-token count increases.</span></span>
     */</span></span>
    event</span> TransferCountIncreased</span>(</span>uint256</span> indexed</span> tokenId</span>, </span>uint256</span> newCount</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Emitted when the per-token transfer limit is set or updated.</span></span>
     */</span></span>
    event</span> TransferLimitUpdated</span>(</span>uint256</span> indexed</span> tokenId</span>, </span>uint256</span> previousLimit</span>, </span>uint256</span> newLimit</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Returns the current transfer count for a tokenId.</span></span>
     */</span></span>
    function</span> transferCountOf</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Sets the transfer limit for a tokenId. Callable by owner or approved.</span></span>
     * </span>@param</span> tokenId</span> The token id to set the limit for.</span></span>
     * </span>@param</span> limit</span> The maximum number of native transfers allowed.</span></span>
     */</span></span>
    function</span> setTransferLimit</span>(</span>uint256</span> tokenId</span>,</span> uint256</span> limit</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Returns the transfer limit for a tokenId.</span></span>
     */</span></span>
    function</span> transferLimitOf</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
}</span></span>
    </span></span></code></pre>Rationale</h2>
Tracking and hooks</h3>
transferCountOf</code> and transferLimitOf</code> expose state needed to enforce a cap. The count should only increase after a successful native transfer (not on mint/burn). Separating TransferLimitUpdated</code> from TransferCountIncreased</code> makes it clear that the former is an administrative change while the latter is derived from runtime transfers.</p>
Backwards Compatibility</h2>
This standard is fully compatible with ERC-721</a>. Existing contracts can adopt it by adding the new interface and hooks without changing ERC-721 semantics.</p>
Extensions</h3>
This standard can be enhanced with additional advanced functionalities alongside existing NFT protocols. For example:</p>


Incorporating a burn function (e.g., ERC-5679</a>) would enable NFTs to automatically expire after reaching their transfer limits, akin to the ephemeral nature of Snapchat messages that disappear after multiple views.</p>
</li>

Incorporating a non-transferring function, as defined in the SBT standards, would enable NFTs to settle and bond with a single owner after a predetermined number of transactions. This functionality mirrors the scenario where a bidder ultimately secures a treasury after participating in multiple bidding rounds.</p>
</li>
</ul>
Reference Implementation</h2>
Below is a recommended pattern. It enforces the cap pre-transfer, increments the count post-transfer, ignores mint/burn for counting, and emits the clarified events. Implementations commonly override _beforeTokenTransfer</code> to enforce transferCount</code> < transferLimit</code> and _afterTokenTransfer</code> to increment the count and emit TransferCountIncreased</code>.</p>
</span>
pragma</span> solidity</span> ^0.8.4</span>;</span></span>
</span>
import</span> "@openzeppelin/contracts/token/ERC721/ERC721.sol"</span>;</span></span>
import</span> "./IERC7634.sol"</span>;</span></span>
</span>
///</span> @title</span> Transfer-Capped ERC-721 (ERC-7634)</span></span>
///</span> @dev</span> Example implementation of ERC-7634 alongside ERC-721</span></span>
contract</span> ERC7634</span> is</span> ERC721</span>, </span>IERC7634</span> {</span></span>
    //</span> tokenId => current transfer count</span></span>
    mapping</span>(</span>uint256</span> =></span> uint256</span>)</span> private</span> _transferCounts</span>;</span></span>
    //</span> tokenId => max allowed native transfers</span></span>
    mapping</span>(</span>uint256</span> =></span> uint256</span>)</span> private</span> _transferLimits</span>;</span></span>
</span>
    function</span> transferCountOf</span>(</span>uint256</span> tokenId</span>)</span> public</span> view</span> override</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "ERC7634: nonexistent token"</span>)</span>;</span></span>
        return</span> _transferCounts</span>[</span>tokenId</span>]</span>;</span></span>
    }</span></span>
</span>
    function</span> setTransferLimit</span>(</span>uint256</span> tokenId</span>,</span> uint256</span> limit</span>)</span> public</span> override</span> {</span></span>
        require</span>(</span>_isApprovedOrOwner</span>(</span>_msgSender</span>(</span>)</span>,</span> tokenId</span>)</span>,</span> "ERC7634: not owner/approved"</span>)</span>;</span></span>
        uint256</span> prev </span>=</span> _transferLimits</span>[</span>tokenId</span>]</span>;</span></span>
        _transferLimits</span>[</span>tokenId</span>]</span> =</span> limit</span>;</span></span>
        emit</span> TransferLimitUpdated</span>(</span>tokenId</span>,</span> prev</span>,</span> limit</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> transferLimitOf</span>(</span>uint256</span> tokenId</span>)</span> public</span> view</span> override</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        require</span>(</span>_exists</span>(</span>tokenId</span>)</span>,</span> "ERC7634: nonexistent token"</span>)</span>;</span></span>
        return</span> _transferLimits</span>[</span>tokenId</span>]</span>;</span></span>
    }</span></span>
</span>
    ///</span> @dev</span> Enforce transfer limit on native transfers (exclude mint/burn).</span></span>
    function</span> _beforeTokenTransfer</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span></span>
    )</span> internal</span> virtual</span> override</span> {</span></span>
        if</span> (</span>from </span>!=</span> address</span>(</span>0</span>)</span> &&</span> to </span>!=</span> address</span>(</span>0</span>)</span>)</span> {</span></span>
            require</span>(</span></span>
                _transferCounts</span>[</span>tokenId</span>]</span> <</span> _transferLimits</span>[</span>tokenId</span>]</span>,</span></span>
                "ERC7634: transfer limit reached"</span></span>
            )</span>;</span></span>
        }</span></span>
        super</span>.</span>_beforeTokenTransfer</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>)</span>;</span></span>
    }</span></span>
</span>
    ///</span> @dev</span> Increment count only after successful native transfer and emit event.</span></span>
    function</span> _afterTokenTransfer</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        uint256</span> quantity</span></span>
    )</span> internal</span> virtual</span> override</span> {</span></span>
        if</span> (</span>from </span>!=</span> address</span>(</span>0</span>)</span> &&</span> to </span>!=</span> address</span>(</span>0</span>)</span>)</span> {</span></span>
            unchecked</span> {</span> _transferCounts</span>[</span>tokenId</span>]</span> +</span>=</span> 1</span>;</span> }</span></span>
            emit</span> TransferCountIncreased</span>(</span>tokenId</span>,</span> _transferCounts</span>[</span>tokenId</span>]</span>)</span>;</span></span>
</span>
            if</span> (</span>_transferCounts</span>[</span>tokenId</span>]</span> ==</span> _transferLimits</span>[</span>tokenId</span>]</span>)</span> {</span></span>
                //</span> Optional: perform action exactly when the cap is reached (e.g., _burn(tokenId))</span></span>
            }</span></span>
        }</span></span>
        super</span>.</span>_afterTokenTransfer</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>,</span> quantity</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> supportsInterface</span>(</span>bytes4</span> interfaceId</span>)</span></span>
        public</span></span>
        view</span></span>
        virtual</span></span>
        override</span>(</span>ERC721</span>)</span></span>
        returns</span> (</span>bool</span>)</span></span>
    {</span></span>
        return</span> interfaceId </span>==</span> type</span>(</span>IERC7634</span>)</span>.</span>interfaceId </span>||</span> super</span>.</span>supportsInterface</span>(</span>interfaceId</span>)</span>;</span></span>
    }</span></span>
}</span></span>
</span></code></pre>Security Considerations</h2>


Scope with wrappers. The cap applies only to native ERC-721</a> transfers of the underlying token. Any owner can cheaply wrap a token and transfer a separate wrapper token; such downstream transfers cannot be prevented without breaking ERC-721</a> composability. As a result, this standard does not provide an unbypassable guarantee that, for example, a game item will always wear out or that secondary trading is globally capped; it standardizes a primitive for budgeting native transfers that ecosystems may choose to coordinate around. Deployments that want stronger effective guarantees MAY</strong> add optional mitigations such as recipient allowlists/registries or "compliant wrapper" patterns that mirror counts/limits, trading off openness for enforcement.</p>
</li>

Limit mutability. Consider making limits immutable once set (or only decreasing), to prevent tampering.</p>
</li>

Gas. Avoid heavy logic in hooks; extensions (e.g., burn on cap) should remain gas-safe.</p>
</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Dual Nature Token Pair
2024-02-21T00:00:00+00:00
Abstract</h2>
A fungible ERC-20</a> token contract and non-fungible ERC-721</a> token contract can be interlinked, allowing actions performed on one contract to be reflected on the other. This proposal defines how the relationship between the two token contracts can be queried. It also enables accounts to configure whether ERC-721 mints and transfers should be skipped during ERC-20 to ERC-721 synchronization.</p>
Motivation</h2>
The ERC-20 fungible and ERC-721 non-fungible token standards offer sufficient flexibility for a co-joined, dual nature token pair. Transfers on the ERC-20 token can automatically trigger transfers on the ERC-721 token, and vice-versa. This enables applications such as native ERC-721 fractionalization, wherein acquiring ERC-20 tokens leads to the automatic issuance of ERC-721 tokens, proportional to the ERC-20 balance.</p>
Dual nature token pairs maintain full compliance with both ERC-20 and ERC-721 token standards. This proposal aims to enhance the functionality of dual nature token pairs.</p>
To facilitate querying the relationship between the tokens, extension interfaces are proposed for the ERC-20 and ERC-721 tokens respectively. This enables various quality of life improvements such as allowing decentralized exchanges and NFT marketplaces to display the relationship between the tokens.</p>
Additionally, users can configure whether they want to skip ERC-721 mints and transfers during ERC-20 to ERC-721 synchronization.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Overview</h3>
A dual nature token pair comprises of an ERC-20 contract and an ERC-721 contract.</p>
For convention, the ERC-20 contract is designated as the base contract, and the ERC-721 contract is designated as the mirror contract.</p>
ERC-20 Extension Interface</h3>
The ERC-20 contract MUST implement the following interface.</p>
interface</span> IERC7631Base</span> {</span></span>
    ///</span> @dev</span> Returns the address of the mirror ERC-721 contract.</span></span>
    ///</span></span>
    ///</span> This method MAY revert or return the zero address</span></span>
    ///</span> to denote that a mirror ERC-721 contract has not been linked.</span></span>
    ///</span></span>
    ///</span> If a non-zero address is returned, the returned address MUST</span></span>
    ///</span> implement `IERC7631Mirror` and its `baseERC20()` method MUST</span></span>
    ///</span> return the address of this contract.</span></span>
    ///</span></span>
    ///</span> Once a non-zero address has been returned, this method</span></span>
    ///</span> MUST NOT revert and the returned value MUST NOT change.</span></span>
    function</span> mirrorERC721</span>(</span>)</span> external</span> view</span> returns</span> (</span>address</span>)</span>;</span></span>
}</span></span></code></pre>
The ERC-20 contract MAY implement the following interface.</p>
interface</span> IERC7631BaseNFTSkippable</span> {</span></span>
    ///</span> @dev</span> Implementations SHOULD emit this event when the skip NFT status</span></span>
    ///</span> of `owner` is updated to `status`.</span></span>
    ///</span></span>
    ///</span> The purpose of this event is to signal to indexers that the</span></span>
    ///</span> skip NFT status has been </span>changed</span>.</span></span>
    ///</span></span>
    ///</span> For simplicity of implementation,</span></span>
    ///</span> this event MAY be emitted even if the status is unchanged.</span></span>
    event</span> SkipNFTSet</span>(</span>address</span> indexed</span> owner</span>, </span>bool</span> status</span>)</span>;</span></span>
</span>
    ///</span> @dev</span> Returns true if ERC-721 mints and transfers to `owner` SHOULD be</span></span>
    ///</span> skipped during ERC-20 to ERC-721 synchronization.</span></span>
    ///</span> Otherwise, returns false.</span></span>
    ///</span> </span></span>
    ///</span> This method MAY revert</span></span>
    ///</span> (e.g. contract not initialized, method not supported).</span></span>
    ///</span></span>
    ///</span> If this method reverts:</span></span>
    ///</span> - Interacting code SHOULD interpret `setSkipNFT` functionality as</span></span>
    ///</span>   unavailable and hide any functionality to call `setSkipNFT`.</span></span>
    ///</span> - The skip NFT status for `owner` SHOULD be interpreted as undefined.</span></span>
    ///</span></span>
    ///</span> Once a true or false value has been returned for a given `owner`,</span></span>
    ///</span> this method MUST NOT revert for the given `owner`.</span></span>
    function</span> getSkipNFT</span>(</span>address</span> owner</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    ///</span> @dev</span> Sets the caller's skip NFT status.</span></span>
    ///</span></span>
    ///</span> This method MAY revert</span></span>
    ///</span> (e.g. insufficient permissions, method not supported).</span></span>
    ///</span></span>
    ///</span> It is RECOMMENDED to keep this method permissionless.</span></span>
    ///</span></span>
    ///</span> Emits a {SkipNFTSet} event.</span></span>
    function</span> setSkipNFT</span>(</span>bool</span> status</span>)</span> external</span>;</span></span>
}</span></span></code></pre>ERC-721 Extension Interface</h3>
The ERC-721 contract MUST implement the following interface.</p>
interface</span> IERC7631Mirror</span> {</span></span>
    ///</span> @dev</span> Returns the address of the base ERC-20 contract.</span></span>
    ///</span></span>
    ///</span> This method MAY revert or return the zero address</span></span>
    ///</span> to denote that a base ERC-20 contract has not been linked.</span></span>
    ///</span></span>
    ///</span> If a non-zero address is returned, the returned address MUST</span></span>
    ///</span> implement `IERC7631Base` and its `mirrorERC721()` method MUST</span></span>
    ///</span> return the address of this contract.</span></span>
    ///</span></span>
    ///</span> Once a non-zero address has been returned, this method</span></span>
    ///</span> MUST NOT revert and the returned value MUST NOT change.</span></span>
    function</span> baseERC20</span>(</span>)</span> external</span> view</span> returns</span> (</span>address</span>)</span>;</span></span>
}</span></span></code></pre>Rationale</h2>
Implementation Detection</h3>
The mirrorERC721</code> and baseERC20</code> methods returning non-zero addresses signal that the ERC-20 and ERC-721 contracts implement the required interfaces respectively. As such, ERC-165</a> is not required.</p>
The getSkipNFT</code> and setSkipNFT</code> methods MAY revert. As contracts compiled with Solidity or Vyper inherently revert on calls to undefined methods, a typical IERC7631Base</code> implementation lacking explicit getSkipNFT</code> and setSkipNFT</code> definitions still complies with IERC7631BaseNFTSkippable</code>.</p>
NFT Skipping</h3>
The skip NFT methods allow accounts to avoid having ERC-721 tokens automatically minted to it whenever there is an ERC-20 transfer.</p>
They are helpful in the following situations:</p>

Loading vesting contracts with large amounts ERC-20 tokens to be vested to many users.</li>
Loading candy machine contracts with large amounts of ERC-20 tokens to sell ERC-721 tokens to customers.</li>
Transferring large amounts of ERC-20 tokens in / out of a liquidity pool.</li>
Transferring large amounts of ERC-20 tokens between admin accounts.</li>
</ul>
Including the skip NFT methods in the standard will:</p>

Enable applications to conveniently display the option for users to skip NFTs.</li>
Enable applications to transfer any amount of ERC-20 tokens without the O(n) gas costs associated with minting multiple ERC-721 tokens, which can surpass the block gas limit.</li>
</ul>
These methods are recommended even on EVM chains with low gas costs, because bulk automatic ERC-721 transfers can still surpass the block gas limit.</p>
A useful pattern is to make getSkipNFT</code> return true by default if owner</code> is a smart contract.</p>
The choice of getSkipNFT</code> returning a boolean value is for simplicity. If more complex behavior is needed, developers may add in extra methods of their own.</p>
Implementation Conventions</h3>
The ERC-20 contract is designated as the base contract for convention, as a typical implementation can conveniently derive ERC-721 balances from the ERC-20 balances. This does not prohibit one from implementing most of the logic in the ERC-721 contract if required.</p>
This proposal does not cover the token synchronization logic. This is to leave flexibility for various implementation patterns and novel use cases (e.g. automatically rebased tokens).</p>
Linking Mechanism</h3>
The linking process is omitted for flexibility purposes. Developers can use any desired mechanism (e.g. linking in constructor, initializer, or via custom admin-only public methods on the two contracts). The only restriction is that the pairing must be immutable once established (to simplify indexing logic).</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
Synchronization Access Guards</h3>
External methods for synchronization logic must be guarded such that only the other contract is authorized to call them.</p>
Rare NFT Sniping</h3>
For dual nature collections that offer ERC-721 tokens with differing rarity levels, the ERC-721 metadata should be revealed in a way that is not easily gameable with metadata scraping and ERC-20 token transfers. A recommendation is to require that an ERC-721 token is held by the same account for some time before revealing its metadata.</p>
Out-of-gas Denial of Service</h3>
Transferring ERC-20 tokens can automatically initiate the minting, transferring, or burning of multiple ERC-721 tokens. This can incur O(n) gas costs instead of the typical O(1) gas costs for ERC-20 tokens transfers. Logic for selecting ERC-721 token IDs can also incur additional gas costs. Synchronization logic must consider ERC-721 related gas costs to prevent out-of-gas denial of service issues.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Secure Messaging Protocol
2024-02-19T00:00:00+00:00
Abstract</h2>
This proposal implements the capability to securely exchange encrypted messages on-chain. Users can register their public keys and encryption algorithms by registration and subsequently send encrypted messages to other users using their addresses. The interface also includes enumerations for public key algorithms and a structure for user information to support various encryption algorithms and user information management.</p>
Motivation</h2>
With the emergence of Layer 2 chains featuring sub-second block times and the introduction of account abstraction, the use of end-to-end encrypted communication has facilitated the proliferation of real-time communication and online chat dApps. Providing a unified interface enables easy integration of encrypted communication into smart contracts, thereby fostering innovation. Standardization promotes interoperability, facilitating seamless communication across platforms.</p>
Specification</h2>
Objectives</h3>

Provide a standardized interface for implementing messaging systems in smart contracts, including user registration and message sending functionalities.</li>
Enhance flexibility and scalability for messaging systems by defining enumerations for public key algorithms and a structure for user information.</li>
Define events for tracking message sending to enhance the observability and auditability of the contract.</li>
Using a custom sessionId allows messages to be organized into a conversation.</li>
Encrypt message content using the recipient's public key during message transmission.</li>
</ul>
Interface</h3>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Implementers of this standard MUST</strong> have all of the following functions:</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
interface</span> IERC7627</span> {</span></span>
</span>
    enum</span> PublicKeyAlgorithm</span> {</span> ECDSA</span>,</span> ED25519</span>,</span> X25519</span> }</span></span>
</span>
    struct</span> PublicKey</span> {</span></span>
        bytes</span> public_key</span>;</span> </span></span>
        uint64</span> valid_before</span>;</span></span>
        PublicKeyAlgorithm algorithm</span>;</span> </span></span>
    }</span></span>
    </span></span>
    //</span> Events</span></span>
	/**</span></span>
     * </span>@notice</span> Event emitted when a message is sent between users.</span></span>
     * </span>@param</span> from</span> The address of the sender</span></span>
     * </span>@param</span> to</span> The address of the recipient</span></span>
     * </span>@param</span> keyIndex</span> The index of the public key used to encrypt the message</span></span>
     * </span>@param</span> sessionId</span> The session ID for the communication</span></span>
     * </span>@param</span> encryptedMessage</span> The encrypted message in bytes</span></span>
	*/</span></span>
    event</span> MessageSent</span>(</span>address</span> indexed</span> from</span>, </span>address</span> indexed</span> to</span>, </span>bytes32</span> indexed</span> keyIndex</span>, </span>bytes32</span> sessionId</span>, </span>bytes</span> encryptedMessage</span>)</span>;</span></span>
</span>
	/**</span></span>
     * </span>@notice</span> Event emitted when a user's public key is updated.</span></span>
     * </span>@param</span> user</span> The address of the user whose public key is updated</span></span>
     * </span>@param</span> keyIndex</span> The index of the public key being updated</span></span>
     * </span>@param</span> newPublicKey</span> The new public key data</span></span>
	*/</span></span>
    event</span> PublicKeyUpdated</span>(</span>address</span> indexed</span> user</span>, </span>bytes32</span> indexed</span> keyIndex</span>, </span>PublicKey</span> newPublicKey</span>)</span>;</span></span>
</span>
    //</span> Functions</span></span>
</span>
	/**</span></span>
     * </span>@notice</span> Updates the public key for the sender.</span></span>
     * </span>@param</span> _keyIndex</span> The index of the key to be updated</span></span>
     * </span>@param</span> _publicKey</span> The new public key data</span></span>
	*/</span></span>
    function</span> updatePublicKey</span>(</span>bytes32</span> _keyIndex</span>,</span> PublicKey</span> memory</span> _publicKey</span>)</span> external</span>;</span></span>
</span>
	/**</span></span>
     * </span>@notice</span> Sends an encrypted message to a specified address.</span></span>
     * </span>@param</span> _to</span> The recipient's address</span></span>
     * </span>@param</span> _keyIndex</span> The index of the public key used to encrypt the message</span></span>
     * </span>@param</span> _sessionId</span> The session ID for the communication</span></span>
     * </span>@param</span> _encryptedMessage</span> The encrypted message in bytes</span></span>
	*/</span></span>
    function</span> sendMessage</span>(</span>address</span> _to</span>,</span> bytes32</span> _keyIndex</span>,</span> bytes32</span> _sessionId</span>,</span> bytes</span> calldata</span> _encryptedMessage</span>)</span> external</span>;</span></span>
</span>
	/**</span></span>
     * </span>@notice</span> Retrieves a public key for a specific user and key index.</span></span>
     * </span>@param</span> _user</span> The address of the user</span></span>
     * </span>@param</span> _keyIndex</span> The index of the key to retrieve</span></span>
     * </span>@return</span> The</span> public key data associated with the user and key index</span></span>
	*/</span></span>
    function</span> getUserPublicKey</span>(</span>address</span> _user</span>,</span> bytes32</span> _keyIndex</span>)</span> external</span> view</span> returns</span> (</span>PublicKey</span> memory</span>)</span>;</span></span>
}</span></span></code></pre>Rationale</h2>
Event Emission for Off-Chain Integration</h3>
By emitting events when messages are sent or public keys are updated, the implementation facilitates seamless integration with off-chain dApps. This enables these dApps to easily track and display the latest messages and updates, ensuring real-time responsiveness and enhancing user interaction.</p>
End-to-End Encryption Security</h3>
The design ensures that only the owner of an address can update their public key. This restriction preserves the integrity of the end-to-end encryption, making sure that only the intended recipient can decrypt and read the messages, thereby securing communication.</p>
Session ID for Conversation Organization</h3>
The use of session IDs in message transactions allows multiple messages to be grouped under specific conversations. This feature is crucial for organizing and managing discussions within a dApp, providing users with a coherent and structured messaging experience.</p>
Reference Implementation</h2>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
contract</span> ERC7627</span> {</span></span>
</span>
    ///</span> @dev</span> Enum to specify the algorithm used for the public key.</span></span>
    enum</span> PublicKeyAlgorithm</span> {</span> ECDSA</span>,</span> ED25519</span>,</span> X25519</span> }</span></span>
</span>
    ///</span> @dev</span> Structure to represent a user's public key.</span></span>
    struct</span> PublicKey</span> {</span></span>
        bytes</span> public_key</span>;</span> </span></span>
        uint64</span> valid_before</span>;</span></span>
        PublicKeyAlgorithm algorithm</span>;</span> </span></span>
    }</span></span>
</span>
    ///</span> @dev</span> Mapping to store public keys for each address. The mapping is by user address and a unique key index.</span></span>
    mapping</span>(</span>address</span> =></span> mapping</span>(</span>bytes32</span> =></span> PublicKey</span>)</span>)</span> public</span> pk</span>;</span></span>
</span>
    event</span> MessageSent</span>(</span>address</span> indexed</span> from</span>, </span>address</span> indexed</span> to</span>, </span>bytes32</span> indexed</span> keyIndex</span>, </span>bytes32</span> sessionId</span>, </span>bytes</span> encryptedMessage</span>)</span>;</span></span>
</span>
    event</span> PublicKeyUpdated</span>(</span>address</span> indexed</span> user</span>, </span>bytes32</span> indexed</span> keyIndex</span>, </span>PublicKey</span> newPublicKey</span>)</span>;</span></span>
</span>
    function</span> updatePublicKey</span>(</span>bytes32</span> _keyIndex</span>,</span> PublicKey</span> memory</span> _publicKey</span>)</span> external</span> {</span></span>
        pk</span>[</span>msg.sender</span>]</span>[</span>_keyIndex</span>]</span> =</span> _publicKey</span>;</span></span>
        emit</span> PublicKeyUpdated</span>(</span>msg.sender</span>,</span> _keyIndex</span>,</span> _publicKey</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> sendMessage</span>(</span>address</span> _to</span>,</span> bytes32</span> _keyIndex</span>,</span> bytes32</span> _sessionId</span>,</span> bytes</span> calldata</span> _encryptedMessage</span>)</span> external</span> {</span></span>
        emit</span> MessageSent</span>(</span>msg.sender</span>,</span> _to</span>,</span> _keyIndex</span>,</span> _sessionId</span>,</span> _encryptedMessage</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> getUserPublicKey</span>(</span>address</span> _user</span>,</span> bytes32</span> _keyIndex</span>)</span> external</span> view</span> returns</span> (</span>PublicKey</span> memory</span>)</span> {</span></span>
        return</span> pk</span>[</span>_user</span>]</span>[</span>_keyIndex</span>]</span>;</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Utilization of Latest Secure Encryption Algorithms</h4>
When selecting encryption algorithms, it is essential to stay informed about the latest security news and recommendations. Avoid using asymmetric encryption algorithms with known vulnerabilities or those not recommended to ensure the confidentiality and integrity of messages. Regularly update encryption algorithms to address evolving security threats.</p>
Strict Encryption Using Public Keys for Message Content</h4>
To maintain message confidentiality, the content of sent messages must be strictly encrypted using the recipient's public key. Any plaintext information transmitted could lead to information leakage and security risks. Encrypt message content at all times during transmission and storage to prevent unauthorized access to sensitive information.</p>
Key Management and Protection</h4>
Robust key management and protection measures are necessary for both user public and private keys. Ensure secure storage and transmission of keys to prevent leakage and tampering. Employ multi-factor authentication and key rotation strategies to enhance key security and regularly assess key management processes to mitigate potential security risks.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a></p>


Increase calldata cost
2024-02-13T00:00:00+00:00
Abstract</h2>
The current calldata pricing permits EL payloads of up to 7.15 MB, while the average size is much smaller at around 100 KB.
This EIP proposes adjusting the calldata cost to reduce the maximum possible block size and its variance without negatively impacting regular users.
This is achieved by increasing calldata costs for transactions that predominantly post data.</p>
Motivation</h2>
The block gas limit has not been increased since EIP-1559</a>, while the average size of blocks has continuously increased due to the growing number of rollups posting data to Ethereum. Moreover, calldata costs have remained unchanged since EIP-2028</a>.
EIP-4844</a> introduces blobs as a preferred method for data availability (DA).
This transition demands a reevaluation of calldata pricing, especially in order to address the disparity between average and maximum block sizes.
By introducing a floor cost dependent on the ratio of gas spent on EVM operations to calldata, this proposal aims to reduce the maximum block size to make room for additional blobs or potential block gas limit increases.</p>
Specification</h2>
Parameter</th> Value</th></tr></thead>

STANDARD_TOKEN_COST</code></td> 4</code></td></tr>
TOTAL_COST_FLOOR_PER_TOKEN</code></td> 10</code></td></tr>
</tbody></table>
Let tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4</code>.</p>
Let isContractCreation</code> be a boolean indicating the respective event.</p>
Let execution_gas_used</code> be the gas used for EVM execution with the gas refund subtracted.</p>
Let INITCODE_WORD_COST</code> be 2 as defined in EIP-3860</a>.</p>
The current formula for determining the total gas used per transaction (tx.gasUsed</code>) is equivalent to:</p>
tx</span>.</span>gasUsed</span> =</span> (</span></span>
    21000</span></span>
    +</span> STANDARD_TOKEN_COST</span> *</span> tokens_in_calldata</span></span>
    +</span> execution_gas_used</span></span>
    +</span> isContractCreation</span> *</span> (</span>32000</span> +</span> INITCODE_WORD_COST</span> *</span> words</span>(</span>calldata</span>)</span>)</span></span>
)</span></span></code></pre>
The formula for determining the gas used per transaction changes to:</p>
tx</span>.</span>gasUsed</span> =</span> (</span></span>
    21000</span></span>
    +</span></span>
    max</span>(</span></span>
        STANDARD_TOKEN_COST</span> *</span> tokens_in_calldata</span></span>
        +</span> execution_gas_used</span></span>
        +</span> isContractCreation</span> *</span> (</span>32000</span> +</span> INITCODE_WORD_COST</span> *</span> words</span>(</span>calldata</span>)</span>)</span>,</span></span>
        TOTAL_COST_FLOOR_PER_TOKEN</span> *</span> tokens_in_calldata</span></span>
    )</span></span>
)</span></span></code></pre>
Any transaction with a gas limit below 21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata</code> or below its intrinsic gas cost (take the maximum of these two calculations) is considered invalid. This limitation exists because transactions must cover the floor price of their calldata without relying on the execution of the transaction. There are valid cases where gasUsed</code> will be below this floor price, but the floor price needs to be reserved in the transaction gas limit.</p>
Rationale</h2>
The current maximum EL payload size is approximately 1.79 MB (30_000_000/16</code>). It is possible to create payloads filled with zero bytes that expand to 7.15 MB. However, since blocks are typically compressed with Snappy at the P2P layer, zero-byte-heavy EL payloads generally compress to under 1.79 MB. The implementation of EIP-4844</a> increased the maximum possible compressed block size to approximately 2.54 MB.</p>
This proposal aims to increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on EVM operations relative to gas spent on calldata. This change will significantly reduce the maximum block size by limiting the size of data-heavy transactions that can fit into a single block. By increasing calldata costs from 4/16 to 10/40 gas per byte, for data-heavy transactions this EIP aims to reduce the possible EL payload size to approximately 0.72 MB (30_000_000/40</code>) without affecting the majority of users. Other adversarial block constructions can have a non-compressible EL payload size of approximately 1.26MiB.</p>
Notably, regular users (e.g. sending ETH/Tokens/NFTs, engaging in DeFi, social media, restaking, bridging, etc.), who do not use calldata predominantly for DA, may remain unaffected.
The calldata cost for transactions involving significant EVM computation remains at 4/16 gas per byte, so those transactions are unaffected.</p>
Backwards Compatibility</h2>
This is a backwards incompatible gas repricing that requires a scheduled network upgrade.</p>
Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically:</p>


Wallets</strong>: Wallets using eth_estimateGas</code> MUST be updated to ensure that they correctly account for the TOTAL_COST_FLOOR_PER_TOKEN</code> parameter. Failure to do so could result in underestimating gas, leading to failed transactions.</p>
</li>

Node Software</strong>: RPC methods such as eth_estimateGas</code> MUST incorporate the updated formula for gas calculation. Node developers MUST ensure compatibility with the updated calldata pricing logic.</p>
</li>
</ol>
Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.</p>
Security Considerations</h2>
As the maximum possible block size is reduced, no security concerns have been raised.</p>
In some cases, it might seem advantageous to combine two transactions into one to reduce costs. For example, bundling a transaction that relies heavily on calldata but minimally on EVM resources with another that does the opposite. However, this is not a significant concern for several reasons:</p>

This type of bundling is already possible today. Merging multiple transactions can save the 21,000 gas cost for each additional transaction beyond the first, a feature explicitly supported in ERC-4337</a>.</li>
Such bundling does not compromise the block size reduction objectives of this EIP.</li>
In practice, transaction bundling is often impractical due to challenges such as trust and coordination requirements.</li>
</ol>
These factors ensure that transaction bundling does not pose a significant issue.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Hardfork Meta - Fusaka
2024-02-01T00:00:00+00:00
Abstract</h2>
This Meta EIP lists the EIPs included in the Fulu/Osaka network upgrade. It follows the Pectra upgrade, documented in EIP-7600</a>.</p>
Specification</h2>
Included EIPs</h3>
Core EIPs</h4>

EIP-7594</a>: PeerDAS - Peer Data Availability Sampling</li>
EIP-7823</a>: Set upper bounds for MODEXP</li>
EIP-7825</a>: Transaction Gas Limit Cap</li>
EIP-7883</a>: ModExp Gas Cost Increase</li>
EIP-7917</a>: Deterministic proposer lookahead</li>
EIP-7918</a>: Blob base fee bounded by execution cost</li>
EIP-7934</a>: RLP Execution Block Size Limit</li>
EIP-7939</a>: Count leading zeros (CLZ) opcode</li>
EIP-7951</a>: Precompile for secp256r1 Curve Support</li>
</ul>
Other EIPs</h4>

EIP-7892</a>: Blob Parameter Only Hardforks</li>
EIP-7642</a>: eth/69 - Drop pre-merge fields

Client teams MUST support this EIP by the activation of the Fusaka network upgrade.</li>
</ul>
</li>
EIP-7910</a>: eth_config JSON-RPC Method

Client teams MUST support this JSON-RPC method by the activation of Fusaka network upgrade.</li>
</ul>
</li>
EIP-7935</a>: Set default gas limit to 60M</li>
</ul>
Activation</h3>
Network Name</th> Activation Epoch</th> Activation Timestamp</th> Activation Time (UTC)</th> Fork ID</th></tr></thead>

Holešky</td> 165120</code></td> 1759308480</code></td> 2025-10-01 08:48:00</td> 0x783def52</code></td></tr>
Sepolia</td> 272640</code></td> 1760427360</code></td> 2025-10-14 07:36:00</td> 0xe2ae4999</code></td></tr>
Hoodi</td> 50688</code></td> 1761677592</code></td> 2025-10-28 18:53:12</td> 0xe7e0e7ff</code></td></tr>
Mainnet</td> 411392</code></td> 1764798551</code></td> 2025-12-03 21:49:11</td> 0x5167e2a6</code></td></tr>
</tbody></table>
Blob Parameter Only Forks</h3>
Blob Parameter Only (BPO) forks, defined in EIP-7892</a>, are scheduled alongside Fusaka to raise blob capacity without additional protocol changes.</p>
BPO 1</h4>
Network Name</th> Activation Epoch</th> Activation Timestamp</th> Activation Time (UTC)</th> Fork ID</th></tr></thead>

Holešky</td> 166400</code></td> 1759800000</code></td> 2025-10-07 01:20:00</td> 0xa280a45c</code></td></tr>
Sepolia</td> 274176</code></td> 1761017184</code></td> 2025-10-21 03:26:24</td> 0x56078a1e</code></td></tr>
Hoodi</td> 52480</code></td> 1762365720</code></td> 2025-11-05 18:02:00</td> 0x3893353e</code></td></tr>
Mainnet</td> 412672</code></td> 1765290071</code></td> 2025-12-09 14:21:11</td> 0xcba2a1c0</code></td></tr>
</tbody></table>
BPO 2</h4>
Network Name</th> Activation Epoch</th> Activation Timestamp</th> Activation Time (UTC)</th> Fork ID</th></tr></thead>

Holešky</td> 167936</code></td> 1760389824</code></td> 2025-10-13 21:10:24</td> 0x9bc6cb31</code></td></tr>
Sepolia</td> 275712</code></td> 1761607008</code></td> 2025-10-27 23:16:48</td> 0x268956b6</code></td></tr>
Hoodi</td> 54016</code></td> 1762955544</code></td> 2025-11-12 13:52:24</td> 0x23aa1351</code></td></tr>
Mainnet</td> 419072</code></td> 1767747671</code></td> 2026-01-07 01:01:11</td> 0x07c9462e</code></td></tr>
</tbody></table>
Rationale</h2>
This Meta EIP provides a global view of all changes included in the Fusaka network upgrade, as well as links to full specification.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Hardfork Meta - Pectra
2024-01-18T00:00:00+00:00
Abstract</h2>
This Meta EIP lists the EIPs Included in the Prague/Electra network upgrade. It follows the Dencun upgrade, documented in EIP-7569</a>.</p>
Specification</h2>
Included EIPs</h3>
Core EIPs</h4>

EIP-2537</a>: Precompile for BLS12-381 curve operations</li>
EIP-2935</a>: Save historical block hashes in state</li>
EIP-6110</a>: Supply validator deposits on chain</li>
EIP-7002</a>: Execution layer triggerable exits</li>
EIP-7251</a>: Increase the MAX_EFFECTIVE_BALANCE</li>
EIP-7549</a>: Move committee index outside Attestation</li>
EIP-7623</a>: Increase calldata cost</li>
EIP-7685</a>: General purpose execution layer requests</li>
EIP-7691</a>: Blob throughput increase</li>
EIP-7702</a>: Set EOA account code</li>
</ul>
Other EIPs</h4>

EIP-7840</a>: Add blob schedule to EL config files (Informational)</li>
EIP-7642</a>: eth/69 - Drop pre-merge fields (Networking)

While not necessary for the Pectra network upgrade, client teams MAY support EIP-7642 by the upgrade's activation and MUST support it by the next network upgrade.</li>
</ul>
</li>
</ul>
Full Specifications</h3>
Consensus Layer</h4>
EIP-6110, EIP-7002 EIP-7251, EIP-7549, EIP-7685 and EIP-7691 require changes to Ethereum's consensus layer. While the EIPs present an overview of these changes, the full specifications can be found in the specs/electra</code> and specs/_features</code> directories of the ethereum/consensus-specs</code> repository.</p>
Execution Layer</h4>
EIP-2537, EIP-2935, EIP-6110, EIP-7002, EIP-7623, EIP-7685, EIP-7702 and EIP-7840 require changes to Ethereum's execution layer. The EIPs fully specify those changes.</p>
Activation</h3>
Network Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead>

Holešky</td> 115968</code></td> 1740434112</code></td></tr>
Sepolia</td> 222464</code></td> 1741159776</code></td></tr>
Hoodi</td> 2048</code></td> 1742999832</code></td></tr>
Mainnet</td> 364032</code></td> 1746612311</code></td></tr>
</tbody></table>
Rationale</h2>
This Meta EIP provides a global view of all changes included in the Prague/Electra network upgrade, as well as links to the full specification.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


PeerDAS - Peer Data Availability Sampling
2024-01-12T00:00:00+00:00
Abstract</h2>
PeerDAS (Peer Data Availability Sampling) is a networking protocol that allows nodes to perform data availability sampling (DAS) to ensure that blob data has been made available while downloading only a subset of the data. PeerDAS utilizes gossip for distribution, discovery for finding peers of particular data custody, and peer requests for sampling.</p>
Motivation</h2>
DAS is a method of scaling data availability beyond the levels of EIP-4844</a> by not requiring all nodes to download all data while still ensuring that all of the data has been made available.</p>
Providing additional data availability helps bring scale to Ethereum users in the context of layer 2 systems called "roll-ups" whose dominant bottleneck is layer 1 data availability.</p>
Specification</h2>
We extend the blobs introduced in EIP-4844 using a one-dimensional erasure coding extension. Each row consists of the blob data combined with its erasure code. It is subdivided into cells, which are the smallest units that can be authenticated with their respective blob's KZG commitments. Each column, associated with a specific gossip subnet, consists of the cells from all rows for a specific index. Each node is responsible for maintaining a deterministic set of column subnets and custodying their data as a function of their node ID.</p>
Nodes find and maintain a diverse peer set and sample columns from their peers to perform DAS every slot.</p>
A node can reconstruct the entire data matrix if it acquires at least 50% of all the columns. If a node has less than 50%, it can request the necessary columns from its peer nodes.</p>
Additionally, a limit of 6 blobs per transaction is introduced. Clients MUST enforce this limit when validating blob transactions at submission time, when received from the network, and during block production and processing.</p>
The detailed specifications are on ethereum/consensus-specs</a>.</p>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Networking</h3>
This EIP introduces cell KZG proofs, which are used to prove that a KZG commitment opens to a cell at the given index. This allows downloading only specific cells from a blob, while still ensuring data integrity with respect to the corresponding KZG commitment, and is therefore a key component of data availability sampling. However, computing the cell proofs for a blob is an expensive operation, which a block producer would have to repeat for many blobs. Since proof verification is much cheaper than proof computation, and the proof size is negligible compared to cell size, we instead require blob transaction senders to compute the proofs themselves and include them in the EIP-4844 transaction pool wrapper for blob transactions.</p>
To this end, during transaction gossip responses (PooledTransactions</code>), the wrapper is modified to:</p>
rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])</span></span>
</span>
cell_proofs = [cell_proof_0, cell_proof_1, ...]</span></span></code></pre>
The tx_payload_body</code>, blobs</code> and commitments</code> are as in EIP-4844, while the proofs</code> field is replaced by cell_proofs</code>, and a wrapper_version</code> is added. These are defined as follows:</p>

wrapper_version</code> - one byte indicating which version of the wrapper is used. For the current version, it is set to 1</code></strong>.</li>
cell_proofs</code> - list of cell proofs for all blobs</code>, including the proofs for the extension indices, for a total of CELLS_PER_EXT_BLOB</code> proofs per blob (CELLS_PER_EXT_BLOB</code> is the number of cells for an extended blob, defined in the consensus specs</a>)</li>
</ul>
Note that, while cell_proofs</code> contain the proofs for all cells, including the extension cells, the blobs themselves are sent without being extended (CELLS_PER_EXT_BLOB / 2</code> cells per blob). This is to avoid sending redundant data, which can quickly be computed by the receiving node.
In other words, cell_proofs[i * CELLS_PER_EXT_BLOB + j]</code> is the proof for cell j</code> of compute_cells(blobs[i])</code>, where compute_cells(blob)</code> outputs all cells of blob</code>, including the extension cells.</p>
The node MUST validate tx_payload_body</code> and verify the wrapped data against it. To do so, ensure that:</p>

There are an equal number of tx_payload_body.blob_versioned_hashes</code>, blobs</code> and commitments</code>.</li>
cell_proofs</code> contains exactly CELLS_PER_EXT_BLOB * len(blobs)</code> cell proofs</li>
The KZG commitments</code> hash to the versioned hashes, i.e. kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]</code></li>
The KZG commitments</code> match the corresponding blobs</code> and cell_proofs</code>. This requires computing the extension cells for all blobs</code> (e.g. via compute_cells</code>), and verifying all cell_proofs</code>. (Note: all cell proofs can be batch verified at once, e.g. via verify_cell_kzg_proof_batch</code>)</li>
</ul>
Rationale</h2>
Why use DAS to scale the DA layer?</h3>
PeerDAS is a DAS scheme that requires nodes to only download a small constant fraction of the data to satisfy a local availability check. With the current parameters, this is 1/8 of the total data (i.e. blobs in a block), which can in the future be decreased to 1/16 or even 1/32 by reducing the size of samples (increasing the number of columns). In this way, PeerDAS allows for securely scaling the blob throughput of the network without compromising decentralization, i.e., without increasing node's bandwidth and storage requirements.</p>
What does peer sampling provide?</h3>
PeerDAS takes the set of peers of a node on the network as a primitive to build a DAS scheme around. A focus on peers allows for redundancy in the mechanism (as a node generally has many peers, and peer count can also be cheaply increased) which both helps with theoretical security as detailed in the "Security Considerations" section, but also practical security of the implementation (e.g. if a single peer fails, a node can likely use another peer for the same sampling task).</p>
PeerDAS also has the nice property that any given node may voluntarily custody more of the data than the bare minimum which increases the performance of the mechanism. Alternative schemes do not readily support this "transparent" scaling property.</p>
Why are these parameters chosen?</h3>
The parameters of PeerDAS given in the specs support network security while keeping node requirements sufficiently low. See the security argument below for further details.</p>
Why do validators have an additional custody requirement beyond full nodes?</h3>
Validators are assumed to have marginally higher requirements to participate on the network. PeerDAS introduces a custody requirement that scales with the validator count so that nodes with more resources can contribute to a more stable backbone that makes the global network more robust.</p>
Column sampling vs row sampling</h3>
PeerDAS defines a sample as a "column" which is a cross-section across all</em> blobs, rather than a "row" which would be a full blob.
The sampling scheme could be defined over rows but then any reconstruction strategy would need to work over "extension" blobs that do not a priori exist on the network.
Reconstruction becomes much more tractable by working over columns as nodes can be assumed to have much more of the complete data by default (e.g. because most/all of the blobs are in the public mempool).</p>
Another benefit is that sampling over rows requires column</em> extensions which would have to be done at the time of block construction, i.e. on the "critical path". Sampling over columns requires row extensions which can be done in advance (not on the critical path), and moreover proof computation can be outsourced to senders of blob transactions.</p>
Backwards Compatibility</h2>
This EIP is fully backwards compatible with EIP-4844</a>.</p>
Test Cases</h2>
Refer to the consensus and execution spec tests for testing of this EIP.</p>
Security Considerations</h2>
The primary failure mode of a DAS scheme is a "data withholding" attack, where a block producer attempts to convince the network some data is available even when the block producer fails to provide the associated data.
PeerDAS resolves withholding attacks by implementing a (pseudo)randomized sampling scheme that decreases the probability of a successful attack as the size of the network grows for a sublinear amount of data that must be downloaded.</p>
This intuition can be formalized as follows:</p>
Letting n</code> be the total number of sampling nodes (i.e. the size of the network), m</code> be the total number of samples possible (cf. NUMBER_OF_CUSTODY_GROUPS</code> in the specs) and k</code> be the minimum number of samples that a node must download (cf. SAMPLES_PER_SLOT</code> in the specs), we have the following bound for the probability of convincing a fraction $\epsilon$ of the nodes that some data is available when it is withheld:</p>
</p>
The first term is the number of possible ways to choose a subset of $n\epsilon$ nodes whose sampling queries should be satisfied (i.e. the nodes to be tricked).
The second term is the number of ways to choose a maximally large subset of samples to be made available to satisfy the sampling queries of the $n\epsilon$ nodes without allowing reconstruction of the full data.
Finally, for any such choices, the third term is the probability of success, i.e. the probability that the sampling queries of all chosen $n\epsilon$ nodes are satisfied by the chosen subset up to the reconstruction threshold.</p>
For mainnet parameters given in the specs and assuming 10,000 nodes on the network, we can compute upper bounds of attack success for varying $\epsilon$:</p>
$\epsilon$</th> $n\epsilon$ (target nodes)</th> Upper bound on $\mathbb{P}$</th></tr></thead>

0.01</td> 100</td> $1$</td></tr>
0.02</td> 200</td> $10^{-20.04}$</td></tr>
0.03</td> 300</td> $10^{-101.55}$</td></tr>
0.04</td> 400</td> $10^{-198.24}$</td></tr>
0.05</td> 500</td> $10^{-306.34}$</td></tr>
</tbody></table>
The table shows that the chances of a successful attack quickly drop to a negligible amount and so PeerDAS is considered secure to withholding attacks.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Expirable NFTs and SBTs
2024-01-04T00:00:00+00:00
Abstract</h2>
Introduces an extension for ERC-721</a> Non-Fungible Tokens (NFTs) and Soulbound Tokens (SBTs) that adds an expiration mechanism, allowing tokens to become invalid after a predefined period. This additional layer of functionality ensures that the expiration mechanism does not interfere with existing NFTs or SBTs, preserving transferability for NFTs and compatibility with current DApps such as NFT Marketplace. Expiration can be defined using either block height or timestamp, offering flexibility for various use cases.</p>
Motivation</h2>
Before this EIP, NFTs and SBTs implemented expiration mechanisms via custom mappings. However, this approach presents challenges, such as: inconsistent integration with other smart contracts, and the custom ERC-721</a> implementations might misbehave when used in NFT marketplaces. This EIP addresses these issues by providing a built-in expiration mechanism and interfaces that are compatible with existing infrastructure. It supports both per-token and epoch-based expiry, allowing developers to choose the appropriate expiry type for their use cases, including:</p>

Access and Authentication

Authentication for Identity and Access Management (IAM)</li>
Membership for Membership Management System (MMS)</li>
Ticket and Press for Meetings, Incentive Travel, Conventions, and Exhibitions (MICE) when using with ERC-2135</a> or ERC-7578</a>.</li>
Subscription-based access for digital platforms.</li>
</ul>
</li>
Digital Certifications, Contracts, Copyrights, Documents, Licenses, Policies, etc.</li>
Loyalty Program voucher or coupon</li>
Governance and Voting Rights</li>
Financial Product

Bonds, Loans, Hedge, and Options Contract</li>
</ul>
</li>
Rental

Real Estate Unit, Digital Access, DePIN, etc</li>
</ul>
</li>
</ul>
Specification</h2>
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Compatible implementations MUST implement the IERC7858</code> interface and MUST inherit from ERC-721</a>'s interface. All functions defined in the interface MUST be present and all function behavior MUST meet the interface specification requirements.</p>
Interface</h3>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> >=0.8.0</span> <</span>0.9</span>.</span>0</span>;</span></span>
</span>
/**</span></span>
 * </span>@title</span> ERC-7858: Expirable NFTs and SBTs</span></span>
 * </span>@notice</span> unique/granular expiry</span></span>
 */</span></span>
</span>
//</span> import "./IERC721.sol";</span></span>
</span>
//</span> The EIP-165 identifier of this interface is `0x3ebdfa31`.</span></span>
interface</span> IERC7858</span> /**</span>is IERC721 </span>*/</span> {</span></span>
    enum</span> EXPIRY_TYPE</span> {</span></span>
        BLOCKS_BASED</span>,</span> //</span> block.number</span></span>
        TIME_BASED</span> //</span> block.timestamp</span></span>
    }</span></span>
    </span></span>
    /**</span></span>
     * </span>@dev</span> Emitted when the expiration date of a token is set or updated.</span></span>
     * </span>@param</span> tokenId</span> The identifier of the token ERC721 `tokenId`.</span></span>
     * </span>@param</span> startTime</span> The start time of the token (block number or timestamp based on `expiryType`).</span></span>
     * </span>@param</span> endTime</span> The end time of the token (block number or timestamp based on `expiryType`).</span></span>
     */</span></span>
    event</span> TokenExpiryUpdated</span>(</span></span>
        uint256</span> indexed</span> tokenId</span>,</span></span>
        uint256</span> indexed</span> startTime</span>,</span></span>
        uint256</span> indexed</span> endTime</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Returns the type of the expiry.</span></span>
     * </span>@return</span> EXPIRY_TYPE</span>  Enum value indicating the unit of an expiry.</span></span>
     */</span></span>
    function</span> expiryType</span>(</span>)</span> external</span> view</span> returns</span> (</span>EXPIRY_TYPE</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Checks whether a specific token is expired.</span></span>
     * </span>@param</span> tokenId</span> The identifier representing the `tokenId` (ERC721).</span></span>
     * </span>@return</span> bool</span> True if the token is expired, false otherwise.</span></span>
     */</span></span>
    function</span> isTokenExpired</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    //</span> return depends on the type `block.timestamp` or `block.number`</span></span>
    //</span> {ERC-5007} return in uint64 MAY not suitable for `block.number` based.</span></span>
    function</span> startTime</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
    function</span> endTime</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
}</span></span></code></pre>Behavior Specification</h3>


balanceOf</code> that inherited from ERC-721</a> MUST return all tokens even if expired; they still exist but are unusable due to the limitation of tracking expired token on-chain.</p>
</li>

For NFTs transferFrom</code>, and safeTransferFrom</code> MUST allow transferring tokens even if they expired. This ensures that expired tokens remain transferable and tradable, preserving compatibility with existing applications already deployed. However, expired tokens MUST be considered invalid and unusable in contracts that check for token validity.</p>
</li>

expiryType</code> MUST return the type of expiry used by the contract, which can be either BLOCK</code> or TIME</code>.</p>
</li>

isTokenExpired</code> is used for retrieving the status of the given tokenId</code>; the function MUST return true</code> if the token is expired and MUST revert if the tokenId</code> does not exist. Implementations that use custom errors SHOULD revert with ERC721NonexistentToken</code> following the relevant ERC-6093</a> and implementations using Solidity version below v0.8.4</code> or those preferring to use revert with string error SHOULD revert with NonexistToken</code>. If the tokenId</code> exists and is not expired, the function MUST return false</code>.</p>
</li>

startTime</code> and endTime</code> of tokenId</code>, can be block.number</code> or block.timestamp</code> depending on expiryType</code>. The startTime</code> MUST be less than or equal to endTime</code> and startTime</code> SHOULD be strictly less than endTime</code> except when both are set to 0</code>. A startTime</code> and endTime</code> of 0</code> indicates that the tokenId</code> has no expiration. Tokens with a non-zero startTime</code> and a zero endTime</code> are also considered to have no expiration. If the tokenId</code> does not exist, this function MUST revert in the same way as isTokenExpired</code>.</p>
</li>

The interface ID for ERC-165</a>'s supportsInterface</code> for IERC7858</code> is 0x3ebdfa31</code>, and for IERC7858Epoch</code> it is 0xec7ffd66</code></p>
</li>

TokenExpiryUpdated</code> MUST be emitted when the token is minted or when its expiration details (startTime</code> or endTime</code>) are updated.</p>
</li>
</ul>
Extension Interface</h3>
Epochs</strong> represent a specific period or block range during which certain tokens are valid borrowing concepts from ERC-7818</a>, tokens are grouped under an epoch</code> and share the same validityDuration</code>. For implementations that require epoch-based expiration management, the IERC7858Epoch</code> extension interface MUST be implemented alongside the base IERC7858</code> interface, and all functions and behaviors MUST meet both IERC7858</code> and IERC7858Epoch</code> interface specification requirements.</p>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> >=0.8.0</span> <</span>0.9</span>.</span>0</span>;</span></span>
</span>
/**</span></span>
 * </span>@title</span> ERC-7858: Expirable NFTs and SBTs</span></span>
 * </span>@notice</span> epoch expiry extension</span></span>
 */</span></span>
</span>
//</span> import "./IERC7858.sol";</span></span>
</span>
//</span> The EIP-165 identifier of this interface is `0xec7ffd66`.</span></span>
interface</span> IERC7858Epoch</span> /**</span> is IERC7858 </span>*/</span> {</span></span>
    /**</span></span>
     * </span>@dev</span> Retrieves the current epoch of the contract.</span></span>
     * </span>@return</span> uint256</span> The current epoch of the token contract,</span></span>
     * often used for determining active/expired states.</span></span>
     */</span></span>
    function</span> currentEpoch</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the duration of a single epoch.</span></span>
     * </span>@return</span> uint256</span> The duration of a single epoch.</span></span>
     * </span>@notice</span> The unit of the epoch length is determined by the `validityPeriodType` function.</span></span>
     */</span></span>
    function</span> epochLength</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Checks whether a specific `epoch` is expired.</span></span>
     * </span>@param</span> epoch</span> The `epoch` to check.</span></span>
     * </span>@return</span> bool</span> True if the token is expired, false otherwise.</span></span>
     * </span>@notice</span> Implementing contracts "MUST" define and document the logic for determining expiration,</span></span>
     * typically by comparing the latest epoch with the given `epoch` value,</span></span>
     * based on the `EXPIRY_TYPE` measurement (e.g., block count or time duration).</span></span>
     */</span></span>
    function</span> isEpochExpired</span>(</span>uint256</span> epoch</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the balance of unexpired tokens owned by an account.</span></span>
     * </span>@param</span> account</span> The address of the account.</span></span>
     * </span>@return</span> uint256</span> The amount of unexpired tokens owned by an account.</span></span>
     */</span></span>
    function</span> unexpiredBalanceOf</span>(</span>address</span> account</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the balance of a specific `epoch` owned by an account.</span></span>
     * </span>@param</span> epoch</span> The `epoch for which the balance is checked.</span></span>
     * </span>@param</span> account</span> The address of the account.</span></span>
     * </span>@return</span> uint256</span> The balance of the specified `epoch`.</span></span>
     * </span>@notice</span> "MUST" return 0 if the specified `epoch` is expired.</span></span>
     */</span></span>
    function</span> unexpiredBalanceOfAtEpoch</span>(</span>uint256</span> epoch</span>,</span> address</span> account</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@dev</span> Retrieves the validity duration of each token.</span></span>
     * </span>@return</span> uint256</span> The validity duration of each token in `epoch` unit.</span></span>
     */</span></span>
    function</span> validityDuration</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
}</span></span></code></pre>Extension Behavior Specification</h3>

unexpiredBalanceOfAtEpoch</code> MUST return the count of usable (unexpired) tokens held by an account from the specified epoch</code>. If the specified epoch</code> is expired, this function MUST return 0</code>. For example, if epoch 5</code> has expired, calling unexpiredBalanceOfAtEpoch(5, address)</code> returns 0</code> even if there were tokens previously held in that epoch.</li>
unexpiredBalanceOf</code> MUST return total count of usable (unexpired) tokens owned by the account.</li>
currentEpoch</code> MUST return the current epoch</code> of the contract.</li>
epochLength</code> MUST return duration between epoch</code> in blocks or time in seconds.</li>
validityDuration</code> MUST return the validity duration of tokens in terms of epoch</code> counts.</li>
isEpochExpired</code> MUST return true if the given epoch</code> is expired, otherwise false</code>.</li>
</ul>
Additional Potential Useful Function</h3>
These OPTIONAL functions provide additional functionality that developers MAY choose to implement based on their specific requirements and use cases.</p>
Base (default)</h4>
function</span> getRemainingDurationBeforeTokenExpired</span>(</span>uint256</span> tokenId</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span></code></pre>

getRemainingDurationBeforeTokenExpired</code> returns the remaining time or blocks before the given tokenId</code> is expired.</li>
</ul>
Epoch (extension)</h4>
function</span> getEpochBalance</span>(</span>uint256</span> epoch</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span></code></pre>

getEpochBalance</code> returns the amount of tokens stored in a given epoch, even if the epoch has expired.</li>
</ul>
function</span> getEpochInfo</span>(</span>uint256</span> epoch</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>,</span>uint256</span>)</span>;</span></span></code></pre>

getEpochInfo</code> returns both the start and end of the specified epoch</code>.</li>
</ul>
function</span> getNearestExpiryOf</span>(</span>address</span> account</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span></code></pre>

getNearestExpiryOf</code> returns the list of tokenId</code> closest to expiration, along with an estimated expiration block number or timestamp based on epochType</code>.</li>
</ul>
function</span> getRemainingDurationBeforeEpochChange</span>(</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span></code></pre>

getRemainingDurationBeforeEpochChange</code> returns the remaining time or blocks before the epoch change happens, based on the epochType</code>.</li>
</ul>
Rationale</h2>
First, do no harm</h3>
Introducing expirability as an additional layer of functionality ensures it doesn’t interfere with existing use cases or applications. For non-SBT tokens, transferability remains intact, maintaining compatibility with current systems. Expired tokens are simply flagged as unusable during validity checks, treating expiration as an enhancement rather than a fundamental change.</p>
Expiry Types</h3>
Defining expiration by either block height (block.number</code>) or block timestamp (block.timestamp</code>) offers flexibility for various use cases. Block-based expiration suits applications that rely on network activity and require precise consistency, while time-based expiration is ideal for networks with variable block intervals.</p>
Backwards Compatibility</h2>
This standard is fully compatible with ERC-721</a>, ERC-5484</a> and other SBTs.</p>
Reference Implementation</h2>
You can find our reference implementation here</a>.</p>
Security Considerations</h2>
Burn and Re-Mint</h3>
Implementation should ensure that burning token and re-minting it with the same tokenId</code> will not introduce an unauthorized renewal.</p>
Unauthorized Update</h3>
Implementation should ensure that only authorized can update startTime</code> and endTime</code>.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Blob Transactions Metadata JSON Schema
2024-01-01T00:00:00+00:00
Abstract</h2>
This EIP introduces a standard for attaching metadata to blobs carried by blob transactions, as outlined in EIP-4844</a>. The metadata is represented as a JSON object adhering to a predefined schema, and its string representation is placed in the data field of the blob transaction.</p>
Motivation</h2>
EIP-4844</a> defines a new type of transaction known as a “blob transaction.” These transactions contain a list of blobs along with their KZG commitments and proofs. Blob transactions serve as a mechanism for rollups to post their layer 2 transaction data to Ethereum layer 1.</p>
While rollups typically manage their own posted blob transactions, third-party solutions (such as Portal Network and blobscan) may also index all blobs ever posted to Ethereum, and provide querying services for blobs. By attaching metadata to blobs, such as information about the originator, a description, or content type, we can significantly enhance the visibility and auditability of these data structures.</p>
Furthermore, decentralized storage applications may utilize blob transactions to post user data to Ethereum, sync and store the blobs off-chain for future retrieval. The inclusion of metadata opens up possibilities for novel applications, including inscriptions and other creative use cases.</p>
Specification</h2>
Metadata JSON Schema</h3>
The metadata is represented as a JSON object adhering to the following JSON Schema:</p>
{</span></span>
    "</span>title</span>"</span>:</span> "</span>Blobs Metadata</span>"</span>,</span></span>
    "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
    "</span>properties</span>"</span>:</span> {</span></span>
        "</span>originator</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Identifies the originator of the carried blobs</span>"</span></span>
        }</span>,</span></span>
        "</span>description</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Describes the contents of the blobs</span>"</span></span>
        }</span>,</span></span>
        "</span>content_type</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Describes the MIME type of the blobs. The MIME type should be defined in RFC 2046 (https://www.rfc-editor.org/rfc/rfc2046)</span>"</span></span>
        }</span>,</span></span>
        "</span>extras</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Dynamic extra information related to the blobs</span>"</span></span>
        }</span>,</span></span>
        "</span>blobs</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>array</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Metadata of the i'th blob. This is optional and overlays the upper level properties if provided</span>"</span>,</span></span>
            "</span>items</span>"</span>:</span> {</span></span>
                "</span>description</span>"</span>:</span> {</span></span>
                    "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
                    "</span>description</span>"</span>:</span> "</span>Describes the content of the i'th blob</span>"</span></span>
                }</span>,</span></span>
                "</span>content_type</span>"</span>:</span> {</span></span>
                    "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
                    "</span>description</span>"</span>:</span> "</span>Describes the MIME type of the i'th blob. The MIME type should be defined in RFC 2046 (https://www.rfc-editor.org/rfc/rfc2046)</span>"</span></span>
                }</span>,</span></span>
                "</span>extras</span>"</span>:</span> {</span></span>
                    "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
                    "</span>description</span>"</span>:</span> "</span>Dynamic extra information related to the i'th blob</span>"</span></span>
                }</span>,</span></span>
            }</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
For example, suppose Vitalik wants to send a blob transaction carrying two blobs explaining “data availability sampling.” He could include a paragraph of textual explanation in the first blob and an illustration image in the second blob. The corresponding metadata JSON object would look like this:</p>
{</span></span>
    "</span>originator</span>"</span>:</span> "</span>Vitalik Buterin</span>"</span>,</span></span>
    "</span>description</span>"</span>:</span> "</span>An illustration of data availability sampling</span>"</span>,</span></span>
    "</span>blobs</span>"</span>:</span> [</span></span>
      {</span></span>
        "</span>content_type</span>"</span>:</span> "</span>text/plain</span>"</span>,</span></span>
        "</span>description</span>"</span>:</span> "</span>This blob contains a description text of the illustration.</span>"</span></span>
      }</span>,</span></span>
      {</span></span>
        "</span>content_type</span>"</span>:</span> "</span>image/png</span>"</span>,</span></span>
        "</span>description</span>"</span>:</span> "</span>This blob contains the illustration image data in base64 format. It's a RFC 2397 (https://www.rfc-editor.org/rfc/rfc2397) data URL.</span>"</span></span>
      }</span>,</span></span>
    ]</span></span>
  }</span></span></code></pre>
The complete blob transaction would include this metadata in the data field, along with other relevant fields:</p>
{</span></span>
  "</span>blobVersionedHashes</span>"</span>:</span> [</span>"</span>0x...</span>"</span>,</span> "</span>0x...</span>"</span>]</span>,</span></span>
  "</span>chainId</span>"</span>:</span> 11155111</span>,</span> //</span> Supposing the blob transaction is posted to Sepolia</span></span>
  "</span>type</span>"</span>:</span> "</span>eip4844</span>"</span>,</span></span>
  "</span>to</span>"</span>:</span> "</span>0x0000000000000000000000000000000000000000</span>"</span>,</span></span>
  "</span>gas</span>"</span>:</span> 28236</span>,</span></span>
  "</span>data</span>"</span>:</span> "</span>0x..</span>"</span>,</span> //</span> String representation of the above metadata JSON object</span></span>
  "</span>nonce</span>"</span>:</span> 18</span>,</span></span>
  "</span>maxFeePerBlobGas</span>"</span>:</span> 1073677089</span>,</span></span>
  "</span>maxFeePerGas</span>"</span>:</span> 1213388073</span>,</span></span>
  "</span>maxPriorityFeePerGas</span>"</span>:</span> 1165808679</span>,</span></span>
  "</span>sidecars</span>"</span>:</span> [</span></span>
    {</span> "</span>blob</span>"</span>:</span> "</span>0x...</span>"</span>,</span> "</span>commitment</span>"</span>:</span> "</span>0x...</span>"</span>,</span> "</span>proof</span>"</span>:</span> "</span>0x...</span>"</span> }</span>,</span></span>
    {</span> "</span>blob</span>"</span>:</span> "</span>0x...</span>"</span>,</span> "</span>commitment</span>"</span>:</span> "</span>0x...</span>"</span>,</span> "</span>proof</span>"</span>:</span> "</span>0x...</span>"</span> }</span></span>
  ]</span></span>
}</span></span></code></pre>Blob Transaction Envelope</h3>
The blob transaction's calldata (i.e., the data field) should be set to the string representation of the metadata JSON object, encoded in UTF-8.</p>
Rationale</h2>
In the Ethereum ecosystem, various types of transactions exist, each serving different purposes. The usage of the data field within these transactions varies:</p>

Regular Funds Transfer Transactions</strong>:
In these transactions, the data field is typically not used, and users may optionally include arbitrary data.</li>
Smart Contract Deployment Transactions</strong>:
For deploying smart contracts. The data field holds the contract bytecode and any encoded arguments required by the constructor.</li>
Smart Contract Function Call Transactions</strong>:
When invoking smart contract functions, the data field contains the function call data, including the function signature and any necessary parameters.</li>
</ul>
Blob transactions are specifically designed for posting blobs, and normally, the data field remains unused. This EIP proposes a novel approach: utilizing the data field to attach metadata to the carried blobs. By doing so, we can enhance the auditability and usability of blob transactions.</p>
However, it’s essential to note that there are scenarios where blob transactions may also need to call smart contract functions. Consider a decentralized storage application that employs a smart contract to track blob versioned hashes and metadata like MIME types. In such cases, users could submit a blob transaction containing blobs while simultaneously using the data field to invoke smart contract functions to store versioned hashes and MIME types of those blobs. It’s important to recognize that this EIP does not cover such specific use cases.</p>
Backwards Compatibility</h1>
This EIP is backward compatible with EIP-4844</a>, as it does not modify the structure or functionality of blob transactions, but only adds an optional metadata field to them.</p>
Security Considerations</h2>
This EIP does not introduce any new security risks or vulnerabilities, as the metadata is only an informational field that does not affect the execution or validity of blob transactions. However, users and applications should be aware of the following potential issues:</p>


The metadata is not verified or enforced by the consensus layer, and therefore it may not be accurate or trustworthy. Users and applications should not rely on the metadata for critical or sensitive operations, and should always verify the contents and sources of the blobs themselves.</p>
</li>

The metadata may contain malicious or harmful data, such as spam, phishing, malware, etc. Users and applications should not blindly trust or execute the metadata, and should always scan and sanitize the metadata before using it.</p>
</li>

The metadata may increase the gas cost of blob transactions, as more data is included in the data field. Users and applications should balance the benefits and costs of using the metadata, and should optimize the size and format of the metadata to reduce the gas cost.</p>
</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Reserve Precompile Address Range for RIPs
2023-12-21T00:00:00+00:00
Abstract</h2>
This EIP reserves precompile ranges to ensure there are no conflicts with those used by the Rollup Improvement Proposal (RIP) process.</p>
Motivation</h2>
As L2s begin to deploy RIPs, it is necessary to reserve an address range for use by the RIP process so as to ensure there are no conflicts between precompile addresses used by RIPs and EIPs.</p>
Specification</h2>
The address range between 0x0000000000000000000000000000000000000100</code> and 0x00000000000000000000000000000000000001ff</code> is reserved for use by the RIP process.</p>
Rationale</h2>
By reserving an address range for RIPs, it allows the RIP process to maintain its own registry of precompiles that are not (necessarily) deployed on L1 mainnet, the EIP process is freed from having to maintain a registry of RIP precompiles while still having 255 addresses for its own use.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
Nil.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Multi-Asset ERC-4626 Vaults
2023-12-11T00:00:00+00:00
Abstract</h2>
The following standard adapts ERC-4626</a> to support multiple assets or entry points for the same share token. This also enables Vaults which don't have a true share token but rather convert between two arbitrary external tokens.</p>
It adds a new share</code> method to the Vault, to allow the ERC-20</a> dependency to be externalized.</p>
It also adds Vault-to-Share lookup to the share token.</p>
Lastly, it enforces ERC-165</a> support for Vaults and the share token.</p>
Motivation</h2>
One missing use case that is not supported by ERC-4626</a> is Vaults which have multiple assets or entry points such as liquidity provider (LP) Tokens. These are generally unwieldy or non-compliant due to the requirement of ERC-4626 to itself be an ERC-20</a>.</p>
Specification</h2>
Definitions:</h3>
The existing definitions from ERC-4626</a> apply. In addition, this spec defines:</p>

Multi-Asset Vaults: A Vault which has multiple assets/entry points. The Multi-Asset Vault refers to the group of ERC-7575</a> contracts with the entry points for a specific asset, linked to one common share</code> token.</li>
Pipe: A converter from one token to another (unidirectional or bidirectional)</li>
</ul>
Methods</h3>
All ERC-7575</a> Vaults MUST implement ERC-4626</a> excluding the ERC-20</a> methods and events.</p>
share</h4>
The address of the underlying share</code> received on deposit into the Vault. MUST return an address of an ERC-20</a> share representation of the Vault.</p>
share</code> MAY return the address of the Vault itself.</p>
If the share</code> returns an external token i.e. share != address(this)</code>:</p>

entry functions MUST increase the share</code> balance of the receiver</code> by the shares</code> amount. i.e. share.balanceOf(receiver) += shares</code></li>
exit functions MUST decrease the share</code> balance of the owner</code> by the shares</code> amount. i.e. share.balanceOf(owner) -= shares</code></li>
</ul>
MUST NOT</em> revert.</p>
-</span> n</span>ame</span>:</span> s</span>hare</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span> [</span>]</span></span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>hareTokenAddress</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span></code></pre>Multi-Asset Vaults</h3>
Multi-Asset Vaults share a single share</code> token with multiple entry points denominated in different asset</code> tokens.</p>
Multi-Asset Vaults MUST implement the share</code> method on each entry point. The entry points SHOULD NOT be ERC-20</a>.</p>
Pipes</h3>
Pipes convert between a single asset</code> and share</code> which are both ERC-20</a> tokens outside the Vault.</p>
A Pipe MAY be either unidirectional or bidirectional.</p>
A unidirectional Pipe SHOULD implement only the entry function(s) deposit</code> and/or mint</code>, not redeem</code> and/or withdraw</code>.</p>
The entry points SHOULD lock or burn the asset</code> from the msg.sender</code> and mint or transfer the share</code> to the receiver</code>. For bidirectional pipes, the exit points SHOULD lock or burn the share</code> from the owner</code> and mint or transfer the asset</code> to the receiver</code>.</p>
Share-to-Vault lookup</h3>
The ERC-20</a> implementation of share</code> SHOULD implement a vault</code> method, that returns the address of the Vault for a specific asset</code>.</p>
SHOULD emit the VaultUpdate</code> event when a Vault linked to the share changes.</p>
-</span> n</span>ame</span>:</span> v</span>ault</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span> </span></span>
    -</span> n</span>ame</span>:</span> a</span>sset</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    </span></span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> v</span>ault</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span></code></pre>ERC-165</a> support</h3>
Vaults implementing ERC-7575</a> MUST implement the ERC-165</a> supportsInterface</code> function. The Vault contract MUST return the constant value true</code> if 0x2f0a18c5</code> is passed through the interfaceID</code> argument.</p>
The share contract SHOULD implement the ERC-165</a> supportsInterface</code> function. The share token MUST return the constant value true</code> if 0xf815c03d</code> is passed through the interfaceID</code> argument.</p>
Events</h3>
VaultUpdate</h4>
The Vault linked to the share has been updated.</p>
-</span> n</span>ame</span>:</span> V</span>aultUpdate</span></span>
  t</span>ype</span>:</span> e</span>vent</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>sset</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> v</span>ault</span></span>
      i</span>ndexed</span>:</span> false</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span></code></pre>Rationale</h2>
This standard is intentionally flexible to support both existing ERC-4626</a> Vaults easily by the introduction of a single new method, but also flexible to support new use cases by allowing separate share tokens.</p>
Ability to externalize ERC-20</a> Dependency</h3>
By allowing share != address(this)</code>, the Vault can have an external contract managing the ERC-20</a> functionality of the Share. In the case of Multi-Asset, this avoids the confusion that might arise if each Vault itself were required to be an ERC-20</a>, which could confuse integrators and front-ends.</p>
This approach also enables the creation of new types of Vaults, such as Pipes, which facilitate the conversion between two external ERC-20</a> tokens. These Pipes could be unidirectional (i.e. only for assets to shares via deposit/mint, or shares to assets via redeem/withdraw) or bidirectional for both entry and exit flows.</p>
Including Share-to-Vault lookup optionally</h3>
The vault</code> method is included to look up a Vault for a share</code> by its asset</code>, combined with the VaultUpdate</code> event and ERC-165</a> support. This enables integrations to easily query Multi-Asset Vaults.</p>
This is optional, to maintain backward compatibility with use cases where the share</code> is an existing deployed contract.</p>
Backwards Compatibility</h2>
ERC-7575</a> Vaults are not fully compatible with ERC-4626</a> because the ERC-20</a> functionality has been removed.</p>
Reference Implementation</h2>
    //</span> This code snippet is incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure</span></span>
</span>
    contract</span> Share</span> is</span> ERC20</span> {</span></span>
        mapping</span> (</span>address</span> asset </span>=></span> address</span>)</span> vault</span>;</span></span>
</span>
        function</span> updateVault</span>(</span>address</span> asset</span>,</span> address</span> vault_</span>)</span> public</span> {</span></span>
            vault</span>[</span>asset</span>]</span> =</span> vault_</span>;</span></span>
            emit</span> UpdateVault</span>(</span>asset</span>,</span> vault_</span>)</span>;</span></span>
        }</span></span>
</span>
        function</span> supportsInterface</span>(</span>bytes4</span> interfaceId</span>)</span> external</span> pure</span> override</span> returns</span> (</span>bool</span>)</span> {</span></span>
            return</span> interfaceId </span>==</span> 0xf815c03d</span> ||</span> interfaceId </span>==</span> 0x01ffc9a7</span>;</span></span>
        }</span></span>
    }</span></span>
</span>
    contract</span> TokenAVault</span> is</span> ERC7575</span> {</span></span>
        address</span> public</span> share </span>=</span> address</span>(</span>Share</span>)</span>;</span></span>
        address</span> public</span> asset </span>=</span> address</span>(</span>TokenA</span>)</span>;</span></span>
</span>
        //</span> ERC4626 implementation</span></span>
</span>
        function</span> supportsInterface</span>(</span>bytes4</span> interfaceId</span>)</span> external</span> pure</span> override</span> returns</span> (</span>bool</span>)</span> {</span></span>
            return</span> interfaceId </span>==</span> 0x2f0a18c5</span> ||</span> interfaceId </span>==</span> 0x01ffc9a7</span>;</span></span>
        }</span></span>
    }</span></span>
</span>
    contract</span> TokenBVault</span> is</span> ERC7575</span> {</span></span>
        address</span> public</span> share </span>=</span> address</span>(</span>Share</span>)</span>;</span></span>
        address</span> public</span> asset </span>=</span> address</span>(</span>TokenB</span>)</span>;</span></span>
</span>
        //</span> ERC4626 implementation</span></span>
</span>
        function</span> supportsInterface</span>(</span>bytes4</span> interfaceId</span>)</span> external</span> pure</span> override</span> returns</span> (</span>bool</span>)</span> {</span></span>
            return</span> interfaceId </span>==</span> 0x2f0a18c5</span> ||</span> interfaceId </span>==</span> 0x01ffc9a7</span>;</span></span>
        }</span></span>
    }</span></span>
</span></code></pre>Security Considerations</h2>
ERC-20</a> non-compliant Vaults must take care with supporting a redeem flow where owner</code> is not msg.sender</code>, since the ERC-20</a> approval flow does not by itself work if the Vault and share are separate contracts. It can work by setting up the Vault as a Trusted Forwarder of the share token, using ERC-2771</a>.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Hardfork Meta Backfill - Berlin to Shapella
2023-12-01T00:00:00+00:00
Abstract</h2>
Following Muir Glacier hard fork, Meta EIPs were abandoned in favor of other ways to track changes included in Ethereum network upgrades. This EIP aggregates the specifications for these upgrades, which themselves list the specific changes included. Specifically, it covers the Beacon Chain launch (Serenity Phase 0), Berlin, London, Altair, Arrow Glacier, Gray Glacier, The Merge (Paris + Bellatrix) and Shapella (Shanghai + Capella).</p>
Motivation</h2>
For many years, Ethereum used Meta EIPs to document network upgrades. Recently, consensus has formed around using them again. This EIP aggregates the network upgrades who did not have Meta EIPs and links out to their specifications.</p>
Specification</h2>
The network upgrades below are listed in order of activation. Upgrades to Ethereum's execution layer are marked "[EL]", and those to Ethereum's consensus layer are marked "[CL]".</p>
Beacon Chain Launch - Serenity Phase 0 [CL]</h3>
The full specifications for the Beacon Chain at launch can be found in the v1.0.0</code> release of the ethereum/consensus-specs</code> repository</a>. Additionally, EIP-2982</a> provides context on the Beacon Chain design and rationale for its mainnet parametrization.</p>
Berlin [EL]</h3>
The set of EIPs included in Berlin were originally specified in EIP-2070</a>, but then moved to the berlin.md</code></a> file of the ethereum/execution-specs</code> repository.</p>
London [EL]</h3>
The set of EIPs included in London are specified in the london.md</code></a> file of the ethereum/execution-specs</code> repository.</p>
Altair [CL]</h3>
The full specifications for the Altair network upgrade can be found in the v1.1.0</code> release of the ethereum/consensus-specs</code> repository</a>.</p>
Arrow Glacier [EL]</h3>
The set of EIPs included in Arrow Glacier are specified in thearrow-glacier.md</code></a> file of the ethereum/execution-specs</code> repository.</p>
Gray Glacier [EL]</h3>
The set of EIPs included in Gray Glacier are specified in thegray-glacier.md</code></a> file of the ethereum/execution-specs</code> repository.</p>
The Merge</h3>
The Merge was the first upgrade to require coordination between the execution and consensus layers. The consensus layer first activated the Bellatrix upgrade, which was followed by the activation of Paris on the execution layer.</p>
Bellatrix [CL]</h4>
The full specifications for the Bellatrix network upgrade can be found in the v1.2.0</code> release of the ethereum/consensus-specs</code> repository</a>.</p>
Paris [EL]</h4>
The set of EIPs included in Paris are specified in the paris.md</code></a> file of the ethereum/execution-specs</code> repository.</p>
Shapella</h3>
The Shapella upgrade was the first upgrade to activate at the same time on both the execution and consensus layers. To enable this, the upgrade activation mechanism on the execution layer was changed to use timestamps instead of blocks. This is described in EIP-6953</a> and EIP-6122</a>.</p>
Shanghai [EL]</h4>
The set of EIPs included in Shanghai are specified in theshanghai.md</code></a> file of the ethereum/execution-specs</code> repository.</p>
Capella [CL]</h4>
The full specifications for the Capella network upgrade can be found in the v1.3.0</code> release of the ethereum/consensus-specs</code> repository</a>.</p>
Rationale</h2>
The EIP repository is well known within the Ethereum community, and Meta EIPs have historically been useful to clearly list the EIPs included in a specific network upgrade.</p>
While the specification process for the execution and consensus layers differ, there is value in having a single, harmonized, list of EIPs included in each upgrade, and for the lists for both layers to be part of the same repository.</p>
Re-introducing Hardfork Meta EIPs enables this, and allows for de-duplication in cases where an EIP affects both the execution and consensus layer of Ethereum. This EIP covers the upgrades which did not use a Hardfork Meta EIP.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Hardfork Meta - Dencun
2023-12-01T00:00:00+00:00
Abstract</h2>
This Meta EIP lists the EIPs included in the Dencun network upgrade across both Ethereum's execution and consensus layers. See EIP-7568</a> for the specifications of past upgrades.</p>
Specification</h2>
Included EIPs</h3>

EIP-1153</a>: Transient storage opcodes</li>
EIP-4788</a>: Beacon block root in the EVM</li>
EIP-4844</a>: Shard Blob Transactions</li>
EIP-5656</a>: MCOPY - Memory copying instruction</li>
EIP-6780</a>: SELFDESTRUCT only in same transaction</li>
EIP-7044</a>: Perpetually Valid Signed Voluntary Exits</li>
EIP-7045</a>: Increase Max Attestation Inclusion Slot</li>
EIP-7514</a>: Add Max Epoch Churn Limit</li>
EIP-7516</a>: BLOBBASEFEE opcode</li>
</ul>
Full Specifications</h3>
Consensus Layer</h4>
EIPs 4788, 4844, 7044, 7045 and 7514 require changes to Ethereum's consensus layer. These are specified in the deneb</code> folder of the ethereum/consensus-specs</code> repository.</p>
Execution Layer</h4>
EIPs 1153, 4788, 4844, 5656, 6780 and 7516 require changes to Ethereum's execution layer. The EIPs fully specify the changes.</p>
Activation</h3>
Network Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead>

Goerli</td> 231680</code></td> 1705473120</code></td></tr>
Sepolia</td> 132608</code></td> 1706655072</code></td></tr>
Holešky</td> 29696</code></td> 1707305664</code></td></tr>
Mainnet</td> 269568</code></td> 1710338135</code></td></tr>
</tbody></table>
Note</strong>: rows in the table above will be filled as activation times are decided by client teams.</p>
Rationale</h2>
This Meta EIP provides a global view of all changes included in the Dencun network upgrade, as well as links to full specification.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Move committee index outside Attestation
2023-11-01T00:00:00+00:00
Abstract</h2>
Move the committee's index</code> field outside of the signed Attestation message to allow aggregation of equal consensus votes.</p>
Motivation</h2>
This proposal aims to make Casper FFG clients more efficient by reducing the average number of pairings needed to verify consensus rules. While all types of clients can benefit from this EIP, ZK circuits proving Casper FFG consensus will likely have the most impact.</p>
On a beacon chain network with at least 262144 active indices, it's necessary to verify a minimum of ceil(32*64 * 2/3) = 1366</code> attestations to reach a 2/3 threshold. Participants cast two votes at once: LMD GHOST vote and Casper-FFG vote. However, the Attestation message contains three elements:</p>

LMD GHOST vote (beacon_block_root, slot)</code>. Note: includes slot in the event (block, slot) voting is adopted.</li>
FFG vote (source, target)</code></li>
Committee index (index)</code></li>
</ol>
Signing over the 3rd item causes tuples of equal votes to produce different signing roots. If the committee index is moved outside of the Attestation message, the minimum number of attestations to verify to reach a 2/3 threshold is reduced to ceil(32 * 2/3) = 22</code> (a factor of 62).</p>
On-chain attestations can now be packed more space-efficiently into beacon blocks. This proposal allows for up to 8 slots worth of votes in a block, compared to 2 today. In other words, a chain with only 1/8 online proposers can still potentially include all votes on-chain.</p>
Specification</h2>
Execution layer</h3>
This requires no changes to the Execution Layer.</p>
Consensus layer</h3>

Set index</code> field from AttestationData</code> to a fixed value of zero</li>
Move committee indexing data to the outer Attestation</code> container with committee_bits</code></li>
Increase the capacity of aggregation_bits</code> to all committees in a slot</li>
</ul>
The full specification of the proposed change can be found in /specs/electra/beacon-chain.md</code></a>.</p>
Rationale</h2>
Deprecation strategy</h3>
The index</code> field in AttestationData</code> can be deprecated by:</p>

Removing the field</li>
Preserving the field and setting it to zero</li>
Changing the field type to Optional (from EIP-7495 StableContainer)</li>
</ol>
This EIP chooses the second option to not complicate the inclusion of AttesterSlashing</code> objects. While the Attestation</code> container changes, AttesterSlashing</code> includes indexed attestations without committee data.</p>
MAX_ATTESTATIONS</code> value</h3>
The maximum size of an attestation increases, with a bitfield 64 times larger on networks with maxed committees. MAX_ATTESTATIONS</code> value is reduced to limit the beacon block size while still increasing the total capacity of votes. A value of 8 increases the voting capacity by 4 while having the same attestation space size with a network of 1.2M active indices.
Read the details here</a>.</p>
MAX_ATTESTER_SLASHINGS</code> value</h3>
On-chain AttesterSlashing</code> includes a list of participants' indices. With this EIP, the worst-case size increases by 64 times, resulting in an uncompressed size of 488 KB per AttesterSlashing</code> in a network of 1M validators. Snappy compression reduces it to 320 KB, which is still significant. To bound the maximum size of the block, this proposal reduces MAX_ATTESTER_SLASHINGS</code> from 2 to 1, the minimum value.
Read the details here</a>.</p>
Using Bitvector</code> for committee_bits</code></h3>
The committee_bits</code> sequence has a variable length with the max size MAX_COMMITTEES_PER_SLOT = 64</code>. Encoding of the Bitlist</code> includes its actual length, which doubles the size of the committee_bits</code> compared to the Bitvector</code> type. Beacon chain state transition ensures correctness of the committee_bits</code> when the effective number of committees in a slot is less than its max value.</p>
Backwards Compatibility</h2>
This EIP introduces backward-incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p>
Security Considerations</h2>
First block after the fork</h3>
Because the on-chain Attestation</code> container changes, attestations from the prior fork can't be included in post-Electra blocks. Therefore, the first block after the fork may have zero attestations. LMD votes can still be applied to fork-choice via on_attestation</code> handler, so there will be only a 1/32 loss of FFG votes. Attesters assigned to the last slot of the fork will incur one epoch worth of offline penalties. One possible mitigation is to change the Electra block body type to allow including attestations from both forks. However, the mitigation increases complexity for little gain, so this proposal chooses not to address the issue.</p>
Mutation over gossip</h3>
Moving the index</code> field outside of the signed message allows malicious mutation only on the p2p gossip topic beacon_attestation_${subnet_id}</code>. Everywhere else, the Attestation</code> message is wrapped with an outer signature that prevents mutation.</p>
Gossip verification rules for the beacon_attestation_${subnet_id}</code> topic include:</p>


[REJECT] The attester is a member of the committee -- i.e., attestation.attester_index</code> in get_beacon_committee(state, attestation.data.slot, index)</code></li>
</ul>
</blockquote>
If an attacker mutates the index</code> field, the above rule verification will fail, and the message will be dropped. If implementations run the above check before registering the attestation in a 'first-seen' cache, there's no risk of cache pollution.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Asynchronous ERC-4626 Tokenized Vaults
2023-10-18T00:00:00+00:00
Abstract</h2>
The following standard extends ERC-4626</a> by adding support for asynchronous deposit and redemption flows. The async flows are called Requests.</p>
New methods are added to asynchronously Request a deposit or redemption, and view the status of the Request. The existing deposit</code>, mint</code>, withdraw</code>, and redeem</code> ERC-4626 methods are used for executing Claimable Requests.</p>
Implementations can choose whether to add asynchronous flows for deposits, redemptions, or both.</p>
Motivation</h2>
The ERC-4626 Tokenized Vaults standard has helped to make yield-bearing tokens more composable across decentralized finance. The standard is optimized for atomic deposits and redemptions up to a limit. If the limit is reached, no new deposits or redemptions can be submitted.</p>
This limitation does not work well for any smart contract system with asynchronous actions or delays as a prerequisite for interfacing with the Vault (e.g. real-world asset protocols, undercollateralized lending protocols, cross-chain lending protocols, liquid staking tokens, or insurance safety modules).</p>
This standard expands the utility of ERC-4626 Vaults for asynchronous use cases. The existing Vault interface (deposit</code>/withdraw</code>/mint</code>/redeem</code>) is fully utilized to claim asynchronous Requests.</p>
Specification</h2>
Definitions:</h3>
The existing definitions from ERC-4626</a> apply. In addition, this spec defines:</p>

Request: a request to enter (requestDeposit</code>) or exit (requestRedeem</code>) the Vault</li>
Pending: the state where a Request has been made but is not yet Claimable</li>
Claimable: the state where a Request is processed by the Vault enabling the user to claim corresponding shares</code> (for async deposit) or assets</code> (for async redeem)</li>
Claimed: the state where a Request is finalized by the user and the user receives the output token (e.g. shares</code> for a deposit Request)</li>
Claim function: the corresponding Vault method to bring a Request to Claimed state (e.g. deposit</code> or mint</code> claims shares</code> from requestDeposit</code>). Lowercase claim always describes the verb action of calling a Claim function.</li>
asynchronous deposit Vault: a Vault that implements asynchronous Requests for deposit flows</li>
asynchronous redemption Vault: a Vault that implements asynchronous Requests for redemption flows</li>
fully asynchronous Vault: a Vault that implements asynchronous Requests for both deposit and redemption flows</li>
controller: owner of the Request, who can manage any actions related to the Request including claiming the assets</code> or shares</code></li>
operator: an account that can manage Requests on behalf of another account.</li>
</ul>
Request Flows</h3>
ERC-7540 Vaults</a> MUST implement one or both of asynchronous deposit and redemption Request flows. If either flow is not implemented in a Request pattern, it MUST use the ERC-4626 standard synchronous interaction pattern.</p>
All ERC-7540 asynchronous tokenized Vaults MUST implement ERC-4626 with overrides for certain behavior described below.</p>
Asynchronous deposit Vaults MUST override the ERC-4626 specification as follows:</p>

The deposit</code> and mint</code> methods do not transfer assets</code> to the Vault, because this already happened on requestDeposit</code>.</li>
previewDeposit</code> and previewMint</code> MUST revert for all callers and inputs.</li>
</ol>
Asynchronous redeem Vaults MUST override the ERC-4626 specification as follows:</p>

The redeem</code> and withdraw</code> methods do not transfer shares</code> to the Vault, because this already happened on requestRedeem</code>.</li>
The owner</code> field of redeem</code> and withdraw</code> SHOULD be renamed to controller</code>, and the controller MUST be msg.sender</code> unless the controller</code> has approved the msg.sender</code> as an operator.</li>
previewRedeem</code> and previewWithdraw</code> MUST revert for all callers and inputs.</li>
</ol>
Request Lifecycle</h3>
After submission, Requests go through Pending, Claimable, and Claimed stages. An example lifecycle for a deposit Request is visualized in the table below.</p>
State</strong></th> User</strong></th> Vault</strong></th></tr></thead>

Pending</td> requestDeposit(assets, controller, owner)</code></td> asset.transferFrom(owner, vault, assets)</code>; pendingDepositRequest[controller] += assets</code></td></tr>
Claimable</td> </td> Internal Request fulfillment</em>:  pendingDepositRequest[controller] -= assets</code>; claimableDepositRequest[controller] += assets</code></td></tr>
Claimed</td> deposit(assets, receiver, controller)</code></td> claimableDepositRequest[controller] -= assets</code>; vault.balanceOf[receiver] += shares</code></td></tr>
</tbody></table>
Note that maxDeposit</code> increases and decreases in sync with claimableDepositRequest</code>.</p>
Requests MUST NOT skip or otherwise short-circuit the Claim state. In other words, to initiate and claim a Request, a user MUST call both request* and the corresponding Claim function separately, even in the same block. Vaults MUST NOT "push" tokens onto the user after a Request, users MUST "pull" the tokens via the Claim function.</p>
For asynchronous Vaults, the exchange rate between shares</code> and assets</code> including fees and yield is up to the Vault implementation. In other words, pending redemption Requests MAY NOT be yield-bearing and MAY NOT have a fixed exchange rate.</p>
Request Ids</h3>
The request ID (requestId</code>) of a request is returned by the corresponding requestDeposit</code> and requestRedeem</code> functions.</p>
Multiple requests may have the same requestId</code>, so a given Request is discriminated by both the requestId</code> and the controller</code>.</p>
Requests of the same requestId</code> MUST be fungible with each other (except in the special case requestId == 0</code> described below). I.e. all Requests with the same requestId</code> MUST transition from Pending to Claimable at the same time and receive the same exchange rate between assets</code> and shares</code>. If a Request with requestId != 0</code> becomes partially claimable, all requests of the same requestId</code> MUST become claimable at the same pro-rata rate.</p>
There are no assumptions or requirements of requests with different requestId</code>. I.e. they MAY transition to Claimable at different times and exchange rates with no ordering or correlation enforced in any way.</p>
When requestId==0</code>, the Vault MUST use purely the controller</code> to discriminate the request state. The Pending and Claimable state of multiple requests from the same controller</code> would be aggregated. If a Vault returns 0</code> for the requestId</code> of any request, it MUST return 0</code> for all requests.</p>
Methods</h3>
requestDeposit</h4>
Transfers assets</code> from owner</code> into the Vault and submits a Request for asynchronous deposit</code>. This places the Request in Pending state, with a corresponding increase in pendingDepositRequest</code> for the amount assets</code>.</p>
The output requestId</code> is used to partially discriminate the request along with the controller</code>. See Request Ids</a> section for more info.</p>
When the Request is Claimable, claimableDepositRequest</code> will be increased for the controller</code>. deposit</code> or mint</code> can subsequently be called by controller</code> to receive shares</code>. A Request MAY transition straight to Claimable state but MUST NOT skip the Claimable state.</p>
The shares</code> that will be received on deposit</code> or mint</code> MAY NOT be equivalent to the value of convertToShares(assets)</code> at the time of Request, as the price can change between Request and Claim.</p>
MUST support ERC-20</a> approve</code> / transferFrom</code> on asset</code> as a deposit Request flow.</p>
owner</code> MUST equal msg.sender</code> unless the owner</code> has approved the msg.sender</code> as an operator.</p>
MUST revert if all of assets</code> cannot be requested for deposit</code>/mint</code> (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc).</p>
Note that most implementations will require pre-approval of the Vault with the Vault's underlying asset</code> token.</p>
MUST emit the DepositRequest</code> event.</p>
-</span> n</span>ame</span>:</span> r</span>equestDeposit</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> n</span>onpayable</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssets</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> o</span>wner</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>pendingDepositRequest</h4>
The amount of requested assets</code> in Pending state for the controller</code> with the given requestId</code> to deposit</code> or mint</code>.</p>
MUST NOT include any assets</code> in Claimable state for deposit</code> or mint</code>.</p>
MUST NOT show any variations depending on the caller.</p>
MUST NOT revert unless due to integer overflow caused by an unreasonably large input.</p>
-</span> n</span>ame</span>:</span> p</span>endingDepositRequest</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssets</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>claimableDepositRequest</h4>
The amount of requested assets</code> in Claimable state for the controller</code> with the given requestId</code> to deposit</code> or mint</code>.</p>
MUST NOT include any assets</code> in Pending state for deposit</code> or mint</code>.</p>
MUST NOT show any variations depending on the caller.</p>
MUST NOT revert unless due to integer overflow caused by an unreasonably large input.</p>
-</span> n</span>ame</span>:</span> c</span>laimableDepositRequest</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssets</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>requestRedeem</h4>
Assumes control of shares</code> from owner</code> and submits a Request for asynchronous redeem</code>. This places the Request in Pending state, with a corresponding increase in pendingRedeemRequest</code> for the amount shares</code>.</p>
The output requestId</code> is used to discriminate the request along with the controller</code>. See Request Ids</a> section for more info.</p>
shares</code> MAY be temporarily locked in the Vault until the Claimable or Claimed state for accounting purposes, or they MAY be burned immediately upon requestRedeem</code>.</p>
In either case, the shares</code> MUST be removed from the custody of owner</code> upon requestRedeem</code> and burned by the time the request is Claimed.</p>
Redeem Request approval of shares</code> for a msg.sender</code> NOT equal to owner</code> may come either from ERC-20 approval over the shares</code> of owner</code> or if the owner</code> has approved the msg.sender</code> as an operator. This MUST be consistent with similar behaviour pointed out in ERC-6909</a>, within "Approvals and Operators" section: "In accordance with the transferFrom method, spenders with operator permission are not subject to allowance restrictions, spenders with infinite approvals SHOULD NOT have their allowance deducted on delegated transfers, but spenders with non-infinite approvals MUST have their balance deducted on delegated transfers."</p>
When the Request is Claimable, claimableRedeemRequest</code> will be increased for the controller</code>. redeem</code> or withdraw</code> can subsequently be called by controller</code> to receive assets</code>. A Request MAY transition straight to Claimable state but MUST NOT skip the Claimable state.</p>
The assets</code> that will be received on redeem</code> or withdraw</code> MAY NOT be equivalent to the value of convertToAssets(shares)</code> at the time of Request, as the price can change between Pending and Claimed.</p>
MUST revert if all of shares</code> cannot be requested for redeem</code> / withdraw</code> (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).</p>
MUST emit the RedeemRequest</code> event.</p>
-</span> n</span>ame</span>:</span> r</span>equestRedeem</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> n</span>onpayable</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>hares</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> o</span>wner</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
    -</span> t</span>ype</span>:</span> u</span>int256</span></span></code></pre>pendingRedeemRequest</h4>
The amount of requested shares</code> in Pending state for the controller</code> with the given requestId</code> to redeem</code> or withdraw</code>.</p>
MUST NOT include any shares</code> in Claimable state for redeem</code> or withdraw</code>.</p>
MUST NOT show any variations depending on the caller.</p>
MUST NOT revert unless due to integer overflow caused by an unreasonably large input.</p>
-</span> n</span>ame</span>:</span> p</span>endingRedeemRequest</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>hares</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>claimableRedeemRequest</h4>
The amount of requested shares</code> in Claimable state for the controller</code> with the given requestId</code> to redeem</code> or withdraw</code>.</p>
MUST NOT include any shares</code> in Pending state for redeem</code> or withdraw</code>.</p>
MUST NOT show any variations depending on the caller.</p>
MUST NOT revert unless due to integer overflow caused by an unreasonably large input.</p>
-</span> n</span>ame</span>:</span> c</span>laimableRedeemRequest</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>hares</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>isOperator</code></h4>
Returns true</code> if the operator</code> is approved as an operator for a controller</code>.</p>
-</span> n</span>ame</span>:</span> i</span>sOperator</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> o</span>perator</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>tatus</span></span>
      t</span>ype</span>:</span> b</span>ool</span></span></code></pre>setOperator</code></h4>
Grants or revokes permissions for operator</code> to manage Requests on behalf of the msg.sender</code>.</p>
MUST set the operator status to the approved</code> value.</p>
MUST log the OperatorSet</code> event.</p>
MUST return True.</p>
-</span> n</span>ame</span>:</span> s</span>etOperator</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> n</span>onpayable</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> o</span>perator</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> a</span>pproved</span></span>
      t</span>ype</span>:</span> b</span>ool</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>uccess</span></span>
      t</span>ype</span>:</span> b</span>ool</span></span></code></pre>deposit</code> and mint</code> overloaded methods</h4>
Implementations MUST support an additional overloaded deposit</code> and mint</code> method on the specification from ERC-4626</a>, with an additional controller</code> input of type address</code>:</p>

deposit(uint256 assets, address receiver, address controller)</code></li>
mint(uint256 shares, address receiver, address controller)</code></li>
</ul>
Calls MUST revert unless msg.sender</code> is either equal to controller</code> or an operator approved by controller</code>.</p>
The controller</code> field is used to discriminate the Request for which the assets</code> should be claimed in the case where msg.sender</code> is NOT controller</code>.</p>
When the Deposit</code> event is emitted, the first parameter MUST be the controller</code>, and the second parameter MUST be the receiver</code>.</p>
Events</h3>
DepositRequest</h4>
owner</code> has locked assets</code> in the Vault to Request a deposit with request ID requestId</code>. controller</code> controls this Request. sender</code> is the caller of the requestDeposit</code> which may not be equal to the owner</code>.</p>
MUST be emitted when a deposit Request is submitted using the requestDeposit</code> method.</p>
-</span> n</span>ame</span>:</span> D</span>epositRequest</span></span>
  t</span>ype</span>:</span> e</span>vent</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> o</span>wner</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> s</span>ender</span></span>
      i</span>ndexed</span>:</span> false</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssets</span></span>
      i</span>ndexed</span>:</span> false</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>RedeemRequest</h4>
sender</code> has locked shares</code>, owned by owner</code>, in the Vault to Request a redemption. controller</code> controls this Request, but is not necessarily the owner</code>.</p>
MUST be emitted when a redemption Request is submitted using the requestRedeem</code> method.</p>
-</span> n</span>ame</span>:</span> R</span>edeemRequest</span></span>
  t</span>ype</span>:</span> e</span>vent</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> o</span>wner</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> r</span>equestId</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> s</span>ender</span></span>
      i</span>ndexed</span>:</span> false</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> s</span>hares</span></span>
      i</span>ndexed</span>:</span> false</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>OperatorSet</code></h4>
The controller</code> has set the approved</code> status to an operator</code>.</p>
MUST be logged when the operator status is set.</p>
MAY be logged when the operator status is set to the same status it was before the current call.</p>
-</span> n</span>ame</span>:</span> O</span>peratorSet</span></span>
  t</span>ype</span>:</span> e</span>vent</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> c</span>ontroller</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> o</span>perator</span></span>
      i</span>ndexed</span>:</span> true</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
    -</span> n</span>ame</span>:</span> a</span>pproved</span></span>
      i</span>ndexed</span>:</span> false</span></span>
      t</span>ype</span>:</span> b</span>ool</span></span></code></pre>ERC-165</a> support</h3>
Smart contracts implementing this Vault standard MUST implement the ERC-165</a> supportsInterface</code> function.</p>
All asynchronous Vaults MUST return the constant value true</code> if either 0xe3bc4e65</code> (representing the operator methods that all ERC-7540 Vaults implement) or 0x2f0a18c5</code> (representing the ERC-7575</a> interface) is passed through the interfaceID</code> argument.</p>
Asynchronous deposit Vaults MUST return the constant value true</code> if 0xce3bbe50</code> is passed through the interfaceID</code> argument.</p>
Asynchronous redemption Vaults MUST return the constant value true</code> if 0x620ee8e4</code> is passed through the interfaceID</code> argument.</p>
ERC-7575</a> support</h3>
Smart contracts implementing this Vault standard MUST implement the ERC-7575</a> standard (in particular the share</code> method).</p>
Rationale</h2>
Including Request IDs but not including a Claim by ID method</h3>
Requests in an Asynchronous Vault have properties of NFTs or Semi-Fungible tokens due to their asynchronicity. However, trying to pigeonhole all ERC-7540 Vaults into supporting ERC-721</a> or ERC-1155</a> for Requests would create too much interface bloat.</p>
Using both an id and address to discriminate Requests allows for any of these use cases to be developed at an external layer without adding too much complexity to the core interface.</p>
Certain Vaults, especially requestId==0</code> cases, benefit from using the underlying ERC-4626</a> methods for claiming because there is no discrimination at the requestId</code> level. This standard is written primarily with those use cases in mind. A future standard can optimize for nonzero request ID with support for claiming and transferring requests discriminated also with a requestId</code>.</p>
Symmetry and Non-inclusion of requestWithdraw and requestMint</h3>
In ERC-4626, the spec was written to be fully symmetrical with respect to converting assets</code> and shares</code> by including deposit/withdraw and mint/redeem.</p>
Due to the nature of Requests, asynchronous Vaults can only operate with certainty on the quantity that is fully known at the time of the Request (assets</code> for deposit</code> and shares</code> for redeem</code>). Therefore the deposit Request flow cannot work with a mint</code> call, because the amount of assets</code> for the requested shares</code> amount may fluctuate before the fulfillment of the Request. Likewise, the redemption Request flow cannot work with a withdraw</code> call.</p>
Optionality of Flows</h3>
Certain use cases are only asynchronous on one side of the deposit or redeem Request flow. A good example of an asynchronous redemption Vault is a liquid staking token. The unstaking period necessitates support for asynchronous withdrawals, however, deposits can be fully synchronous.</p>
Non-inclusion of a Request Cancelation Flow</h3>
In many cases, canceling a Request may not be straightforward or even technically feasible. The state transition of cancelations could be synchronous or asynchronous, and the way to claim a cancelation interfaces with the remaining Vault functionality in complex ways.</p>
A separate EIP should be developed to standardize the behavior of cancelling a pending Request. Defining the cancel flow is still important for certain classes of use cases for which the fulfillment of a Request can take a considerable amount of time.</p>
Request Implementation Flexibility</h3>
The standard is flexible enough to support a wide range of interaction patterns for Request flows. Pending Requests can be handled via internal accounting, globally or on per-user levels, use ERC-20 or ERC-721</a>, etc.</p>
Likewise yield on redemption Requests can accrue or not, and the exchange rate of any Request may be fixed or variable depending on the implementation.</p>
Not Allowing Short-circuiting for Claims</h3>
If claims can short-circuit, this creates ambiguity for integrators and complicates the interface with overloaded behavior on Request functions.</p>
An example of a short-circuiting Request flow could be as follows: user triggers a Request which enters Pending state. When the Vault fulfills the Request, the corresponding assets/shares</code> are pushed straight to the user. This requires only 1 step on the user's behalf.</p>
This approach has a few issues:</p>

cost/lack of scalability: as the number of vault users grows it can become intractably expensive to offload the Claim costs to the Vault operator</li>
hinders integration potential: Vault integrators would need to handle both the 2-step and 1-step cases, with the 1-step pushing arbitrary tokens in from an unknown Request at an unknown time. This pushes complexity out onto integrators and reduces the standard's utility.</li>
</ul>
The 2-step approach used in the standard may be abstracted into a 1-step approach from the user perspective through the use of routers, relayers, message signing, or account abstraction.</p>
In the case where a Request may become Claimable immediately in the same block, there can be router contracts that atomically check for Claimable amounts immediately upon Request. Frontends can dynamically route Requests in this way depending on the state and implementation of the Vault to handle this edge case.</p>
No Outputs for Request Functions</h3>
requestDeposit</code> and requestRedeem</code> may not have a known exchange rate that will happen when the Request becomes Claimed. Returning the corresponding assets</code> or shares</code> could not work in this case.</p>
The Requests could also output a timestamp representing the minimum amount of time expected for the Request to become Claimable, however, not all Vaults will be able to return a reliable timestamp.</p>
No Event for Claimable State</h3>
The state transition of a Request from Pending to Claimable happens at the Vault implementation level and is not specified in the standard. Requests may be batched into the Claimable state, or the state may transition automatically after a timestamp has passed. It is impractical to require an event to emit after a Request becomes Claimable at the user or batch level.</p>
Reversion of Preview Functions in Async Request Flows</h3>
The preview functions do not take an address parameter, therefore the only way to discriminate discrepancies in the exchange rate is via the msg.sender</code>. However, this could lead to integration/implementation complexities where support contracts cannot determine the output of a claim on behalf of a controller</code>.</p>
In addition, there is no on-chain benefit to previewing the Claim step as the only valid state transition is to Claim anyway. If the output of a Claim is undesirable for any reason, the calling contract can revert on the output of that function call.</p>
It reduces code and implementation complexity at little to no cost to simply mandate reversion for the preview functions of an async flow.</p>
Mandated Support for ERC-165</a></h3>
Implementing support for ERC-165</a> is mandated because of the optionality of flows</a>. Integrations can use the supportsInterface</code> method to check whether a vault is fully asynchronous, partially asynchronous, or fully synchronous (for which it is just following the ERC-4626</a>), and use a single contract to support all cases.</p>
Not Allowing Pending Claims to be Fungible</h3>
The async pending claims represent a sort of semi-fungible intermediate share class. Vaults can elect to wrap these claims in any token standard they like, for example, ERC-20, ERC-1155</a>, or ERC-721 depending on the use case. This is intentionally left out of the spec to provide flexibility to implementers.</p>
Backwards Compatibility</h2>
The interface is fully backward compatible with ERC-4626</a>. The specification of the deposit</code>, mint</code>, redeem</code>, and withdraw</code> methods is different as described in Specification</a>.</p>
Reference Implementation</h2>
    //</span> This code snippet is incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure</span></span>
</span>
    mapping</span>(</span>address</span> =></span> uint256</span>)</span> public</span> pendingDepositRequest</span>;</span></span>
    </span></span>
    mapping</span>(</span>address</span> =></span> uint256</span>)</span> public</span> claimableDepositRequest</span>;</span></span>
</span>
    mapping</span>(</span>address</span> controller </span>=></span> mapping</span>(</span>address</span> operator </span>=></span> bool</span>)</span>)</span> public</span> isOperator</span>;</span></span>
</span>
    function</span> requestDeposit</span>(</span>uint256</span> assets</span>,</span> address</span> controller</span>,</span> address</span> owner</span>)</span> external</span> returns</span> (</span>uint256</span> requestId</span>)</span> {</span></span>
        require</span>(</span>assets </span>!=</span> 0</span>)</span>;</span></span>
        require</span>(</span>owner </span>==</span> msg.sender</span> ||</span> isOperator</span>[</span>owner</span>]</span>[</span>msg.sender</span>]</span>)</span>;</span></span>
</span>
        requestId </span>=</span> 0</span>;</span> //</span> no requestId associated with this request</span></span>
</span>
        asset</span>.</span>safeTransferFrom</span>(</span>owner</span>,</span> address</span>(</span>this</span>)</span>,</span> assets</span>)</span>;</span> //</span> asset here is the Vault underlying asset</span></span>
</span>
        pendingDepositRequest</span>[</span>controller</span>]</span> +</span>=</span> assets</span>;</span></span>
</span>
        emit</span> DepositRequest</span>(</span>controller</span>,</span> owner</span>,</span> requestId</span>,</span> msg.sender</span>,</span> assets</span>)</span>;</span></span>
        return</span> requestId</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * Include some arbitrary transition logic here from Pending to Claimable</span></span>
     */</span></span>
</span>
    function</span> deposit</span>(</span>uint256</span> assets</span>,</span> address</span> receiver</span>,</span> address</span> controller</span>)</span> external</span> returns</span> (</span>uint256</span> shares</span>)</span> {</span></span>
        require</span>(</span>assets </span>!=</span> 0</span>)</span>;</span></span>
        require</span>(</span>controller </span>==</span> msg.sender</span> ||</span> isOperator</span>[</span>controller</span>]</span>[</span>msg.sender</span>]</span>)</span>;</span></span>
</span>
        claimableDepositRequest</span>[</span>controller</span>]</span> -</span>=</span> assets</span>;</span> //</span> underflow would revert if not enough claimable assets</span></span>
</span>
        shares </span>=</span> convertToShares</span>(</span>assets</span>)</span>;</span> //</span> this naive example uses the instantaneous exchange rate. It may be more common to use the rate locked in upon Claimable stage.</span></span>
</span>
        balanceOf</span>[</span>receiver</span>]</span> +</span>=</span> shares</span>;</span></span>
</span>
        emit</span> Deposit</span>(</span>controller</span>,</span> receiver</span>,</span> assets</span>,</span> shares</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> setOperator</span>(</span>address</span> operator</span>,</span> bool</span> approved</span>)</span> public</span> returns</span> (</span>bool</span>)</span> {</span></span>
        isOperator</span>[</span>msg.sender</span>]</span>[</span>operator</span>]</span> =</span> approved</span>;</span></span>
        emit</span> OperatorSet</span>(</span>msg.sender</span>,</span> operator</span>,</span> approved</span>)</span>;</span></span>
        return</span> true</span>;</span></span>
    }</span></span>
</span></code></pre>Security Considerations</h2>
In general, asynchronicity concerns make state transitions in the Vault much more complex and vulnerable to security risks. Access control on Vault operations, clear documentation of state transitions, and invariant checks should all be performed to mitigate these risks. For example:</p>

The view methods for viewing Pending and Claimable request states (e.g. pendingDepositRequest) are estimates useful for display purposes but can be outdated. The inability to know the final exchange rate on any Request requires users to trust the implementation of the asynchronous Vault in the computation of the exchange rate and fulfillment of their Request.</li>
Shares or assets locked for Requests can be stuck in the Pending state. Vaults may elect to allow for the fungibility of pending claims or implement some cancellation functionality to protect users.</li>
</ul>
Operators</h3>
An operator has the ability to transfer the asset</code> of the vault from the approver to any address, and simultaneously grants control over the share</code> of the vault.</p>
Any user approving an operator must trust that operator with both the asset</code> and share</code> of the Vault.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Native Asset ERC-4626 Tokenized Vault
2023-10-12T00:00:00+00:00
Abstract</h2>
This standard is an extension of the ERC-4626</a> spec with an identical interface and behavioral overrides for handling Ether or any native asset as the underlying.</p>
Motivation</h2>
A standard for tokenized ETH Vaults has the same benefits as ERC-4626</a>, particularly in the case of Liquid Staking Tokens, (i.e. fungible ERC-20</a> wrappers around ETH staking).</p>
Maintaining the same exact interface as ERC-4626 further amplifies the benefits as the standard will be maximally compatible with existing ERC-4626 tooling and protocols.</p>
Specification</h2>
All ERC-7535</a> tokenized Vaults MUST implement ERC-4626 (and by extension ERC-20) with behavioral overrides for the methods asset</code>, deposit</code>, and mint</code> specified below.</p>
ERC-4626 Breaking Changes</h3>

Any assets</code> quantity refers to wei of Ether rather than ERC-20 balances.</li>
Any ERC-20 transfer</code> calls are replaced by Ether transfer (send</code> or call</code>)</li>
Any ERC-20 transferFrom</code> approval flows for asset</code> are not implemented</li>
deposit</code> and mint</code> have state mutability payable</code></li>
deposit</code> uses msg.value</code> as the primary input and MAY ignore assets</code></li>
</ul>
Methods</h3>
asset</h4>
MUST return 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE</code> per ERC-7528</a>.</p>
-</span> n</span>ame</span>:</span> a</span>sset</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> v</span>iew</span></span>
</span>
  i</span>nputs</span>:</span> [</span>]</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssetTokenAddress</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span></code></pre>deposit</h4>
Mints shares</code> Vault shares to receiver</code> by depositing exactly msg.value</code> of Ether.</p>
MUST have state mutability of payable</code>.</p>
MUST use msg.value</code> as the primary input parameter for calculating the shares</code> output. I.e. MAY ignore assets</code> parameter as an input.</p>
MUST emit the Deposit</code> event.</p>
MUST revert if all of msg.value</code> cannot be deposited (due to deposit limit being reached, slippage, etc).</p>
-</span> n</span>ame</span>:</span> d</span>eposit</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> p</span>ayable</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssets</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> r</span>eceiver</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>hares</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>mint</h4>
Mints exactly shares</code> Vault shares to receiver</code> by depositing assets</code> of ETH.</p>
MUST have state mutability of payable</code>.</p>
MUST emit the Deposit</code> event.</p>
MUST revert if all of shares</code> cannot be minted (due to deposit limit being reached, slippage, the user not sending a large enough msg.value</code> of Ether to the Vault contract, etc).</p>
-</span> n</span>ame</span>:</span> m</span>int</span></span>
  t</span>ype</span>:</span> f</span>unction</span></span>
  s</span>tateMutability</span>:</span> p</span>ayable</span></span>
</span>
  i</span>nputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> s</span>hares</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span>
    -</span> n</span>ame</span>:</span> r</span>eceiver</span></span>
      t</span>ype</span>:</span> a</span>ddress</span></span>
</span>
  o</span>utputs</span>:</span></span>
    -</span> n</span>ame</span>:</span> a</span>ssets</span></span>
      t</span>ype</span>:</span> u</span>int256</span></span></code></pre>Events</h3>
The event usage MUST be identical to ERC-4626.</p>
Wrapped ETH</h3>
Any ERC-4626 Vault that uses a Wrapped ETH ERC-20 as the asset</code> MUST NOT implement ERC-7535. ERC-7535 only applies to native ETH.</p>
Rationale</h2>
This standard was designed to maximize compatibility with ERC-4626 while minimizing additional opinionated details on the interface. Examples of this decision rationale are described below:</p>

maintaining the redundant assets</code> input to the deposit</code> function while making its usage optional</li>
not enforcing a relationship between msg.value</code> and assets</code> in a mint</code> call</li>
not enforcing any behaviors or lack thereof for fallback</code>/__default__</code> methods, payability on additional vault functions, or handling ETH forcibly sent to the contract</li>
</ul>
All breaking implementation level changes with ERC-4626 are purely to accomodate for the usage of Ether or any native asset instead of an ERC-20 token.</p>
Allowing assets Parameter to be Ignored in a Deposit</h3>
msg.value</code> must always be passed anyway to fund a deposit</code>, therefore it may as well be treated as the primary input number. Allowing assets</code> to be used either forces a strict equality and extra unnecessary gas overhead for redundancy, or allows different values which could cause footguns and undefined behavior.</p>
The last option which could work is to require that assets</code> MUST be 0, but this still requires gas to enforce at the implementation level and can more easily be left unspecified, as the input is functionally ignorable in the spec as written.</p>
Allowing msg.value to Not Equal assets Output in a Mint</h3>
There may be many cases where a user deposits slightly too much Ether in a mint</code> call. In these cases, enforcing msg.value</code> to equal assets</code> would cause unnecessary reversions. It is up to the vault implementer to decide whether to refund or absorb any excess Ether, and up to depositors to deposit as close to the exact amount as possible.</p>
Backwards Compatibility</h2>
ERC-7535 is fully backward compatible with ERC-4626 at the function interface level. Certain implementation behaviors are different due to the fact that ETH is not ERC-20 compliant, such as the priority of msg.value</code> over assets</code>.</p>
It has no known compatibility issues with other standards.</p>
Security Considerations</h2>
In addition to all security considerations of ERC-4626</a>, there are security implications of having ETH as the Vault asset.</p>
call</code> vs send</code></h3>
Contracts should take care when using call</code> to transfer ETH, as this allows additional reentrancy vulnerabilities and arbitrary code execution beyond what is possible with trusted ERC-20 tokens.</p>
It is safer to simply send</code> ETH with a small gas stipend.</p>
Implementers should take extra precautions when deciding how to transfer ETH.</p>
Forceful ETH transfers</h3>
ETH can be forced into any Vault through the SELFDESTRUCT</code> opcode. Implementers should validate that this does not disrupt Vault accounting in any way.</p>
Similarly, any additional payable</code> methods should be checked to ensure they do not disrupt Vault accounting.</p>
Wrapped ETH</h3>
Smart contract systems which implement ERC-4626 should consider only supporting ERC-20 underlying assets, and default to using a Wrapped ETH ERC-20 instead of implementing ERC-7535 for handling ETH.</p>
The subtle differences between ERC-4626 and ERC-7535 can introduce code fragmentation and security concerns.</p>
Cleaner use cases for ERC-7535 are ETH exclusive, such as Wrapped ETH and Liquid Staking Tokens.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


ETH (Native Asset) Address Convention
2023-10-03T00:00:00+00:00
Abstract</h2>
The following standard proposes a convention for using the address 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee</code> in all contexts where an address is used to represent ETH in the same capacity as an ERC-20</a> token. This would apply to both events where an address field would denote ETH or an ERC-20</a> token, as well as discriminators such as the asset</code> field of an ERC-4626</a> vault.</p>
This standard generalizes to other EVM chains where the native asset is not ETH.</p>
Motivation</h2>
ETH, being a fungible unit of value, often behaves similarly to ERC-20</a> tokens. Protocols tend to implement a standard interface for ERC-20 tokens, and benefit from having the ETH implementation to closely mirror the ERC-20</a> implementations.</p>
In many cases, protocols opt to use Wrapped ETH (e.g. WETH9 deployed at address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 on Etherum Mainnet) for ERC-20</a> compliance. In other cases, protocols will use native ETH due to gas considerations, or the requirement of using native ETH such as in the case of a Liquid Staking Token (LST).</p>
In addition, protocols might create separate events for handling ETH native cases and ERC-20 cases. This creates data fragmentation and integration overhead for off-chain infrastructure. By having a strong convention for an ETH address to use for cases where it behaves like an ERC-20</a> token, it becomes beneficial to use one single event format for both cases.</p>
One intended use case for the standard is ERC-4626</a> compliant LSTs which use ETH as the asset</code>. This extends the benefits and tooling of ERC-4626</a> to LSTs and integrating protocols.</p>
This standard allows protocols and off-chain data infrastructure to coordinate around a shared understanding that any time 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee</code> is used as an address in an ERC-20</a> context, it means ETH.</p>
Specification</h2>
This standard applies for all components of smart contract systems in which an address is used to identify an ERC-20</a> token, and where native ETH is used in certain instances in place of an ERC-20</a> token. The usage of the term Token below means ETH or an ERC-20</a> in this context.</p>
Any fields or events where an ERC-20</a> address is used, yet the underlying Token is ETH, the address field MUST return 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee</code></p>
Any fields or events where the Token is a non-enshrined wrapped ERC-20 version of ETH (i.e WETH9) MUST use that Token's address and MUST NOT use 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee</code>.</p>
Where appropriate, the address should be checksummed. E.g. the EIP-55</a> checksum is 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE</code>.</p>
Rationale</h2>
Considered alternative addresses</h3>
Many existing implementations of the same use case as this standard use addresses such as 0x0, 0x1, and 0xe for gas efficiency of having leading zero bytes.</p>
Ultimately, all of these addresses collide with potential precompile addresses and are less distinctive as identifiers for ETH.</p>
0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee</code> has the most current usage, is distinctive, and would not collide with any precompiles. These benefits outweigh the potential gas benefits of other alternatives.</p>
Backwards Compatibility</h2>
This standard has no known compatibility issues with other standards.</p>
Security Considerations</h2>
Using ETH as a Token instead of WETH exposes smart contract systems to re-entrancy and similar classes of vulnerabilities. Implementers must take care to follow the industry standard development patterns (e.g.  checks-effects-interactions) when the Token is ETH.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


BLOBBASEFEE instruction
2023-09-11T00:00:00+00:00
Abstract</h2>
Add a BLOBBASEFEE (0x4a)</code> instruction that returns the value of the blob base-fee of the current block it is executing in. It is the identical to EIP-3198</a> (BASEFEE</code> opcode) except that it returns the blob base-fee as per EIP-4844</a>.</p>
Motivation</h2>
The intended use case would be for contracts to get the value of the blob base-fee. This feature enables blob-data users to programmatically account for the blob gas price, eg:</p>

Allow rollup contracts to trustlessly account for blob data usage costs.</li>
Blob gas futures can be implemented based on it which allows for blob users to smooth out data blob costs.</li>
</ul>
Specification</h2>
Add a BLOBBASEFEE</code> instruction with opcode 0x4a</code>, with gas cost 2</code>.</p>
Op</th> Input</th> Output</th> Cost</th></tr></thead>

0x4a</td> 0</td> 1</td> 2</td></tr>
</tbody></table>
BLOBBASEFEE</code> returns the result of the get_blob_gasprice(header) -> int</code> function as defined in EIP-4844 §Gas accounting</a>.</p>
Rationale</h2>
Gas cost</h3>
The value of the blob base-fee is needed to process data-blob transactions. That means its value is already available before running the EVM code.
The instruction does not add extra complexity and additional read/write operations, hence the choice of 2</code> gas cost. This is also identical to EIP-3198</a> (BASEFEE</code> opcode)'s cost as it just makes available data that is in the header.</p>
Backwards Compatibility</h2>
There are no known backward compatibility issues with this instruction.</p>
Test Cases</h2>
Nominal Case</h3>
Assume calling get_blob_gasprice(header)</code> (as defined in EIP-4844 §Gas accounting</a>) on the current block's header returns 7 wei</code>:
BLOBBASEFEE</code> should push the value 7</code> (left padded byte32) to the stack.</p>
Bytecode: 0x4900</code> (BLOBBASEFEE, STOP</code>)</p>
Pc</th> Op</th> Cost</th> Stack</th> RStack</th></tr></thead>

0</td> BLOBBASEFEE</td> 2</td> []</td> []</td></tr>
1</td> STOP</td> 0</td> [7]</td> []</td></tr>
</tbody></table>
Output: 0x
Consumed gas: 2</code></p>
Comprehensive Test Suite</h3>
A complete suite of tests can be found here</a>.</p>
Security Considerations</h2>
The value of the blob base-fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this instruction.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Add Max Epoch Churn Limit
2023-09-07T00:00:00+00:00
Abstract</h2>
Update the maximum validator growth rate from an exponential to a linear increase by capping the epoch churn limit.</p>
Motivation</h2>
This proposal aims to mitigate the negative externalities of very high level of total ETH supply staked before a proper solution is implemented. In other words, this proposal accepts the complexities of changing the rewards curve and is meant only to slow down growth.</p>
In the event that the deposit queue stays 100% full, the share of ETH supply staked will reach 50% by May 2024, 75% by September 2024, and 100% by December 2024. While rewards decrease as the validator set size increases, at 100% of ETH supply staked, yearly consensus rewards alone (excluding MEV/transaction fees) for validators still represent ~1.6% of their stake. This small yield does not necessarily dissuade additional capital staking due to the often much higher and unpredictable yields from MEV. As such, the equilibrium point of the validator set size can be close to its maximum possible. Liquid staking tokens (LSTs) also contribute to this, given stakers can use them as they use unstaked ETH.</p>
As the levels of ETH staked increase, more strain is put on the consensus layer. A larger number of validators leads to an increase in gossip messages, as well as a growing Beacon state size. Additionally, as the amount of stake grows, it's unclear how much marginal security benefits come from additional economic weight.</p>
The Beacon Chain validator reward function was chosen before its launch in 2020. PoS research and reward curve design were performed in a pre-MEV world. Much has changed since then, including the Beacon chain achieving unprecedented success, beyond the original intended targets of stake rate. In light of this, it is worth discussing whether Beacon chain validator rewards should be adjusted to better match today's reality, potentially to discourage staking past a certain point.</p>
This EIP does not attempt to do this, but to allow more time for the community to have these discussions. By limiting the epoch churn limit now, the time to reach critical milestones of total ETH supply staked are significantly delayed. This allows more time for research into more comprehensive solutions, and for community consensus around them to emerge.</p>
Specification</h2>
Constants</h3>
Name</th> Value</th></tr></thead>

MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code></td> 8</td></tr>
</tbody></table>
Execution layer</h3>
This requires no changes to the Execution Layer.</p>
Consensus layer</h3>

Add get_validator_activation_churn_limit</code> with upper bound MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code></li>
Modify process_registry_updates</code> to use bounded activation churn limit</li>
</ul>
The full specification of the proposed change can be found in /specs/deneb/beacon-chain.md</code></a>.</p>
Rationale</h2>
MAX_PER_EPOCH_CHURN_LIMIT</code> value</h3>
Depending on the specific constant selection the churn can decrease</em> at the activation fork epoch. The Beacon chain spec can handle this without issues. During 2023 Q4 (projected Dencun activation) the churn value will range 14-16. The table below compares the projected validator set assuming a continuous full deposit queue.</p>
MAX_PER_EPOCH_CHURN_LIMIT</code> activation date: Dec 01, 2023</h4>
Max Churn Limit</th> 50% ETH staked</th> 75% ETH staked</th> 100% ETH staked</th></tr></thead>

inf</td> May 28, 2024</td> Sep 25, 2024</td> Dec 18, 2024</td></tr>
16</td> Jul 23, 2024</td> Apr 10, 2025</td> Dec 26, 2025</td></tr>
12</td> Oct 09, 2024</td> Sep 21, 2025</td> Sep 04, 2026</td></tr>
8</td> Mar 15, 2025</td> Aug 18, 2026</td> Jan 21, 2028</td></tr>
6</td> Aug 19, 2025</td> Jul 14, 2027</td> Jun 08, 2029</td></tr>
4</td> Jun 29, 2026</td> May 05, 2029</td> Mar 12, 2032</td></tr>
</tbody></table>
MAX_PER_EPOCH_CHURN_LIMIT</code> activation date: Apr 01, 2024</h4>
Max Churn Limit</th> 50% ETH staked</th> 75% ETH staked</th> 100% ETH staked</th></tr></thead>

inf</td> May 28, 2024</td> Sep 25, 2024</td> Dec 18, 2024</td></tr>
16</td> Jul 01, 2024</td> Mar 18, 2025</td> Dec 04, 2025</td></tr>
12</td> Aug 01, 2024</td> Jul 14, 2025</td> Jun 26, 2026</td></tr>
8</td> Oct 01, 2024</td> Mar 05, 2026</td> Aug 08, 2027</td></tr>
6</td> Dec 01, 2024</td> Oct 26, 2026</td> Sep 20, 2028</td></tr>
4</td> Apr 02, 2025</td> Feb 07, 2028</td> Dec 15, 2030</td></tr>
</tbody></table>
Assuming that the earliest the next fork can happen is at the start of 2024 Q3, a value of 8 provides a significant reduction in projected size without causing a big drop in churn at a projected Dencun fork date. A value of 8 prevents reaching a level of 50% ETH staked for at least 1 full year even with a delayed dencun fork.</p>
Backwards Compatibility</h2>
This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.</p>
Test Cases</h2>
Test cases for this EIP can be found in the deneb</code></a> test suite of the consensus-specs</code> repository.</p>
Security Considerations</h2>
This EIP breaks the symmetry between the validator entry and exit queues, where the former is bound by MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT</code> while the latter isn't.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Physical Asset Redemption
2023-08-01T00:00:00+00:00
Abstract</h2>
This proposal is an extension of ERC-721</a> and implements additional functionality and information pertaining to the NFT’s underlying physical asset by capturing information that enables the holder of physical asset backed NFTs to verify authenticity and facilitate redemption of the underlying physical assets. This proposal is primarily aimed at providing transparency by disclosing details of involved parties and provides opportunity to define and make readily available relevant legal relationship between NFT holder and the owner/holder of the respective underlying physical asset. This proposal makes the token issuer accountable to embed accurate information on a set of standardized information about the underlying physical asset and the involved key parties.</p>
Motivation</h2>
The first wave of NFT use cases encompass predominately the representation of ownership of digital assets. In view of the anticipated trend to tokenize any real-world asset, it is to be expected that the use cases of NFTs will rapidly grow and expand around physical assets. The absence of an embedded standardized set of information pertaining to the underlying physical asset together with lack of transparency of involved key parties, creates an unnecessary hurdle for NFT holders and potential users which might, as a result, hinder mass adoption of NFTs that are used as ownership representation of a specific physical asset.</p>
Addressing the lack of readily available information and paving the way for mass adoption for a tokenized economy, this proposal requires that each minted token includes a defined number of predefined variables enabling verification of authenticity and facilitating redemption of the underlying physical asset.</p>
Specification</h2>
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p>
When a token is minted, its properties SHOULD be initialized beforehand, with each field being defined as follows:</p>


Token issuer</strong>: identification of an individual or entity minting the NFT

 The token issuer is the key person connecting the physical asset and the digital representation. By identifying and disclosing the token issuer, a reference point is made instantly available to the NFT holder which allows them to conduct a due diligence on the NFT issuer and assessment of the NFT issuer’s trustworthiness. At the same time, it creates accountability for the token issuer which leads to overall improvement and standardisation of the NFT minting process. Token issuers will compete for best practices and recognition to gain advantages over competitors. A reputable NFT issuer will e.g. keep information on the legal owner of the physical asset prior to the minting of the underlying physical asset to satisfy any AML and KYC concerns. Ideally the NFT issuer is identified by a name but may also be identifiable via unique identification number or network ID that is issued by a service provider who stores relevant information on the NFT issuer.</em></p>
</li>

Asset holder</strong>: identification of legal owner of underlying physical asset

 In view of a redemption of the underlying physical asset and enforcing of legal rights, it is (from a legal perspective) essential for the NFT holder to identify the legal owner of the underlying physical asset. It allows the NFT holder to consider the legal counterparty risk. It cannot be assumed that the NFT issuer is the legal owner of the underlying physical asset, therefore it is vital for the NFT holder to have instant access to this additional information. Same as with the NFT issuer’s identity, the legal owner is ideally identified by a name but may also be identifiable via unique identification number or network ID that is issued by a service provider who stores relevant information on the legal owner.</em></p>
</li>

Storage location</strong>: identification of storage location of underlying physical asset

 Certain physical assets require specific storage conditions. A digital representation of an inappropriately stored physical asset may impact the value of the NFT significantly. Disclosing the storage location and making it directly accessible to the NFT holder, allows them to evaluate the storage risk of the underlying physical asset. In addition, it provides the NFT holder with a second point of contact for the enforcement of the redemption of the underlying physical asset.</em></p>
</li>

Terms</strong>: identification of legal relationship

 The disclosure and accessibility of the legal basis of the relationship between NFT holder and legal owner of the underlying physical asset promotes token issuers to stipulate and define the legal rights of the involved key parties. It furthermore allows the NFT Holder to conduct a legal risk and enforcement assessment. Ideally, the information is provided by embedding a link to the actual legal documentation such as an agreement or terms. The more information is accessible via the NFT, the better the NFT holder can assess the legal risks associated with enforcement of the redemption of the underlying physical asset.</em></p>
</li>

Jurisdiction</strong>: governing law and jurisdiction

 The applicable law is an extension of the legal contract disclosure and makes instantly available to the NFT holder or smart contract under what jurisdiction an enforcement would be governed without the need to review the details legal contract. This allows for an instant assessment of jurisdiction risk.</em></p>
</li>

Declared value</strong>: value of the underlying asset

 Certain auxiliary services such as insurance are tied to a value of the NFT and underlying physical asset. By defining a declared value, NFTs are able to be categorised in certain ways while the declared value provides an indication regarding the underlying asset’s value. The declared value of the underlying physical asset does not necessarily represent the market value.</em></p>
</li>
</ul>
The terms</code> parameter SHOULD be an HTTP link to a document that is stored on IPFS. This is to ensure that the document is immutable and can be verified by the NFT holder.</p>
When a token with valid properties is to be burned, the properties MUST be removed.</p>
Contract Interface</h3>
pragma</span> solidity</span> ^0.8.21</span>;</span></span>
</span>
/**</span></span>
 * </span>@notice</span> Struct encapsulating fields required to by the ERC-7578 standard to represent the physical asset</span></span>
 * </span>@param</span> tokenIssuer</span> The network or entity minting the token</span></span>
 * </span>@param</span> assetHolder</span> The legal owner of the physical asset</span></span>
 * </span>@param</span> storageLocation</span> The physical location where the asset is stored</span></span>
 * </span>@param</span> terms</span> Link to IPFS contract, agreement or terms</span></span>
 * </span>@param</span> jurisdiction</span> The legal justification set out in the terms</span></span>
 * </span>@param</span> declaredValue</span> The declared value at time of token minting</span></span>
 */</span></span>
struct</span> Properties</span> {</span></span>
    string</span> tokenIssuer</span>;</span></span>
    string</span> assetHolder</span>;</span></span>
    string</span> storageLocation</span>;</span></span>
    string</span> terms</span>;</span></span>
    string</span> jurisdiction</span>;</span></span>
    Amount declaredValue</span>;</span></span>
}</span></span>
</span>
/**</span></span>
 * </span>@notice</span> Struct encapsulating fields describing the declared value of the physical asset</span></span>
 * </span>@param</span> currency</span> The currency of the amount</span></span>
 * </span>@param</span> value</span> The value of the amount</span></span>
 */</span></span>
struct</span> Amount</span> {</span></span>
    string</span> currency</span>;</span></span>
    uint256</span> value</span>;</span></span>
}</span></span>
</span>
/**</span></span>
 * </span>@notice</span> Required interface of an ERC-7578 compliant contract</span></span>
 */</span></span>
interface</span> IERC7578</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> Emitted when the properties of the `tokenId` token are set</span></span>
     * </span>@param</span> tokenId</span> The ID of the token</span></span>
     * </span>@param</span> properties</span> The properties of the token</span></span>
     */</span></span>
    event</span> PropertiesSet</span>(</span>uint256</span> indexed</span> tokenId</span>, </span>Properties</span> properties</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Emitted when the properties of the `tokenId` token are removed</span></span>
     * </span>@param</span> tokenId</span> The ID of the token</span></span>
     */</span></span>
    event</span> PropertiesRemoved</span>(</span>uint256</span> indexed</span> tokenId</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Retrieves all properties of the `tokenId` token</span></span>
     * </span>@dev</span> Does NOT revert if token doesn't exist</span></span>
     * </span>@param</span> tokenId</span> The token ID of the minted token</span></span>
     */</span></span>
    function</span> getPropertiesOf</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>Properties</span> memory</span> properties</span>)</span>;</span></span>
}</span></span></code></pre>
When properties</code> are set, the PropertiesSet(uint256 indexed tokenId, Properties properties)</code> event is emitted.</p>
When properties</code> are removed, the PropertiesRemoved(uint256 indexed tokenId)</code> event is emitted.</p>
The getPropertiesOf(uint256 tokenId)</code> function MUST return the unique properties</code> of a token. If the ERC-721 token is burned or has no properties set, it SHOULD return an empty Properties</code> struct.</p>
Rationale</h2>
By not initializing a token's properties before minting, one risks that the asset's provenance represented by the token cannot be established.</p>
Contract level validation is not used on the properties as we believe the accuracy of the data declared is the responsibility of the token issuer. This builds trust on the token issuer and the token itself.</p>
Backwards Compatibility</h2>
This standard is compatible with ERC-721.</p>
Reference Implementation</h2>
An example of an ERC-721</a> that includes this proposal using the OpenZeppelin ERC-721 v5 library:</p>
pragma</span> solidity</span> ^0.8.21</span>;</span></span>
</span>
import</span> { </span>ERC721</span> }</span> from</span> "@openzeppelin/contracts/token/ERC721/ERC721.sol"</span>;</span></span>
import</span> { </span>IERC7578</span>, </span>Properties</span>, </span>Amount</span> }</span> from</span> "./interfaces/IERC7578.sol"</span>;</span></span>
</span>
/**</span></span>
 * </span>@title</span> ERC7578</span></span>
 * </span>@author</span> DESAT</span></span>
 * </span>@notice</span> Implementation of the ERC-7578: Physical Asset Redemption standard</span></span>
 *</span>*/</span></span>
contract</span> ERC7578</span> is</span> ERC721</span>, </span>IERC7578</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> Thrown when the properties of a token are not initialized</span></span>
     */</span></span>
    error</span> PropertiesUninitialized</span>(</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Retrieves the properties of the `tokenId` token</span></span>
     */</span></span>
    mapping</span>(</span>uint256</span> tokenId </span>=></span> Properties</span>)</span> private</span> _properties</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Initializes the name and symbol of the ERC-721 collection</span></span>
     */</span></span>
    constructor</span>(</span>string</span> memory</span> _name</span>,</span> string</span> memory</span> _symbol</span>)</span> ERC721</span>(</span>_name, _symbol) </span>{</span>}</span></span>
</span>
    /**</span></span>
     * </span>@inheritdoc</span> IERC7578</span></span>
     */</span></span>
    function</span> getPropertiesOf</span>(</span>uint256</span> tokenId</span>)</span> public</span> view</span> override</span> returns</span> (</span>Properties</span> memory</span> properties</span>)</span> {</span></span>
        properties </span>=</span> _properties</span>[</span>tokenId</span>]</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Initializes the ERC-7578 properties of the `tokenId` token</span></span>
     *</span></span>
     * WARNING: This method should only be called within a function that has appropriate access control</span></span>
     * It is recommended to restrict access to trusted Externally Owned Accounts (EOAs),</span></span>
     * authorized contracts, or implement a Role-Based Access Control (RBAC) mechanism</span></span>
     * Failure to properly secure this method could lead to unauthorized modification of token properties</span></span>
     *</span></span>
     * Emits a {PropertiesSet} event</span></span>
     */</span></span>
    function</span> _setPropertiesOf</span>(</span>uint256</span> tokenId</span>,</span> Properties</span> calldata</span> properties</span>)</span> internal</span> {</span></span>
        _properties</span>[</span>tokenId</span>]</span> =</span> Properties</span>(</span>{</span></span>
            tokenIssuer</span>:</span> properties</span>.</span>tokenIssuer</span>,</span></span>
            assetHolder</span>:</span> properties</span>.</span>assetHolder</span>,</span></span>
            storageLocation</span>:</span> properties</span>.</span>storageLocation</span>,</span></span>
            terms</span>:</span> properties</span>.</span>terms</span>,</span></span>
            jurisdiction</span>:</span> properties</span>.</span>jurisdiction</span>,</span></span>
            declaredValue</span>:</span> Amount</span>(</span>{</span></span>
                currency</span>:</span> properties</span>.</span>declaredValue</span>.</span>currency</span>,</span></span>
                value</span>:</span> properties</span>.</span>declaredValue</span>.</span>value</span></span>
            }</span>)</span></span>
        }</span>)</span>;</span></span>
</span>
        emit</span> PropertiesSet</span>(</span>tokenId</span>,</span> _properties</span>[</span>tokenId</span>]</span>)</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Removes the properties of the `tokenId` token</span></span>
     * </span>@param</span> tokenId</span> The unique identifier of the token whose properties are to be removed</span></span>
     *</span></span>
     * Emits a {PropertiesRemoved} event</span></span>
     */</span></span>
    function</span> _removePropertiesOf</span>(</span>uint256</span> tokenId</span>)</span> internal</span> {</span></span>
        delete</span> _properties</span>[</span>tokenId</span>]</span>;</span></span>
        emit</span> PropertiesRemoved</span>(</span>tokenId</span>)</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Override of the {_update} function to remove the properties of the `tokenId` token or</span></span>
     * to check if they are set before minting</span></span>
     * </span>@param</span> tokenId</span> The unique identifier of the token being minted or burned</span></span>
     */</span></span>
    function</span> _update</span>(</span>address</span> to</span>,</span> uint256</span> tokenId</span>,</span> address</span> auth</span>)</span> internal</span> virtual</span> override</span> returns</span> (</span>address</span>)</span> {</span></span>
        address</span> from </span>=</span> _ownerOf</span>(</span>tokenId</span>)</span>;</span></span>
        if</span> (</span>to </span>==</span> address</span>(</span>0</span>)</span>)</span> {</span></span>
            _removePropertiesOf</span>(</span>tokenId</span>)</span>;</span></span>
        }</span> else</span> if</span> (</span>from </span>==</span> address</span>(</span>0</span>)</span>)</span> {</span></span>
            if</span> (</span>bytes</span>(</span>_properties</span>[</span>tokenId</span>]</span>.</span>tokenIssuer</span>)</span>.</span>length </span>==</span> 0</span>)</span> revert</span> PropertiesUninitialized</span>(</span>)</span>;</span></span>
        }</span></span>
</span>
        return</span> super</span>.</span>_update</span>(</span>to</span>,</span> tokenId</span>,</span> auth</span>)</span>;</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>
To ensure authenticity, token properties must be set only via a method that is restricted to a trusted Externally Owned Account (EOA) or contract. This trusted entity must verify that the properties accurately reflect the real physical attributes of the represented asset. Additionally, proper access control mechanisms should be implemented to prevent unauthorized modifications of token properties after they are set.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Prevent ticket touting
2023-07-28T00:00:00+00:00
Abstract</h2>
This standard is an extension of  ERC-721</a> and defines standard functions outlining a scope for ticketing agents or event organizers to take preventative actions to stop audiences being exploited in the ticket scalping market and allow customers to resell their tickets via authorized ticket resellers.</p>
Motivation</h2>
Industrial-scale ticket touting has been a longstanding issue, with its associated fraud and criminal problems leading to unfortunate incidents and waste of social resources. It is also hugely damaging to artists at all levels of their careers and to related businesses across the board. Although the governments of various countries have begun to legislate to restrict the behavior of scalpers, the effect is limited. They still sold tickets for events at which resale was banned or did not yet own then obtained substantial illegal profits from speculative selling. We consulted many opinions to provide a consumer-friendly resale interface, enabling buyers to resell or reallocate a ticket at the price they initially paid or less is the efficient way to rip off “secondary ticketing”.that enables ticketing agents to utilize</p>
The typical ticket may be a "piece of paper" or even a voucher in your email inbox, making it easy to counterfeit or circulate. To restrict the transferability of these tickets, we have designed a mechanism that prohibits ticket transfers for all parties, including the ticket owner, except for specific accounts that are authorized to transfer tickets. The specific accounts may be ticketing agents, managers, promoters and authorized resale platforms. Therefore, the ticket touts are unable to transfer tickets as they wish. Furthermore, to enhance functionality, we have implemented a token info schema to each ticket,  allowing only authorized accounts(excluding the owner) to modify these records.</p>
This standard defines a framework that enables ticketing agents to utilize ERC-721</a> tokens as event tickets and restricts token transferability to prevent ticket touting. By implementing this standard, we aim to protect customers from scams and fraudulent activities.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Interface</h3>
The interface and structure referenced here are as follows:</p>

TokenInfo

signature</code>: Recommend that the adapter self-defines what to sign using the user's private key or agent's private key to prove the token validity.</li>
status</code>: Represent token current status.</li>
expireTime</code>: Recommend set to the event due time.</li>
</ul>
</li>
TokenStatus

Sold</code>: When a token is sold, it MUST change to Sold</code>. The token is valid in this status.</li>
Resell</code>: When a token is in the secondary market, it MUST be changed to Resell. The token is valid in this status.</li>
Void</code>: When the token owner engages in an illegal transaction, the token status MUST be set to Void, and the token is invalid in this status.</li>
Redeemed</code>:  When the token is used, it is RECOMMENDED to change the token status to Redeemed</code>.</li>
</ul>
</li>
</ul>
///</span> @title</span> IERC7439 Prevent Ticket Touting Interface</span></span>
interface</span> IERC7439</span> /*</span> is ERC721 </span>*/</span> {</span></span>
    ///</span> @dev</span> TokenStatus represent the token current status, only specific role can change status</span></span>
    enum</span> TokenStatus</span> {</span></span>
        Sold</span>,</span>    //</span> 0</span></span>
        Resell</span>,</span>  //</span> 1</span></span>
        Void</span>,</span>    //</span> 2</span></span>
        Redeemed</span> //</span> 3</span></span>
    }</span></span>
</span>
    ///</span> @param</span> signature</span> Data signed by user's private key or agent's private key</span></span>
    ///</span> @param</span> tokenStatus</span> Token status changing to</span></span>
    ///</span> @param</span> expireTime</span> Event due time</span></span>
    struct</span> TokenInfo</span> {</span></span>
        bytes</span> signature</span>;</span></span>
        TokenStatus tokenStatus</span>;</span></span>
        uint256</span> expireTime</span>;</span></span>
    }</span></span>
</span>
    ///</span> @notice</span> Used to notify listeners that the token with the specified ID has been </span>changed</span> status</span></span>
    ///</span> @param</span> tokenId</span> The token has been </span>changed</span> status</span></span>
    ///</span> @param</span> tokenStatus</span> Token status has been </span>changed</span> to</span></span>
    ///</span> @param</span> signature</span> Data signed by user's private key or agent's private key</span></span>
    event</span> TokenStatusChanged</span>(</span></span>
        uint256</span> indexed</span> tokenId</span>,</span></span>
        TokenStatus</span> indexed</span> tokenStatus</span>,</span></span>
        bytes</span> signature</span></span>
    )</span>;</span></span>
</span>
    ///</span> @notice</span> Used to mint token with token status</span></span>
    ///</span> @dev</span> MUST emit the `TokenStatusChanged` event if the token status is </span>changed</span>.</span></span>
    ///</span> @param</span> to</span> The receiptent of token</span></span>
    ///</span> @param</span> signature</span> Data signed by user's private key or agent's private key</span></span>
    function</span> safeMint</span>(</span>address</span> to</span>,</span> bytes</span> memory</span> signature</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Used to change token status and can only be invoked by a specific role</span></span>
    ///</span> @dev</span> MUST emit the `TokenStatusChanged` event if the token status is </span>changed</span>.</span></span>
    ///</span> @param</span> tokenId</span> The token need to change status</span></span>
    ///</span> @param</span> signature</span> Data signed by user's private key or agent's private key</span></span>
    ///</span> @param</span> tokenStatus</span> Token status changing to</span></span>
    ///</span> @param</span> newExpireTime</span> New event due time</span></span>
    function</span> changeState</span>(</span></span>
        uint256</span> tokenId</span>,</span></span>
        bytes</span> memory</span> signature</span>,</span></span>
        TokenStatus</span> tokenStatus</span>,</span></span>
        uint256</span> newExpireTime</span></span>
    )</span> external</span>;</span></span>
}</span></span></code></pre>
The supportsInterface</code> method MUST return true</code> when called with 0x15fbb306</code>.</p>
Rationale</h2>
Designing the proposal, we considered the following questions:</p>


What is the most crucial for ticketing agents, performers, and audiences?</p>


For ticketing companies, selling out all tickets is crucial. Sometimes, to create a vibrant sales environment, ticketing companies may even collaborate with scalpers. This practice can be detrimental to both the audience and performers. To prevent such situations, there must be an open and transparent primary sales channel, as well as a fair secondary sales mechanism. In the safeMint</code> function, which is a public function, we hope that everyone can mint tickets transparently at a listed price by themselves. At that time, TokenInfo</code> adds a signature that only the buyer account or agent can resolve depending on the mechanism, to prove the ticket validity. And the token status</code> is Sold</code>. Despite this, we must also consider the pressures on ticketing companies. They aim to maximize the utility of every valid ticket, meaning selling out each one. In the traditional mechanism, ticketing companies only benefit from the initial sale, implying that they do not enjoy the excess profits from secondary sales. Therefore, we have designed a secondary sales process that is manageable for ticketing companies. In the _beforeTokenTransfer()</code> function, you can see that it is an accessControl function, and only the PARTNER_ROLE</code> mint</code> or burn</code> situation can transfer the ticket. The PARTNER_ROLE</code> can be the ticket agency or a legal secondary ticket selling platform, which may be a state supervision or the ticket agency designated platform. To sustain the fair ticketing market, we cannot allow them to transfer tickets themselves, because we can’t distinguish whether the buyer is a scalper.</p>
</li>

For performers or event holder, they aren't willing to see bad news during ticket selling. A smooth ticketing process or no news that may damage their performers’ reputation is what they want. Other than that, what really matters is all the audience true fans who come. Tickets ending up in the hands of scalpers or entering a chaotic secondary market doesn't really appeal to genuine fans. We believe performers wouldn't be pleased with such a situation. Through the transparant mechanism, performers or event holder can control the real sales status at all times form cross-comparison of token mint amount and TokenInfo</code>-TokenStatus</code>.</p>
enum TokenStatus {</span></span>
    Sold,    // 0</span></span>
    Resell,  // 1</span></span>
    Void,    // 2</span></span>
    Redeemed // 3</span></span>
}</span></span></code></pre></li>

For audiences, the only thing they need is to get a valid ticket. In the traditional mechanism,fans encounter many obstacles. At hot concerts, fans who try to snag tickets can run into some foes, like scalpers and ticketing companies. These scalpers are like pros, all organized and strategic in grabbing up tickets. Surprisingly, ticketing companies might actually team up with these scalpers. Or, they might just keep a bunch of freebies or VIP tickets to themselves. A transparent mechanism is equally important for the audiences.</p>
</li>
</ul>
</li>

How to establish a healthy ticketing ecosystem?</p>


Clear ticketing rules are key to making sure the supply and demand stay in balance.</p>
</li>

An open pricing system is a must to make sure consumers are protected.</p>
</li>

Excellent liquidity. In the initial market, users can mint tickets themselves. If needed, purchased tickets can also be transferred in a transparent and open secondary market. Audiences who didn’t buy tickets during the initial sale can also confidently purchase tickets in a legal secondary market. The changeState</code> function is to help the ticket have good liquidity. Only PARTNER_ROLE</code> can change the ticket status. Once the sold ticket needs to be sold in the secondary market, it needs to ask the secondary market to help it change to resell status. The process of changing status is a kind of official verification of the secondary sale ticket. It is a protection mechanism to the second hand buyer.</p>
</li>
</ul>
</li>

How to design a smooth ticketing process？</p>


Easy to buy/sell. Audiences can buy ticket as mint NFT. This is a well-known practice.</p>
</li>

Easy to refund. When something extreme happens and you need to cancel the show. Handling ticket refunds can be a straightforward process.</p>
</li>

Easy to redeem. Before the show, the ticket agency can verify the ticket by the signature to confirm if the audience is genuine. TokenStatus</code> needs to be equal to sold</code>, and expireTime</code> can distinguish whether the audience has arrived at the correct session. After verification is passed, the ticket agency can change the TokenStatus</code> to Redeemed</code>.</p>
</li>

Normal Flow
</p>
</li>

Void Flow
</p>
</li>

Resell Flow
</p>
</li>
</ul>
</li>
</ol>
Backwards Compatibility</h2>
This standard is compatible with ERC-721</a>.</p>
Test Cases</h2>
const</span> {</span> expectRevert</span> }</span> =</span> require</span>(</span>"</span>@openzeppelin/test-helpers</span>"</span>)</span>;</span></span>
const</span> {</span> expect</span> }</span> =</span> require</span>(</span>"</span>chai</span>"</span>)</span>;</span></span>
const</span> ERC7439</span> =</span> artifacts</span>.</span>require</span>(</span>"</span>ERC7439</span>"</span>)</span>;</span></span>
</span>
contract</span>(</span>"</span>ERC7439</span>"</span>,</span> (</span>accounts</span>)</span> =></span> {</span></span>
  const</span> [</span>deployer</span>,</span> partner</span>,</span> userA</span>,</span> userB</span>]</span> =</span> accounts</span>;</span></span>
  const</span> expireTime</span> =</span> 19999999</span>;</span></span>
  const</span> tokenId</span> =</span> 0</span>;</span></span>
  const</span> signature</span> =</span> "</span>0x993dab3dd91f5c6dc28e17439be475478f5635c92a56e17e82349d3fb2f166196f466c0b4e0c146f285204f0dcb13e5ae67bc33f4b888ec32dfe0a063e8f3f781b</span>"</span></span>
  const</span> zeroHash</span> =</span> "</span>0x</span>"</span>;</span></span>
</span>
  beforeEach</span>(</span>async</span> (</span>)</span> =></span> {</span></span>
    this</span>.</span>erc7439</span> =</span> await</span> ERC7439</span>.</span>new</span>(</span>{</span></span>
      from</span>:</span> deployer</span>,</span></span>
    }</span>)</span>;</span></span>
    await</span> this</span>.</span>erc7439</span>.</span>mint</span>(</span>userA</span>,</span> signature</span>,</span> {</span> from</span>:</span> deployer</span> }</span>)</span>;</span></span>
  }</span>)</span>;</span></span>
</span>
  it</span>(</span>"</span>Should mint a token</span>"</span>,</span> async</span> (</span>)</span> =></span> {</span></span>
    const</span> tokenInfo</span> =</span> await</span> this</span>.</span>erc7439</span>.</span>tokenInfo</span>(</span>tokenId</span>)</span>;</span></span>
</span>
    expect</span>(</span>await</span> this</span>.</span>erc7439</span>.</span>ownerOf</span>(</span>tokenId</span>)</span>)</span>.</span>to</span>.</span>equal</span>(</span>userA</span>)</span>;</span></span>
    expect</span>(</span>tokenInfo</span>.</span>signature</span>)</span>.</span>equal</span>(</span>signature</span>)</span>;</span></span>
    expect</span>(</span>tokenInfo</span>.</span>status</span>)</span>.</span>equal</span>(</span>"</span>0</span>"</span>)</span>;</span> //</span> Sold</span></span>
    expect</span>(</span>tokenInfo</span>.</span>expireTime</span>)</span>.</span>equal</span>(</span>expireTime</span>)</span>;</span></span>
  }</span>)</span>;</span></span>
</span>
  it</span>(</span>"</span>should ordinary users cannot transfer successfully</span>"</span>,</span> async</span> (</span>)</span> =></span> {</span></span>
    expectRevert</span>(</span>await</span> this</span>.</span>erc7439</span>.</span>transferFrom</span>(</span>userA</span>,</span> userB</span>,</span> tokenId</span>,</span> {</span> from</span>:</span> userA</span> }</span>)</span>,</span> "</span>ERC7439: You cannot transfer this NFT!</span>"</span>)</span>;</span></span>
  }</span>)</span>;</span></span>
</span>
  it</span>(</span>"</span>should partner can transfer successfully and chage the token info to resell status</span>"</span>,</span> async</span> (</span>)</span> =></span> {</span></span>
    const</span> tokenStatus</span> =</span> 1</span>;</span> //</span> Resell</span></span>
</span>
    await</span> this</span>.</span>erc7439</span>.</span>changeState</span>(</span>tokenId</span>,</span> zeroHash</span>,</span> tokenStatus</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
    await</span> this</span>.</span>erc7439</span>.</span>transferFrom</span>(</span>userA</span>,</span> partner</span>,</span> tokenId</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
</span>
    expect</span>(</span>tokenInfo</span>.</span>tokenHash</span>)</span>.</span>equal</span>(</span>zeroHash</span>)</span>;</span></span>
    expect</span>(</span>tokenInfo</span>.</span>status</span>)</span>.</span>equal</span>(</span>tokenStatus</span>)</span>;</span> //</span> Resell</span></span>
    expect</span>(</span>await</span> this</span>.</span>erc7439</span>.</span>ownerOf</span>(</span>tokenId</span>)</span>)</span>.</span>to</span>.</span>equal</span>(</span>partner</span>)</span>;</span></span>
  }</span>)</span>;</span></span>
</span>
  it</span>(</span>"</span>should partner can change the token status to void</span>"</span>,</span> async</span> (</span>)</span> =></span> {</span></span>
    const</span> tokenStatus</span> =</span> 2</span>;</span> //</span> Void</span></span>
</span>
    await</span> this</span>.</span>erc7439</span>.</span>changeState</span>(</span>tokenId</span>,</span> zeroHash</span>,</span> tokenStatus</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
</span>
    expect</span>(</span>tokenInfo</span>.</span>tokenHash</span>)</span>.</span>equal</span>(</span>zeroHash</span>)</span>;</span></span>
    expect</span>(</span>tokenInfo</span>.</span>status</span>)</span>.</span>equal</span>(</span>tokenStatus</span>)</span>;</span> //</span> Void</span></span>
  }</span>)</span>;</span></span>
</span>
  it</span>(</span>"</span>should partner can change the token status to redeemed</span>"</span>,</span> async</span> (</span>)</span> =></span> {</span></span>
    const</span> tokenStatus</span> =</span> 3</span>;</span> //</span> Redeemed</span></span>
</span>
    await</span> this</span>.</span>erc7439</span>.</span>changeState</span>(</span>tokenId</span>,</span> zeroHash</span>,</span> tokenStatus</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
</span>
    expect</span>(</span>tokenInfo</span>.</span>tokenHash</span>)</span>.</span>equal</span>(</span>zeroHash</span>)</span>;</span></span>
    expect</span>(</span>tokenInfo</span>.</span>status</span>)</span>.</span>equal</span>(</span>tokenStatus</span>)</span>;</span> //</span> Redeemed</span></span>
  }</span>)</span>;</span></span>
</span>
  it</span>(</span>"</span>should partner can resell the token and change status from resell to sold</span>"</span>,</span> async</span> (</span>)</span> =></span> {</span>    </span></span>
    let</span> tokenStatus</span> =</span> 1</span>;</span> //</span> Resell</span></span>
    await</span> this</span>.</span>erc7439</span>.</span>changeState</span>(</span>tokenId</span>,</span> zeroHash</span>,</span> tokenStatus</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
    await</span> this</span>.</span>erc7439</span>.</span>transferFrom</span>(</span>userA</span>,</span> partner</span>,</span> tokenId</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
    </span></span>
    expect</span>(</span>tokenInfo</span>.</span>status</span>)</span>.</span>equal</span>(</span>tokenStatus</span>)</span>;</span> //</span> Resell</span></span>
    expect</span>(</span>tokenInfo</span>.</span>tokenHash</span>)</span>.</span>equal</span>(</span>zeroHash</span>)</span>;</span></span>
</span>
    tokenStatus</span> =</span> 0</span>;</span> //</span> Sold</span></span>
    const</span> newSignature</span> =</span> "</span>0x113hqb3ff45f5c6ec28e17439be475478f5635c92a56e17e82349d3fb2f166196f466c0b4e0c146f285204f0dcb13e5ae67bc33f4b888ec32dfe0a063w7h2f742f</span>"</span>;</span></span>
    await</span> this</span>.</span>erc7439</span>.</span>changeState</span>(</span>tokenId</span>,</span> newSignature</span>,</span> tokenStatus</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
    await</span> this</span>.</span>erc7439</span>.</span>transferFrom</span>(</span>partner</span>,</span> userB</span>,</span> tokenId</span>,</span> {</span> from</span>:</span> partner</span> }</span>)</span>;</span></span>
</span>
    expect</span>(</span>tokenInfo</span>.</span>status</span>)</span>.</span>equal</span>(</span>tokenStatus</span>)</span>;</span> //</span> Sold</span></span>
    expect</span>(</span>tokenInfo</span>.</span>tokenHash</span>)</span>.</span>equal</span>(</span>newSignature</span>)</span>;</span></span>
  }</span>)</span>;</span></span>
}</span>)</span>;</span></span></code></pre>Reference Implementation</h2>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> 0.8.19</span>;</span></span>
</span>
import</span> "@openzeppelin/contracts/token/ERC721/ERC721.sol"</span>;</span></span>
//</span> If you need additional metadata, you can import ERC721URIStorage</span></span>
//</span> import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";</span></span>
import</span> "@openzeppelin/contracts/access/AccessControl.sol"</span>;</span></span>
import</span> "@openzeppelin/contracts/utils/Counters.sol"</span>;</span></span>
import</span> "./IERC7439.sol"</span>;</span></span>
</span>
contract</span> ERC7439</span> is</span> ERC721</span>, </span>AccessControl</span>, </span>IERC7439</span> {</span></span>
    using</span> Counters</span> for</span> Counters</span>.</span>Counter</span>;</span></span>
</span>
    bytes32</span> public</span> constant</span> PARTNER_ROLE </span>=</span> keccak256</span>(</span>"PARTNER_ROLE"</span>)</span>;</span></span>
    Counters</span>.</span>Counter </span>private</span> _tokenIdCounter</span>;</span></span>
</span>
    uint256</span> public</span> expireTime</span>;</span></span>
</span>
    mapping</span>(</span>uint256</span> =></span> TokenInfo</span>)</span> public</span> tokenInfo</span>;</span></span>
</span>
    constructor</span>(</span>uint256</span> _expireTime</span>)</span> ERC721</span>(</span>"MyToken", "MTK") </span>{</span></span>
        _grantRole</span>(</span>DEFAULT_ADMIN_ROLE</span>,</span> msg.sender</span>)</span>;</span></span>
        _grantRole</span>(</span>PARTNER_ROLE</span>,</span> msg.sender</span>)</span>;</span></span>
        expireTime </span>=</span> _expireTime</span>;</span></span>
    }</span></span>
</span>
    function</span> safeMint</span>(</span>address</span> to</span>,</span> bytes</span> memory</span> signature</span>)</span> public</span> {</span></span>
        uint256</span> tokenId </span>=</span> _tokenIdCounter</span>.</span>current</span>(</span>)</span>;</span></span>
        _tokenIdCounter</span>.</span>increment</span>(</span>)</span>;</span></span>
        _safeMint</span>(</span>to</span>,</span> tokenId</span>)</span>;</span></span>
        tokenInfo</span>[</span>tokenId</span>]</span> =</span> TokenInfo</span>(</span>signature</span>,</span> TokenStatus</span>.</span>Sold</span>,</span> expireTime</span>)</span>;</span></span>
        emit</span> TokenStatusChanged</span>(</span>tokenId</span>,</span> TokenStatus</span>.</span>Sold</span>,</span> signature</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> changeState</span>(</span></span>
        uint256</span> tokenId</span>,</span></span>
        bytes</span> memory</span> signature</span>,</span></span>
        TokenStatus</span> tokenStatus</span>,</span></span>
        uint256</span> newExpireTime</span></span>
    )</span> public</span> onlyRole</span>(</span>PARTNER_ROLE</span>)</span> {</span></span>
        tokenInfo</span>[</span>tokenId</span>]</span> =</span> TokenInfo</span>(</span>signature</span>,</span> tokenStatus</span>,</span> newExpireTime</span>)</span>;</span></span>
        emit</span> TokenStatusChanged</span>(</span>tokenId</span>,</span> tokenStatus</span>,</span> signature</span>)</span>;</span></span>
    }</span></span>
    </span></span>
    function</span> _burn</span>(</span>uint256</span> tokenId</span>)</span> internal</span> virtual</span> override</span>(</span>ERC721</span>)</span> {</span></span>
        super</span>.</span>_burn</span>(</span>tokenId</span>)</span>;</span></span>
</span>
        if</span> (</span>_exists</span>(</span>tokenId</span>)</span>)</span> {</span></span>
            delete</span> tokenInfo</span>[</span>tokenId</span>]</span>;</span></span>
            //</span> If you import ERC721URIStorage</span></span>
            //</span> delete _tokenURIs[tokenId];</span></span>
        }</span></span>
    }</span></span>
</span>
    function</span> supportsInterface</span>(</span></span>
        bytes4</span> interfaceId</span></span>
    )</span> public</span> view</span> virtual</span> override</span>(</span>AccessControl</span>,</span> ERC721</span>)</span> returns</span> (</span>bool</span>)</span> {</span></span>
        return</span></span>
            interfaceId </span>==</span> type</span>(</span>IERC7439</span>)</span>.</span>interfaceId </span>||</span></span>
            super</span>.</span>supportsInterface</span>(</span>interfaceId</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> _beforeTokenTransfer</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span></span>
    )</span> internal</span> virtual</span> override</span>(</span>ERC721</span>)</span> {</span></span>
        if</span> (</span>!</span>hasRole</span>(</span>PARTNER_ROLE</span>,</span> _msgSender</span>(</span>)</span>)</span>)</span> {</span></span>
            require</span>(</span></span>
                from </span>==</span> address</span>(</span>0</span>)</span> ||</span> to </span>==</span> address</span>(</span>0</span>)</span>,</span></span>
                "ERC7439: You cannot transfer this NFT!"</span></span>
            )</span>;</span></span>
        }</span></span>
</span>
        super</span>.</span>_beforeTokenTransfer</span>(</span>from</span>,</span> to</span>,</span> tokenId</span>)</span>;</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>
There are no security considerations related directly to the implementation of this standard.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Parent-Governed Non-Fungible Tokens Nesting
2023-07-26T00:00:00+00:00
Abstract</h2>
❗️ ERC-7401</a> supersedes ERC-6059</a>.</strong> ❗️</p>
The Parent-Governed NFT Nesting standard extends ERC-721</a> by allowing for a new inter-NFT relationship and interaction.</p>
At its core, the idea behind the proposal is simple: the owner of an NFT does not have to be an Externally Owned Account (EOA) or a smart contract, it can also be an NFT.</p>
The process of nesting an NFT into another is functionally identical to sending it to another user. The process of sending a token out of another one involves issuing a transaction from the account owning the parent token.</p>
An NFT can be owned by a single other NFT, but can in turn have a number of NFTs that it owns. This proposal establishes the framework for the parent-child relationships of NFTs. A parent token is the one that owns another token. A child token is a token that is owned by another token. A token can be both a parent and child at the same time. Child tokens of a given token can be fully managed by the parent token's owner, but can be proposed by anyone.</p>
</p>
The graph illustrates how a child token can also be a parent token, but both are still administered by the root parent token's owner.</p>
Motivation</h2>
With NFTs being a widespread form of tokens in the Ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. Having the ability for tokens to own other tokens allows for greater utility, usability and forward compatibility.</p>
In the four years since ERC-721</a> was published, the need for additional functionality has resulted in countless extensions. This ERC improves upon ERC-721 in the following areas:</p>

Bundling</a></li>
Collecting</a></li>
Membership</a></li>
Delegation</a></li>
</ul>
This proposal fixes the inconsistency in the ERC-6059</a> interface specification, where interface ID doesn't match the interface specified as the interface evolved during the proposal's lifecycle, but one of the parameters was not added to it. The missing parameter is, however, present in the interface ID. Apart from this fix, this proposal is functionally equivalent to ERC-6059</a>.</p>
Bundling</h3>
One of the most frequent uses of ERC-721</a> is to disseminate the multimedia content that is tied to the tokens. In the event that someone wants to offer a bundle of NFTs from various collections, there is currently no easy way of bundling all of these together and handle their sale as a single transaction. This proposal introduces a standardized way of doing so. Nesting all of the tokens into a simple bundle and selling that bundle would transfer the control of all of the tokens to the buyer in a single transaction.</p>
Collecting</h3>
A lot of NFT consumers collect them based on countless criteria. Some aim for utility of the tokens, some for the uniqueness, some for the visual appeal, etc. There is no standardized way to group the NFTs tied to a specific account. By nesting NFTs based on their owner's preference, this proposal introduces the ability to do it. The root parent token could represent a certain group of tokens and all of the children nested into it would belong to it.</p>
The rise of soulbound, non-transferable, tokens, introduces another need for this proposal. Having a token with multiple soulbound traits (child tokens), allows for numerous use cases. One concrete example of this can be drawn from supply chains use case. A shipping container, represented by an NFT with its own traits, could have multiple child tokens denoting each leg of its journey.</p>
Membership</h3>
A common utility attached to NFTs is a membership to a Decentralised Autonomous Organization (DAO) or to some other closed-access group. Some of these organizations and groups occasionally mint NFTs to the current holders of the membership NFTs. With the ability to nest mint a token into a token, such minting could be simplified, by simply minting the bonus NFT directly into the membership one.</p>
Delegation</h3>
One of the core features of DAOs is voting and there are various approaches to it. One such mechanic is using fungible voting tokens where members can delegate their votes by sending these tokens to another member. Using this proposal, delegated voting could be handled by nesting your voting NFT into the one you are delegating your votes to and transferring it when the member no longer wishes to delegate their votes.</p>
Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p>
///</span> @title</span> EIP-7401 Parent-Governed Nestable Non-Fungible Tokens</span></span>
///</span> @dev</span> See https://eips.ethereum.org/EIPS/eip-7401</span></span>
///</span> @dev</span> Note</span>: the ERC-165 identifier for this interface is 0x42b0e56f.</span></span>
</span>
pragma</span> solidity</span> ^0.8.16</span>;</span></span>
</span>
interface</span> IERC7059</span> /*</span> is ERC165 </span>*/</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> The core struct of ownership.</span></span>
     * </span>@dev</span> The `DirectOwner` struct is used to store information of the next immediate owner, be it the parent token,</span></span>
     * an `ERC721Receiver` contract or an externally owned account.</span></span>
     * </span>@dev</span> If the token is not owned by an NFT, the `tokenId` MUST equal `0`.</span></span>
     * </span>@param</span> tokenId</span> ID of the parent token</span></span>
     * </span>@param</span> ownerAddress</span> Address of the owner of the token. If the owner is another token, then the address MUST be</span></span>
     *  the one of the parent token's collection smart contract. If the owner is externally owned account, the address</span></span>
     *  MUST be the address of this account</span></span>
     */</span></span>
    struct</span> DirectOwner</span> {</span></span>
        uint256</span> tokenId</span>;</span></span>
        address</span> ownerAddress</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> The core child token struct, holding the information about the child tokens.</span></span>
     * </span>@return</span> tokenId</span> ID of the child token in the child token's collection smart contract</span></span>
     * </span>@return</span> contractAddress</span> Address of the child token's smart contract</span></span>
     */</span></span>
    struct</span> Child</span> {</span></span>
        uint256</span> tokenId</span>;</span></span>
        address</span> contractAddress</span>;</span></span>
    }</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to notify listeners that the token is being transferred.</span></span>
     * </span>@dev</span> Emitted when `tokenId` token is transferred from `from` to `to`.</span></span>
     * </span>@param</span> from</span> Address of the previous immediate owner, which is a smart contract if the token was nested.</span></span>
     * </span>@param</span> to</span> Address of the new immediate owner, which is a smart contract if the token is being nested.</span></span>
     * </span>@param</span> fromTokenId</span> ID of the previous parent token. If the token was not nested before, the value MUST be `0`</span></span>
     * </span>@param</span> toTokenId</span> ID of the new parent token. If the token is not being nested, the value MUST be `0`</span></span>
     * </span>@param</span> tokenId</span> ID of the token being transferred</span></span>
     */</span></span>
    event</span> NestTransfer</span>(</span></span>
        address</span> indexed</span> from</span>,</span></span>
        address</span> indexed</span> to</span>,</span></span>
        uint256</span> fromTokenId</span>,</span></span>
        uint256</span> toTokenId</span>,</span></span>
        uint256</span> indexed</span> tokenId</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to notify listeners that a new token has been added to a given token's pending children array.</span></span>
     * </span>@dev</span> Emitted when a child NFT is added to a token's pending array.</span></span>
     * </span>@param</span> tokenId</span> ID of the token that received a new pending child token</span></span>
     * </span>@param</span> childIndex</span> Index of the proposed child token in the parent token's pending children array</span></span>
     * </span>@param</span> childAddress</span> Address of the proposed child token's collection smart contract</span></span>
     * </span>@param</span> childId</span> ID of the child token in the child token's collection smart contract</span></span>
     */</span></span>
    event</span> ChildProposed</span>(</span></span>
        uint256</span> indexed</span> tokenId</span>,</span></span>
        uint256</span> childIndex</span>,</span></span>
        address</span> indexed</span> childAddress</span>,</span></span>
        uint256</span> indexed</span> childId</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to notify listeners that a new child token was accepted by the parent token.</span></span>
     * </span>@dev</span> Emitted when a parent token accepts a token from its pending array, migrating it to the active array.</span></span>
     * </span>@param</span> tokenId</span> ID of the token that accepted a new child token</span></span>
     * </span>@param</span> childIndex</span> Index of the newly accepted child token in the parent token's active children array</span></span>
     * </span>@param</span> childAddress</span> Address of the child token's collection smart contract</span></span>
     * </span>@param</span> childId</span> ID of the child token in the child token's collection smart contract</span></span>
     */</span></span>
    event</span> ChildAccepted</span>(</span></span>
        uint256</span> indexed</span> tokenId</span>,</span></span>
        uint256</span> childIndex</span>,</span></span>
        address</span> indexed</span> childAddress</span>,</span></span>
        uint256</span> indexed</span> childId</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to notify listeners that all pending child tokens of a given token have been rejected.</span></span>
     * </span>@dev</span> Emitted when a token removes all child tokens from its pending array.</span></span>
     * </span>@param</span> tokenId</span> ID of the token that rejected all of the pending children</span></span>
     */</span></span>
    event</span> AllChildrenRejected</span>(</span>uint256</span> indexed</span> tokenId</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to notify listeners a child token has been transferred from parent token.</span></span>
     * </span>@dev</span> Emitted when a token transfers a child from itself, transferring ownership.</span></span>
     * </span>@param</span> tokenId</span> ID of the token that transferred a child token</span></span>
     * </span>@param</span> childIndex</span> Index of a child in the array from which it is being transferred</span></span>
     * </span>@param</span> childAddress</span> Address of the child token's collection smart contract</span></span>
     * </span>@param</span> childId</span> ID of the child token in the child token's collection smart contract</span></span>
     * </span>@param</span> fromPending</span> A boolean value signifying whether the token was in the pending child tokens array (`true`) or</span></span>
     *  in the active child tokens array (`false`)</span></span>
     * </span>@param</span> toZero</span> A boolean value signifying whether the token is being transferred to the `0x0` address (`true`) or</span></span>
     *  not (`false`)</span></span>
     */</span></span>
    event</span> ChildTransferred</span>(</span></span>
        uint256</span> indexed</span> tokenId</span>,</span></span>
        uint256</span> childIndex</span>,</span></span>
        address</span> indexed</span> childAddress</span>,</span></span>
        uint256</span> indexed</span> childId</span>,</span></span>
        bool</span> fromPending</span>,</span></span>
        bool</span> toZero</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to retrieve the *root* owner of a given token.</span></span>
     * </span>@dev</span> The *root* owner of the token is the top-level owner in the hierarchy which is not an NFT.</span></span>
     * </span>@dev</span> If the token is owned by another NFT, it MUST recursively look up the parent's root owner.</span></span>
     * </span>@param</span> tokenId</span> ID of the token for which the *root* owner has been retrieved</span></span>
     * </span>@return</span> owner</span> The *root* owner of the token</span></span>
     */</span></span>
    function</span> ownerOf</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>address</span> owner</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to retrieve the immediate owner of the given token.</span></span>
     * </span>@dev</span> If the immediate owner is another token, the address returned, MUST be the one of the parent token's</span></span>
     *  collection smart contract.</span></span>
     * </span>@param</span> tokenId</span> ID of the token for which the direct owner is being retrieved</span></span>
     * </span>@return</span> address</span> Address of the given token's owner</span></span>
     * </span>@return</span> uint256</span> The ID of the parent token. MUST be `0` if the owner is not an NFT</span></span>
     * </span>@return</span> bool</span> The boolean value signifying whether the owner is an NFT or not</span></span>
     */</span></span>
    function</span> directOwnerOf</span>(</span>uint256</span> tokenId</span>)</span></span>
        external</span></span>
        view</span></span>
        returns</span> (</span></span>
            address</span>,</span></span>
            uint256</span>,</span></span>
            bool</span></span>
        )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to burn a given token.</span></span>
     * </span>@dev</span> When a token is burned, all of its child tokens are recursively burned as well.</span></span>
     * </span>@dev</span> When specifying the maximum recursive burns, the execution MUST be reverted if there are more children to be</span></span>
     *  burned.</span></span>
     * </span>@dev</span> Setting the `maxRecursiveBurn` value to 0 SHOULD only attempt to burn the specified token and MUST revert if</span></span>
     *  there are any child tokens present.</span></span>
     * </span>@param</span> tokenId</span> ID of the token to burn</span></span>
     * </span>@param</span> maxRecursiveBurns</span> Maximum number of tokens to recursively burn</span></span>
     * </span>@return</span> uint256</span> Number of recursively burned children</span></span>
     */</span></span>
    function</span> burn</span>(</span>uint256</span> tokenId</span>,</span> uint256</span> maxRecursiveBurns</span>)</span></span>
        external</span></span>
        returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to add a child token to a given parent token.</span></span>
     * </span>@dev</span> This adds the child token into the given parent token's pending child tokens array.</span></span>
     * </span>@dev</span> The destination token MUST NOT be a child token of the token being transferred or one of its downstream</span></span>
     *  child tokens.</span></span>
     * </span>@dev</span> This method MUST NOT be called directly. It MUST only be called from an instance of `IERC7059` as part of a </span></span>
        `nestTransfer` or `transferChild` to an NFT.</span></span>
     * </span>@dev</span> Requirements:</span></span>
     *</span></span>
     *  - `directOwnerOf` on the child contract MUST resolve to the called contract.</span></span>
     *  - the pending array of the parent contract MUST not be full.</span></span>
     * </span>@param</span> parentId</span> ID of the parent token to receive the new child token</span></span>
     * </span>@param</span> childId</span> ID of the new proposed child token</span></span>
     */</span></span>
    function</span> addChild</span>(</span>uint256</span> parentId</span>,</span> uint256</span> childId</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to accept a pending child token for a given parent token.</span></span>
     * </span>@dev</span> This moves the child token from parent token's pending child tokens array into the active child tokens</span></span>
     *  array.</span></span>
     * </span>@param</span> parentId</span> ID of the parent token for which the child token is being accepted</span></span>
     * </span>@param</span> childIndex</span> Index of the child token to accept in the pending children array of a given token</span></span>
     * </span>@param</span> childAddress</span> Address of the collection smart contract of the child token expected to be at the specified</span></span>
     *  index</span></span>
     * </span>@param</span> childId</span> ID of the child token expected to be located at the specified index</span></span>
     */</span></span>
    function</span> acceptChild</span>(</span></span>
        uint256</span> parentId</span>,</span></span>
        uint256</span> childIndex</span>,</span></span>
        address</span> childAddress</span>,</span></span>
        uint256</span> childId</span></span>
    )</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to reject all pending children of a given parent token.</span></span>
     * </span>@dev</span> Removes the children from the pending array mapping.</span></span>
     * </span>@dev</span> The children's ownership structures are not updated.</span></span>
     * </span>@dev</span> Requirements:</span></span>
     *</span></span>
     * - `parentId` MUST exist</span></span>
     * </span>@param</span> parentId</span> ID of the parent token for which to reject all of the pending tokens</span></span>
     * </span>@param</span> maxRejections</span> Maximum number of expected children to reject, used to prevent from</span></span>
     *  rejecting children which arrive just before this operation.</span></span>
     */</span></span>
    function</span> rejectAllChildren</span>(</span>uint256</span> parentId</span>,</span> uint256</span> maxRejections</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to transfer a child token from a given parent token.</span></span>
     * </span>@dev</span> MUST remove the child from the parent's active or pending children.</span></span>
     * </span>@dev</span> When transferring a child token, the owner of the token MUST be set to `to`, or not updated in the event of `to`</span></span>
     *  being the `0x0` address.</span></span>
     * </span>@param</span> tokenId</span> ID of the parent token from which the child token is being transferred</span></span>
     * </span>@param</span> to</span> Address to which to transfer the token to</span></span>
     * </span>@param</span> destinationId</span> ID of the token to receive this child token (MUST be 0 if the destination is not a token)</span></span>
     * </span>@param</span> childIndex</span> Index of a token we are transferring, in the array it belongs to (can be either active array or</span></span>
     *  pending array)</span></span>
     * </span>@param</span> childAddress</span> Address of the child token's collection smart contract</span></span>
     * </span>@param</span> childId</span> ID of the child token in its own collection smart contract</span></span>
     * </span>@param</span> isPending</span> A boolean value indicating whether the child token being transferred is in the pending array of the</span></span>
     *  parent token (`true`) or in the active array (`false`)</span></span>
     * </span>@param</span> data</span> Additional data with no specified format, sent in call to `to`</span></span>
     */</span></span>
    function</span> transferChild</span>(</span></span>
        uint256</span> tokenId</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> destinationId</span>,</span></span>
        uint256</span> childIndex</span>,</span></span>
        address</span> childAddress</span>,</span></span>
        uint256</span> childId</span>,</span></span>
        bool</span> isPending</span>,</span></span>
        bytes</span> data</span></span>
    )</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to retrieve the active child tokens of a given parent token.</span></span>
     * </span>@dev</span> Returns array of Child structs existing for parent token.</span></span>
     * </span>@dev</span> The Child struct consists of the following values:</span></span>
     *  [</span></span>
     *      tokenId,</span></span>
     *      contractAddress</span></span>
     *  ]</span></span>
     * </span>@param</span> parentId</span> ID of the parent token for which to retrieve the active child tokens</span></span>
     * </span>@return</span> struct</span>[] An array of Child structs containing the parent token's active child tokens</span></span>
     */</span></span>
    function</span> childrenOf</span>(</span>uint256</span> parentId</span>)</span></span>
        external</span></span>
        view</span></span>
        returns</span> (</span>Child</span>[</span>]</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to retrieve the pending child tokens of a given parent token.</span></span>
     * </span>@dev</span> Returns array of pending Child structs existing for given parent.</span></span>
     * </span>@dev</span> The Child struct consists of the following values:</span></span>
     *  [</span></span>
     *      tokenId,</span></span>
     *      contractAddress</span></span>
     *  ]</span></span>
     * </span>@param</span> parentId</span> ID of the parent token for which to retrieve the pending child tokens</span></span>
     * </span>@return</span> struct</span>[] An array of Child structs containing the parent token's pending child tokens</span></span>
     */</span></span>
    function</span> pendingChildrenOf</span>(</span>uint256</span> parentId</span>)</span></span>
        external</span></span>
        view</span></span>
        returns</span> (</span>Child</span>[</span>]</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to retrieve a specific active child token for a given parent token.</span></span>
     * </span>@dev</span> Returns a single Child struct locating at `index` of parent token's active child tokens array.</span></span>
     * </span>@dev</span> The Child struct consists of the following values:</span></span>
     *  [</span></span>
     *      tokenId,</span></span>
     *      contractAddress</span></span>
     *  ]</span></span>
     * </span>@param</span> parentId</span> ID of the parent token for which the child is being retrieved</span></span>
     * </span>@param</span> index</span> Index of the child token in the parent token's active child tokens array</span></span>
     * </span>@return</span> struct</span> A Child struct containing data about the specified child</span></span>
     */</span></span>
    function</span> childOf</span>(</span>uint256</span> parentId</span>,</span> uint256</span> index</span>)</span></span>
        external</span></span>
        view</span></span>
        returns</span> (</span>Child</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to retrieve a specific pending child token from a given parent token.</span></span>
     * </span>@dev</span> Returns a single Child struct locating at `index` of parent token's active child tokens array.</span></span>
     * </span>@dev</span> The Child struct consists of the following values:</span></span>
     *  [</span></span>
     *      tokenId,</span></span>
     *      contractAddress</span></span>
     *  ]</span></span>
     * </span>@param</span> parentId</span> ID of the parent token for which the pending child token is being retrieved</span></span>
     * </span>@param</span> index</span> Index of the child token in the parent token's pending child tokens array</span></span>
     * </span>@return</span> struct</span> A Child struct containing data about the specified child</span></span>
     */</span></span>
    function</span> pendingChildOf</span>(</span>uint256</span> parentId</span>,</span> uint256</span> index</span>)</span></span>
        external</span></span>
        view</span></span>
        returns</span> (</span>Child</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to transfer the token into another token.</span></span>
     * </span>@dev</span> The destination token MUST NOT be a child token of the token being transferred or one of its downstream</span></span>
     *  child tokens.</span></span>
     * </span>@param</span> from</span> Address of the direct owner of the token to be transferred</span></span>
     * </span>@param</span> to</span> Address of the receiving token's collection smart contract</span></span>
     * </span>@param</span> tokenId</span> ID of the token being transferred</span></span>
     * </span>@param</span> destinationId</span> ID of the token to receive the token being transferred</span></span>
     * </span>@param</span> data</span> Additional data with no specified format</span></span>
     */</span></span>
    function</span> nestTransferFrom</span>(</span></span>
        address</span> from</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        uint256</span> destinationId</span>,</span></span>
        bytes</span> memory</span> data</span></span>
    )</span> external</span>;</span></span>
}</span></span></code></pre>
ID MUST never be a 0</code> value, as this proposal uses 0</code> values do signify that the token/destination is not an NFT.</p>
Rationale</h2>
Designing the proposal, we considered the following questions:</p>

How to name the proposal?</strong>

In an effort to provide as much information about the proposal we identified the most important aspect of the proposal; the parent centered control over nesting. The child token's role is only to be able to be Nestable</code> and support a token owning it. This is how we landed on the Parent-Centered</code> part of the title.</li>
Why is automatically accepting a child using EIP-712</a> permit-style signatures not a part of this proposal?</strong>

For consistency. This proposal extends ERC-721 which already uses 1 transaction for approving operations with tokens. It would be inconsistent to have this and also support signing messages for operations with assets.</li>
Why use indexes?</strong>

To reduce the gas consumption. If the token ID was used to find which token to accept or reject, iteration over arrays would be required and the cost of the operation would depend on the size of the active or pending children arrays. With the index, the cost is fixed. Lists of active and pending children per token need to be maintained, since methods to get them are part of the proposed interface.

To avoid race conditions in which the index of a token changes, the expected token ID as well as the expected token's collection smart contract is included in operations requiring token index, to verify that the token being accessed using the index is the expected one.

Implementation that would internally keep track of indices using mapping was attempted. The minimum cost of accepting a child token was increased by over 20% and the cost of minting has increased by over 15%. We concluded that it is not necessary for this proposal and can be implemented as an extension for use cases willing to accept the increased transaction cost this incurs. In the sample implementation provided, there are several hooks which make this possible.</li>
Why is the pending children array limited instead of supporting pagination?</strong>

The pending child tokens array is not meant to be a buffer to collect the tokens that the root owner of the parent token wants to keep, but not enough to promote them to active children. It is meant to be an easily traversable list of child token candidates and should be regularly maintained; by either accepting or rejecting proposed child tokens. There is also no need for the pending child tokens array to be unbounded, because active child tokens array is.

Another benefit of having bounded child tokens array is to guard against spam and griefing. As minting malicious or spam tokens could be relatively easy and low-cost, the bounded pending array assures that all of the tokens in it are easy to identify and that legitimate tokens are not lost in a flood of spam tokens, if one occurs.

A consideration tied to this issue was also how to make sure, that a legitimate token is not accidentally rejected when clearing the pending child tokens array. We added the maximum pending children to reject argument to the clear pending child tokens array call. This assures that only the intended number of pending child tokens is rejected and if a new token is added to the pending child tokens array during the course of preparing such call and executing it, the clearing of this array SHOULD result in a reverted transaction.</li>
Should we allow tokens to be nested into one of its children?</strong>

The proposal enforces that a parent token can't be nested into one of its child token, or downstream child tokens for that matter. A parent token and its children are all managed by the parent token's root owner. This means that if a token would be nested into one of its children, this would create the ownership loop and none of the tokens within the loop could be managed anymore.</li>
Why is there not a "safe" nest transfer method?</strong>

nestTransfer</code> is always "safe" since it MUST check for IERC7059</code> compatibility on the destination.</li>
How does this proposal differ from the other proposals trying to address a similar problem?</strong>

This interface allows for tokens to both be sent to and receive other tokens. The propose-accept and parent governed patterns allow for a more secure use. The backward compatibility is only added for ERC-721, allowing for a simpler interface. The proposal also allows for different collections to inter-operate, meaning that nesting is not locked to a single smart contract, but can be executed between completely separate NFT collections.

Additionally this proposal addresses the inconsistencies between interfaceId</code>, interface specification and example implementation of ERC-6059</a>.</li>
</ol>
Propose-Commit pattern for child token management</h3>
Adding child tokens to a parent token MUST be done in the form of propose-commit pattern to allow for limited mutability by a 3rd party. When adding a child token to a parent token, it is first placed in a "Pending"</em> array, and MUST be migrated to the "Active"</em> array by the parent token's root owner. The "Pending"</em> child tokens array SHOULD be limited to 128 slots to prevent spam and griefing.</p>
The limitation that only the root owner can accept the child tokens also introduces a trust inherent to the proposal. This ensures that the root owner of the token has full control over the token. No one can force the user to accept a child if they don't want to.</p>
Parent Governed pattern</h3>
The parent NFT of a nested token and the parent's root owner are in all aspects the true owners of it. Once you send a token to another one you give up ownership.</p>
We continue to use ERC-721's ownerOf</code> functionality which will now recursively look up through parents until it finds an address which is not an NFT, this is referred to as the root owner</em>. Additionally we provide the directOwnerOf</code> which returns the most immediate owner of a token using 3 values: the owner address, the tokenId which MUST be 0 if the direct owner is not an NFT, and a flag indicating whether or not the parent is an NFT.</p>
The root owner or an approved party MUST be able to do the following operations on children: acceptChild</code>, rejectAllChildren</code> and transferChild</code>.</p>
The root owner or an approved party MUST also be allowed to do these operations only when token is not owned by an NFT: transferFrom</code>, safeTransferFrom</code>, nestTransferFrom</code>, burn</code>.</p>
If the token is owned by an NFT, only the parent NFT itself MUST be allowed to execute the operations listed above. Transfers MUST be done from the parent token, using transferChild</code>, this method in turn SHOULD call nestTransferFrom</code> or safeTransferFrom</code> in the child token's smart contract, according to whether the destination is an NFT or not. For burning, tokens must first be transferred to an EOA and then burned.</p>
We add this restriction to prevent inconsistencies on parent contracts, since only the transferChild</code> method takes care of removing the child from the parent when it is being transferred out of it.</p>
Child token management</h3>
This proposal introduces a number of child token management functions. In addition to the permissioned migration from "Pending"</em> to "Active"</em> child tokens array, the main token management function from this proposal is the transferChild</code> function. The following state transitions of a child token are available with it:</p>

Reject child token</li>
Abandon child token</li>
Unnest child token</li>
Transfer the child token to an EOA or an ERC721Receiver</code></li>
Transfer the child token into a new parent token</li>
</ol>
To better understand how these state transitions are achieved, we have to look at the available parameters passed to transferChild</code>:</p>
    function</span> transferChild</span>(</span></span>
        uint256</span> tokenId</span>,</span></span>
        address</span> to</span>,</span></span>
        uint256</span> destinationId</span>,</span></span>
        uint256</span> childIndex</span>,</span></span>
        address</span> childAddress</span>,</span></span>
        uint256</span> childId</span>,</span></span>
        bool</span> isPending</span>,</span></span>
        bytes</span> data</span></span>
    )</span> external</span>;</span></span></code></pre>
Based on the desired state transitions, the values of these parameters have to be set accordingly (any parameters not set in the following examples depend on the child token being managed):</p>

Reject child token</strong>

</li>
Abandon child token</strong>

</li>
Unnest child token</strong>

</li>
Transfer the child token to an EOA or an ERC721Receiver</code></strong>

</li>
Transfer the child token into a new parent token</strong>



This state change places the token in the pending array of the new parent token. The child token still needs to be accepted by the new parent token's root owner in order to be placed into the active array of that token.</li>
</ol>
Backwards Compatibility</h2>
The Nestable token standard has been made compatible with ERC-721</a> in order to take advantage of the robust tooling available for implementations of ERC-721 and to ensure compatibility with existing ERC-721 infrastructure.</p>
The only incompatibility with ERC-721 is that Nestable tokens cannot use a token ID of 0.</p>
There is some differentiation of how the ownerOf</code> method behaves compared to ERC-721. The ownerOf</code> method will now recursively look up through parent tokens until it finds an address that is not an NFT; this is referred to as the root owner</em>. Additionally, we provide the directOwnerOf</code>, which returns the most immediate owner of a token using 3 values: the owner address, the tokenId</code>, which MUST be 0 if the direct owner is not an NFT, and a flag indicating whether or not the parent is an NFT. In case the token is owned by an EoA or an ERC-721 Receiver, the ownerOf</code> method will behave the same as in ERC-721.</p>
Test Cases</h2>
Tests are included in nestable.ts</code></a>.</p>
To run them in terminal, you can use the following commands:</p>
cd ../assets/eip-7401</span></span>
npm install</span></span>
npx hardhat test</span></span></code></pre>Reference Implementation</h2>
See NestableToken.sol</code></a>.</p>
Security Considerations</h2>
The same security considerations as with ERC-721</a> apply: hidden logic may be present in any of the functions, including burn, add child, accept child, and more.</p>
Since the current owner of the token is allowed to manage the token, there is a possibility that after the parent token is listed for sale, the seller might remove a child token just before before the sale and thus the buyer would not receive the expected child token. This is a risk that is inherent to the design of this standard. Marketplaces should take this into account and provide a way to verify the expected child tokens are present when the parent token is being sold or to guard against such a malicious behaviour in another way.</p>
It is worth noting that balanceOf</code> method only accounts for immediate tokens owned by the address; the tokens that are nested into a token owned by this address will not be reflected in this value as the recursive lookup needed in order to calculate this value is potentially too deep and might break the method.</p>
Caution is advised when dealing with non-audited contracts.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Public Non-Fungible Tokens Emote Repository
2023-07-26T00:00:00+00:00
Abstract</h2>
❗️ ERC-7409</a> supersedes ERC-6381</a>.</strong> ❗️</p>
The Public Non-Fungible Tokens Emote Repository standard provides an enhanced interactive utility for ERC-721</a> and ERC-1155</a> by allowing NFTs to be emoted at.</p>
This proposal introduces the ability to react to NFTs using Unicode standardized emoji in a public non-gated repository smart contract that is accessible at the same address in all of the networks.</p>
Motivation</h2>
With NFTs being a widespread form of tokens in the Ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. Having the ability for anyone to interact with an NFT introduces an interactive aspect to owning an NFT and unlocks feedback-based NFT mechanics.</p>
This ERC introduces new utilities for ERC-721</a> based tokens in the following areas:</p>

Interactivity</a></li>
Feedback based evolution</a></li>
Valuation</a></li>
</ul>
This proposal fixes the compatibility issue in the ERC-6381</a> interface specification, where emojis are represented using bytes4</code> values. The introduction of variation flags and emoji skin tones has rendered the bytes4</code> namespace insufficient for representing all possible emojis, so the new standard used string</code> instead. Apart from this fix, this proposal is functionally equivalent to ERC-6381</a>.</p>
Interactivity</h3>
The ability to emote on an NFT introduces the aspect of interactivity to owning an NFT. This can either reflect the admiration for the emoter (person emoting to an NFT) or can be a result of a certain action performed by the token's owner. Accumulating emotes on a token can increase its uniqueness and/or value.</p>
Feedback based evolution</h3>
Standardized on-chain reactions to NFTs allow for feedback based evolution.</p>
Current solutions are either proprietary or off-chain and therefore subject to manipulation and distrust. Having the ability to track the interaction on-chain allows for trust and objective evaluation of a given token. Designing the tokens to evolve when certain emote thresholds are met incentivizes interaction with the token collection.</p>
Valuation</h3>
Current NFT market heavily relies on previous values the token has been sold for, the lowest price of the listed token and the scarcity data provided by the marketplace. There is no real time indication of admiration or desirability of a specific token. Having the ability for users to emote to the tokens adds the possibility of potential buyers and sellers gauging the value of the token based on the impressions the token has collected.</p>
Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p>
///</span> @title</span> ERC-7409 Emotable Extension for Non-Fungible Tokens</span></span>
///</span> @dev</span> See https://eips.ethereum.org/EIPS/eip-7409</span></span>
///</span> @dev</span> Note</span>: the ERC-165 identifier for this interface is 0x1b3327ab.</span></span>
</span>
pragma</span> solidity</span> ^0.8.16</span>;</span></span>
</span>
interface</span> IERC7409</span> /*</span>is IERC165</span>*/</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> Used to notify listeners that the token with the specified ID has been emoted to or that the reaction has been revoked.</span></span>
     * </span>@dev</span> The event MUST only be emitted if the state of the emote is </span>changed</span>.</span></span>
     * </span>@param</span> emoter</span> Address of the account that emoted or revoked the reaction to the token</span></span>
     * </span>@param</span> collection</span> Address of the collection smart contract containing the token being emoted to or having the reaction revoked</span></span>
     * </span>@param</span> tokenId</span> ID of the token</span></span>
     * </span>@param</span> emoji</span> Unicode identifier of the emoji</span></span>
     * </span>@param</span> on</span> Boolean value signifying whether the token was emoted to (`true`) or if the reaction has been revoked (`false`)</span></span>
     */</span></span>
    event</span> Emoted</span>(</span></span>
        address</span> indexed</span> emoter</span>,</span></span>
        address</span> indexed</span> collection</span>,</span></span>
        uint256</span> indexed</span> tokenId</span>,</span></span>
        string</span> emoji</span>,</span></span>
        bool</span> on</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to get the number of emotes for a specific emoji on a token.</span></span>
     * </span>@param</span> collection</span> Address of the collection containing the token being checked for emoji count</span></span>
     * </span>@param</span> tokenId</span> ID of the token to check for emoji count</span></span>
     * </span>@param</span> emoji</span> Unicode identifier of the emoji</span></span>
     * </span>@return</span> Number</span> of emotes with the emoji on the token</span></span>
     */</span></span>
    function</span> emoteCountOf</span>(</span></span>
        address</span> collection</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        string</span> memory</span> emoji</span></span>
    )</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to get the number of emotes for a specific emoji on a set of tokens.</span></span>
     * </span>@param</span> collections</span> An array of addresses of the collections containing the tokens being checked for emoji count</span></span>
     * </span>@param</span> tokenIds</span> An array of IDs of the tokens to check for emoji count</span></span>
     * </span>@param</span> emojis</span> An array of unicode identifiers of the emojis</span></span>
     * </span>@return</span> An</span> array of numbers of emotes with the emoji on the tokens</span></span>
     */</span></span>
    function</span> bulkEmoteCountOf</span>(</span></span>
        address</span>[</span>]</span> memory</span> collections</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> tokenIds</span>,</span></span>
        string</span>[</span>]</span> memory</span> emojis</span></span>
    )</span> external</span> view</span> returns</span> (</span>uint256</span>[</span>]</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to get the information on whether the specified address has used a specific emoji on a specific</span></span>
     *  token.</span></span>
     * </span>@param</span> emoter</span> Address of the account we are checking for a reaction to a token</span></span>
     * </span>@param</span> collection</span> Address of the collection smart contract containing the token being checked for emoji reaction</span></span>
     * </span>@param</span> tokenId</span> ID of the token being checked for emoji reaction</span></span>
     * </span>@param</span> emoji</span> The ASCII emoji code being checked for reaction</span></span>
     * </span>@return</span> A</span> boolean value indicating whether the `emoter` has used the `emoji` on the token (`true`) or not</span></span>
     *  (`false`)</span></span>
     */</span></span>
    function</span> hasEmoterUsedEmote</span>(</span></span>
        address</span> emoter</span>,</span></span>
        address</span> collection</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        string</span> memory</span> emoji</span></span>
    )</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to get the information on whether the specified addresses have used specific emojis on specific</span></span>
     *  tokens.</span></span>
     * </span>@param</span> emoters</span> An array of addresses of the accounts we are checking for reactions to tokens</span></span>
     * </span>@param</span> collections</span> An array of addresses of the collection smart contracts containing the tokens being checked</span></span>
     *  for emoji reactions</span></span>
     * </span>@param</span> tokenIds</span> An array of IDs of the tokens being checked for emoji reactions</span></span>
     * </span>@param</span> emojis</span> An array of the ASCII emoji codes being checked for reactions</span></span>
     * </span>@return</span> An</span> array of boolean values indicating whether the `emoter`s has used the `emoji`s on the tokens (`true`)</span></span>
     *  or not (`false`)</span></span>
     */</span></span>
    function</span> haveEmotersUsedEmotes</span>(</span></span>
        address</span>[</span>]</span> memory</span> emoters</span>,</span></span>
        address</span>[</span>]</span> memory</span> collections</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> tokenIds</span>,</span></span>
        string</span>[</span>]</span> memory</span> emojis</span></span>
    )</span> external</span> view</span> returns</span> (</span>bool</span>[</span>]</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to get the message to be signed by the `emoter` in order for the reaction to be submitted by someone</span></span>
     *  else.</span></span>
     * </span>@param</span> collection</span> The address of the collection smart contract containing the token being emoted at</span></span>
     * </span>@param</span> tokenId</span> ID of the token being emoted</span></span>
     * </span>@param</span> emoji</span> Unicode identifier of the emoji</span></span>
     * </span>@param</span> state</span> Boolean value signifying whether to emote (`true`) or undo (`false`) emote</span></span>
     * </span>@param</span> deadline</span> UNIX timestamp of the deadline for the signature to be submitted</span></span>
     * </span>@return</span> The</span> message to be signed by the `emoter` in order for the reaction to be submitted by someone else</span></span>
     */</span></span>
    function</span> prepareMessageToPresignEmote</span>(</span></span>
        address</span> collection</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        string</span> memory</span> emoji</span>,</span></span>
        bool</span> state</span>,</span></span>
        uint256</span> deadline</span></span>
    )</span> external</span> view</span> returns</span> (</span>bytes32</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to get multiple messages to be signed by the `emoter` in order for the reaction to be submitted by someone</span></span>
     *  else.</span></span>
     * </span>@param</span> collections</span> An array of addresses of the collection smart contracts containing the tokens being emoted at</span></span>
     * </span>@param</span> tokenIds</span> An array of IDs of the tokens being emoted</span></span>
     * </span>@param</span> emojis</span> An array of unicode identifiers of the emojis</span></span>
     * </span>@param</span> states</span> An array of boolean values signifying whether to emote (`true`) or undo (`false`) emote</span></span>
     * </span>@param</span> deadlines</span> An array of UNIX timestamps of the deadlines for the signatures to be submitted</span></span>
     * </span>@return</span> The</span> array of messages to be signed by the `emoter` in order for the reaction to be submitted by someone else</span></span>
     */</span></span>
    function</span> bulkPrepareMessagesToPresignEmote</span>(</span></span>
        address</span>[</span>]</span> memory</span> collections</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> tokenIds</span>,</span></span>
        string</span>[</span>]</span> memory</span> emojis</span>,</span></span>
        bool</span>[</span>]</span> memory</span> states</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> deadlines</span></span>
    )</span> external</span> view</span> returns</span> (</span>bytes32</span>[</span>]</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to emote or undo an emote on a token.</span></span>
     * </span>@dev</span> Does nothing if attempting to set a pre-existent state.</span></span>
     * </span>@dev</span> MUST emit the `Emoted` event is the state of the emote is </span>changed</span>.</span></span>
     * </span>@param</span> collection</span> Address of the collection containing the token being emoted at</span></span>
     * </span>@param</span> tokenId</span> ID of the token being emoted</span></span>
     * </span>@param</span> emoji</span> Unicode identifier of the emoji</span></span>
     * </span>@param</span> state</span> Boolean value signifying whether to emote (`true`) or undo (`false`) emote</span></span>
     */</span></span>
    function</span> emote</span>(</span></span>
        address</span> collection</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        string</span> memory</span> emoji</span>,</span></span>
        bool</span> state</span></span>
    )</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to emote or undo an emote on multiple tokens.</span></span>
     * </span>@dev</span> Does nothing if attempting to set a pre-existent state.</span></span>
     * </span>@dev</span> MUST emit the `Emoted` event is the state of the emote is </span>changed</span>.</span></span>
     * </span>@dev</span> MUST revert if the lengths of the `collections`, `tokenIds`, `emojis` and `states` arrays are not equal.</span></span>
     * </span>@param</span> collections</span> An array of addresses of the collections containing the tokens being emoted at</span></span>
     * </span>@param</span> tokenIds</span> An array of IDs of the tokens being emoted</span></span>
     * </span>@param</span> emojis</span> An array of unicode identifiers of the emojis</span></span>
     * </span>@param</span> states</span> An array of boolean values signifying whether to emote (`true`) or undo (`false`) emote</span></span>
     */</span></span>
    function</span> bulkEmote</span>(</span></span>
        address</span>[</span>]</span> memory</span> collections</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> tokenIds</span>,</span></span>
        string</span>[</span>]</span> memory</span> emojis</span>,</span></span>
        bool</span>[</span>]</span> memory</span> states</span></span>
    )</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to emote or undo an emote on someone else's behalf.</span></span>
     * </span>@dev</span> Does nothing if attempting to set a pre-existent state.</span></span>
     * </span>@dev</span> MUST emit the `Emoted` event is the state of the emote is </span>changed</span>.</span></span>
     * </span>@dev</span> MUST revert if the lengths of the `collections`, `tokenIds`, `emojis` and `states` arrays are not equal.</span></span>
     * </span>@dev</span> MUST revert if the `deadline` has passed.</span></span>
     * </span>@dev</span> MUST revert if the recovered address is the zero address.</span></span>
     * </span>@param</span> emoter</span> The address that presigned the emote</span></span>
     * </span>@param</span> collection</span> The address of the collection smart contract containing the token being emoted at</span></span>
     * </span>@param</span> tokenId</span> IDs of the token being emoted</span></span>
     * </span>@param</span> emoji</span> Unicode identifier of the emoji</span></span>
     * </span>@param</span> state</span> Boolean value signifying whether to emote (`true`) or undo (`false`) emote</span></span>
     * </span>@param</span> deadline</span> UNIX timestamp of the deadline for the signature to be submitted</span></span>
     * </span>@param</span> v</span> `v` value of an ECDSA signature of the message obtained via `prepareMessageToPresignEmote`</span></span>
     * </span>@param</span> r</span> `r` value of an ECDSA signature of the message obtained via `prepareMessageToPresignEmote`</span></span>
     * </span>@param</span> s</span> `s` value of an ECDSA signature of the message obtained via `prepareMessageToPresignEmote`</span></span>
     */</span></span>
    function</span> presignedEmote</span>(</span></span>
        address</span> emoter</span>,</span></span>
        address</span> collection</span>,</span></span>
        uint256</span> tokenId</span>,</span></span>
        string</span> memory</span> emoji</span>,</span></span>
        bool</span> state</span>,</span></span>
        uint256</span> deadline</span>,</span></span>
        uint8</span> v</span>,</span></span>
        bytes32</span> r</span>,</span></span>
        bytes32</span> s</span></span>
    )</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Used to bulk emote or undo an emote on someone else's behalf.</span></span>
     * </span>@dev</span> Does nothing if attempting to set a pre-existent state.</span></span>
     * </span>@dev</span> MUST emit the `Emoted` event is the state of the emote is </span>changed</span>.</span></span>
     * </span>@dev</span> MUST revert if the lengths of the `collections`, `tokenIds`, `emojis` and `states` arrays are not equal.</span></span>
     * </span>@dev</span> MUST revert if the `deadline` has passed.</span></span>
     * </span>@dev</span> MUST revert if the recovered address is the zero address.</span></span>
     * </span>@param</span> emoters</span> An array of addresses of the accounts that presigned the emotes</span></span>
     * </span>@param</span> collections</span> An array of addresses of the collections containing the tokens being emoted at</span></span>
     * </span>@param</span> tokenIds</span> An array of IDs of the tokens being emoted</span></span>
     * </span>@param</span> emojis</span> An array of unicode identifiers of the emojis</span></span>
     * </span>@param</span> states</span> An array of boolean values signifying whether to emote (`true`) or undo (`false`) emote</span></span>
     * </span>@param</span> deadlines</span> UNIX timestamp of the deadline for the signature to be submitted</span></span>
     * </span>@param</span> v</span> An array of `v` values of an ECDSA signatures of the messages obtained via `prepareMessageToPresignEmote`</span></span>
     * </span>@param</span> r</span> An array of `r` values of an ECDSA signatures of the messages obtained via `prepareMessageToPresignEmote`</span></span>
     * </span>@param</span> s</span> An array of `s` values of an ECDSA signatures of the messages obtained via `prepareMessageToPresignEmote`</span></span>
     */</span></span>
    function</span> bulkPresignedEmote</span>(</span></span>
        address</span>[</span>]</span> memory</span> emoters</span>,</span></span>
        address</span>[</span>]</span> memory</span> collections</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> tokenIds</span>,</span></span>
        string</span>[</span>]</span> memory</span> emojis</span>,</span></span>
        bool</span>[</span>]</span> memory</span> states</span>,</span></span>
        uint256</span>[</span>]</span> memory</span> deadlines</span>,</span></span>
        uint8</span>[</span>]</span> memory</span> v</span>,</span></span>
        bytes32</span>[</span>]</span> memory</span> r</span>,</span></span>
        bytes32</span>[</span>]</span> memory</span> s</span></span>
    )</span> external</span>;</span></span>
}</span></span></code></pre>Message format for presigned emotes</h3>
The message to be signed by the emoter</code> in order for the reaction to be submitted by someone else is formatted as follows:</p>
keccak256</span>(</span></span>
        abi</span>.</span>encode</span>(</span></span>
            DOMAIN_SEPARATOR</span>,</span></span>
            collection</span>,</span></span>
            tokenId</span>,</span></span>
            emoji</span>,</span></span>
            state</span>,</span></span>
            deadline</span></span>
        )</span></span>
    )</span>;</span></span></code></pre>
The values passed when generating the message to be signed are:</p>

DOMAIN_SEPARATOR</code> - The domain separator of the Emotable repository smart contract</li>
collection</code> - Address of the collection containing the token being emoted at</li>
tokenId</code> - ID of the token being emoted</li>
emoji</code> - Unicode identifier of the emoji</li>
state</code> - Boolean value signifying whether to emote (true</code>) or undo (false</code>) emote</li>
deadline</code> - UNIX timestamp of the deadline for the signature to be submitted</li>
</ul>
The DOMAIN_SEPARATOR</code> is generated as follows:</p>
keccak256</span>(</span></span>
        abi</span>.</span>encode</span>(</span></span>
            "ERC-7409: Public Non-Fungible Token Emote Repository"</span>,</span></span>
            "1"</span>,</span></span>
            block</span>.</span>chainid</span>,</span></span>
            address</span>(</span>this</span>)</span></span>
        )</span></span>
    )</span>;</span></span></code></pre>
Each chain, that the Emotable repository smart contract is deployed on, will have a different DOMAIN_SEPARATOR</code> value due to chain IDs being different.</p>
Pre-determined address of the Emotable repository</h3>
The address of the Emotable repository smart contract is designed to resemble the function it serves. It starts with 0x3110735</code> which is the abstract representation of EMOTES</code>. The address is:</p>
0x3110735F0b8e71455bAe1356a33e428843bCb9A1</span></span></code></pre>Rationale</h2>
Designing the proposal, we considered the following questions:</p>

Does the proposal support custom emotes or only the Unicode specified ones?</strong>

The proposal only accepts the Unicode identifier which is a string</code> value. This means that while we encourage implementers to add the reactions using standardized emojis, the values not covered by the Unicode standard can be used for custom emotes. The only drawback being that the interface displaying the reactions will have to know what kind of image to render and such additions will probably be limited to the interface or marketplace in which they were made.</li>
Should the proposal use emojis to relay the impressions of NFTs or some other method?</strong>

The impressions could have been done using user-supplied strings or numeric values, yet we decided to use emojis since they are a well established mean of relaying impressions and emotions.</li>
Should the proposal establish an emotable extension or a common-good repository?</strong>

Initially we set out to create an emotable extension to be used with any ERC-721 compliant tokens. However, we realized that the proposal would be more useful if it was a common-good repository of emotable tokens. This way, the tokens that can be reacted to are not only the new ones but also the old ones that have been around since before the proposal.

In line with this decision, we decided to calculate a deterministic address for the repository smart contract. This way, the repository can be used by any NFT collection without the need to search for the address on the given chain.</li>
Should we include only single-action operations, only multi-action operations, or both?</strong>

We've considered including only single-action operations, where the user is only able to react with a single emoji to a single token, but we decided to include both single-action and multi-action operations. This way, the users can choose whether they want to emote or undo emote on a single token or on multiple tokens at once.

This decision was made for the long-term viability of the proposal. Based on the gas cost of the network and the number of tokens in the collection, the user can choose the most cost-effective way of emoting.</li>
Should we add the ability to emote on someone else's behalf?</strong>

While we did not intend to add this as part of the proposal when drafting it, we realized that it would be a useful feature for it. This way, the users can emote on behalf of someone else, for example, if they are not able to do it themselves or if the emote is earned through an off-chain activity.</li>
How do we ensure that emoting on someone else's behalf is legitimate?</strong>

We could add delegates to the proposal; when a user delegates their right to emote to someone else, the delegate can emote on their behalf. However, this would add a lot of complexity and additional logic to the proposal.

Using ECDSA signatures, we can ensure that the user has given their consent to emote on their behalf. This way, the user can sign a message with the parameters of the emote and the signature can be submitted by someone else.</li>
Should we add chain ID as a parameter when reacting to a token?</strong>

During the course of discussion of the proposal, a suggestion arose that we could add chain ID as a parameter when reacting to a token. This would allow the users to emote on the token of one chain on another chain.

We decided against this as we feel that additional parameter would rarely be used and would add additional cost to the reaction transactions. If the collection smart contract wants to utilize on-chain emotes to tokens they contain, they require the reactions to be recorded on the same chain. Marketplaces and wallets integrating this proposal will rely on reactions to reside in the same chain as well, because if chain ID parameter was supported this would mean that they would need to query the repository smart contract on all of the chains the repository is deployed in order to get the reactions for a given token.

Additionally, if the collection creator wants users to record their reactions on a different chain, they can still direct the users to do just that. The repository does not validate the existence of the token being reacted to, which in theory means that you can react to non-existent token or to a token that does not exist yet. The likelihood of a different collection existing at the same address on another chain is significantly low, so the users can react using the collection's address on another chain and it is very unlikely that they will unintentionally react to another collection's token.</li>
Should we use bytes4</code> or strings</code> to represent emotes?</strong>

Initially the proposal used bytes4</code>. This was due to the assumption that all of the emojis use UTF-4 encoding, which is not the case.

The emojis usually use up to 8 bytes, but the personalized emojis with skin tones use much more. This is why we decided to use strings</code> to represent the emotes. This allows the repository to be forward compatible with any future emojis that might be added to the Unicode standard.

This is how this proposal fixes the forward compatibility issue of the ERC-6381</a>.</li>
</ol>
Backwards Compatibility</h2>
The Emote repository standard is fully compatible with ERC-721</a> and with the robust tooling available for implementations of ERC-721 as well as with the existing ERC-721 infrastructure.</p>
Test Cases</h2>
Tests are included in emotableRepository.ts</code></a>.</p>
To run them in terminal, you can use the following commands:</p>
cd ../assets/eip-7409</span></span>
npm install</span></span>
npx hardhat test</span></span></code></pre>Reference Implementation</h2>
See EmotableRepository.sol</code></a>.</p>
Security Considerations</h2>
The proposal does not envision handling any form of assets from the user, so the assets should not be at risk when interacting with an Emote repository.</p>
The ability to use ECDSA signatures to emote on someone else's behalf introduces the risk of a replay attack, which the format of the message to be signed guards against. The DOMAIN_SEPARATOR</code> used in the message to be signed is unique to the repository smart contract of the chain it is deployed on. This means that the signature is invalid on any other chain and the Emote repositories deployed on them should revert the operation if a replay attack is attempted.</p>
Another thing to consider is the ability of presigned message reuse. Since the message includes the signature validity deadline, the message can be reused any number of times before the deadline is reached. The proposal only allows for a single reaction with a given emoji to a specific token to be active, so the presigned message can not be abused to increase the reaction count on the token. However, if the service using the repository relies on the ability to revoke the reaction after certain actions, a valid presigned message can be used to re-react to the token. We suggest that the services using the repository in conjunction with presigned messages use deadlines that invalidate presigned messages after a reasonably short period of time.</p>
Caution is advised when dealing with non-audited contracts.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Non-Fungible Token Roles
2023-07-14T00:00:00+00:00
Abstract</h2>
This standard introduces role management for NFTs. Each role assignment is associated with a single NFT and expires
automatically at a given timestamp. Roles are defined as bytes32</code> and feature a custom data</code> field of arbitrary size
to allow customization.</p>
Motivation</h2>
The NFT Roles interface aims to establish a standard for role management in NFTs. Tracking on-chain roles enables
decentralized applications (dApps) to implement access control for privileged actions, e.g., minting tokens with a role
(airdrop claim rights).</p>
NFT roles can be deeply integrated with dApps to create a utility-sharing mechanism. A good example is in digital real
estate. A user can create a digital property NFT and grant a keccak256("PropertyManager()")</code> role to another user,
allowing them to delegate specific utility without compromising ownership. The same user could also grant a
keccak256("PropertyTenant(uint256)")</code> role to other users, allowing the recipient to access and interact with the
digital property.</p>
There are also interesting use cases in decentralized finance (DeFi). Insurance policies could be issued as NFTs, and
the beneficiaries, insured, and insurer could all be on-chain roles tracked using this standard.</p>
Specification</h2>
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 and RFC-8174.</p>
Compliant contracts MUST implement the following interface:</p>
///</span> @title</span> ERC-7432 Non-Fungible Token Roles</span></span>
///</span> @dev</span> See https://eips.ethereum.org/EIPS/eip-7432</span></span>
///</span> Note</span>: the ERC-165 identifier for this interface is 0xd00ca5cf.</span></span>
interface</span> IERC7432</span> /*</span> is ERC165 </span>*/</span> {</span></span>
  struct</span> Role</span> {</span></span>
    bytes32</span> roleId</span>;</span></span>
    address</span> tokenAddress</span>;</span></span>
    uint256</span> tokenId</span>;</span></span>
    address</span> recipient</span>;</span></span>
    uint64</span> expirationDate</span>;</span></span>
    bool</span> revocable</span>;</span></span>
    bytes</span> data</span>;</span></span>
  }</span></span>
</span>
  /**</span> Events *</span>*/</span></span>
</span>
  ///</span> @notice</span> Emitted when an NFT is locked (deposited or frozen).</span></span>
  ///</span> @param</span> _owner</span> The owner of the NFT.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  event</span> TokenLocked</span>(</span>address</span> indexed</span> _owner</span>, </span>address</span> indexed</span> _tokenAddress</span>, </span>uint256</span> _tokenId</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Emitted when a role is granted.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  ///</span> @param</span> _owner</span> The user assigning the role.</span></span>
  ///</span> @param</span> _recipient</span> The user receiving the role.</span></span>
  ///</span> @param</span> _expirationDate</span> The expiration date of the role.</span></span>
  ///</span> @param</span> _revocable</span> Whether the role is revocable or not.</span></span>
  ///</span> @param</span> _data</span> Any additional data about the role.</span></span>
  event</span> RoleGranted</span>(</span></span>
    address</span> indexed</span> _tokenAddress</span>,</span></span>
    uint256</span> indexed</span> _tokenId</span>,</span></span>
    bytes32</span> indexed</span> _roleId</span>,</span></span>
    address</span> _owner</span>,</span></span>
    address</span> _recipient</span>,</span></span>
    uint64</span> _expirationDate</span>,</span></span>
    bool</span> _revocable</span>,</span></span>
    bytes</span> _data</span></span>
  )</span>;</span></span>
</span>
  ///</span> @notice</span> Emitted when a role is revoked.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  event</span> RoleRevoked</span>(</span>address</span> indexed</span> _tokenAddress</span>, </span>uint256</span> indexed</span> _tokenId</span>, </span>bytes32</span> indexed</span> _roleId</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Emitted when an NFT is unlocked (withdrawn or unfrozen).</span></span>
  ///</span> @param</span> _owner</span> The original owner of the NFT.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  event</span> TokenUnlocked</span>(</span>address</span> indexed</span> _owner</span>, </span>address</span> indexed</span> _tokenAddress</span>, </span>uint256</span> indexed</span> _tokenId</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Emitted when a user is approved to manage roles on behalf of another user.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _operator</span> The user approved to grant and revoke roles.</span></span>
  ///</span> @param</span> _isApproved</span> The approval status.</span></span>
  event</span> RoleApprovalForAll</span>(</span>address</span> indexed</span> _tokenAddress</span>, </span>address</span> indexed</span> _operator</span>, </span>bool</span> indexed</span> _isApproved</span>)</span>;</span></span>
</span>
  /**</span> External Functions *</span>*/</span></span>
</span>
  ///</span> @notice</span> Grants a role to a user.</span></span>
  ///</span> @dev</span> Reverts if sender is not approved or the NFT owner.</span></span>
  ///</span> @param</span> _role</span> The role attributes.</span></span>
  function</span> grantRole</span>(</span>Role</span> calldata</span> _role</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Revokes a role from a user.</span></span>
  ///</span> @dev</span> Reverts if sender is not approved or the original owner.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  function</span> revokeRole</span>(</span>address</span> _tokenAddress</span>,</span> uint256</span> _tokenId</span>,</span> bytes32</span> _roleId</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Unlocks NFT (transfer back to original owner or unfreeze it).</span></span>
  ///</span> @dev</span> Reverts if sender is not approved or the original owner.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  function</span> unlockToken</span>(</span>address</span> _tokenAddress</span>,</span> uint256</span> _tokenId</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Approves operator to grant and revoke roles on behalf of another user.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _operator</span> The user approved to grant and revoke roles.</span></span>
  ///</span> @param</span> _approved</span> The approval status.</span></span>
  function</span> setRoleApprovalForAll</span>(</span>address</span> _tokenAddress</span>,</span> address</span> _operator</span>,</span> bool</span> _approved</span>)</span> external</span>;</span></span>
</span>
  /**</span> View Functions *</span>*/</span></span>
</span>
  ///</span> @notice</span> Retrieves the original owner of the NFT.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @return</span> owner_</span> The owner of the token.</span></span>
  function</span> ownerOf</span>(</span>address</span> _tokenAddress</span>,</span> uint256</span> _tokenId</span>)</span> external</span> view</span> returns</span> (</span>address</span> owner_</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Retrieves the recipient of an NFT role.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  ///</span> @return</span> recipient_</span> The user that received the role.</span></span>
  function</span> recipientOf</span>(</span></span>
    address</span> _tokenAddress</span>,</span></span>
    uint256</span> _tokenId</span>,</span></span>
    bytes32</span> _roleId</span></span>
  )</span> external</span> view</span> returns</span> (</span>address</span> recipient_</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Retrieves the custom data of a role assignment.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  ///</span> @return</span> data_</span> The custom data of the role.</span></span>
  function</span> roleData</span>(</span></span>
    address</span> _tokenAddress</span>,</span></span>
    uint256</span> _tokenId</span>,</span></span>
    bytes32</span> _roleId</span></span>
  )</span> external</span> view</span> returns</span> (</span>bytes</span> memory</span> data_</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Retrieves the expiration date of a role assignment.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  ///</span> @return</span> expirationDate_</span> The expiration date of the role.</span></span>
  function</span> roleExpirationDate</span>(</span></span>
    address</span> _tokenAddress</span>,</span></span>
    uint256</span> _tokenId</span>,</span></span>
    bytes32</span> _roleId</span></span>
  )</span> external</span> view</span> returns</span> (</span>uint64</span> expirationDate_</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Verifies whether the role is revocable.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _tokenId</span> The token identifier.</span></span>
  ///</span> @param</span> _roleId</span> The role identifier.</span></span>
  ///</span> @return</span> revocable_</span> Whether the role is revocable.</span></span>
  function</span> isRoleRevocable</span>(</span></span>
    address</span> _tokenAddress</span>,</span></span>
    uint256</span> _tokenId</span>,</span></span>
    bytes32</span> _roleId</span></span>
  )</span> external</span> view</span> returns</span> (</span>bool</span> revocable_</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Verifies if the owner approved the operator.</span></span>
  ///</span> @param</span> _tokenAddress</span> The token address.</span></span>
  ///</span> @param</span> _owner</span> The user that approved the operator.</span></span>
  ///</span> @param</span> _operator</span> The user that can grant and revoke roles.</span></span>
  ///</span> @return</span> Whether</span> the operator is approved.</span></span>
  function</span> isRoleApprovedForAll</span>(</span></span>
    address</span> _tokenAddress</span>,</span></span>
    address</span> _owner</span>,</span></span>
    address</span> _operator</span></span>
  )</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
}</span></span></code></pre>Metadata Extension</h3>
The Roles Metadata extension extends the traditional JSON-based metadata schema of NFTs. Therefore, DApps supporting
this feature MUST also implement the metadata extension of ERC-721</a>. This extension is optional</strong> and allows
developers to provide additional information for roles.</p>
Updated Metadata Schema:</p>
{</span></span>
  </span></span>
  /**</span> Existing NFT Metadata *</span>*/</span></span>
</span>
  "</span>title</span>"</span>: </span>"</span>Asset Metadata</span>"</span>,</span></span>
  "</span>type</span>"</span>: </span>"</span>object</span>"</span>,</span></span>
  "</span>properties</span>"</span>:</span> {</span></span>
    "</span>name</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>Identifies the asset to which this NFT represents</span>"</span></span>
    }</span>,</span></span>
    "</span>description</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>Describes the asset to which this NFT represents</span>"</span></span>
    }</span>,</span></span>
    "</span>image</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive</span>"</span></span>
    }</span></span>
  }</span>,</span></span>
  </span></span>
  /**</span> Additional fields for Roles *</span>*/</span></span>
</span>
  "</span>roles</span>"</span>:</span> [</span></span>
    {</span></span>
      "</span>id</span>"</span>:</span> {</span></span>
        "</span>type</span>"</span>:</span> "</span>bytes32</span>"</span>,</span></span>
        "</span>description</span>"</span>:</span> "</span>Identifies the role</span>"</span></span>
      }</span>,</span></span>
      "</span>name</span>"</span>:</span> {</span></span>
        "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
        "</span>description</span>"</span>:</span> "</span>Human-readable name of the role</span>"</span></span>
      }</span>,</span></span>
      "</span>description</span>"</span>:</span> {</span></span>
        "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
        "</span>description</span>"</span>:</span> "</span>Describes the role</span>"</span></span>
      }</span>,</span></span>
      "</span>inputs</span>"</span>:</span> [</span></span>
        {</span></span>
          "</span>name</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Human-readable name of the argument</span>"</span></span>
          }</span>,</span></span>
          "</span>type</span>"</span>:</span> {</span></span>
            "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
            "</span>description</span>"</span>:</span> "</span>Solidity type, e.g., uint256 or address</span>"</span></span>
          }</span></span>
        }</span></span>
      ]</span></span>
    }</span></span>
  ]</span></span>
  </span></span>
}</span></span></code></pre>
The following JSON is an example of ERC-7432</a> Metadata:</p>
{</span></span>
  //</span> ... Existing NFT Metadata</span></span>
  </span></span>
  "</span>roles</span>"</span>:</span> [</span></span>
    {</span></span>
      //</span> keccak256("PropertyManager()")</span></span>
      "</span>id</span>"</span>:</span> "</span>0x76be0ffb73d8cd9e8fa76c28632ebbc3865a8ec7a0b6acab6ac589a1c88dd301</span>"</span>,</span></span>
      "</span>name</span>"</span>:</span> "</span>Property Manager</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>The manager of the property is responsible for furnishing it and ensuring its good condition.</span>"</span>,</span></span>
      "</span>inputs</span>"</span>:</span> [</span>]</span></span>
    }</span>,</span></span>
    {</span></span>
      //</span> keccak256("PropertyTenant(uint256)")</span></span>
      "</span>id</span>"</span>:</span> "</span>0x17dfc8ea82661b71bd62ce0bd9db3858dd8f3e8ab9799d6ab468ec64f1be21a5</span>"</span>,</span></span>
      "</span>name</span>"</span>:</span> "</span>Property Tenant</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>The tenant of the property is responsible for paying the rent and keeping the property in good condition.</span>"</span>,</span></span>
      "</span>inputs</span>"</span>:</span> [</span></span>
        {</span></span>
          "</span>name</span>"</span>:</span> "</span>rent</span>"</span>,</span></span>
          "</span>type</span>"</span>:</span> "</span>uint256</span>"</span></span>
        }</span></span>
      ]</span></span>
    }</span></span>
  ]</span></span>
  </span></span>
}</span></span></code></pre>
The roles</code> array properties are SUGGESTED, and developers should add any other relevant information as necessary (e.g.,
an image for the role). It's also important to highlight the importance of the inputs</code> property. This field describes
the parameters that should be encoded and passed to the grantRole</code> function. It's RECOMMENDED to use the properties
type</code> and components</code> defined on the Solidity ABI Specification, where type</code> is the canonical type of the parameter,
and components</code> is used for complex tuple types.</p>
Caveats</h3>

Compliant contracts MUST implement the IERC7432</code> interface.</li>
A role is represented by a bytes32</code>, and it's RECOMMENDED to use the keccak256</code> of the role's name with its inputs:
bytes32 roleId = keccak256("RoleName(input_type)")</code>.</li>
The grantRole</code> function MUST revert if the expirationDate</code> is in the past or if the msg.sender</code> is not approved to
grant roles on behalf of the NFT owner. It MAY be implemented as public</code> or external</code>.</li>
In addition to emitting the RoleGranted</code> event, the grantRole</code> function MUST emit a TokenLocked</code> event if the token
is frozen or transferred to an escrow account.</li>
The revokeRole</code> function MUST revert if the msg.sender</code> is not approved to revoke roles on behalf of the original
NFT owner or the recipient</code>. It MAY be implemented as public</code> or external</code>.</li>
If revocable</code> is false, only the recipient</code> can revoke the role. If revocable</code> is true, both the recipient</code> and
the original NFT owner can revoke the role.</li>
The unlockToken</code> function MUST revert if the msg.sender</code> is not approved, or if there is at least one non-revocable
role not expired. It MAY be implemented as public</code> or external</code>.</li>
The setRoleApprovalForAll</code> function MAY be implemented as public</code> or external</code>.</li>
The ownerOf</code> function MAY be implemented as pure</code> or view</code>, and MUST return the address of the original owner of
the NFT.</li>
The recipientOf</code> function MAY be implemented as pure</code> or view</code>, and MUST return the address of the account that
received the role.</li>
The roleData</code> function MAY be implemented as pure</code> or view</code>, and MUST return the encoded data passed to the
grantRole</code> function.</li>
The roleExpirationDate</code> function MAY be implemented as pure</code> or view</code>, and MUST return the expiration date of a
given role.</li>
The isRoleRevocable</code> function MAY be implemented as pure</code> or view</code>, and MUST return whether the role is revocable.</li>
The isRoleApprovedForAll</code> function MAY be implemented as pure</code> or view</code>, and SHOULD only return true</code> if the
_operator</code> is approved to grant and revoke roles on behalf of the original NFT owner.</li>
Compliant contracts SHOULD implement ERC-165</a>.</li>
</ul>
Rationale</h2>
ERC-7432</a> IS NOT an extension of ERC-721</a>. The main reason behind this decision is to
enable it to be implemented externally or on the same contract as the NFT, allowing dApps to implement roles with
immutable assets. This standard covers many crucial features, such as automatic expiration and custom data, but perhaps
the most important one is its flexibility in implementation. ERC-7432 can be implemented in many ways, and for this
reason, the neutral term "lock" is employed. This term can refer to an NFT being frozen (preventing transfers until
roles expire) or deposited in an escrow contract. Developers should decide which implementation to use based on their
use cases.</p>
Automatic Expiration</h3>
Automatic expiration is implemented via the grantRole</code> and roleExpirationDate</code> functions. grantRole</code> is responsible
for setting the expiration date, and roleExpirationDate</code> allow developers to check whether the role is expired. Since
uint256</code> is not natively supported by most programming languages, dates are represented as uint64</code> on this standard.
The maximum UNIX timestamp represented by a uint64</code> is about the year 584,942,417,355</code>, which should be enough to be
considered "permanent". For this reason, it's recommended using type(uint64).max</code> to support use cases that require a
role never to expire.</p>
Revocable Roles</h3>
In certain scenarios, the original owner of the NFT may need to revoke a role before its expiration date, while in
others, the recipient may require assurance that the role cannot be revoked. The revocable</code> parameter was introduced
to the grantRole</code> function to specify whether a role can be revoked prematurely, enabling the standard to
support both use cases.</p>
Regardless of the value of revocable</code>, it's recommended always to enable the recipient</code> to revoke roles, allowing them
to eliminate undesirable assignments.</p>
Custom Data</h3>
DApps can customize roles using the data</code> parameter of the grantRole</code> function. data</code> is implemented using the
generic type bytes</code> to enable dApps to encode any role-specific information when granting a role. The custom
data is retrievable using the roleData</code> function and is emitted with the RoleGranted</code> event. With this approach,
developers can integrate this information into their applications, both on-chain and off-chain.</p>
Role Approval</h3>
Similar to ERC-721</a>, this standard enable other accounts to manage roles on behalf of the NFT owner. This
functionality was introduced to allow third-parties to interact with ERC-7432 without requiring NFT ownership. Compliant
contracts MUST implement the functions setRoleApprovalForAll</code> and isRoleApprovedForAll</code> to deliver this feature.</p>
Backwards Compatibility</h2>
On all functions and events, the standard requires both the tokenAddress</code> and tokenId</code> to be provided. This
requirement enables dApps to use a standalone ERC-7432</a> contract as the authoritative source for the
roles of immutable NFTs.</p>
Reference Implementation</h2>
See ERC-7432.sol</a>.</p>
Security Considerations</h2>
Developers integrating the Non-Fungible Token Roles interface should consider the following on their implementations:</p>

Ensure proper access controls are in place to prevent unauthorized role assignments or revocations.</li>
Take into account potential attack vectors such as reentrancy and ensure appropriate safeguards are in place.</li>
Approved accounts should be able to manage roles on behalf of another user. However, ensure that the NFT can
only be transferred to an escrow contract, and back to its original owner (not to the approved account).</li>
Always check the expiration date before allowing users to access the utility of an NFT.</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


ERC/EIP Repository split
2023-07-13T00:00:00+00:00
Abstract</h2>
Describes the motivation and rational for splitting the EIP repositories into an
EIP repository, targeting core ethereum changes and an ERC repository, targeting
application layer specifications.</p>
Motivation</h2>
Long ago when the EIPs repository was created, there was a vision of a single
home for all standards related to Ethereum. The community was small and most
people were interacting at every level of the ecosystem. It made sense to
combine application standards with core consensus changes.</p>
Since then, the ecosystem has grown. Today, the chasm between application
development and core development is wide. Fewer people are involved across the
ecosystem (for better or worse); yet the repository remains unified.</p>
For years, we've considered separating the repository. This would allow ERC and
EIP specifications to evolve more naturally due to the independence. But it's
always difficult to reach critical threshold to make a change like this happen.
Each time we get lost in the details of the migration and the debate grinds
progress to a halt.</p>
Now that the Consensus Layer is also utilizing the EIP process, the cracks are
becoming more visible. There are changes we could make to the process that might
benefit them more, but because we also need to ensure the quality of ERCs, we
are restricted.</p>
There are also many more efforts to catalyze applications around the ERC
process. Attempts have been made to develop working groups and review groups for
certain ERC "categories" (a distinction that doesn't even technically exist
because of the unified repo).</p>
Specification</h2>
This specification only details with the initial mechanism of the split. The
particulars of how each repository will govern itself is out of scope for this
EIP, as it is the motivating point of this EIP that the divergent needs of the
community will require highly divergent methods.</p>

All ERCs and Interface-category EIPs are removed from this repository and
migrated to a new repo. The history should be intact so that repo should be
forked of this one with the non-ERCs removed.</li>
The new ERCs repository goes live and includes the changes from the script.</li>
Setup ercs.ethereum.org subdomain and update the CI to point to the ERCs
repo.</li>
Set up a redirect for ERCs on eips.ethereum.org to go to the new website.</li>
Create a unified document for editors to assign EIP/ERC numbers. EIPs and
ERCs will no longer be based on an initial PR number but on a number
incremented by the EIP editors of their respective repositories. EIPs will be
assigned even numbers and ERCs will be assigned odd numbers. The exact timing
of this migration is a policy decision of the editors.</li>
</ol>
The EIP repository will be associated with core protocol changes, specifically
the kind that would be discussed in one of the AllCoreDevs calls; whereas the
ERC repository will be affiliated with all remaining areas such as smart
contract application interfaces, wallet standards, DeFi protocol standards, and
all other such improvements that do not require core protocol changes.</p>
This association is to persist across any other process changes the EIP editors
may introduce such as working groups, topic groups, expert groups, special
interest groups, splitting of the process, or other such changes. Any
sub-groupings that includes core protocol changes would be associated with the
EIP repository and other sub-groupings are associated with the ERC repository.
Any such process change are out of scope of this EIP and are independent of the
structural changes to the repositories specified in this EIP.</p>
There may be further structural changes to repository layouts to accommodate
more sub-groupings. Such proposals are out of scope of this EIP.</p>
Rationale</h2>
There are two major communities served by the EIP process that are highly
divergent and very differentiated in their needs.</p>
Let's consider the impact of specification ambiguity, the impacts are different
based on the community. The core protocol community has a low tolerance for
difference of implementation and a high penalty for specification ambiguity. An
improperly implemented part of a new spec could cause the ethereum mainnet to
split, possibly costing millions to billions of value lost to node operators as
well as community members using the services offered by the Ethereum protocols.
A poorly specified solidity interface, however, can be adapted and implemented
in multiple compatible ways across any smart choosing to implement it. A missing
RPC API (such as a configuration option specifying the number of decimals in the
chains native currency) can have limited to zero impact on the rest of the
community not choosing to use that wallet.</p>
Timeframe for delivery of a feature is also similarly differentiated. A Core
protocol EIP adjusting the gas cost for transaction data needs to be rolled out
at a specific time uniformly across the network. Whereas a new RPC to support
new semantics to gas estimation would not need uniform rollout across the
Ethereum clients, and in fact would also need to be rolled out by service
provides that provide RPC services for Ethereum networks. Wallets can use early
support as a differentiating factor in their appeal to community members.</p>
To address this divergence the AllCoreDevs call has adopted a lifecycle for EIPs
different from the Draft -> Review -> Last Call -> Final lifecycle of the EIP
repository. It would best be described as Draft -> Eligible for Inclusion ->
Considered for Inclusion -> Testnet -> Mainnet. The EIPs also get slotted for a
fork in the third step, a consideration that simply does not apply to a smart
contract or wallet standard.</p>
Several alternatives have been proposed, but the actual implementation only
further underscores the specialization that each side of the split encounters.</p>
Alternative: Working Groups</h3>
One repeated concern of editors is that they often lack the technical experience
to adequately judge if an EIP is complete and sound. Considering that EIPs
covers wide variety of topics such as elliptic curve cryptography, VM
performance, DeFi market dynamics, compression protocols, NFT Royalties, and
consensus protocols it is impossible for a single editor to provide sensible
feedback on every one of those topics.</p>
When examining how the core protocol and ERC communities would approach the
working group process, however, it underscores how different they would handle
it. For core protocol change the working group would be one of the two
AllCoreDevs meetings, either AllCoreDevs-Execution or AllCoreDevs-Consensus. And
sometimes both. There is no EIP that would be shipped in mainnet that would not
first be extensively considered by one of these two groups.</p>
ERC proposals have no such standing groups. Wallet impacting changes may go
through the AllWalletDevs group, but it is entirely possible for a wallet or
group of wallets to collaborate on a protocol outside AllWalletDevs. Smart
contract APIs have no such standing meeting.</p>
The Working Group model, however, would be a critical social signal for the ERC
community. It would signal a critical mass for a particular proposal issue if
enough experts could get together to agree to review a set of changes.</p>
While working groups are excellent for the ERC community, it is overhead for the
core protocol community that would only add friction to an already established
process with know governance checkpoints.</p>
Alternative: Specialized Editors</h3>
This alternative has already been implemented with the introduction of the
eip-editors.yml</code> file. This allows for different groups of editors to review
different types of EIPs.</p>
There has been no measurable impact on the divergence of the community. Most
categories have a significant overlap with other categories.</p>
This alternative does not address the governance and workflow issues that the
Core Protocol Developers would want to implement. All subgroups would still be
subject to the same workflow as other groups.</p>
Alternative: Pain unrelated to process divergences</h3>
This is a catch-all for a number of proposals, from allowing discord links in
discussion-to to allowing more freedom in external links.</p>
While the theory that this may reduce the total amount of pain felt by users and
editors, bringing the pain level down to a more acceptable level, this does not
address the core divergence issue. Many of these pain relief proposals should
probably be done anyway, weather or not the EIP repository splits.</p>
Alternative: Replace EIP Editors with AI Chatbots</h3>
Nobody wins in this proposal. We would instead end up debating training sets,
competing implementations, and whether to use commercial providers. And
that's if things go well.</p>
AI chatbots, however, would not be able to compartmentalize the divergent needs
of the multiple groups if all adjudication were to be handled with one model or
one chat session. Higher quality output would be received if separate training
repositories were used for each major functional area.</p>
Alternatives are not Mutually Exclusive</h3>
It is critical to note that most of the discussed alternatives all have merits
and address important pain points. The adoption of a split should not be viewed
as a rejection of those alternatives. To quote a famous internet meme "Why Not
Both?"</p>
Objection: This splits the ethereum community</h3>
One objection is that splitting the repository would result in the community no
longer being able to say "we are all of us Ethereum Magicians."</p>
First it is important to note that such splits are already occurring. The
AllCoreDevs call has split into a Consensus and Execution layer call. ACD calls
no longer discuss client issues like wallet apis, the AllWalletDevs call has
adopted those issues and has grown into user experience issues. Cross chain
issues have been adopted by the Chain Agnostic Improvement Process (CAIP) group.</p>
Rather than splitting this should be viewed as "sharding", where a sub-community
of interest rallies around a shared sub issue, and by gathering are able to
increase the total scope of the community. CAIP is a perfect example where
operating separate from EIPs have allowed them to strengthen the ethereum
community.</p>
Is a single cell organism weakened when it grows large and then splits into two?
Is an animal weakened when cells split and specialize into different tasks? It
is this very act of division and specialization that allows it to accomplish the
things that would be impossible as a single uniform cell.</p>
Objection: This should be an  EIP-1</a> proposal</h3>
Since this is directly impacting the ERC process it should be documented
in  EIP-1</a> first.</p>
As the old programming adage goes: "Refactor first before adding any new
features."  Adding new processes specific to the post-split governing docs would
only confuse the existing process, adding special cases for one class of EIPs
that don't apply to another. It is precisely this kind of problem the proposed
split is aiming to change.</p>
This is also valid grounds for a Meta category EIP, as how many and which
repository to put a proposal in is core to the "procedures, guidelines, [and]
changes to the decision-making process".</p>
Some process changes that can be expected in a Core Protocol EIP may include:</p>

Changing the work flow to add the Eligible for Inclusion/Considered for
Inclusion stages to a pre-last-call EIP.</li>
Adding test net and mainnet steps to the lifecycle</li>
Adding a "fork" header to the RFCs section, for EIPs that are (or will be)
implemented in a specific fork</li>
Changing the testing section to a header link to reference tests</li>
</ul>
Some process change ERC may want to adopt:</p>

A strong working group model and adding an optional "forming working group"
step editors may require.</li>
Add an "outdated" or "replaced" lifecycle step for EIPs that are abrogated by
future specs.</li>
Deputize single-eip reviewers for specific EIPs</li>
</ul>
Objection: Structural changes to a repository and process changes do not need to be bundled.</h3>
It is possible to split the structure of the repositories separately from any
EIP process changes related to this. Bundling the changes is unnecessary and
such structure and process changes should be handled independently.</p>
To accommodate this objection this EIP has been revised to only address
structural changes in the repository and can be adapted to any other,
independent, process changes and mapped onto those outcomes.</p>
Backwards Compatibility</h2>
Old Links</h3>
Old ERC links pointing to the old url https://eips.ethereum.org/</code> will continue
to work. Redirect instructions will be put into place to redirect to the new ERC
repos for their corresponding location.</p>
Stray Proposals</h3>
ERC community members may continue to post new ERCs in the EIP proposal. Editors
will be able to redirect them to the new repository. ERCs that do not respond to
editor requests would not be merged anyway.</p>
Security Considerations</h2>
This proposal only addresses the EIP and ERC proposal process and is not
expected to expose any new attack surfaces by virtue of its adoption.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Increase the MAX_EFFECTIVE_BALANCE
2023-06-28T00:00:00+00:00
Abstract</h2>
Increases the constant MAX_EFFECTIVE_BALANCE</code>, while keeping the minimum staking balance 32 ETH</code>. This permits large node operators to consolidate into fewer validators while also allowing solo-stakers to earn compounding rewards and stake in more flexible increments.</p>
Motivation</h2>
As of October 3, 2023, there are currently over 830,000 validators participating in the consensus layer. The size of this set continues to grow due, in part, to the MAX_EFFECTIVE_BALANCE</code>, which limits the stake of a single validator to 32 ETH</code>. This leads to large amounts of "redundant validators", which are controlled by a single entity, possibly running on the same beacon node, but with distinct BLS signing keys. The limit on the MAX_EFFECTIVE_BALANCE</code> is technical debt from the original sharding design, in which subcommittees (not the attesting committee but the committee calculated in is_aggregator</code>) needed to be majority honest. As a result, keeping the weights of subcommittee members approximately equal reduced the risk of a single large validator containing too much influence. Under the current design, these subcommittees are only used for attestation aggregation, and thus only have a 1/N</code> honesty assumption.</p>
With the security model of the protocol no longer dependent on a low value for MAX_EFFECTIVE_BALANCE</code>, we propose raising this value while keeping the minimum validator threshold of 32 ETH</code>. This increase aims to reduce the validator set size, thereby reducing the number of P2P messages over the network, the number of BLS signatures that need to be aggregated each epoch, and the BeaconState</code> memory footprint. This change adds value for both small and large validators. Large validators can consolidate to run fewer validators and thus fewer beacon nodes. Small validators now benefit from compounding rewards and the ability to stake in more flexible increments (e.g., the ability to stake 40 ETH</code> instead of needing to accumulate 64 ETH</code> to run two validators today).</p>
Specification</h2>
Constants</h3>
Execution layer</h4>
Name</th> Value</th> Comment</th></tr></thead>

CONSOLIDATION_REQUEST_TYPE</code></td> 0x02</code></td> The EIP-7685</a> type prefix for consolidation request</td></tr>
CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code></td> 0x0000BBdDc7CE488642fb579F8B00f3a590007251</code></td> Where to call and store relevant details about consolidation request mechanism</td></tr>
SYSTEM_ADDRESS</code></td> 0xfffffffffffffffffffffffffffffffffffffffe</code></td> Address used to invoke system operation on contract</td></tr>
EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</code></td> 0</code></td> </td></tr>
CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</code></td> 1</code></td> </td></tr>
CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</code></td> 2</code></td> Pointer to the head of the consolidation request message queue</td></tr>
CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</code></td> 3</code></td> Pointer to the tail of the consolidation request message queue</td></tr>
CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET</code></td> 4</code></td> The start memory slot of the in-state consolidation request message queue</td></tr>
MAX_CONSOLIDATION_REQUESTS_PER_BLOCK</code></td> 2</code></td> Maximum number of consolidation requests that can be dequeued into a block</td></tr>
TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</code></td> 1</code></td> </td></tr>
MIN_CONSOLIDATION_REQUEST_FEE</code></td> 1</code></td> </td></tr>
CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION</code></td> 17</code></td> </td></tr>
EXCESS_INHIBITOR</code></td> 2**256-1</code></td> Excess value used to compute the fee before the first system call</td></tr>
</tbody></table>
Consensus layer</h4>
Name</th> Value</th></tr></thead>

COMPOUNDING_WITHDRAWAL_PREFIX</code></td> Bytes1('0x02')</code></td></tr>
MIN_ACTIVATION_BALANCE</code></td> Gwei(2**5 * 10**9)</code>  (32 ETH)</td></tr>
MAX_EFFECTIVE_BALANCE_ELECTRA</code></td> Gwei(2**11 * 10**9)</code> (2048 ETH)</td></tr>
</tbody></table>
Execution layer</h3>
Consolidation request</h4>
The new consolidation request is an EIP-7685</a> request with type 0x02</code> consisting of the following fields:</p>

source_address</code>: Bytes20</code></li>
source_pubkey</code>: Bytes48</code></li>
target_pubkey</code>: Bytes48</code></li>
</ol>
The EIP-7685</a> encoding of a consolidation request is as follows. Note we simply return the encoded request value as returned by the contract.</p>
request_type</span> =</span> CONSOLIDATION_REQUEST_TYPE</span></span>
request_data</span> =</span> dequeue_consolidation_requests</span>(</span>)</span></span></code></pre>Consolidation request contract</h4>
The contract has three different code paths, which can be summarized at a high level as follows:</p>

Add consolidation request - requires a 96</code> byte input, concatenated public keys of the source and the target validators.</li>
Fee getter - if the input length is zero, return the current fee required to add a consolidation request.</li>
System process - if called by system address, pop off the consolidation requests for the current block from the queue.</li>
</ol>
Add Consolidation Request</h5>
If call data input to the contract is exactly 96</code> bytes, perform the following:</p>

Ensure enough ETH was sent to cover the current consolidation request fee (msg.value >= get_fee()</code>)</li>
Increase consolidation request count by 1</code> for the current block (increment_count()</code>)</li>
Insert a consolidation request into the queue for the source address and pubkeys of the source and the target (insert_consolidation_request_into_queue()</code>)</li>
</ol>
Specifically, the functionality is defined in pseudocode as the function add_consolidation_request()</code>:</p>
def</span> add_consolidation_request</span>(</span>Bytes48</span>:</span> source_pubkey</span>,</span> Bytes48</span>:</span> target_pubkey</span>)</span>:</span></span>
    """</span></span>
    Add consolidation request adds new request to the consolidation request queue, so long as a sufficient fee is provided.</span></span>
    """</span></span>
</span>
    #</span> Verify sufficient fee was provided.</span></span>
    fee</span> =</span> get_fee</span>(</span>)</span></span>
    require</span>(</span>msg</span>.</span>value</span> >=</span> fee</span>,</span> '</span>Insufficient value for fee</span>'</span>)</span></span>
</span>
    #</span> Increment consolidation request count.</span></span>
    count</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span>)</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span>,</span> count</span> +</span> 1</span>)</span></span>
</span>
    #</span> Insert into queue.</span></span>
    queue_tail_index</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span>)</span></span>
    queue_storage_slot</span> =</span> CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET</span> +</span> queue_tail_index</span> *</span> 4</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span>,</span> msg</span>.</span>sender</span>)</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 1</span>,</span> source_pubkey</span>[</span>0</span>:</span>32</span>]</span>)</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 2</span>,</span> source_pubkey</span>[</span>32</span>:</span>48</span>]</span> ++</span> target_pubkey</span>[</span>0</span>:</span>16</span>]</span>)</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 3</span>,</span> target_pubkey</span>[</span>16</span>:</span>48</span>]</span>)</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span>,</span> queue_tail_index</span> +</span> 1</span>)</span></span></code></pre>Fee calculation</h6>
The following pseudocode can compute the cost of an individual consolidation request, given a certain number of excess consolidation requests.</p>
def</span> get_fee</span>(</span>)</span> -></span> int</span>:</span></span>
    excess</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</span>)</span></span>
    require</span>(</span>excess</span> !=</span> EXCESS_INHIBITOR</span>,</span> '</span>Inhibitor still active</span>'</span>)</span></span>
    return</span> fake_exponential</span>(</span></span>
        MIN_CONSOLIDATION_REQUEST_FEE</span>,</span></span>
        excess</span>,</span></span>
        CONSOLIDATION_REQUEST_FEE_UPDATE_FRACTION</span></span>
    )</span></span>
</span>
def</span> fake_exponential</span>(</span>factor</span>:</span> int</span>,</span> numerator</span>:</span> int</span>,</span> denominator</span>:</span> int</span>)</span> -></span> int</span>:</span></span>
    i</span> =</span> 1</span></span>
    output</span> =</span> 0</span></span>
    numerator_accum</span> =</span> factor</span> *</span> denominator</span></span>
    while</span> numerator_accum</span> ></span> 0</span>:</span></span>
        output</span> +=</span> numerator_accum</span></span>
        numerator_accum</span> =</span> (</span>numerator_accum</span> *</span> numerator</span>)</span> //</span> (</span>denominator</span> *</span> i</span>)</span></span>
        i</span> +=</span> 1</span></span>
    return</span> output</span> //</span> denominator</span></span></code></pre>Fee Getter</h5>
When the input to the contract is length zero, interpret this as a get request for the current fee, i.e. the contract returns the result of get_fee()</code>.</p>
System Call</h5>
At the end of processing any execution block where this EIP is active (i.e. after processing all transactions and after performing the block body consolidation requests validations), call the contract at CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code> as SYSTEM_ADDRESS</code> with no calldata. The invocation triggers the following:</p>

The contract's queue is updated based on consolidation requests dequeued and the consolidation requests queue head/tail are reset if the queue has been cleared (dequeue_consolidation_requests()</code>)</li>
The contract's excess consolidation requests are updated based on usage in the current block (update_excess_consolidation_requests()</code>)</li>
The contract's consolidation requests count is reset to 0</code> (reset_consolidation_requests_count()</code>)</li>
</ul>
Each consolidation request must appear in the EIP-7685 requests list in the exact order returned by dequeue_consolidation_requests()</code>.</p>
Additionally, the system call and the processing of that block must conform to the following:</p>

The call has a dedicated gas limit of 30_000_000</code>.</li>
Gas consumed by this call does not count against the block’s overall gas usage.</li>
Both the gas limit assigned to the call and the gas consumed are excluded from any checks against the block’s gas limit.</li>
The call does not follow EIP-1559</a> fee burn semantics — no value should be transferred as part of this call.</li>
If there is no code at CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code>, the corresponding block MUST</strong> be marked invalid.</li>
If the call to the contract fails or returns an error, the block MUST</strong> be invalidated.</li>
</ul>
The functionality triggered by the system call is defined in pseudocode as the function process_consolidation_requests()</code>:</p>
#</span>##################</span></span>
#</span> Public function #</span></span>
#</span>##################</span></span>
</span>
def</span> process_consolidation_requests</span>(</span>)</span>:</span></span>
    reqs</span> =</span> dequeue_consolidation_requests</span>(</span>)</span></span>
    update_excess_consolidation_requests</span>(</span>)</span></span>
    reset_consolidation_requests_count</span>(</span>)</span></span>
    return</span> ssz</span>.</span>serialize</span>(</span>reqs</span>)</span></span>
</span>
#</span>##########</span></span>
#</span> Helpers #</span></span>
#</span>##########</span></span>
</span>
class</span> ConsolidationRequest</span>(</span>object</span>)</span>:</span></span>
    source_address</span>:</span> Bytes20</span></span>
    source_pubkey</span>:</span> Bytes48</span></span>
    target_pubkey</span>:</span> Bytes48</span></span>
</span>
def</span> dequeue_consolidation_requests</span>(</span>)</span>:</span></span>
    queue_head_index</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span>)</span></span>
    queue_tail_index</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span>)</span></span>
    num_in_queue</span> =</span> queue_tail_index</span> -</span> queue_head_index</span></span>
    num_dequeued</span> =</span> min</span>(</span>num_in_queue</span>,</span> MAX_CONSOLIDATION_REQUESTS_PER_BLOCK</span>)</span></span>
</span>
    reqs</span> =</span> [</span>]</span></span>
    for</span> i</span> in</span> range</span>(</span>num_dequeued</span>)</span>:</span></span>
        queue_storage_slot</span> =</span> CONSOLIDATION_REQUEST_QUEUE_STORAGE_OFFSET</span> +</span> (</span>queue_head_index</span> +</span> i</span>)</span> *</span> 4</span></span>
        source_address</span> =</span> address</span>(</span>sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span>)</span>[</span>0</span>:</span>20</span>]</span>)</span></span>
        source_pubkey</span> =</span> (</span></span>
            sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 1</span>)</span>[</span>0</span>:</span>32</span>]</span> +</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 2</span>)</span>[</span>0</span>:</span>16</span>]</span></span>
        )</span></span>
        target_pubkey</span> =</span> (</span></span>
            sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 2</span>)</span>[</span>16</span>:</span>32</span>]</span> +</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> queue_storage_slot</span> +</span> 3</span>)</span>[</span>0</span>:</span>32</span>]</span></span>
        )</span></span>
        req</span> =</span> ConsolidationRequest</span>(</span></span>
            source_address</span>=</span>Bytes20</span>(</span>source_address</span>)</span>,</span></span>
            source_pubkey</span>=</span>Bytes48</span>(</span>source_pubkey</span>)</span>,</span></span>
            target_pubkey</span>=</span>Bytes48</span>(</span>target_pubkey</span>)</span></span>
        )</span></span>
        reqs</span>.</span>append</span>(</span>req</span>)</span></span>
</span>
    new_queue_head_index</span> =</span> queue_head_index</span> +</span> num_dequeued</span></span>
    if</span> new_queue_head_index</span> ==</span> queue_tail_index</span>:</span></span>
        #</span> Queue is empty, reset queue pointers</span></span>
        sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span>,</span> 0</span>)</span></span>
        sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_TAIL_STORAGE_SLOT</span>,</span> 0</span>)</span></span>
    else</span>:</span></span>
        sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_QUEUE_HEAD_STORAGE_SLOT</span>,</span> new_queue_head_index</span>)</span></span>
</span>
    return</span> reqs</span></span>
</span>
def</span> update_excess_consolidation_requests</span>(</span>)</span>:</span></span>
    previous_excess</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</span>)</span></span>
    #</span> Check if excess needs to be reset to 0 for first iteration after activation</span></span>
    if</span> previous_excess</span> ==</span> EXCESS_INHIBITOR</span>:</span></span>
        previous_excess</span> =</span> 0</span></span>
</span>
    count</span> =</span> sload</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span>)</span></span>
</span>
    new_excess</span> =</span> 0</span></span>
    if</span> previous_excess</span> +</span> count</span> ></span> TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</span>:</span></span>
        new_excess</span> =</span> previous_excess</span> +</span> count</span> -</span> TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</span></span>
</span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> EXCESS_CONSOLIDATION_REQUESTS_STORAGE_SLOT</span>,</span> new_excess</span>)</span></span>
</span>
def</span> reset_consolidation_requests_count</span>(</span>)</span>:</span></span>
    sstore</span>(</span>CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</span>,</span> CONSOLIDATION_REQUEST_COUNT_STORAGE_SLOT</span>,</span> 0</span>)</span></span></code></pre>Bytecode</h5>
caller</span></span>
push20 </span>0xfffffffffffffffffffffffffffffffffffffffe</span></span>
eq</span></span>
push1 </span>0xd3</span></span>
jumpi</span></span>
</span>
push1 </span>0x11</span></span>
push0</span></span>
sload</span></span>
dup1</span></span>
push32 </span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span>
eq</span></span>
push2</span> 0x019a</span></span>
jumpi</span></span>
</span>
push1 </span>0x01</span></span>
dup3</span></span>
mul</span></span>
push1 </span>0x01</span></span>
swap1</span></span>
push0</span></span>
</span>
jumpdest</span></span>
push0</span></span>
dup3</span></span>
gt</span></span>
iszero</span></span>
push1 </span>0x68</span></span>
jumpi</span></span>
</span>
dup2</span></span>
add</span></span>
swap1</span></span>
dup4</span></span>
mul</span></span>
dup5</span></span>
dup4</span></span>
mul</span></span>
swap1</span></span>
div</span></span>
swap2</span></span>
push1 </span>0x01</span></span>
add</span></span>
swap2</span></span>
swap1</span></span>
push1 </span>0x4d</span></span>
jump</span></span>
</span>
jumpdest</span></span>
swap1</span></span>
swap4</span></span>
swap1</span></span>
div</span></span>
swap3</span></span>
pop</span></span>
pop</span></span>
pop</span></span>
calldatasize</span></span>
push1 </span>0x60</span></span>
eq</span></span>
push1 </span>0x88</span></span>
jumpi</span></span>
</span>
calldatasize</span></span>
push2</span> 0x019a</span></span>
jumpi</span></span>
</span>
callvalue</span></span>
push2</span> 0x019a</span></span>
jumpi</span></span>
</span>
push0</span></span>
mstore</span></span>
push1 </span>0x20</span></span>
push0</span></span>
return</span></span>
</span>
jumpdest</span></span>
callvalue</span></span>
lt</span></span>
push2</span> 0x019a</span></span>
jumpi</span></span>
</span>
push1 </span>0x01</span></span>
sload</span></span>
push1 </span>0x01</span></span>
add</span></span>
push1 </span>0x01</span></span>
sstore</span></span>
push1 </span>0x03</span></span>
sload</span></span>
dup1</span></span>
push1 </span>0x04</span></span>
mul</span></span>
push1 </span>0x04</span></span>
add</span></span>
caller</span></span>
dup2</span></span>
sstore</span></span>
push1 </span>0x01</span></span>
add</span></span>
push0</span></span>
calldataload</span></span>
dup2</span></span>
sstore</span></span>
push1 </span>0x01</span></span>
add</span></span>
push1 </span>0x20</span></span>
calldataload</span></span>
dup2</span></span>
sstore</span></span>
push1 </span>0x01</span></span>
add</span></span>
push1 </span>0x40</span></span>
calldataload</span></span>
swap1</span></span>
sstore</span></span>
caller</span></span>
push1 </span>0x60</span></span>
shl</span></span>
push0</span></span>
mstore</span></span>
push1 </span>0x60</span></span>
push0</span></span>
push1 </span>0x14</span></span>
calldatacopy</span></span>
push1 </span>0x74</span></span>
push0</span></span>
log0</span></span>
push1 </span>0x01</span></span>
add</span></span>
push1 </span>0x03</span></span>
sstore</span></span>
stop</span></span>
</span>
jumpdest</span></span>
push1 </span>0x03</span></span>
sload</span></span>
push1 </span>0x02</span></span>
sload</span></span>
dup1</span></span>
dup3</span></span>
sub</span></span>
dup1</span></span>
push1 </span>0x02</span></span>
gt</span></span>
push1 </span>0xe7</span></span>
jumpi</span></span>
</span>
pop</span></span>
push1 </span>0x02</span></span>
</span>
jumpdest</span></span>
push0</span></span>
</span>
jumpdest</span></span>
dup2</span></span>
dup2</span></span>
eq</span></span>
push2</span> 0x0129</span></span>
jumpi</span></span>
</span>
dup3</span></span>
dup2</span></span>
add</span></span>
push1 </span>0x04</span></span>
mul</span></span>
push1 </span>0x04</span></span>
add</span></span>
dup2</span></span>
push1 </span>0x74</span></span>
mul</span></span>
dup2</span></span>
sload</span></span>
push1 </span>0x60</span></span>
shl</span></span>
dup2</span></span>
mstore</span></span>
push1 </span>0x14</span></span>
add</span></span>
dup2</span></span>
push1 </span>0x01</span></span>
add</span></span>
sload</span></span>
dup2</span></span>
mstore</span></span>
push1 </span>0x20</span></span>
add</span></span>
dup2</span></span>
push1 </span>0x02</span></span>
add</span></span>
sload</span></span>
dup2</span></span>
mstore</span></span>
push1 </span>0x20</span></span>
add</span></span>
swap1</span></span>
push1 </span>0x03</span></span>
add</span></span>
sload</span></span>
swap1</span></span>
mstore</span></span>
push1 </span>0x01</span></span>
add</span></span>
push1 </span>0xe9</span></span>
jump</span></span>
</span>
jumpdest</span></span>
swap2</span></span>
add</span></span>
dup1</span></span>
swap3</span></span>
eq</span></span>
push2</span> 0x013b</span></span>
jumpi</span></span>
</span>
swap1</span></span>
push1 </span>0x02</span></span>
sstore</span></span>
push2</span> 0x0146</span></span>
jump</span></span>
</span>
jumpdest</span></span>
swap1</span></span>
pop</span></span>
push0</span></span>
push1 </span>0x02</span></span>
sstore</span></span>
push0</span></span>
push1 </span>0x03</span></span>
sstore</span></span>
</span>
jumpdest</span></span>
push0</span></span>
sload</span></span>
dup1</span></span>
push32 </span>0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</span></span>
eq</span></span>
iszero</span></span>
push2</span> 0x0173</span></span>
jumpi</span></span>
</span>
pop</span></span>
push0</span></span>
</span>
jumpdest</span></span>
push1 </span>0x01</span></span>
sload</span></span>
push1 </span>0x01</span></span>
dup3</span></span>
dup3</span></span>
add</span></span>
gt</span></span>
push2</span> 0x0188</span></span>
jumpi</span></span>
</span>
pop</span></span>
pop</span></span>
push0</span></span>
push2</span> 0x018e</span></span>
jump</span></span>
</span>
jumpdest</span></span>
add</span></span>
push1 </span>0x01</span></span>
swap1</span></span>
sub</span></span>
</span>
jumpdest</span></span>
push0</span></span>
sstore</span></span>
push0</span></span>
push1 </span>0x01</span></span>
sstore</span></span>
push1 </span>0x74</span></span>
mul</span></span>
push0</span></span>
return</span></span>
</span>
jumpdest</span></span>
push0</span></span>
push0</span></span>
revert</span></span></code></pre>Deployment</h5>
The consolidation requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:</p>
{</span></span>
  "</span>type</span>"</span>:</span> "</span>0x0</span>"</span>,</span></span>
  "</span>nonce</span>"</span>:</span> "</span>0x0</span>"</span>,</span></span>
  "</span>to</span>"</span>:</span> null</span>,</span></span>
  "</span>gas</span>"</span>:</span> "</span>0x3d090</span>"</span>,</span></span>
  "</span>gasPrice</span>"</span>:</span> "</span>0xe8d4a51000</span>"</span>,</span></span>
  "</span>maxPriorityFeePerGas</span>"</span>:</span> null</span>,</span></span>
  "</span>maxFeePerGas</span>"</span>:</span> null</span>,</span></span>
  "</span>value</span>"</span>:</span> "</span>0x0</span>"</span>,</span></span>
  "</span>input</span>"</span>:</span> "</span>0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5561019e80602d5f395ff33373fffffffffffffffffffffffffffffffffffffffe1460d35760115f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff1461019a57600182026001905f5b5f82111560685781019083028483029004916001019190604d565b9093900492505050366060146088573661019a573461019a575f5260205ff35b341061019a57600154600101600155600354806004026004013381556001015f358155600101602035815560010160403590553360601b5f5260605f60143760745fa0600101600355005b6003546002548082038060021160e7575060025b5f5b8181146101295782810160040260040181607402815460601b815260140181600101548152602001816002015481526020019060030154905260010160e9565b910180921461013b5790600255610146565b90505f6002555f6003555b5f54807fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff141561017357505f5b6001546001828201116101885750505f61018e565b01600190035b5f555f6001556074025ff35b5f5ffd</span>"</span>,</span></span>
  "</span>v</span>"</span>:</span> "</span>0x1b</span>"</span>,</span></span>
  "</span>r</span>"</span>:</span> "</span>0x539</span>"</span>,</span></span>
  "</span>s</span>"</span>:</span> "</span>0xc0730f92dc275b663d377a7cbb141b6600052</span>"</span>,</span></span>
  "</span>hash</span>"</span>:</span> "</span>0x379269d571beff3ed1d8eba3abb24076a7267b0eaf0cc66d728fb0544f5a690d</span>"</span></span>
}</span></span></code></pre>Sender: 0x13d1913d623E6a9D8811736359E50fD31Fe54fCA</span></span>
Address: 0x0000BBdDc7CE488642fb579F8B00f3a590007251</span></span></code></pre>Consensus layer</h3>
The defining features of this EIP are:</p>

Increasing the MAX_EFFECTIVE_BALANCE</code>, while creating a MIN_ACTIVATION_BALANCE</code>.</strong></em> The core feature of allowing variable size validators.</li>
Allowing for multiple validator indices to be combined through the protocol.</strong></em> A mechanism by which large node operators can combine validators without cycling through the exit and activation queues.</li>
Adding execution layer partial withdrawals (part of EIP-7002</a>).</strong></em> Allowing Execution Layer messages to trigger partial withdrawals in addition to full exits (e.g., a 100 ETH</code> validator can remove up to 68 ETH</code> without exiting the validator).</li>
Making the initial slashing penalty negligible.</strong></em> This reduces the risk of consolidation for large validators.</li>
</ol>
The Rationale</a> section contains an explanation for each of these proposed core features. A sketch of the resulting changes to the consensus layer is included below.</p>

Add COMPOUNDING_WITHDRAWAL_PREFIX</code> and MIN_ACTIVATION_BALANCE</code> constants, while introducing the updated value of MAX_EFFECTIVE_BALANCE</code> (MAX_EFFECTIVE_BALANCE_ELECTRA</code>).</li>
Create the PendingDeposit</code> container, which is used to track incoming deposits in the weight-based rate limiting mechanism.</li>
Update the BeaconState</code> with deposit and partial withdrawal queues, fields needed for deposit, and exit queue weight-based rate limiting.</li>
Modify is_eligible_for_activation_queue</code> to check against MIN_ACTIVATION_BALANCE</code> rather than MAX_EFFECTIVE_BALANCE</code>.</li>
Modify get_validator_churn_limit</code> to depend on the validator weight rather than the validator count.</li>
Create a helper compute_exit_epoch_and_update_churn</code> to calculate the exit epoch based on the current pending withdrawals.</li>
Modify initiate_validator_exit</code> to rate limit the exit queue by balance rather than the number of validators.</li>
Modify initialize_beacon_state_from_eth1</code> to use MIN_ACTIVATION_BALANCE</code>.</li>
Modify process_registry_updates</code> to activate all eligible validators.</li>
Add a per-epoch helper, process_pending_deposits</code>, to consume some of the pending deposits.</li>
Modify get_validator_from_deposit</code> to initialize the effective balance to zero (it's updated by the pending deposit flow).</li>
Modify process_deposit</code> to store incoming deposits in state.pending_deposits</code>.</li>
Modify compute_weak_subjectivity_period</code> to use the new churn limit function.</li>
Add has_compounding_withdrawal_credential</code> to check for the 0x02</code> credential.</li>
Modify is_fully_withdrawable_validator</code> to check for compounding credentials.</li>
Add get_validator_excess_balance</code> to calculate the excess balance of validators.</li>
Modify is_partially_withdrawable_validator</code> to check for excess balance.</li>
Modify get_expected_withdrawals</code> to use excess balance and process pending partial withdrawals.</li>
Add process_consolidation</code> to initiate in-protocol validator consolidation and switch a validator to compounding withdrawal credentials.</li>
Limits the usage of exit churn to 256 ETH (equivalent to 8 validators with 32 ETH effective balance), and defers the surplus of the churn to process consolidations.</li>
</ol>
Full consensus layer specification can be found in ./electra/beacon-chain.md</code></a></p>
Rationale</h2>
This EIP aims to reduce the total number of validators without changing anything about the economic security of the protocol. It provides a mechanism by which large node operators who control significant amounts of stake can consolidate into fewer validators. We analyze the reasoning behind each of the core features.</p>
Increasing the MAX_EFFECTIVE_BALANCE</code>, while creating a MIN_ACTIVATION_BALANCE</code></h3>
While increasing the MAX_EFFECTIVE_BALANCE</code> to allow larger-stake validators, it is important to keep the lower bound of 32 ETH</code> (by introducing a new constant – MIN_ACTIVATION_BALANCE</code>) to encourage solo-staking.</p>
Allowing for multiple validator indices to be combined through the protocol</h3>
For large staking pools that already control thousands of validators, exiting and re-entering would be extremely slow and costly. The adoption of the EIP will be much higher by allowing in-protocol consolidation.</p>
Adding execution layer partial withdrawals (part of EIP-7002</a>)</h3>
For validators that choose to raise their effective balance ceiling, allowing for custom partial withdrawals triggered from the execution layer increases the flexibility of the staking configurations. Validators can choose when and how much they withdraw but will have to pay gas for the EL transaction.</p>
Making the initial slashing penalty negligible</h3>
To encourage consolidation, we could modify the slashing penalties. The biggest hit comes from the initial penalty of 1/32</code> of the validator's effective balance. Since this scales linearly on the effective balance, the higher-stake validators directly incur higher risk. By changing the scaling properties, we could make consolidation more attractive.</p>
Consolidation contract parameter values</h3>
The consolidation smart contract uses a fee mechanism to rate limit the number of requests per block. Details of the fee mechanism are available in EIP-7002</a>.</p>
TARGET_CONSOLIDATION_REQUESTS_PER_BLOCK</code> is chosen to be 1</code> to rate limit consolidation requests as much as possible.
MAX_CONSOLIDATION_REQUESTS_PER_BLOCK</code> is chosen to be 2</code> to allow for switching a validator to compounding credentials and requesting a consolidation in the same block.</p>
One consolidation per block is still higher than the size of consolidation churn which can lead to unbounded growth of the consolidation queue.
Thus, there is a hard limit on the consolidation queue size equal to 262,144 requests which is 4 MB</code> of data in the beacon state.</p>
Backwards Compatibility</h2>
This EIP introduces backward incompatible changes to the block validation rule set and must be accompanied by a hard fork. These changes do not break anything related to current user activity and experience.</p>
Security Considerations</h2>
This change modifies committees and churn, but doesn't significantly impact the security properties.</p>
Security of attestation committees</h3>
Given full consolidation as the worst case, the probability of an adversarial takeover of a committee remains low. Even in a high consolidation scenario, the required share of honest validators remains well below the 2/3 supermajority needed for finality.</p>
Aggregator selection</h3>
In the original sharding roadmap, subcommittees were required to be secure with extremely high probability. Now with the sole responsibility of attestation aggregation, we only require each committee to have at least one honest aggregator. Currently, aggregators are selected through a VRF lottery, targeting several validator units that can be biased by non-consolidated attackers. This proposal changes the VRF lottery to consider weight, so the probability of having at least one honest aggregator is not worse.</p>
Proposer selection probability</h3>
Proposer selection is already weighted by the ratio of their effective balance to MAX_EFFECTIVE_BALANCE</code>. Due to the lower probabilities, this change will slightly increase the time it takes to calculate the next proposer index.</p>
Sync committee selection probability</h3>
Sync committee selection is also already weighted by effective balance, so this proposal does not require modifications to the sync protocol. Light clients can still check that a super-majority of participants have signed an update irrespective of their weights since we maintain a weight-based selection probability.</p>
Churn invariants</h3>
This proposal maintains the activation and exit churn invariants limiting active weight instead of validator count. Balance top-ups are now handled explicitly, being subject to the same activation queue as full deposits.</p>
Fee Overpayment</h3>
Calls to the system contract require a fee payment defined by the current contract state. Overpaid fees are not returned to the caller. It is not generally possible to compute the exact required fee amount ahead of time. When adding a consolidation request from a contract, the contract can perform a read operation to check for the current fee and then pay exactly the required amount. Here is an example in Solidity:</p>
function addConsolidation(bytes memory srcPubkey, bytes memory targetPubkey, uint64 requestFeeLimit) private {</span></span>
    assert(srcPubkey.length == 48);</span></span>
    assert(targetPubkey.length == 48);</span></span>
</span>
    // Read current fee from the contract.</span></span>
    (bool readOK, bytes memory feeData) = ConsolidationsContract.staticcall('');</span></span>
    if (!readOK) {</span></span>
        revert('reading fee failed');</span></span>
    }</span></span>
    uint256 fee = uint256(bytes32(feeData));</span></span>
</span>
    // Check the fee is not too high.</span></span>
    if (fee > requestFeeLimit) {</span></span>
        revert('fee is too high');</span></span>
    }</span></span>
</span>
    // Add the request.</span></span>
    bytes memory callData = bytes.concat(srcPubkey, targetPubkey);</span></span>
    (bool writeOK,) = ConsolidationsContract.call{value: fee}(callData);</span></span>
    if (!writeOK) {</span></span>
        revert('adding request failed');</span></span>
    }</span></span>
}</span></span></code></pre>
Note: the system contract uses the EVM CALLER</code> operation (Solidity: msg.sender</code>) to get the address used in the consolidation request, i.e. the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state.</p>
Note: the above code reverts if the fee is too high, the fee can change significantly between the creation of a consolidation request transaction and its inclusion into a block, thus, this check is very important to avoid overpayments.</p>
Using an EOA to request consolidations will always result in overpayment of fees. There is no way for an EOA to use a wrapper contract to request a consolidation. And even if a way existed, the gas cost of returning the overage would likely be higher than the overage itself. If requesting consolidations from an EOA to the system contract is desired, we recommend that users perform transaction simulations to estimate a reasonable fee amount to send.</p>
Consolidation queue hard limit</h3>
Consolidations exceeding the hard limit of the consolidation queue (262,144 requests) will be discarded by the consensus layer and will need to be re-submitted,
note that the fee is not refunded in this case.</p>
System Call failure</h3>
Although the likelihood of a failed system call to CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code> is extremely low, the behavior in such cases is well-defined: the block is marked as invalid. This consideration directly follows from EIP-7002</a></p>
Empty Code failure</h3>
This EIP should not have been activated if there is no code present at CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS</code> (i.e., if the chain is not "ready"). This is also similar to the consideration in EIP-7002</a></p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Identity-aggregated NFT
2023-06-25T00:00:00+00:00
Abstract</h2>
This standard extends ERC-721</a> by binding individuals' Web2 and Web3 identities to non-fungible tokens (NFTs) and soulbound tokens (SBTs). By binding multiple identities, aggregated and composible identity infomation can be verified, resulting in more beneficial onchain scenarios for individuals, such as self-authentication, social overlapping, commercial value generation from user targetting, etc. By adding a custom schema in the metadata, and updating and verifying the schema hash in the contract, the binding of NFT and identity information is completed.</p>
Motivation</h2>
One of the most interesting aspects of Web3 is the ability to bring an individual's own identity to different applications. Even more powerful is the fact that individuals truly own their accounts without relying on centralized gatekeepers, disclosing to different apps components necessary for authentication and approved by individuals.
Exisiting solutions such as ENS, although open, decentralized, and more convenient for Ethereum-based applications, suffer from a lack of data standardization and authentication of identity due to inherent anominity. Other solutions such as SBTs rely on centralized attestors, can not prevent data tampering, and do not inscribe data into the ledger itself in a privacy enabling way.

The proposed pushes the boundaries of solving identity problems with Identity Aggregated NFT, i.e., the individual-authenticated aggregation of web2 and web3 identities to NFTs (SBTs included).</p>
Specification</h2>
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p>
Every compliant contract must implement the Interface</h3>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> ^0.8.15</span>;</span></span>
</span>
interface</span> IERC7231</span> {</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> emit the use binding information</span></span>
     * </span>@param</span> id</span> nft id </span></span>
     * </span>@param</span> identitiesRoot</span> new identity root</span></span>
     */</span></span>
    event</span> SetIdentitiesRoot</span>(</span></span>
        uint256</span> id</span>,</span></span>
        bytes32</span> identitiesRoot</span></span>
    )</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> </span></span>
     * </span>@dev</span> set the user ID binding information of NFT with identitiesRoot</span></span>
     * </span>@param</span> id</span> nft id </span></span>
     * </span>@param</span> identitiesRoot</span> multi UserID Root data hash</span></span>
     * MUST allow external calls</span></span>
     */</span></span>
    function</span> setIdentitiesRoot</span>(</span></span>
        uint256</span> id</span>,</span></span>
        bytes32</span> identitiesRoot</span></span>
    )</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> </span></span>
     * </span>@dev</span> get the multi-userID root by  NFTID</span></span>
     * </span>@param</span> id</span> nft id </span></span>
     * MUST return the bytes32 multiUserIDsRoot</span></span>
     * MUST NOT modify the state</span></span>
     * MUST allow external calls</span></span>
     */</span></span>
    function</span> getIdentitiesRoot</span>(</span></span>
        uint256</span> id</span></span>
    )</span> external</span> returns</span>(</span>bytes32</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> </span></span>
     * </span>@dev</span> verify the userIDs binding </span></span>
    * </span>@param</span> id</span> nft id </span></span>
     * </span>@param</span> userIDs</span> userIDs for check</span></span>
     * </span>@param</span> identitiesRoot</span> msg hash to verify</span></span>
     * </span>@param</span> signature</span> ECDSA signature </span></span>
     * MUST If the verification is passed, return true, otherwise return false</span></span>
     * MUST NOT modify the state</span></span>
     * MUST allow external calls</span></span>
     */</span></span>
    function</span> verifyIdentitiesBinding</span>(</span></span>
        uint256</span> id</span>,</span>address</span> nftOwnerAddress</span>,</span>string</span>[</span>]</span> memory</span> userIDs</span>,</span>bytes32</span> identitiesRoot</span>,</span> bytes</span> calldata</span> signature</span></span>
    )</span> external</span> returns</span> (</span>bool</span>)</span>;</span></span>
}</span></span></code></pre>
This is the “Metadata JSON Schema” referenced above.</p>
{</span></span>
  "</span>title</span>"</span>:</span> "</span>Asset Metadata</span>"</span>,</span></span>
  "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
  "</span>properties</span>"</span>:</span> {</span></span>
    "</span>name</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>Identifies the asset to which this NFT represents</span>"</span></span>
    }</span>,</span></span>
    "</span>description</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>Describes the asset to which this NFT represents</span>"</span></span>
    }</span>,</span></span>
    "</span>image</span>"</span>:</span> {</span></span>
      "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
      "</span>description</span>"</span>:</span> "</span>A URI pointing to a resource with mime type image</span>"</span></span>
    }</span>,</span></span>
    "</span>MultiIdentities</span>"</span>:</span> [</span></span>
      {</span></span>
        "</span>userID</span>"</span>:</span> {</span></span>
          "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
          "</span>description</span>"</span>:</span> "</span>User ID of Web2 and web3(DID)</span>"</span></span>
        }</span>,</span></span>
        "</span>verifierUri</span>"</span>:</span> {</span></span>
          "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
          "</span>description</span>"</span>:</span> "</span>Verifier Uri of the userID</span>"</span></span>
        }</span>,</span></span>
        "</span>memo</span>"</span>:</span> {</span></span>
          "</span>type</span>"</span>:</span> "</span>string</span>"</span>,</span></span>
          "</span>description</span>"</span>:</span> "</span>Memo of the userID</span>"</span></span>
        }</span>,</span></span>
        "</span>properties</span>"</span>:</span> {</span></span>
          "</span>type</span>"</span>:</span> "</span>object</span>"</span>,</span></span>
          "</span>description</span>"</span>:</span> "</span>properties of the user ID information</span>"</span></span>
        }</span></span>
      }</span></span>
    ]</span></span>
  }</span></span>
}</span></span></code></pre>Rationale</h2>
Designing the proposal, we considered the following problems that are solved by this standard:
</p>

Resolve the issue of multiple ID bindings for web2 and web3.
By incorporating the MultiIdentities schema into the metadata file, an authorized bond is established between user identity information and NFTs. This schema encompasses a userID field that can be sourced from a variety of web2 platforms or a decentralized identity (DID) created on blockchain. By binding the NFT ID with the UserIDInfo array, it becomes possible to aggregate multiple identities seamlessly.</li>
Users have full ownership and control of their data
Once the user has set the metadata, they can utilize the setIdentitiesRoot function to establish a secure binding between hashed userIDs objects and NFT ID. As only the user holds the authority to carry out this binding, it can be assured that the data belongs solely to the user.</li>
Verify the binding relationship between data on-chain and off-chain data through signature based on ERC-1271</a>
Through the signature method based on the ERC-1271</a> protocol, the verifyIdentiesBinding function of this EIP realizes the binding of the userID and NFT owner address between on-chain and off-chain.

NFT ownership validation</li>
UserID format validation</li>
IdentitiesRoot Consistency verification</li>
Signature validation from nft owner</li>
</ol>
</li>
</ol>
As for how to verify the authenticity of the individuals' identities, wallets, accounts, there are various methods, such as zk-based DID authentication onchain, and offchain authentication algorithms, such as auth2, openID2, etc.</p>
Backwards Compatibility</h2>
As mentioned in the specifications section, this standard can be fully ERC-721</a> compatible by adding an extension function set.
In addition, new functions introduced in this standard have many similarities with the existing functions in ERC-721</a>. This allows developers to easily adopt the standard quickly.</p>
Test Cases</h2>
Tests are included in erc7231.ts</code></a>.</p>
To run them in terminal, you can use the following commands:</p>
cd ../assets/eip-7231</span></span>
npm install</span></span>
npx hardhat test</span></span></code></pre>Reference Implementation</h2>
ERC7231.sol</code> Implementation: ERC7231.sol</code></a></p>
Security Considerations</h2>
This EIP standard can comprehensively empower individuals to have ownership and control of their identities, wallets, and relevant data by themselves adding or removing the NFTs and identity bound information.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Purpose bound money
2023-06-24T00:00:00+00:00
Abstract</h2>
A Purpose Bound Money (PBM) token is a wrapper around an ERC-1155</a> token that can be used for a limited activity. This proposal outlines a smart contract interface that builds upon the ERC-1155 standard to implement the purpose bound money (PBM) concept:</p>

A PBM consists of a PBM wrapper and the digital money token it wraps. A digital money token (e.g., stablecoins, central bank digital currencies, tokenized bank deposits, and similar instruments) serves as a store of value (abbreviated as "sov"). Thus, a digital money token (also referred to as "sovToken") SHOULD</strong> be:

a good store of value;</li>
a suitable unit of account; and</li>
a medium of exchange.</li>
</ul>
</li>
PBMs are bearer instruments, with self-contained programming logic, and can be transferred between two parties without involving intermediaries. It combines the concept of:

programmable payment - automatic execution of payments once a pre-defined set of conditions are met; and</li>
programmable money - the possibility of embedding rules within the medium of exchange itself that define or constrain its usage.</li>
</ul>
</li>
Once the conditions are met, sovToken is released, and it becomes unbounded once again. A PBM can be thought of as a digital cash voucher, because it places constraints on how a payer can use the PBM but does not impose any constraints on the merchant/redeemer because the PBM unwraps and releases the underlying digital money upon payment to the merchant/redeemer. This is akin to a physical cash voucher: the payer is restricted to purchases from the merchants specified by the issuer but the merchants accepting the vouchers can exchange the physical vouchers with the issuer for fiat money.</li>
</ul>
In this EIP, we propose a modular structure consisting of a sovToken compatible with ERC-20</a> as the digital money, an ERC-1155 compatible smart contract as the PBM wrapper, a compliance guard smart contract as a component of the PBM Wrapper logic, and a PBM token manager smart contract to manage token registration and retrieval.</p>
Motivation</h2>
Purpose Bound Money (PBM) enables digital currencies to carry conditions on how they can be spent, making them especially useful in real-world scenarios such as:</p>

Government vouchers</strong> (e.g. CDC vouchers in Singapore), where funds should only be redeemable at approved heartland merchants;</li>
Conditional disbursements</strong>, such as SkillsFuture learning accounts, where funds are released only after course participation is verified;</li>
Escrow-style payments</strong>, like homebuyer milestones, where payouts to developers are tied to the completion of specific construction stages;</li>
</ul>
This proposal intends to forestall technology fragmentation and consequently a lack of interoperability. By making the PBM specification open, it gives new participants easy and free access to the pre-existing market standards, enabling interoperability across different platforms, wallets, payment systems and rails. This would lower cost of entry for new participants, foster a vibrant payment landscape and prevent the development of walled gardens and monopolies, ultimately leading to more efficient, affordable services and better user experiences.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Definitions</h3>


sovToken</strong> - an ERC-20 or ERC-20 compatible digital currency (e.g. ERC-777</a>, ERC-1363</a>) serving as the store of value token (i.e. collateral backing the PBM Token).</p>
</li>

PBM Wrapper</strong> - an ERC-1155 compliant smart contract, which wraps the sovToken by specifying one or more conditions that have to be met (referred to as PBM business logic in subsequent section of this proposal). The PBM wrapper can be designed to be modular in nature, with core, plug-ins and hooks components (see section on PBM Architecture for elaboration). The PBM wrapper smart contract, together with adopted hooks smart contracts verifies that condition(s) has/have been met before unwrapping the underlying sovToken.</p>
</li>

PBM Token</strong> - the sovToken and its PBM wrapper are collectively referred to as a PBM Token. PBM Tokens are represented as ERC-1155 tokens.</p>
</li>

PBM Creator</strong> defines the conditions of the PBM Wrapper to create PBM Tokens.</p>
</li>

Merchant / Redeemer</strong> - In the context of this proposal, a Merchant or a Redeemer is broadly defined as the ultimate recipient, or endpoint, for PBM tokens, to which these tokens are intrinsically directed or purpose-bound to. The identity of merchant/redeemer will be one of the validations performed by the compliance guard, which may be implemented as part of the PBM Wrapper smart contract or as a standalone compliance guard contract registered as a PBM hook.</p>
</li>
</ul>
Overview</h3>


PBM SHALL</strong> adhere to the definition of "wrap" or "wrapping" to mean binding a token in accordance with PBM business logic throughout its lifecycle.</p>
</li>

PBM SHALL</strong> adhere to the definition of "unwrap" or "unwrapping" to mean the release of a token in accordance with the PBM business logic during its lifecycle stage.</p>
</li>

A valid PBM Token MUST</strong> consist of an underlying sovToken and a PBM Wrapper.</p>


The sovToken can be wrapped either upon the creation of the PBM Token or at a later date.</p>
</li>

A sovToken can be implemented as any widely accepted ERC-20 compatible token, such as ERC-20, ERC-777, or ERC-1363.</p>
</li>
</ul>
</li>

PBM Wrapper MUST</strong> provide a mechanism for all transacting parties to verify that all necessary condition(s) have been met before allowing the PBM Token to be unwrapped. Refer to Auditability section for elaborations. The necessary conditions can be implemented within the PBM wrapper, or in a separate PBM hook(s) smart contract(s).</p>
</li>

PBM Wrapper MUST</strong> ensure the destination address for unwrapped sovToken is in a whitelist of Merchant/Redeemer addresses and not in a blacklist of banned addresses prior to unwrapping the underlying sovToken.</p>
</li>

The PBM Token MUST</strong> be burnt upon being fully unwrapped and used.</p>
</li>

A PBM Token SHOULD</strong> have an expiry time that is decided by the PBM Creator.</p>

For cases where an expiry time is not needed, the expiry time SHOULD</strong> be set to infinity (typically represented as the maximum value of uint256 or type(uint256).max).</li>
</ul>
</li>

This proposal defines a base specification of what a PBM should entail. Extensions to this base specification can be implemented as separate specifications.</p>
</li>
</ul>
PBM Architecture</h3>
In this EIP, we propose a modular PBM architecture that has three distinct components (the core, the plugins and the hooks):</p>

The core components</strong> contains basic functionalities and validation checks that all PBMs should have. Core components includes sovToken and PBM wrapper containing the core logic (e.g. logic to whitelist the merchant/redeemer address, logic to unwrap upon transfer to a whitelisted address, logic for minting and burning the PBM) and a token manager which allows for token registration, retrieval. In addition, the PBM wrapper MAY</strong> include logic to interface with plugins and hooks.</li>
The plugin components</strong> implement additional functionality that only specific PBMs may require (e.g. logic to call external application programming interfaces to verify specific PBM condition was met, logic to track PBM usage patterns).</li>
The hook components</strong> implement additional validation checks that some PBMs may need (e.g. checks for expiration, daily spending limit, goods & services limit etc).</li>
</ul>
For example, a PBM creator may want to ensure that only 50% of PBM Series A can be spent in supermarkets, while there are no restrictions on the proportion of PBM Series B that can be spent in supermarkets. The creator can implement a plugin smart contract to keep track of supermarket spending by PBM users and a hook to validate that less than 50% of the PBM Series A issued to a user is spent in a supermarket. This approach allows the same generic PBM wrapper and sovToken to be used for both PBM Series A and B. In addition, PBM Series A will register the plugin module and hook module for additional data tracking and validations.</p>
Auditability</h3>
PBM Wrapper SHOULD</strong> provide the public easily accessible mechanism(s) to verify the smart contract logic for unwrapping a PBM. Such mechanisms could be leveraged by automated validation or asynchronous user verifications from transacting parties and/or whitelisted third parties attestations.</p>
As the fulfilment of PBM conditions is likely to be subjected to audits to ensure trust amongst all transacting parties, the following evidence shall be documented to support audits:</p>

The interface/events emitted SHOULD</strong> allow a fine-grained recreation of the transaction history, token types and token balances</li>
The source code SHOULD</strong> be verified and formally published on a blockchain explorer.</li>
</ul>
Fungibility</h3>
A PBM Wrapper SHOULD</strong> be able to wrap multiple types of compatible sovTokens (e.g. the same PBM Wrapper should be able to wrap USDC and XSGD). sovTokens wrapped by the same PBM wrapper may or may not be fungible to one another. The standard does NOT mandate how an implementation must do this.</p>
PBM token details</h3>
The ERC-1155 Multi Token Standard enables each token ID to correspond to a unique, configurable token type. All essential details facilitating the business or display logic for a PBM MUST</strong> be defined for each token type. The mandatory fields for this purpose are outlined in the struct PBMToken</code> (below). Future proposals may define additional, optional state variables as needed. Once a token detail has been defined, it MUST</strong> be immutable.</p>
Example of token details:</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
interface</span> IPBMRC1_TokenManager</span> {</span></span>
    ///</span> @notice</span> A PBM token MUST include compulsory state variables (name, faceValue, expiry, and uri) to adhere to this standard.</span></span>
    ///</span> @dev</span> Represents all the details corresponding to a PBM tokenId.</span></span>
    struct</span> PBMToken</span> {</span></span>
        //</span> Name of the token.</span></span>
        string</span> name</span>;</span></span>
</span>
        //</span> Value of the underlying wrapped ERC20-compatible sovToken. Additional information on the `faceValue` can be specified by</span></span>
        //</span> adding the optional variables: `currencySymbol` or `tokenSymbol` as indicated below</span></span>
        uint256</span> faceValue</span>;</span></span>
</span>
        //</span> Time after which the token will be rendered useless (expressed in Unix Epoch time).</span></span>
        uint256</span> expiry</span>;</span></span>
</span>
        //</span> Metadata URI for ERC-1155 display purposes.</span></span>
        string</span> uri</span>;</span></span>
    }</span></span>
}</span></span></code></pre>
An implementer of the standard can enhance their PBM tokens with additional functionality by implementing the IPBMRC1_TokenManagerExt</code> interface. This extension provides optional properties that can be used to support a variety of use cases beyond the core requirements.</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
interface</span> IPBMRC1_TokenManagerExt</span> {</span></span>
    ///</span> @notice</span> Optional properties that a PBM token MAY include for extended functionality.</span></span>
    ///</span> @dev</span> Represents additional optional fields that can be implemented for a PBM tokenId.</span></span>
    struct</span> PBMTokenExt</span> {</span></span>
        //</span> Indicates if the PBM token can be transferred to a non merchant/redeemer wallet.</span></span>
        bool</span> isTransferable</span>;</span></span>
</span>
        //</span> Determines whether the PBM will be burned or revoked upon expiry, under certain predefined conditions, or at the owner's discretion.</span></span>
        bool</span> burnable</span>;</span></span>
</span>
        //</span> Number of decimal places for the token.</span></span>
        uint8</span> decimals</span>;</span></span>
</span>
        //</span> The address of the creator of this PBM type on this smart contract. This field is optional because the creator is msg.sender by default.</span></span>
        address</span> creator</span>;</span></span>
</span>
        //</span> The smart contract address of the sovToken.</span></span>
        address</span> tokenAddress</span>;</span></span>
</span>
        //</span> The running balance of the PBM Token type that has been minted.</span></span>
        uint256</span> totalSupply</span>;</span></span>
</span>
        //</span> An ISO4217 three-character alphabetic code may be needed for the faceValue in multicurrency PBM use cases.</span></span>
        string</span> currencySymbol</span>;</span></span>
</span>
        //</span> An abbreviation for the PBM token name may be assigned.</span></span>
        string</span> tokenSymbol</span>;</span></span>
</span>
        //</span> Add other optional state variables below...</span></span>
    }</span></span>
}</span></span></code></pre>
An implementer has the option to define all token types upon PBM contract deployment. If needed, they can also expose an external function to create new PBM tokens at a later time.
All token types created SHOULD</strong> emit a NewPBMTypeCreated</code> event.</p>
    ///</span> @notice</span> Creates a new PBM Token type with the provided data.</span></span>
    ///</span> @dev</span> The caller of createPBMTokenType shall be responsible for setting the creator address.</span></span>
    ///</span> Example of uri can be found in [`sample-uri`](./assets/sample-uri/stx-10-static)</span></span>
    ///</span> MUST Emit the {NewPBMTypeCreated} event</span></span>
    ///</span> @param</span> _name</span> Name of the token.</span></span>
    ///</span> @param</span> _faceValue</span> Value of the underlying wrapped ERC20-compatible sovToken.</span></span>
    ///</span> @param</span> _tokenExpiry</span> Time after which the token will be rendered useless (expressed in Unix Epoch time).</span></span>
    ///</span> @param</span> _tokenURI</span> Metadata URI for ERC-1155 display purposes</span></span>
    function</span> createPBMTokenType</span>(</span></span>
        string</span> memory</span> _name</span>,</span></span>
        uint256</span> _faceValue</span>,</span></span>
        uint256</span> _tokenExpiry</span>,</span></span>
        string</span> memory</span> _tokenURI</span></span>
    )</span> external</span> returns</span> (</span>uint256</span> tokenId_</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Emitted when a new Purpose-Bound Token (PBM) type is created within the contract.</span></span>
    ///</span> @param</span> tokenId</span> The unique identifier for the newly created PBM token type.</span></span>
    ///</span> @param</span> tokenName</span> A human-readable string representing the name of the newly created PBM token type.</span></span>
    ///</span> @param</span> amount</span> The initial supply of the newly created PBM token type.</span></span>
    ///</span> @param</span> expiry</span> The timestamp at which the newly created PBM token type will expire.</span></span>
    ///</span> @param</span> creator</span> The address of the account that created the new PBM token type.</span></span>
    event</span> NewPBMTypeCreated</span>(</span>uint256</span> tokenId</span>, </span>string</span> tokenName</span>, </span>uint256</span> amount</span>, </span>uint256</span> expiry</span>, </span>address</span> creator</span>)</span>;</span></span>
</span></code></pre>
Implementors of the standard MUST</strong> define a method to retrieve a PBM token detail</p>
    ///</span> @notice</span> Retrieves the details of a PBM Token type given its tokenId.</span></span>
    ///</span> @dev</span> This function fetches the PBMToken struct associated with the tokenId and returns it.</span></span>
    ///</span> @param</span> tokenId</span> The identifier of the PBM token type.</span></span>
    ///</span> @return</span> pbmToken_</span> A PBMToken struct containing all the details of the specified PBM token type.</span></span>
    function</span> getTokenDetails</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span>(</span>PBMToken</span> memory</span> pbmToken_</span>)</span>;</span></span></code></pre>Compliance Guard</h3>
A compliance guard should have logic to store and retrieve whitelisted merchants/redeemers and blacklisted addresses to fulfill the basic premise of a PBM. Additional logic can be added to fulfill other compliance goals.</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
///</span> @title</span> Compliance Guard Interface.</span></span>
///</span> @notice</span> The compliance guard stores and manages whitelisted merchants/redeemers and blacklisted addresses for the PBMs</span></span>
interface</span> IComplianceGuard</span> {</span></span>
    ///</span> @notice</span> Checks if the address is one of the blacklisted addresses</span></span>
    ///</span> @param</span> _address</span> The address to query</span></span>
    ///</span> @return</span> bool_</span> True if address is blacklisted, else false</span></span>
    function</span> isBlacklisted</span>(</span>address</span> _address</span>)</span> external</span> returns</span> (</span>bool</span> bool_</span>)</span> ;</span></span>
</span>
    ///</span> @notice</span> Checks if the address is one of the whitelisted merchant/redeemer addresses</span></span>
    ///</span> @param</span> _address</span> The address to query</span></span>
    ///</span> @return</span> bool_</span> True if the address is in merchant/redeemer whitelist and is NOT a blacklisted address, otherwise false.</span></span>
    function</span> isMerchant</span>(</span>address</span> _address</span>)</span> external</span> returns</span> (</span>bool</span> bool_</span>)</span> ;</span></span>
</span>
    ///</span> @notice</span> Event emitted when the Merchant/Redeemer List is edited</span></span>
    ///</span> @param</span> action</span> Tags "add" or "remove" for action type</span></span>
    ///</span> @param</span> addresses</span> An array of merchant wallet addresses that was just added or removed from Merchant/Redeemer whitelist</span></span>
    ///</span> @param</span> metadata</span> Optional comments or notes about the added or removed addresses.</span></span>
    event</span> MerchantList</span>(</span>string</span> action</span>, </span>address</span>[</span>]</span> addresses</span>, </span>string</span> metadata</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Event emitted when the Blacklist is edited</span></span>
    ///</span> @param</span> action</span> Tags "add" or "remove" for action type</span></span>
    ///</span> @param</span> addresses</span> An array of wallet addresses that was just added or removed from address blacklist</span></span>
    ///</span> @param</span> metadata</span> Optional comments or notes about the added or removed addresses.</span></span>
    event</span> Blacklist</span>(</span>string</span> action</span>, </span>address</span>[</span>]</span> addresses</span>, </span>string</span> metadata</span>)</span>;</span></span>
}</span></span>
</span></code></pre>PBMRC1 - Base Interface</h3>
This interface contains the essential functions required to implement a pre-loaded PBM.</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
///</span> LIST OF EVENTS TO BE EMITTED</span></span>
///</span> A database or explorer may listen to events and be able to provide indexed and categorized searches</span></span>
///</span> @title</span> PBM Specification interface</span></span>
///</span> @notice</span> The PBM (purpose bound money) allows us to add logical requirements on the use of sovTokens.</span></span>
///</span> The PBM acts as wrapper around the sovTokens and implements the necessary business logic.</span></span>
///</span> @dev</span> PBM deployer must assign an overall owner to the smart contract. If fine grain access controls are required, EIP-5982 can be used on top of ERC173</span></span>
interface</span> IPBMRC1</span> is</span> IERC173</span>, </span>IERC5679Ext1155</span> {</span></span>
</span>
    ///</span> @notice</span> Initialise the contract by specifying an underlying ERC20-compatible token address,</span></span>
    ///</span> contract expiry and PBM Wrapper Logic smart contract's address.</span></span>
    ///</span> @param</span> _sovToken</span> The address of the underlying sovToken.</span></span>
    ///</span> @param</span> _expiry</span> The contract-wide expiry timestamp (in Unix epoch time).</span></span>
    ///</span> @param</span> _pbmWrapperLogic</span> This address should point to a smart contract that contains conditions governing a PBM;</span></span>
    ///</span> such as purpose-bound conditions (e.g., a compliance guard determining whether a PBM is permitted to be transferred or to be unwrapped)</span></span>
    ///</span> and other relevant business logic, effectively implementing an inversion of control.</span></span>
    function</span> initialise</span>(</span>address</span> _sovToken</span>,</span> uint256</span> _expiry</span>,</span> address</span> _pbmWrapperLogic</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Returns the Uniform Resource Identifier (URI) metadata information for the PBM with the corresponding tokenId.</span></span>
    ///</span> @dev</span> URIs are defined in RFC 3986.</span></span>
    ///</span> The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema".</span></span>
    ///</span> Developers may choose to adhere to the ERC1155Metadata_URI extension interface if necessary.</span></span>
    ///</span> The URI is not expected to be immutable.</span></span>
    ///</span> @param</span> tokenId</span> The id for the PBM in query</span></span>
    ///</span> @return</span> Returns</span> the metadata URI string for the PBM</span></span>
    function</span> uri</span>(</span>uint256</span> tokenId</span>)</span> external</span>  view</span> returns</span> (</span>string</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
        @notice</span> Creates a PBM copy ( ERC1155 NFT ) of an existing PBM token type.</span></span>
        @dev</span> See {IERC5679Ext1155} for further implementation notes</span></span>
        @param</span> receiver</span> The wallet address to which the created PBMs need to be transferred to</span></span>
        @param</span> tokenId</span> The identifier of the PBM token type to be copied.</span></span>
        @param</span> amount</span> The number of the PBMs that are to be created</span></span>
        @param</span> data</span> Additional data with no specified format, based on EIP-5750</span></span>
</span>
        This function transfers the underlying token from the caller into the PBM smart contract.</span></span>
        IMPT: Before minting, the caller should approve the contract address to spend sovTokens on behalf of the caller.</span></span>
            This can be done by calling the `approve` or `increaseMinterAllowance` functions of the ERC-20 contract and specifying `_spender` to be the PBM contract address.</span></span>
            Ref : https://eips.ethereum.org/EIPS/eip-20</span></span>
</span>
        WARNING: Any contracts that externally call these safeMint() and safeMintBatch() functions should implement some sort of reentrancy guard procedure</span></span>
        (such as OpenZeppelin's ReentrancyGuard) or a Checks-effects-interactions pattern.</span></span>
</span>
        As per ERC-5679 standard: When the token is being minted, the transfer events MUST be emitted as if the token in the `amount` for EIP-1155</span></span>
        and `tokenId` being _id for EIP-1155 were transferred from address 0x0 to the recipient address identified by receiver.</span></span>
        The total supply MUST increase accordingly.</span></span>
</span>
        MUST Emit the {TokenWrap} event as the underlying sovToken is wrapped by the PBM wrapper smart contract during minting.</span></span>
</span>
        Requirements:</span></span>
        - contract must not be paused</span></span>
        - tokens must not be expired</span></span>
        - `tokenId` should be a valid id that has already been created</span></span>
        - caller should have the necessary amount of the sovTokens required to mint</span></span>
        - caller should have approved the PBM contract to spend the sovTokens</span></span>
        - receiver should not be blacklisted</span></span>
     */</span></span>
    function</span> safeMint</span>(</span>address</span> receiver</span>,</span> uint256</span> tokenId</span>,</span> uint256</span> amount</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
        @notice</span> Creates multiple PBM copies (ERC1155 NFT) of an existing PBM token type.</span></span>
        @dev</span> See {IERC5679Ext1155}.</span></span>
        @param</span> receiver</span> The wallet address to which the created PBMs need to be transferred to</span></span>
        @param</span> tokenIds</span> The identifier of the PBM token type</span></span>
        @param</span> amounts</span> The number of the PBMs that are to be created</span></span>
        @param</span> data</span> Additional data with no specified format, based on eip-5750</span></span>
</span>
        This function will transfer the underlying token from the caller into the PBM smart contract.</span></span>
        IMPT: Before minting, the caller should approve the contract address to spend sovTokens on behalf of the caller.</span></span>
            This can be done by calling the `approve` or `increaseMinterAllowance` functions of the ERC-20 contract and specifying `_spender` to be the PBM contract address.</span></span>
            Ref : https://eips.ethereum.org/EIPS/eip-20</span></span>
</span>
        WARNING: Any contracts that externally call these safeMint() and safeMintBatch() functions should implement some sort of reentrancy guard procedure</span></span>
        (such as OpenZeppelin's ReentrancyGuard) or a Checks-effects-interactions pattern.</span></span>
</span>
        As per ERC-5679 standard: When the token is being minted, the transfer events MUST be emitted as if the token in the `amount` for EIP-1155</span></span>
        and `tokenId` being _id for EIP-1155 were transferred from address 0x0 to the recipient address identified by receiver.</span></span>
        The total supply MUST increase accordingly.</span></span>
</span>
        MUST Emit the {TokenWrap} event as the underlying sovToken is wrapped by PBM wrapper smart contract during minting.</span></span>
</span>
        Requirements:</span></span>
        - contract must not be paused</span></span>
        - tokens must not be expired</span></span>
        - `tokenIds` should all be valid ids that have already been created</span></span>
        - `tokenIds` and `amounts` list need to have the same number of values</span></span>
        - caller should have the necessary amount of the sovTokens required to mint</span></span>
        - caller should have approved the PBM contract to spend the sovTokens</span></span>
        - receiver should not be blacklisted</span></span>
     */</span></span>
    function</span> safeMintBatch</span>(</span>address</span> receiver</span>,</span> uint256</span>[</span>]</span> calldata</span> tokenIds</span>,</span> uint256</span>[</span>]</span> calldata</span> amounts</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
        @notice</span> Burns a PBM token. Upon burning of the tokens, the underlying wrapped token (if any) should be handled.</span></span>
        @dev</span> Destroys `amount` tokens of token type `tokenId` from `from`</span></span>
        @dev</span> See {IERC5679Ext1155}</span></span>
</span>
        @param</span> from</span> The originating wallet address of the PBMs to be burned</span></span>
        @param</span> tokenId</span> The identifier of the PBM token type</span></span>
        @param</span> amount</span> The amount of the PBMs that are to be burned</span></span>
        @param</span> data</span> Additional data with no specified format, based on EIP-5750</span></span>
</span>
        MUST Emit the {TransferSingle} event.</span></span>
        MUST Emit the {TokenUnwrapForPBMBurn} event if the underlying wrapped token is moved out of the PBM smart contract.</span></span>
</span>
        Requirements:</span></span>
        - `from` cannot be the zero address.</span></span>
        - `from` must have at least `amount` tokens of token type `tokenId`.</span></span>
</span>
     */</span></span>
    function</span> burn</span>(</span>address</span> from</span>,</span> uint256</span> tokenId</span>,</span> uint256</span> amount</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
        @notice</span> Burns multiple PBM token. Upon burning of the tokens, the underlying wrapped token (if any) should be handled.</span></span>
        @dev</span> Destroys `amount` tokens of token type `tokenId` from `from`</span></span>
        @dev</span> See {IERC5679Ext1155}</span></span>
</span>
        @param</span> from</span> The originating wallet address of the PBMs to be burned</span></span>
        @param</span> tokenIds</span> The identifier of the PBM token types</span></span>
        @param</span> amounts</span> The amount of the PBMs that are to be burned for each tokenId in _tokenIds</span></span>
        @param</span> data</span> Additional data with no specified format, based on eip-5750</span></span>
</span>
        MUST Emit the {TransferSingle} event.</span></span>
        MUST Emit the {TokenUnwrapForPBMBurn} event if the underlying wrapped token is moved out of the PBM smart contract.</span></span>
</span>
        Requirements:</span></span>
        - `from` cannot be the zero address.</span></span>
        - `from` must have at least amount specified in `_amounts` of the corresponding token type tokenId in `_tokenIds` array.</span></span>
     */</span></span>
    function</span> burnBatch</span>(</span>address</span> from</span>,</span> uint256</span>[</span>]</span> calldata</span> tokenIds</span>,</span> uint256</span>[</span>]</span> calldata</span> amounts</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Transfers the PBM(NFT) from one wallet to another.</span></span>
    ///</span> @dev</span> This function extends the ERC-1155 standard in order to allow the PBM token to be freely transferred between wallet addresses due to</span></span>
    ///</span> widespread support across wallet providers. Specific conditions and restrictions on whether a pbm can be moved across addresses can be incorporated in this function.</span></span>
    ///</span> Unwrap logic MAY also be placed within this function to be called.</span></span>
    ///</span> @param</span> from</span> The account from which the PBM (NFT) is moving from</span></span>
    ///</span> @param</span> to</span> The account which is receiving the PBM (NFT)</span></span>
    ///</span> @param</span> id</span> The identifier of the PBM token type</span></span>
    ///</span> @param</span> amount</span> The number of (quantity) the PBM type that are to be transferred of the PBM type</span></span>
    ///</span> @param</span> data</span> To record any data associated with the transaction, can be left blank if none</span></span>
    function</span> safeTransferFrom</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint256</span> id</span>,</span> uint256</span> amount</span>,</span> bytes</span> memory</span> data</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Transfers the PBM(NFT)(s) from one wallet to another.</span></span>
    ///</span> @dev</span> This function extends the ERC-1155 standard in order to allow the PBM token to be freely transferred between wallet addresses due to</span></span>
    ///</span> widespread support across wallet providers.  Specific conditions and restrictions on whether a pbm can be moved across addresses can be incorporated in this function.</span></span>
    ///</span> Unwrap logic MAY also be placed within this function to be called.</span></span>
    ///</span> If the receiving wallet is a whitelisted /redeemer wallet address, the PBM(NFT)(s) will be burnt and the underlying sovTokens will be transferred to the merchant/redeemer wallet instead.</span></span>
    ///</span> @param</span> from</span> The account from which the PBM (NFT)(s) is moving from</span></span>
    ///</span> @param</span> to</span> The account which is receiving the PBM (NFT)(s)</span></span>
    ///</span> @param</span> ids</span> The identifiers of the different PBM token type</span></span>
    ///</span> @param</span> amounts</span> The number of (quantity) the different PBM types that are to be created</span></span>
    ///</span> @param</span> data</span> To record any data associated with the transaction, can be left blank if none.</span></span>
    function</span> safeBatchTransferFrom</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint256</span>[</span>]</span> memory</span> ids</span>,</span> uint256</span>[</span>]</span> memory</span> amounts</span>,</span> bytes</span> memory</span> data</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Unwraps the underlying ERC-20 compatible tokens to an intended end point (ie: merchant/redeemer) upon fulfilling the required PBM conditions.</span></span>
    ///</span> @dev</span> Add implementation specific logic for the conditions under which a PBM processes and transfers the underlying tokens here.</span></span>
    ///</span> e.g. If the receiving wallet is a whitelisted merchant/redeemer wallet address, the PBM (NFT) MUST be burnt and the underlying sovTokens</span></span>
    ///</span> will unwrapped to be transferred to the merchant/redeemer wallet.</span></span>
    ///</span> MUST Emit the {TokenUnwrapForTarget} event on success</span></span>
    ///</span> @param</span> from</span> The account currently holding the PBM</span></span>
    ///</span> @param</span> to</span> The account receiving the PBM (NFT)</span></span>
    ///</span> @param</span> tokenId</span> The identifier of the PBM token type</span></span>
    ///</span> @param</span> amount</span> The quantity of the PBM type involved in this transaction</span></span>
    ///</span> @param</span> data</span> Additional data without a specified format, based on EIP-5750</span></span>
    function</span> unwrap</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint256</span> tokenId</span>,</span> uint256</span> amount</span>,</span> bytes</span> memory</span> data</span>)</span> internal</span>;</span></span>
</span>
    ///</span> @notice</span> Allows the creator of a PBM token type to retrieve all locked-up underlying sovTokens within that PBM.</span></span>
    ///</span> @dev</span> Ensure that only the creator of the PBM token type or the contract owner can call this function.</span></span>
    ///</span> Validate the token state and existence, handle PBM token burning if necessary, safely transfer the remaining sovTokens to the originator,</span></span>
    ///</span> MUST Emit the {PBMrevokeWithdraw} event upon a successful revoke.</span></span>
    ///</span> @param</span> tokenId</span> The identifier of the PBM token type</span></span>
    ///</span> Requirements:</span></span>
    ///</span> - `tokenId` should be a valid identifier for an existing PBM token type.</span></span>
    ///</span> - The caller must be either the creator of the token type or the smart contract owner.</span></span>
    function</span> revokePBM</span>(</span>uint256</span> tokenId</span>)</span> external</span>;</span></span>
</span>
    ///</span> @notice</span> Emitted when a PBM type creator withdraws the underlying sovTokens from all the remaining expired PBMs</span></span>
    ///</span> @param</span> beneficiary</span> the address ( PBM type creator ) which receives the sovToken</span></span>
    ///</span> @param</span> PBMTokenId</span> The identifiers of the different PBM token type</span></span>
    ///</span> @param</span> sovToken</span> The address of the underlying sovToken</span></span>
    ///</span> @param</span> sovTokenValue</span> The number of underlying sovTokens transferred</span></span>
    event</span> PBMrevokeWithdraw</span>(</span>address</span> beneficiary</span>, </span>uint256</span> PBMTokenId</span>, </span>address</span> sovToken</span>, </span>uint256</span> sovTokenValue</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Emitted when the underlying tokens are unwrapped and transferred to a specific purpose-bound address.</span></span>
    ///</span> This event signifies the end of the PBM lifecycle, as all necessary conditions have been met to release the underlying tokens to the recipient (whitelisted merchant/redeemer with non-blacklisted wallet address).</span></span>
    ///</span> If there are multiple different underlying tokens involved in a single unwrap operation, this event should be emitted for each underlying token.</span></span>
    ///</span> @param</span> from</span> The address from which the PBM tokens are being unwrapped.</span></span>
    ///</span> @param</span> to</span> The purpose-bound address receiving the unwrapped underlying tokens.</span></span>
    ///</span> @param</span> tokenIds</span> An array containing the identifiers of the unwrapped PBM token types.</span></span>
    ///</span> @param</span> amounts</span> An array containing the quantities of the corresponding unwrapped PBM tokens.</span></span>
    ///</span> @param</span> sovToken</span> The address of the underlying sovToken.</span></span>
    ///</span> @param</span> sovTokenValue</span> The amount of unwrapped underlying sovTokens transferred.</span></span>
    event</span> TokenUnwrapForTarget</span>(</span>address</span> from</span>, </span>address</span> to</span>, </span>uint256</span>[</span>]</span> tokenIds</span>, </span>uint256</span>[</span>]</span> amounts</span>, </span>address</span> sovToken</span>, </span>uint256</span> sovTokenValue</span>)</span>;</span></span>
</span>
    ///</span> @notice</span> Emitted when PBM tokens are burned, resulting in the unwrapping of the underlying tokens for the designated recipient.</span></span>
    ///</span> This event is required if there is an unwrapping of the underlying tokens during the PBM (NFT) burning process.</span></span>
    ///</span> If there are multiple different underlying tokens involved in a single unwrap operation, this event should be emitted for each underlying token.</span></span>
    ///</span> @param</span> from</span> The address from which the PBM tokens are being burned.</span></span>
    ///</span> @param</span> to</span> The address receiving the unwrapped underlying tokens.</span></span>
    ///</span> @param</span> tokenIds</span> An array containing the identifiers of the burned PBM token types.</span></span>
    ///</span> @param</span> amounts</span> An array containing the quantities of the corresponding burned PBM tokens.</span></span>
    ///</span> @param</span> sovToken</span> The address of the underlying sovToken.</span></span>
    ///</span> @param</span> sovTokenValue</span> The amount of unwrapped underlying sovTokens transferred.</span></span>
    event</span> TokenUnwrapForPBMBurn</span>(</span>address</span> from</span>, </span>address</span> to</span>, </span>uint256</span>[</span>]</span> tokenIds</span>, </span>uint256</span>[</span>]</span> amounts</span>, </span>address</span> sovToken</span>, </span>uint256</span> sovTokenValue</span>)</span>;</span></span>
</span>
    ///</span> Indicates the wrapping of a token into the PBM smart contract.</span></span>
    ///</span> @notice</span> Emitted when underlying tokens are wrapped within the PBM smart contract.</span></span>
    ///</span> If there are multiple different underlying tokens involved in a single wrap operation, this event should be emitted for each underlying token.</span></span>
    ///</span> This event signifies the beginning of the PBM lifecycle, as tokens are now managed by the conditions within the PBM contract.</span></span>
    ///</span> @param</span> from</span> The address initiating the token wrapping process, and</span></span>
    ///</span> @param</span> tokenIds</span> An array containing the identifiers of the token types being wrapped.</span></span>
    ///</span> @param</span> amounts</span> An array containing the quantities of the corresponding wrapped tokens.</span></span>
    ///</span> @param</span> sovToken</span> The address of the underlying sovToken.</span></span>
    ///</span> @param</span> sovTokenValue</span> The amount of wrapped underlying sovTokens transferred.</span></span>
    event</span> TokenWrap</span>(</span>address</span> from</span>, </span>uint256</span>[</span>]</span> tokenIds</span>, </span>uint256</span>[</span>]</span> amounts</span>,</span>address</span> sovToken</span>, </span>uint256</span> sovTokenValue</span>)</span>;</span></span>
}</span></span>
</span></code></pre>Extensions</h3>
PBMRC1 - Token Receiver</h4>
Smart contracts MUST implement all of the functions in the PBMRC1_TokenReceiver interface to subscribe to PBM unwrap callbacks.</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
///</span> @notice</span> Smart contracts MUST implement the ERC-165 `supportsInterface` function and signify support for the `PBMRC1_TokenReceiver` interface to accept callbacks.</span></span>
///</span> It is optional for a receiving smart contract to implement the `PBMRC1_TokenReceiver` interface</span></span>
///</span> @dev</span> WARNING: Reentrancy guard procedure, Non delegate call, or the check-effects-interaction pattern must be adhere to when calling an external smart contract.</span></span>
///</span> The interface functions MUST only be called at the end of the `unwrap` function.</span></span>
interface</span> PBMRC1_TokenReceiver</span> {</span></span>
    /**</span></span>
        @notice</span> Handles the callback from a PBM smart contract upon unwrapping</span></span>
        @dev</span> An PBM smart contract MUST call this function on the token recipient contract, at the end of a `unwrap` if the</span></span>
        receiver smart contract supports type(PBMRC1_TokenReceiver).interfaceId</span></span>
        @param</span> _operator</span>  The address which initiated the transfer (either the address which previously owned the token or the address authorised to make transfers on the owner's behalf) (i.e. msg.sender)</span></span>
        @param</span> _from</span>      The address which previously owned the token</span></span>
        @param</span> _id</span>        The ID of the token being unwrapped</span></span>
        @param</span> _value</span>     The amount of tokens being transferred</span></span>
        @param</span> _data</span>      Additional data with no specified format</span></span>
        @return</span>           `bytes4(keccak256("onPBMRC1Unwrap(address,address,uint256,uint256,bytes)"))`</span></span>
    */</span></span>
    function</span> onPBMRC1Unwrap</span>(</span>address</span> _operator</span>,</span> address</span> _from</span>,</span> uint256</span> _id</span>,</span> uint256</span> _value</span>,</span> bytes</span> calldata</span> _data</span>)</span> external</span> returns</span>(</span>bytes4</span>)</span>;</span></span>
</span>
    /**</span></span>
        @notice</span> Handles the callback from a PBM smart contract upon unwrapping a batch of tokens</span></span>
        @dev</span> A PBM smart contract MUST call this function on the token recipient contract at the end of an `unwrap` if the</span></span>
        receiver smart contract supports type(PBMRC1_TokenReceiver).interfaceId</span></span>
</span>
        @param</span> _operator</span>  The address which initiated the transfer (either the address which previously owned the token or the address authorised to make transfers on the owner's behalf) (i.e. msg.sender)</span></span>
        @param</span> _from</span>      The address which previously owned the token</span></span>
        @param</span> _id</span>        The ID of the token being unwrapped</span></span>
        @param</span> _value</span>     The amount of tokens being transferred</span></span>
        @param</span> _data</span>      Additional data with no specified format</span></span>
        @return</span>           `bytes4(keccak256("onPBMRC1BatchUnwrap(address,address,uint256,uint256,bytes)"))`</span></span>
    */</span></span>
    function</span> onPBMRC1BatchUnwrap</span>(</span>address</span> _operator</span>,</span> address</span> _from</span>,</span> uint256</span>[</span>]</span> calldata</span> _ids</span>,</span> uint256</span>[</span>]</span> calldata</span> _values</span>,</span> bytes</span> calldata</span> _data</span>)</span> external</span> returns</span>(</span>bytes4</span>)</span>;</span></span>
}</span></span>
</span></code></pre>PBMRC2 - Non preloaded PBM Interface</h4>
The Non Preloaded</strong> PBM extension is OPTIONAL for compliant smart contracts. This allows contracts to bind an underlying sovToken to the PBM at a later date instead of during a minting process.</p>
Compliant contract MUST</strong> implement the following interface:</p>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
/**</span></span>
 *  </span>@dev</span> This interface extends IPBMRC1, adding functions for working with non-preloaded PBMs.</span></span>
 *  Non-preloaded PBMs are minted as empty containers without any underlying tokens of value,</span></span>
 *  allowing the loading of the underlying token to happen at a later stage.</span></span>
 */</span></span>
interface</span> PBMRC2_NonPreloadedPBM</span> is</span> IPBMRC1</span> {</span></span>
</span>
  ///</span> @notice</span> This function extends IPBMRC1 to mint PBM tokens as empty containers without underlying tokens of value.</span></span>
  ///</span> @dev</span> The loading of the underlying token of value can be done by calling the `load` function. The function parameters should be identical to IPBMRC1</span></span>
  function</span> safeMint</span>(</span>address</span> receiver</span>,</span> uint256</span> tokenId</span>,</span> uint256</span> amount</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> This function extends IPBMRC1 to mint PBM tokens as empty containers without underlying tokens of value.</span></span>
  ///</span> @dev</span> The loading of the underlying token of value can be done by calling the `load` function. The function parameters should be identical to IPBMRC1</span></span>
  function</span> safeMintBatch</span>(</span>address</span> to</span>,</span> uint256</span>[</span>]</span> calldata</span> ids</span>,</span> uint256</span>[</span>]</span> calldata</span> amounts</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Wrap an amount of sovTokens into the PBM</span></span>
  ///</span> @dev</span> function will pull sovTokens from msg.sender</span></span>
  ///</span> Approval must be given to the PBM smart contract in order to for the pbm to pull money from msg.sender</span></span>
  ///</span> underlying data structure must record how much the msg.sender has been loaded into the PBM.</span></span>
  ///</span> Emits {TokenLoad} event.</span></span>
  ///</span> @param</span> amount</span>    The amount of sovTokens to be loaded</span></span>
  function</span> load</span>(</span>uint256</span> amount</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Retrieves the balance of the underlying sovToken associated with a specific PBM token type and user address.</span></span>
  ///</span> This function provides a way to check the amount of the underlying token that a user has loaded into a particular PBM token.</span></span>
  ///</span> @param</span> user</span> The address of the user whose underlying token balance is being queried.</span></span>
  ///</span> @return</span> The</span> balance of the underlying sovToken associated with the specified PBM token type and user address.</span></span>
  function</span> underlyingBalanceOf</span>(</span>address</span> user</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Unloads all of the underlying token belonging to the caller from the PBM smart contract.</span></span>
  ///</span> @dev</span> The underlying token that belongs to the caller (msg.sender) will be removed and transferred</span></span>
  ///</span> back to the caller.</span></span>
  ///</span> Emits {TokenUnload} event.</span></span>
  ///</span> @param</span> amount</span> The quantity of the corresponding tokens to be unloaded.</span></span>
  ///</span> Amount should not exceed the amount that the caller has originally loaded into the PBM smart contract.</span></span>
  function</span> unload</span>(</span>uint256</span> amount</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Emitted when an underlying token is loaded into a PBM</span></span>
  ///</span> @param</span> caller</span> Address by which sovToken is taken from.</span></span>
  ///</span> @param</span> to</span> Address by which the token is loaded and assigned to</span></span>
  ///</span> @param</span> amount</span> The quantity of tokens to be loaded</span></span>
  ///</span> @param</span> sovToken</span> The address of the underlying sovToken.</span></span>
  ///</span> @param</span> sovTokenValue</span> The amount of underlying sovTokens loaded</span></span>
  event</span> TokenLoad</span>(</span>address</span> caller</span>, </span>address</span> to</span>, </span>uint256</span> amount</span>, </span>address</span> sovToken</span>, </span>uint256</span> sovTokenValue</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Emitted when an underlying token is unloaded from a PBM.</span></span>
  ///</span> This event indicates the process of releasing the underlying token from the PBM smart contract.</span></span>
  ///</span> @param</span> caller</span> The address initiating the token unloading process.</span></span>
  ///</span> @param</span> from</span> The address from which the token is being unloaded and removed from.</span></span>
  ///</span> @param</span> amount</span> The quantity of the corresponding unloaded tokens.</span></span>
  ///</span> @param</span> sovToken</span> The address of the underlying sovToken.</span></span>
  ///</span> @param</span> sovTokenValue</span> The amount of unloaded underlying sovTokens transferred.</span></span>
  event</span> TokenUnload</span>(</span>address</span> caller</span>, </span>address</span> from</span>, </span>uint256</span> amount</span>, </span>address</span> sovToken</span>, </span>uint256</span> sovTokenValue</span>)</span>;</span></span>
}</span></span>
</span></code></pre>Rationale</h2>
Why sovToken MUST</strong> be ERC-20 compatible?</h3>
As PBM is envisioned to have functionality of money, it has to be a fungible token with stable value. Currently, the major stablecoins in the market are mainly based on the ERC-20 interface. ERC-20 or ERC-20 compatible tokens are the most widely supported by existing wallets, defi apps, and used also by protocol design such as ERC-4337</a> and more importantly they are the de facto standard for fungible tokens.</p>
With regards to ERC-721</a> and ERC-1155 compatible tokens:</p>

ERC-721 is not suitable given that it is a standard for non-fungible tokens, which cannot fulfill the functions of money.</li>
While ERC-1155 tokens could be used for fungible tokens, we decided not to include it because there is a lack of ERC-1155 stablecoins in the market. Requiring the PBM interface to support both ERC-20 compatible and ERC-1155 compatible sovToken would complicate PBM interface without adding much practical utility. Furthermore, the base ERC-1155 does not support decimals, but this is not a dealbreaker as there can be workarounds. However, should there be changes in the stablecoin market in future, a revision can be considered.</li>
</ul>
Why PBM Wrapper MUST</strong> be ERC-1155 compatible?</h3>
This paper extends the ERC-1155 standards in order to enable easy adoption by existing wallet providers. Currently, most wallet providers are able to support and display ERC-20, ERC-1155 and ERC-721 standards. An implementation which doesn't extend these standards will require the wallet provider to build a custom user interface and interfacing logic which increases the implementation cost and lengthen the time-to-market.</p>
The core aim of our proposal is to standardize the implementation of PBM. Hence, we have surveyed existing interface standards and decided to build upon ERC-1155 standard for the PBM tokens for the following reasons:</p>

ERC-1155 allows a single contract to support multiple tokens. This is very useful for the PBM use cases as a single contract can support issuance of tokens with different denominations, expiry dates, business logics.</li>
ERC-1155 also has batch transfer support, which is absent in ERC-20, which could lead to gas savings when tokens have to be airdropped to a large number of recipients.</li>
ERC-1155 is able to support semi-fungible tokens which could be very useful for PBM use cases as a PBM can be converted into a collectible after its expiry.</li>
ERC-1155 allows for a visualisation of a PBM token on the UI of a wallet issuer.</li>
</ul>
Why PBM MUST</strong> ensure the destination address for unwrapped sovToken is in a whitelist of Merchant/Redeemer addresses and not in a blacklist of banned addresses prior to unwrapping the underlying sovToken?</h3>
Why do we need a whitelist?</p>

The whitelist is a compulsory requirement because a PBM is purpose-bound, i.e., it should be unwrapped only if all conditions are fulfilled and it is transferred to someone in the predefined whitelist.</li>
In some implementations, developers can define a whitelisted address dynamically at runtime, such as requiring the presence of an NFT in a wallet address or relying on an oracle, etc.</li>
</ul>
Why do we need a blacklist?</p>

The blacklist is a compulsory requirement to ensure that accounts which were banned for various reasons (e.g., address owner has re-registered a new account, address owner suspended, withdrawn, or expelled due to complaints or law enforcement reasons, etc.) are excluded.</li>
</ul>
Why we can't have either a whitelist or a blacklist?</p>

While the same effect can be obtained by only having a whitelist, repeatedly redeploying the whitelist to the blockchain to ban one person is not gas efficient.</li>
Using only a blacklist to implement purpose-bound money is not practical as it would require maintaining a list of all addresses to be excluded and updating it whenever a new account is created.</li>
</ul>
Why is there a need for destination?</p>

This forms the core of our proposal: a PBM can be unwrapped when only it is transferred to pre-approved destinations.</li>
PBMs can be transferred freely, but only the target is allowed to unwrap the PBM and take delivery of the underlying sovToken must be limited to differentiate it from plain vanilla stablecoins that are wrapped by smart contracts.</li>
</ul>
What does business logic encompass?</h3>

In general, business logic can be categorized into core, plugin, and hook logic:

Core logic contains essential functionalities and validation checks and should be included in the PBM Wrapper contract.</li>
Plugin and hook logic can be implemented as standalone smart contract modules and are registered by the PBM Wrapper contract. Plugin logic extends the core logic by adding functionality, e.g., custom data collection, additional administrative functions, etc.</li>
Hook logic implements additional validation checks which are only applicable for a subset of PBMs.</li>
</ul>
</li>
"PBM business logic" can contain access control logic, PBM unwrapping logic, API logic to integrate with non-blockchain IT systems.</li>
As PBM can be used for a wide variety of use cases, ranging from government disbursement tokens, shopping vouchers, prepaid tokens, rewards points tokens, purpose-bound donation tokens, school allowance tokens, etc., with each use case having separate business logic, it was intentionally left undefined so that implementation authors can have maximum flexibility.</li>
</ul>
Why was a push transaction model chosen?</h3>

This standard sticks to the push transaction model where the transfer of PBM is initiated on the sender's side. Modern wallets can support the required PBM logic by embedding the unwrapping logic within the ERC-1155 safeTransfer</code> function.</li>
</ul>
Customisability</h3>
Each ERC-1155 PBM Token would map to an underlying PBMToken</code> data structure that implementers are free to customize in accordance to the business logic.</p>
By mapping the underlying ERC-1155 token model with an additional data structure, implementers gain flexibility in the management of multiple token types within the same smart contract with multiple conditional unwrapping logic attached to each token type, reducing gas costs as there is no need to deploy multiple smart contracts for each token type.</p>


To keep it simple, this standard intentionally</em> omits functions or events that doesn't add to definition and concept of a PBM.</p>
</li>

This EIP makes no assumptions about access control or the conditions under which a function can be executed. It is the responsibility of the PBM creator to determine the various roles involved in each specific PBM business flow.</p>
</li>

The proposed PBM Architecture intentionally</em> modular to enable greater customisability and reusability of smart contracts.</p>
</li>

Metadata associated to the PBM standard is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface, e.g. ERC721Metadata</code> from ERC-721. Refer to Opensea's metadata-standards for an implementation example.</p>
</li>

To allow for future extensibility, it is RECOMMENDED</strong> that developers read and adopt the specifications for building general extensibility for method behaviours (ERC-5750</a>).</p>
</li>
</ol>
Backwards Compatibility</h2>
This interface is designed to be compatible with ERC-1155.</p>
Reference Implementation</h2>
Reference implementations can be found in README.md</code></a>.</p>
Security Considerations</h2>


Malicious users may attempt to:</p>

Double spend through reentrancy.</li>
clone existing PBM Tokens to perform double-spending;</li>
create invalid PBM Token with no underlying sovToken; or</li>
falsifying the face value of PBM token through wrapping of fraudulent/invalid/worthless sovTokens.</li>
</ul>
</li>

For consistency, when the contract is suspended or a user's token transfer is restricted due to suspected fraudulent activity or erroneous transfers, corresponding restrictions MUST</strong> be applied to the user's unwrap requests for the PBM Token.</p>
</li>

Security audits and tests should be performed to verify that unwrap logic behaves as expected or if any complex business logic is being implemented that involves calling an external smart contract to prevent re-entrancy attacks and other forms of call chain attacks.</p>
</li>

This EIP relies on the secure and accurate bookkeeping behavior of the token implementation.</p>


Contracts adhering to this standard should closely monitor balance changes for each user during token consumption or minting.</p>
</li>

The PBM Wrapper must be meticulously designed to ensure effective control over the permission to mint new tokens. Failure to secure the minting permission can lead to fraudulent issuance and unauthorized inflation of the total token supply.</p>
</li>

The mapping of each PBM Token to the corresponding amount of underlying sovToken held by the smart contract requires careful accounting and auditing.</p>
</li>

The access control over permission to burn tokens should be carefully designed. Typically, only the following two roles are entitled to burn a token:</p>

Role 1. Prior to a PBM's expiry, only whitelisted merchants/redeemers with non-blacklisted wallet addresses are allowed to unwrap and burn tokens that they hold.</li>
Role 2. After a PBM has expired:

whitelisted merchants/redeemers with non-blacklisted wallet addresses are allowed to unwrap and burn tokens that they hold; and</li>
PBM owners are allowed to burn unused PBM Tokens remaining in the hands of non-whitelisted merchants/redeemers to retrieve underlying sovTokens.</li>
</ul>
</li>
</ul>
</li>

Nevertheless, we do recognize there are potentially other use cases where a third type of role may be entitled to burning. Implementors should be cautious when designing access control over burning of PBM Tokens.</p>
</li>
</ul>
</li>

It is recommended to adopt a sovToken standard that is compatible with ERC-20. Examples of such compatible tokens include those implementing ERC-777 or ERC-1363. However, ERC-20 remains the most widely accepted due to its simplicity and there is a high degree of confidence in its security.</p>
</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Namespaced Storage Layout
2023-06-20T00:00:00+00:00
Abstract</h2>
We define the NatSpec annotation @custom:storage-location</code> to document storage namespaces and their location in storage in Solidity or Vyper source code. Additionally, we define a formula to derive a location from an arbitrary identifier. The formula is chosen to be safe against collisions with the storage layouts used by Solidity and Vyper.</p>
Motivation</h2>
Smart contract languages such as Solidity and Vyper rely on tree-shaped storage layout. This tree starts at slot 0 and is composed of sequential chunks for consecutive variables. Hashes are used to ensure the chunks containing values of mappings and dynamic arrays do not collide. This is sufficient for most contracts. However, it presents a challenge for various design patterns used in smart contract development. One example is a modular design where using DELEGATECALL</code> a contract executes code from multiple contracts, all of which share the same storage space, and which have to carefully coordinate on how to use it. Another example is upgradeable contracts, where it can be difficult to add state variables in an upgrade given that they may affect the assigned storage location for the preexisting variables.</p>
Rather than using this default storage layout, these patterns can benefit from laying out state variables across the storage space, usually at pseudorandom locations obtained by hashing. Each value may be placed in an entirely different location, but more frequently values that are used together are put in a Solidity struct and co-located in storage. These pseudorandom locations can be the root of new storage trees that follow the same rules as the default one. Provided that this pseudorandom root is constructed so that it is not part of the default tree, this should result in the definition of independent spaces that do not collide with one another or with the default one.</p>
These storage usage patterns are invisible to the Solidity and Vyper compilers because they are not represented as Solidity state variables. Smart contract tools like static analyzers or blockchain explorers often need to know the storage location of contract data. Standardizing the location for storage layouts will allow these tools to correctly interpret contracts where these design patterns are used.</p>
Specification</h2>
Preliminaries</h3>
A namespace</em> consists of a set of ordered variables, some of which may be dynamic arrays or mappings, with its values laid out following the same rules as the default storage layout but rooted in some location that is not necessarily slot 0. A contract using namespaces to organize storage is said to use namespaced storage</em>.</p>
A namespace id</em> is a string that identifies a namespace in a contract. It should not contain any whitespace characters.</p>
@custom:storage-location</code></h3>
A namespace in a contract should be implemented as a struct type. These structs should be annotated with the NatSpec tag @custom:storage-location <FORMULA_ID>:<NAMESPACE_ID></code>, where <FORMULA_ID></code> identifies a formula used to compute the storage location where the namespace is rooted, based on the namespace id. (Note: The Solidity compiler includes this annotation in the AST since v0.8.20, so this is recommended as the minimum compiler version when using this pattern.)</em> Structs with this annotation found outside of contracts are not considered to be namespaces for any contract in the source code.</p>
Formula</h3>
The formula identified by erc7201</code> is defined as erc7201(id: string) = keccak256(keccak256(id) - 1) & ~0xff</code>. In Solidity, this corresponds to the expression keccak256(abi.encode(uint256(keccak256(bytes(id))) - 1)) & ~bytes32(uint256(0xff))</code>. When using this formula the annotation becomes @custom:storage-location erc7201:<NAMESPACE_ID></code>. For example, @custom:storage-location erc7201:foobar</code> annotates a namespace with id "foobar"</code> rooted at erc7201("foobar")</code>.</p>
Future EIPs may define new formulas with unique formula identifiers. It is recommended to follow the convention set in this EIP and use an identifier of the format erc1234</code>.</p>
Rationale</h2>
The tree-shaped storage layout used by Solidity and Vyper follows the following grammar (with root=0):</p>
$L_{root} := \mathit{root} \mid L_{root} + n \mid \texttt{keccak256}(L_{root}) \mid \texttt{keccak256}(H(k) \oplus L_{root}) \mid \texttt{keccak256}(L_{root} \oplus H(k))$</p>
A requirement for the root is that it shouldn't overlap with any storage location that would be part of the standard storage tree used by Solidity and Vyper (root = 0), nor should it be part of the storage tree derived from any other namespace (another root). This is so that multiple namespaces may be used alongside each other and alongside the standard storage layout, either deliberately or accidentally, without colliding. The term keccak256(id) - 1</code> in the formula is chosen as a location that is unused by Solidity, but this is not used as the final location because namespaces can be larger than 1 slot and would extend into keccak256(id) + n</code>, which is potentially used by Solidity. A second hash is added to prevent this and guarantee that namespaces are completely disjoint from standard storage, assuming keccak256 collision resistance and that arrays are not unreasonably large.</p>
Additionally, namespace locations are aligned to 256 as a potential optimization, in anticipation of gas schedule changes after the Verkle state tree migration, which may cause groups of 256 storage slots to become warm all at once.</p>
Naming</h3>
This pattern has sometimes been referred to as "diamond storage". This causes it to be conflated with the "diamond proxy pattern", even though they can be used independently of each other. This EIP has chosen to use a different name to clearly differentiate it from the proxy pattern.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Reference Implementation</h2>
pragma</span> solidity</span> ^0.8.20</span>;</span></span>
</span>
contract</span> Example</span> {</span></span>
    ///</span> @custom:storage</span>-location erc7201:example.main</span></span>
    struct</span> MainStorage</span> {</span></span>
        uint256</span> x</span>;</span></span>
        uint256</span> y</span>;</span></span>
    }</span></span>
</span>
    //</span> keccak256(abi.encode(uint256(keccak256("example.main")) - 1)) & ~bytes32(uint256(0xff));</span></span>
    bytes32</span> private</span> constant</span> MAIN_STORAGE_LOCATION </span>=</span></span>
        0x183a6125c38840424c4a85fa12bab2ab606c4b6d0e7cc73c0c06ba5300eab500</span>;</span></span>
</span>
    function</span> _getMainStorage</span>(</span>)</span> private</span> pure</span> returns</span> (</span>MainStorage</span> storage</span> $</span>)</span> {</span></span>
        assembly</span> {</span></span>
            $</span>.</span>slot </span>:=</span> MAIN_STORAGE_LOCATION</span></span>
        }</span></span>
    }</span></span>
</span>
    function</span> _getXTimesY</span>(</span>)</span> internal</span> view</span> returns</span> (</span>uint256</span>)</span> {</span></span>
        MainStorage </span>storage</span> $ </span>=</span> _getMainStorage</span>(</span>)</span>;</span></span>
        return</span> $</span>.</span>x </span>*</span> $</span>.</span>y</span>;</span></span>
    }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Namespaces should avoid collisions with other namespaces or with standard Solidity or Vyper storage layout. The formula defined in this ERC guarantees this property for arbitrary namespace ids under the assumption of keccak256 collision resistance, as discussed in Rationale.</p>
@custom:storage-location</code> is a NatSpec annotation that current compilers don't enforce any rules for or ascribe any meaning to. The contract developer is responsible for implementing the pattern and using the namespace as claimed in the annotation.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


ERC-721 Multi-Metadata Extension
2023-06-09T00:00:00+00:00
Abstract</h2>
This EIP proposes an extension to the ERC-721</a> standard to support multiple metadata URIs per token. It introduces a new interface, IERC721MultiMetadata</code>, which provides methods for accessing the metadata URIs associated with a token, including a pinned URI index and a list of all metadata URIs. The extension is designed to be backward compatible with existing ERC721Metadata</code> implementations.</p>
Motivation</h2>
The current ERC-721</a> standard allows for a single metadata URI per token with the ERC721Metadata</code> implementation. However, there are use cases where multiple metadata URIs are desirable. Some example use cases are listed below:</p>

A token represents a collection of (cycling) assets with individual metadata</li>
An on-chain history of revisions to token metadata</li>
Appending metadata with different aspect ratios so that it can be displayed properly on all screens</li>
Dynamic and evolving metadata</li>
Collaborative and multi-artist tokens</li>
</ul>
This extension enables such use cases by introducing the concept of multi-metadata support.</p>
The primary reason for having a multi-metadata standard in addition to the existing ERC721Metadata</code> standard is that dapps and marketplaces don't have a mechanism to infer and display all the token URIs. Giving a standard way for marketplaces to offer collectors a way to pin/unpin one of the metadata choices also enables quick and easy adoption of this functionality.</p>
Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p>
The multi-metadata extension is OPTIONAL for ERC-721</a> contracts and it is RECOMMENDED to be used in conjunction with the ERC-4906</a> standard if implemented</strong>.</p>
///</span> @title</span> EIP-721 Multi-Metdata Extension</span></span>
///</span> @dev</span> The ERC-165 identifier for this interface is 0x06e1bc5b.</span></span>
interface</span> IERC7160</span> {</span></span>
</span>
  ///</span> @dev</span> This event emits when a token uri is pinned and is</span></span>
  ///</span>  useful for indexing purposes.</span></span>
  event</span> TokenUriPinned</span>(</span>uint256</span> indexed</span> tokenId</span>, </span>uint256</span> indexed</span> index</span>)</span>;</span></span>
</span>
  ///</span> @dev</span> This event emits when a token uri is unpinned and is</span></span>
  ///</span>  useful for indexing purposes.</span></span>
  event</span> TokenUriUnpinned</span>(</span>uint256</span> indexed</span> tokenId</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Get all token uris associated with a particular token</span></span>
  ///</span> @dev</span> If a token uri is pinned, the index returned SHOULD be the index in the string array</span></span>
  ///</span> @dev</span> This call MUST revert if the token does not exist</span></span>
  ///</span> @param</span> tokenId</span> The identifier for the nft</span></span>
  ///</span> @return</span> index</span> An unisgned integer that specifies which uri is pinned for a token (or the default uri if unpinned)</span></span>
  ///</span> @return</span> uris</span> A string array of all uris associated with a token</span></span>
  ///</span> @return</span> pinned</span> A boolean showing if the token has pinned metadata or not</span></span>
  function</span> tokenURIs</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>uint256</span> index</span>,</span> string</span>[</span>]</span> memory</span> uris</span>,</span> bool</span> pinned</span>)</span>;</span></span>
</span>
  ///</span> @notice</span> Pin a specific token uri for a particular token</span></span>
  ///</span> @dev</span> This call MUST revert if the token does not exist</span></span>
  ///</span> @dev</span> This call MUST emit a `TokenUriPinned` event</span></span>
  ///</span> @dev</span> This call MAY emit a `MetadataUpdate` event from ERC-4096</span></span>
  ///</span> @param</span> tokenId</span> The identifier of the nft</span></span>
  ///</span> @param</span> index</span> The index in the string array returned from the `tokenURIs` function that should be pinned for the token</span></span>
  function</span> pinTokenURI</span>(</span>uint256</span> tokenId</span>,</span> uint256</span> index</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Unpin metadata for a particular token</span></span>
  ///</span> @dev</span> This call MUST revert if the token does not exist</span></span>
  ///</span> @dev</span> This call MUST emit a `TokenUriUnpinned` event</span></span>
  ///</span> @dev</span> This call MAY emit a `MetadataUpdate` event from ERC-4096</span></span>
  ///</span> @dev</span> It is up to the developer to define what this function does and is intentionally left open-ended</span></span>
  ///</span> @param</span> tokenId</span> The identifier of the nft</span></span>
  function</span> unpinTokenURI</span>(</span>uint256</span> tokenId</span>)</span> external</span>;</span></span>
</span>
  ///</span> @notice</span> Check on-chain if a token id has a pinned uri or not</span></span>
  ///</span> @dev</span> This call MUST revert if the token does not exist</span></span>
  ///</span> @dev</span> Useful for on-chain mechanics that don't require the tokenURIs themselves</span></span>
  ///</span> @param</span> tokenId</span> The identifier of the nft</span></span>
  ///</span> @return</span> pinned</span> A bool specifying if a token has metadata pinned or not</span></span>
  function</span> hasPinnedTokenURI</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>bool</span> pinned</span>)</span>;</span></span>
}</span></span></code></pre>
The TokenUriPinned</code> event MUST be emitted when pinning a token uri with the pinTokenUri</code> function.</p>
The TokenUriUnpinned</code> event MUST be emitted when unpinning a token uri with the unpinTokenUri</code> function.</p>
The tokenURI</code> function defined in the ERC-721 Metadata extension MUST return the pinned URI when a token has a pinned uri.</p>
The tokenURI</code> function defined in the ERC-721 Metadata extension MUST return a default uri when a token has an unpinned uri.</p>
The supportsInterface</code> method MUST return true</code> when called with 0x06e1bc5b</code>.</p>
Implementing functionality to add or remove uris to a token MUST be implemented separately from this standard. It is RECOMMENDED that one of the event defined in ERC-4906</a> are emitted whenever uris are added or removed.</p>
See the Implementation</a> section for an example.</p>
Rationale</h2>
Similar terminology to ERC-721</a> was used in order to keep fetching metadata familiar. The concept of pinning and unpinning metadata is introduced as it is clear that NFT owners might want to choose which piece of metadata to display. At first, we considered leaving the pinning and unpinning actions up to each developer, but realized that a standard interface for pinning and unpinning allows for dApps to easily implement universal support for multi-metadata tokens.</p>
We first considered whether the tokenURIs</code> function should return just a string array, but added the extra information so that you could get all info desired in one call instead of potentially three calls. The pinned URI should be used as the primary URI for the token, while the list of metadata URIs can be used to access individual assets' metadata within the token. dApps could present these as a gallery or media carousels.</p>
The TokenUriPinned</code> and TokenUriUnpinned</code> events included in this specification can be used by dApps to index what metadata to show. This can eliminate on-chain calls and event driven architecture can be used instead.</p>
The reason why this standard recommends the use of ERC-4906</a> when adding or removing uris from a token is that there is already wide dApp support for this event and it already is what is needed - an alert to dApps that metadata for a token has been updated. We did not want to potentially cause dApp issues with duplicate events. A third party listening to this event could then call the tokenURIs</code> function to get the updated metadata.</p>
Backwards Compatibility</h2>
This extension is designed to be backward compatible with existing ERC-721</a> contracts. The implementation of the tokenURI</code> method must either return the pinned token uri (if pinned) or some default uri (if unpinned).</p>
Reference Implementation</h2>
An open-source reference implementation of the IERC721MultiMetadata</code> interface can be provided, demonstrating how to extend an existing ERC-721</a> contract to support multi-metadata functionality. This reference implementation can serve as a guide for developers looking to implement the extension in their own contracts.</p>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
</span>
pragma</span> solidity</span> ^0.8.19</span>;</span></span>
</span>
import</span> {</span>ERC721</span>}</span> from</span> "@openzeppelin/contracts/token/ERC721/ERC721.sol"</span>;</span></span>
import</span> {</span>Ownable</span>}</span> from</span> "@openzeppelin/contracts/access/Ownable.sol"</span>;</span></span>
import</span> {</span>IERC4906</span>}</span> from</span> "@openzeppelin/contracts/interfaces/IERC4906.sol"</span>;</span></span>
import</span> {</span>IERC7160</span>}</span> from</span> "./IERC7160.sol"</span>;</span></span>
</span>
contract</span> MultiMetadata</span> is</span> ERC721</span>, </span>Ownable</span>, </span>IERC7160</span>, </span>IERC4906</span> {</span></span>
  mapping</span>(</span>uint256</span> =></span> string</span>[</span>]</span>)</span> private</span> _tokenURIs</span>;</span></span>
  mapping</span>(</span>uint256</span> =></span> uint256</span>)</span> private</span> _pinnedURIIndices</span>;</span></span>
  mapping</span>(</span>uint256</span> =></span> bool</span>)</span> private</span> _hasPinnedTokenURI</span>;</span></span>
</span>
  constructor</span>(</span>string</span> memory</span> _name</span>,</span> string</span> memory</span> _symbol</span>)</span> ERC721</span>(</span>_name, _symbol) </span>Ownable</span>(</span>) </span>{</span></span>
    _mint</span>(</span>msg.sender</span>,</span> 1</span>)</span>;</span></span>
  }</span></span>
</span>
  //</span> @notice Returns the pinned URI index or the last token URI index (length - 1).</span></span>
  function</span> _getTokenURIIndex</span>(</span>uint256</span> tokenId</span>)</span> internal</span> view</span> returns</span> (</span>uint256</span>)</span> {</span></span>
    return</span> _hasPinnedTokenURI</span>[</span>tokenId</span>]</span> ?</span> _pinnedURIIndices</span>[</span>tokenId</span>]</span> :</span> _tokenURIs</span>[</span>tokenId</span>]</span>.</span>length </span>-</span> 1</span>;</span></span>
  }</span></span>
</span>
  //</span> @notice Implementation of ERC721.tokenURI for backwards compatibility.</span></span>
  //</span> @inheritdoc ERC721.tokenURI</span></span>
  function</span> tokenURI</span>(</span>uint256</span> tokenId</span>)</span> public</span> view</span> virtual</span> override</span> returns</span> (</span>string</span> memory</span>)</span> {</span></span>
    _requireMinted</span>(</span>tokenId</span>)</span>;</span></span>
</span>
    uint256</span> index </span>=</span> _getTokenURIIndex</span>(</span>tokenId</span>)</span>;</span></span>
    string</span>[</span>]</span> memory</span> uris </span>=</span> _tokenURIs</span>[</span>tokenId</span>]</span>;</span></span>
    string</span> memory</span> uri </span>=</span> uris</span>[</span>index</span>]</span>;</span></span>
</span>
    //</span> Revert if no URI is found for the token.</span></span>
    require</span>(</span>bytes</span>(</span>uri</span>)</span>.</span>length </span>></span> 0</span>,</span> "ERC721: not URI found"</span>)</span>;</span></span>
    return</span> uri</span>;</span></span>
  }</span></span>
</span>
  ///</span> @inheritdoc</span> IERC721MultiMetadata.tokenURIs</span></span>
  function</span> tokenURIs</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>uint256</span> index</span>,</span> string</span>[</span>]</span> memory</span> uris</span>,</span> bool</span> pinned</span>)</span> {</span></span>
    _requireMinted</span>(</span>tokenId</span>)</span>;</span></span>
    return</span> (</span>_getTokenURIIndex</span>(</span>tokenId</span>)</span>,</span> _tokenURIs</span>[</span>tokenId</span>]</span>,</span> _hasPinnedTokenURI</span>[</span>tokenId</span>]</span>)</span>;</span></span>
  }</span></span>
</span>
  ///</span> @inheritdoc</span> IERC721MultiMetadata.pinTokenURI</span></span>
  function</span> pinTokenURI</span>(</span>uint256</span> tokenId</span>,</span> uint256</span> index</span>)</span> external</span> {</span></span>
    require</span>(</span>msg.sender</span> ==</span> ownerOf</span>(</span>tokenId</span>)</span>,</span> "Unauthorized"</span>)</span>;</span></span>
    _pinnedURIIndices</span>[</span>tokenId</span>]</span> =</span> index</span>;</span></span>
    _hasPinnedTokenURI</span>[</span>tokenId</span>]</span> =</span> true</span>;</span></span>
    emit</span> TokenUriPinned</span>(</span>tokenId</span>,</span> index</span>)</span>;</span></span>
  }</span></span>
</span>
  ///</span> @inheritdoc</span> IERC721MultiMetadata.unpinTokenURI</span></span>
  function</span> unpinTokenURI</span>(</span>uint256</span> tokenId</span>)</span> external</span> {</span></span>
    require</span>(</span>msg.sender</span> ==</span> ownerOf</span>(</span>tokenId</span>)</span>,</span> "Unauthorized"</span>)</span>;</span></span>
    _pinnedURIIndices</span>[</span>tokenId</span>]</span> =</span> 0</span>;</span></span>
    _hasPinnedTokenURI</span>[</span>tokenId</span>]</span> =</span> false</span>;</span></span>
    emit</span> TokenUriUnpinned</span>(</span>tokenId</span>)</span>;</span></span>
  }</span></span>
</span>
  ///</span> @inheritdoc</span> IERC721MultiMetadata.hasPinnedTokenURI</span></span>
  function</span> hasPinnedTokenURI</span>(</span>uint256</span> tokenId</span>)</span> external</span> view</span> returns</span> (</span>bool</span> pinned</span>)</span> {</span></span>
    return</span> _hasPinnedTokenURI</span>[</span>tokenId</span>]</span>;</span></span>
  }</span></span>
</span>
  ///</span> @notice</span> Sets a specific metadata URI for a token at the given index.</span></span>
  function</span> setUri</span>(</span>uint256</span> tokenId</span>,</span> uint256</span> index</span>,</span> string</span> calldata</span> uri</span>)</span> external</span> onlyOwner</span> {</span></span>
    if</span> (</span>_tokenURIs</span>[</span>tokenId</span>]</span>.</span>length </span>></span> index</span>)</span> {</span></span>
      _tokenURIs</span>[</span>tokenId</span>]</span>[</span>index</span>]</span> =</span> uri</span>;</span></span>
    }</span> else</span> {</span></span>
      _tokenURIs</span>[</span>tokenId</span>]</span>.</span>push</span>(</span>uri</span>)</span>;</span></span>
    }</span></span>
</span>
    emit</span> MetadataUpdate</span>(</span>tokenId</span>)</span>;</span></span>
  }</span></span>
</span>
  //</span> Overrides supportsInterface to include IERC721MultiMetadata interface support.</span></span>
  function</span> supportsInterface</span>(</span>bytes4</span> interfaceId</span>)</span> public</span> view</span> virtual</span> override</span>(</span>IERC165</span>,</span> ERC721</span>)</span> returns</span> (</span>bool</span>)</span> {</span></span>
    return</span> (</span></span>
      interfaceId </span>==</span> type</span>(</span>IERC7160</span>)</span>.</span>interfaceId </span>||</span></span>
      super</span>.</span>supportsInterface</span>(</span>interfaceId</span>)</span></span>
    )</span>;</span></span>
  }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Care should be taken when specifying access controls for state changing events, such as those that allow uris to be added to tokens
and those specified in this standard: the pinTokenUri</code> and unpinTokenUri</code> functions. This is up to the developers to specify
as each application may have different requirements to allow for pinning and unpinning.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


On-Chain Data Containers
2023-06-09T00:00:00+00:00
Abstract</h2>
This ERC defines a series of interfaces for the abstraction of storage of on-chain data by implementing the logic functions that govern such data on independent smart contracts. "On-chain Data Containers" (ODCs) refer to the separation and indexing of data storage away from data management. We propose that on-chain data can be abstracted and stored in smart contracts called "Data Objects" (DO), which answer to external data indexing mechanisms named "Data Points" (DP). This data can be accessed and modified by implementing (one or many) separate smart contracts identified as "Data Managers" (DM). We introduce two mechanisms for access management: first, through a "Data Index" (DI) implementation, the "Data Managers" (DM) can be gated from accessing "Data Objects" (DO); second, a "Data Point Registry" (DPR) implementation manages the issuance of "Data Points" (DP). Lastly, we introduce the concept of data portability (horizontal data mobility) between implementations of "Data Index" (DI), enabling massive updates to the logic without affecting the underlying data storage.</p>
Motivation</h2>
As the Ethereum ecosystem grows, so does the demand for on-chain functionalities. The market encourages a desire for broader adoption through more complex systems and there is a constant need for improved efficiency. We have seen times when an explosion of new standard token proposals was solely driven by market hype. While ultimately each standard serves its purpose, most of them require more flexibility to manage interoperability with other standards. A standard adapter mechanism is needed to enhance interoperability by driving the interactions between assets issued under different ERCs.</p>
Without such mechanisms, most projects have implemented bespoke solutions for interoperability. This is an inefficient approach and leads to a fragmented ecosystem. We recognize there is no “one size fits all” solution to solve the standardization and interoperability challenges. Most assets - Fungible, Non-Fungible, Digital Twins, Real-world Assets, DePin, etc - have multiple mechanisms for representing them as on-chain tokens through the use of different standard interfaces and the diversity of standards spurs innovation.</p>
However, for these assets to be exchanged, traded, or otherwise interacted with, protocols must implement compatibility with the relevant interfaces to access and modify on-chain data. This is especially challenging when considering the previously mentioned bespoke solutions for interoperability. Additionally, the immutability of smart contracts complicates the ability of already deployed protocols to adapt to new tokenization standards, which is critical for future-proofing implementations. A collaborative effort must be made to enable interaction between assets tokenized under different standards. The current ERC provides the tools for developing such on-chain adapters.</p>
We aim to abstract the on-chain data handling from the logical implementation, exposing the underlying data independently of the ERC interface. We propose a series of interfaces for storing and accessing data on-chain in contracts called "Data Objects" (DO), grouping the underlying assets as generic "Data Points" (DP) that may be associated with multiple interoperable and even concurrent "Data Manager" (DM) contracts. This proposal is designed to work by coexisting with previous and future token standards, providing a flexible, efficient, and coherent mechanism to manage asset interoperability.</p>


Data Abstraction</strong>: We propose a standardized interface for enabling developers to separate the data storage code from the underlying token utility logic, reducing the need for supporting and implementing multiple inherited -and often clashing- interfaces to achieve asset compatibility. The data (and therefore the assets) can be stored independently of the logic that governs such data.</p>
</li>

Standard Neutrality</strong>: A neutral approach must enable the underlying data of any tokenized asset to transition seamlessly between different token standards. This will significantly improve interoperability among other standards, reducing fragmentation in the landscape. Our proposal aims to separate the storage of data representing an underlying asset from the standard interface used for representing the token.</p>
</li>

Consistent Interface</strong>: A uniform interface of primitive functions abstracts the data storage from the use case, irrespective of the underlying token's standard or the interface exposing such data. Data and metadata can be stored on-chain, and exposed through the same primitives.</p>
</li>

Data Portability</strong>: We provide a mechanism for the Horizontal Mobility of data between implementations of this standard, incentivizing the implementation of interoperable solutions and standard adapters.</p>
</li>
</ul>
Specification</h2>
Terms</h3>
Data Point</strong>: A uniquely identifiable reference to an on-chain data structure stored within one or many Data Objects</strong> and managed by one or many Data Managers</strong>. Data Points</strong> are issued by a Data Point Registry</strong>.</p>
Data Object</strong>: A Smart Contract implementing the low-level storage management of information indexed through Data Points</strong>.</p>
Data Manager</strong>: One or many Smart Contracts implementing the high-level logic and end-user interfaces for managing Data Objects.</p>
Data Point Registry</strong>: One or many Smart Contracts used for managing the issuance of Data Points</strong>. Additionally, a Data Point Registry</strong> defines a space of compatible or interoperable Data Points</strong>.</p>
Data Index</strong>: One or many Smart Contracts used for managing the access of Data Managers</strong> to Data Objects</strong>.</p>
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Data Point Structure</h3>

Data Point MUST be bytes32</code> storage units.</li>
Data Point SHOULD NOT be used for storing asset data.</li>
Data Point SHOULD be used for indexing data.</li>
Data Point SHOULD use a 4 bytes prefix for storing information relevant to the compatibility with other Data Points.</li>
Data Point MUST use 4 bytes for storing the Chain ID</li>
Data Point SHOULD use the last 20 bytes for identifying which Registry allocated them.</li>
The RECOMMENDED internal structure of the Data Point is as follows:</li>
</ul>
/**</span></span>
 * RECOMMENDED internal DataPoint structure on the Reference Implementation:</span></span>
 * 0xPPPPVVRRIIIIIIIIHHHHHHHHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</span></span>
 * - Prefix (bytes4)</span></span>
 * -- PPPP - Type prefix (i.e. 0x4450 - ASCII representation of letters "DP")</span></span>
 * -- VV   - Version of DataPoint specification (i.e. 0x00 for the reference implementation)</span></span>
 * -- RR   - Reserved</span></span>
 * - Registry-local identifier</span></span>
 * -- IIIIIIII - 32 bit implementation-specific id of the DataPoint</span></span>
 * - Chain ID (bytes4)</span></span>
 * -- HHHHHHHH - 32 bit of chain identifier</span></span>
 * - REGISTRY Address (bytes20)</span></span>
 * -- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - Address of Registry which allocated the DataPoint</span></span>
*</span>*/</span></span></code></pre>
Data Points</strong> are a low-level structure abstracting and indexing information. Data Points</strong> act as pointers to information stored within data structures in Data Objects</strong>.
Data Points</strong> are allocated by a Data Point Registry</strong>. The Data Point</strong> SHOULD store which Data Point Registry</strong> initialized it within its internal structure. Each Data Point</strong> SHOULD have a unique identifier provided by the Data Point Registry</strong> when instantiated.</p>
Data Object Interface</h3>

Data Object SHOULD be used for storing asset data.</li>
Data Object SHOULD use Data Points</strong> for indexing the structure storing the data.</li>
Data Object SHOULD implement the logic directly related to handling the data structure.</li>
Data Object SHOULD implement the logic for transferring management of its Data Points</strong> to a different Data Index</strong> implementation.</li>
Data Object MUST use the IDataObject interface:</li>
</ul>
interface</span> IDataObject</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> Reads stored data</span></span>
     * </span>@param</span> dp</span> Identifier of the DataPoint</span></span>
     * </span>@param</span> operation</span> Read operation to run on the data</span></span>
     * </span>@param</span> data</span> Operation-specific data</span></span>
     * </span>@return</span> Operation</span>-specific data</span></span>
     */</span></span>
    function</span> read</span>(</span>bytes32</span> dp</span>,</span> bytes4</span> operation</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span> view</span> returns</span>(</span>bytes</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Store data</span></span>
     * </span>@param</span> dp</span> Identifier of the DataPoint</span></span>
     * </span>@param</span> operation</span> Write operation to execute on the data</span></span>
     * </span>@param</span> data</span> Operation-specific data</span></span>
     * </span>@return</span> Operation</span>-specific data (can be empty)</span></span>
     */</span></span>
    function</span> write</span>(</span>bytes32</span> dp</span>,</span> bytes4</span> operation</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span> returns</span>(</span>bytes</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Sets DataIndex Implementation</span></span>
     * </span>@param</span> dp</span> Identifier of the DataPoint</span></span>
     * </span>@param</span> newImpl</span> address of the new DataIndex implementation</span></span>
     */</span></span>
    function</span> setDIImplementation</span>(</span>bytes32</span> dp</span>,</span> address</span> newImpl</span>)</span> external</span>;</span></span>
}</span></span></code></pre>
Data Objects</strong> are entrusted with the storage and management of data. Data Objects</strong> SHOULD implement the logic for managing the storage of on-chain data. Data Object</strong> internal data structure SHOULD use Data Points</strong> for indexing information.</p>
Data Objects</strong> CAN receive read()</code>, write()</code>, or any other custom requests from a Data Manager</strong> requesting access to a storage structure indexed by a Data Point</strong>.</p>
As such, Data Objects</strong> respond to a gating mechanism given by a single Data Index</strong>. The function setDIImplementation()</code> SHOULD enable the delegation of the management function to an IDataIndex</code> implementation.</p>
Data Manager Contract</h3>

Data Manager SHOULD use IDataIndex.read()</code> or IDataObject.read()</code> to read data from Data Objects</strong></li>
Data Manager MUST use IDataIndex.write()</code> to write data to Data Objects</strong></li>
Data Manager MAY share Data Point</strong> with other Data Managers</strong></li>
Data Manager MAY use multiple Data Points</strong></li>
Data Manager SHOULD implement the logic for requesting Data Points</strong> from a Data Point Registry</strong>.</li>
</ul>
Data Managers</strong> are independent smart contracts that implement the business logic or "high-level" data management. They can read()</code> from a Data Object</strong> address and write()</code> through a Data Index</strong> implementation managing the delegated storage of the Data Points</strong>.</p>
Data Point Registry Interface</h3>

Data Point Registry SHOULD define functions to manage the creation, transfer, and access control of Data Points</strong></li>
Data Point Registry SHOULD manage Data Point</strong> access management for Data Managers</strong></li>
Data Point Registry MUST use the IDataPointRegistry interface:</li>
</ul>
interface</span> IDataPointRegistry</span> {</span></span>
</span>
  /**</span></span>
     * </span>@notice</span> Verifies if an address has an Admin role for a DataPoint</span></span>
     * </span>@param</span> dp</span> DataPoint</span></span>
     * </span>@param</span> account</span> Account to verify</span></span>
     */</span></span>
    function</span> isAdmin</span>(</span>bytes32</span> dp</span>,</span> address</span> account</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Allocates a DataPoint to an owner</span></span>
     * </span>@param</span> owner</span> Owner of the new DataPoint</span></span>
     * </span>@dev</span> Owner should be granted Admin role during allocation</span></span>
     */</span></span>
    function</span> allocate</span>(</span>address</span> owner</span>)</span> external</span> payable</span> returns</span> (</span>DataPoint</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Transfers a DataPoint to an owner</span></span>
     * </span>@param</span> dp</span> Data Point to be transferred</span></span>
     * </span>@param</span> owner</span> Owner of the new DataPoint</span></span>
     */</span></span>
    function</span> transferOwnership</span>(</span>bytes32</span> dp</span>,</span> address</span> newOwner</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Grant permission to grant/revoke other roles on the DataPoint inside a Data Index Implementation</span></span>
     * This is useful if DataManagers are deployed during lifecycle of the application.</span></span>
     * </span>@param</span> dp</span> DataPoint</span></span>
     * </span>@param</span> account</span> New admin</span></span>
     * </span>@return</span> If</span> the role was granted (otherwise account already had the role)</span></span>
     */</span></span>
    function</span> grantAdminRole</span>(</span>bytes32</span> dp</span>,</span> address</span> account</span>)</span> external</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Revoke permission to grant/revoke other roles on the DataPoint inside a Data Index Implementation</span></span>
     * </span>@param</span> dp</span> DataPoint</span></span>
     * </span>@param</span> account</span> Old admin</span></span>
     * </span>@dev</span> If an owner revokes Admin role from himself, he can add it again</span></span>
     * </span>@return</span> If</span> the role was revoked (otherwise account didn't have the role)</span></span>
     */</span></span>
    function</span> revokeAdminRole</span>(</span>bytes32</span> dp</span>,</span> address</span> account</span>)</span> external</span> returns</span> (</span>bool</span>)</span>;</span></span>
}</span></span></code></pre>
The Data Point Registry</strong> is a smart contract entrusted with Data Point</strong> access control. Data Managers</strong> may request the allocation of Data Points</strong> to the Data Point Registry</strong>.</p>
Data Index Interface</h3>

DataIndex SHOULD manage the access of Data Managers</strong> to Data Objects</strong>.</li>
DataIndex SHOULD manage internal IDs for each user.</li>
DataIndex MUST use the IDataIndex interface:</li>
</ul>
interface</span> IDataIndex</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> Verifies if DataManager is allowed to write specific DataPoint on specific DataObject</span></span>
     * </span>@param</span> dp</span> Identifier of the DataPoint</span></span>
     * </span>@param</span> dm</span> Address of DataManager</span></span>
     * </span>@return</span> if</span> write access is allowed</span></span>
     */</span></span>
    function</span> isApprovedDataManager</span>(</span>bytes32</span> dp</span>,</span> address</span> dm</span>)</span> external</span> view</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Defines if DataManager is allowed to write specific DataPoint</span></span>
     * </span>@param</span> dp</span> Identifier of the DataPoint</span></span>
     * </span>@param</span> dm</span> Address of DataManager</span></span>
     * </span>@param</span> approved</span> if DataManager should be approved for the DataPoint</span></span>
     * </span>@dev</span> Function should be restricted to DataPoint maintainer only</span></span>
     */</span></span>
    function</span> allowDataManager</span>(</span>bytes32</span> dp</span>,</span> address</span> dm</span>,</span> bool</span> approved</span>)</span> external</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Reads stored data</span></span>
     * </span>@param</span> dobj</span> Identifier of DataObject</span></span>
     * </span>@param</span> dp</span> Identifier of the datapoint</span></span>
     * </span>@param</span> operation</span> Read operation to execute on the data</span></span>
     * </span>@param</span> data</span> Operation-specific data</span></span>
     * </span>@return</span> Operation</span>-specific data</span></span>
     */</span></span>
    function</span> read</span>(</span>address</span> dobj</span>,</span> bytes32</span> dp</span>,</span> bytes4</span> operation</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span> view</span> returns</span>(</span>bytes</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
     * </span>@notice</span> Store data</span></span>
     * </span>@param</span> dobj</span> Identifier of DataObject</span></span>
     * </span>@param</span> dp</span> Identifier of the datapoint</span></span>
     * </span>@param</span> operation</span> Read operation to execute on the data</span></span>
     * </span>@param</span> data</span> Operation-specific data</span></span>
     * </span>@return</span> Operation</span>-specific data (can be empty)</span></span>
     * </span>@dev</span> Function should be restricted to allowed DMs only</span></span>
     */</span></span>
    function</span> write</span>(</span>address</span> dobj</span>,</span> bytes32</span> dp</span>,</span> bytes4</span> operation</span>,</span> bytes</span> calldata</span> data</span>)</span> external</span> returns</span>(</span>bytes</span> memory</span>)</span>;</span></span>
}</span></span></code></pre>
The Data Index</strong> is a smart contract entrusted with access control. It is a gating mechanism for Data Managers</strong> to access Data Objects</strong>. If a Data Manager</strong> intends to access a Data Point</strong> (either by read()</code>, write()</code>, or any other method), the Data Index</strong> SHOULD be used for validating access to the data.</p>
The mechanism for ID management determines a space of compatibility between implementations.</p>
Rationale</h2>
The decision to encode Data Points</strong> as bytes32</code> data pointers is primarily driven by flexibility and future-proofing. The use bytes32</code> allows for a wide range of data encodings. This provides the developer with many options to accommodate diverse use cases. Furthermore, as Ethereum and its standards continue to evolve, encoding as bytes32</code> ensures that the Standard Adapters built with the current ERC can reference future data types or structures without requiring significant changes to the adapter itself. The Data Point</strong> encoding should have a prefix so that the Data Object</strong> can efficiently identify compatibility issues when accessing the data storage. Additionally, the prefix should be used to find the Data Point Registry</strong> and verify admin access to the Data Point</strong>. The use of a suffix for identifying the Data Point Registry</strong> is also required, for the Data Object</strong> to quickly discard badly formed transactions that aim to use a Data Point</strong> from an unmatching Data Point Registry</strong>.</p>
Data Manager</strong> implementations decide which Data Points</strong> they will be using. Their allocation is managed through a Data Point Registry</strong>, and the write()</code> access to the Data Point</strong> is managed by passing through the Data Index</strong> implementation.</p>
Data Objects</strong> are independent separate Smart Contracts that implement the same read</code>/write</code> interface for communicating with Data Managers</strong>. This is a decision mainly driven by the scalability of the system. Offering a simple interface for this layered structure enables different applications to have their addresses for storage of data independently from the asset's interface. It is up to each implementation to manage access to their Data Point</strong> storage space. This enables a wide array of complex, dynamic, and interactive use cases to be implemented with multiple ERCs as well as other smart contracts, including the embedding of cross-chain and rollup logic for asset management.</p>
Data Objects</strong> offer flexibility in storing mutable on-chain data that can be modified as per the requirements of each specific use case. This enables the Data Managers</strong> to hold mutable states in delegated storage and reflect changes over time, providing a dynamic layer to the otherwise static nature of storage through most other standardized interfaces.</p>
Data Managers</strong> can decide to migrate the complete storage management of a Data Object</strong> from one Data Index</strong> implementation to another. As the Data Index</strong> implements user ID management, this mechanism enables a Data Manager</strong> to upgrade its internal access control mechanisms without affecting the underlying storage of value, as it is located elsewere (in the Data Object</strong>). We call this mechanism "Horizontal Data Mobility/Portability".</p>
Backwards Compatibility</h2>
This ERC is intended to augment the functionality of existing token standards without introducing breaking changes. As such, it does not present any backward compatibility issues. Already deployed tokens under other ERCs can be wrapped and indexed as Data Points</strong> and managed by Data Objects</strong>, and later exposed through any implementation of Data Managers</strong>. All interoperability integrations will require a compatibility analysis, depending on the use case. However, the interfaces defined in this ERC define a framework for adapting one standard to another through storage abstraction.</p>
Reference Implementation</h2>
We present an educational example</em> implementation of a Standard Adapter showcasing two types of tokens (Fungible and Semi-Fungible) with shared data storage. The end user can interact with this implementation through one of two types of interfaces: The semi-fungible one (represented through a single Data Manager</strong>), and the fungible interface (represented by many Data Managers</strong>). The abstraction of the storage from the logic is achieved through the use of a single Fungible Fractions</em> Data Object</strong>. A factory is used for deploying the Fungible token interfaces that share storage with each semi-fungible collection. Note that if a transfer()</code> is called by either interface (Fungible or Semi-Fungible), both interfaces are emitting an event.</p>
This example has not been audited and should not be used in production environments.</strong></p>
See contracts</a></p>
Security Considerations</h2>
The access control is separated into three layers:</p>

Layer 1</strong>: The Data Point Registry</strong> allocates for Data Managers</strong> and manages ownership (admin/write rights) of Data Points</strong>.</li>
Layer 2</strong>: The Data Index</strong> smart contract implements Access Control by managing Approvals of Data Managers</strong> to Data Points</strong>. It uses the Data Point Registry</strong> to verify who can grant/revoke this access.</li>
Layer 3</strong>: The DataObject</strong> manages trust relationship between the DataPoint</strong> and a DataIndex</strong>  implementation and allows a trusted DataIndex</strong> to execute write</code> operations.</li>
</ul>
A common task for a Data Object</strong> is to store user-related data, while the Data Manager</strong> implements the logic for managing such data. Both Data Objects</strong> and Data Managers</strong> often require the management of user IDs. A Data Index</strong> can offer logic for user management (i.e. IDs based on address</code>) that are independent of any particular implementation, but care must be taken in selecting these identifiers. If chosen improperly, they could hinder a Data Manager</strong>'s ability to migrate between different Data Indexes</strong>.</p>
No further security considerations are derived specifically from this ERC.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Financial Bonds
2023-05-28T00:00:00+00:00
Abstract</h2>
This proposal introduces fixed-income financial bonds with key characteristics defined to facilitate bond issuance in the primary market and enable buying or selling bonds in the secondary market. The standard also provides cross-chain functionalities for bonds operations and management across multiple blockchains.</p>
Motivation</h2>
Fixed-income instruments are a widely utilized asset class for corporations and other entities raising funds. However, transitioning to tokenized bonds is challenging due to existing standards like ERC-3475</a>, which introduces unfamiliar concepts and leads to unnecessary gas consumption. Additionally, the lack of named variables like coupon, maturity date, and principal, makes it difficult to implement ERC-3475 since developers need to remember which metadata is assigned to each parameter.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Every contract compliant with this ERC MUST implement the following Token Interface as well as the ERC-165</a> interface:</strong></p>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
/**</span></span>
* </span>@title</span> ERC-7092 Financial Bonds Standard</span></span>
*/</span></span>
interface</span> IERC7092</span> /**</span> is ERC165 </span>*/</span> {</span></span>
    //</span> events</span></span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when bond tokens are transferred, issued or redeemed, except during contract creation</span></span>
    * </span>@param</span> _from</span> the account that owns bonds</span></span>
    * </span>@param</span> _to</span> the account that receives the bond</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to be transferred</span></span>
    */</span></span>
    event</span> Transfer</span>(</span>address</span> indexed</span> _from</span>, </span>address</span> indexed</span> _to</span>, </span>uint256</span> _amount</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when an account is approved or when the allowance is decreased</span></span>
    * </span>@param</span> _owner</span> bond token's owner</span></span>
    * </span>@param</span> _spender</span> the account to be allowed to spend bonds</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens allowed by _owner to be spent by `_spender`</span></span>
    *        Or amount of bond tokens to decrease allowance from `_spender`</span></span>
    */</span></span>
    event</span> Approval</span>(</span>address</span> indexed</span> _owner</span>, </span>address</span> indexed</span> _spender</span>, </span>uint256</span> _amount</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when multiple bond tokens are transferred, issued or redeemed, with the exception being during contract creation</span></span>
    * </span>@param</span> _from</span> array of bondholders accounts</span></span>
    * </span>@param</span> _to</span> array of accounts to transfer bonds to</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to be transferred</span></span>
    *</span></span>
    ** OPTIONAL - interfaces and other contracts MUST NOT expect this function to be present. MUST be emitted in `batchTransfer` and `batchTransferFrom` functions</span></span>
    */</span></span>
    event</span> TransferBatch</span>(</span>address</span>[</span>]</span> _from</span>, </span>address</span>[</span>]</span> _to</span>, </span>uint256</span>[</span>]</span> _amount</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when multiple accounts are approved or when the allowance is decreased from multiple accounts</span></span>
    * </span>@param</span> _owner</span> bondholder account</span></span>
    * </span>@param</span> _spender</span> array of accounts to be allowed to spend bonds, or to decrase the allowance from</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens allowed by `_owner` to be spent by multiple accounts in `_spender`.</span></span>
    *</span></span>
    ** OPTIONAL - interfaces and other contracts MUST NOT expect this function to be present. MUST be emitted in `batchApprove` and `batchDecreaseAllowance` functions</span></span>
    */</span></span>
    event</span> ApprovalBatch</span>(</span>address</span> indexed</span> _owner</span>, </span>address</span>[</span>]</span> _spender</span>, </span>uint256</span>[</span>]</span> _amount</span>)</span>;</span></span>
</span>
    //</span> getter functions</span></span>
    /**</span></span>
    *  </span>@notice</span> Returns the bond isin</span></span>
    */</span></span>
    function</span> isin</span>(</span>)</span> external</span> view</span> returns</span>(</span>string</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the bond name</span></span>
    */</span></span>
    function</span> name</span>(</span>)</span> external</span> view</span> returns</span>(</span>string</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the bond symbol</span></span>
    *         It is RECOMMENDED to represent the symbol as a combination of the issuer Issuer'shorter name and the maturity date</span></span>
    *         Ex: If a company named Green Energy issues bonds that will mature on october 25, 2030, the bond symbol could be `GE30` or `GE2030` or `GE102530`</span></span>
    */</span></span>
    function</span> symbol</span>(</span>)</span> external</span> view</span> returns</span>(</span>string</span> memory</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the bond currency. This is the contract address of the token used to pay and return the bond principal</span></span>
    */</span></span>
    function</span> currency</span>(</span>)</span> external</span> view</span> returns</span>(</span>address</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the bond denominiation. This is the minimum amount in which the Bonds may be issued. It must be expressend in unit of the principal currency</span></span>
    *         ex: If the denomination is equal to 1,000 and the currency is USDC, then the bond denomination is equal to 1,000 USDC</span></span>
    */</span></span>
    function</span> denomination</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the issue volume (total debt amount). It is RECOMMENDED to express the issue volume in denomination unit.</span></span>
    */</span></span>
    function</span> issueVolume</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the bond interest rate. It is RECOMMENDED to express the interest rate in basis point unit.</span></span>
    *         1 basis point = 0.01% = 0.0001</span></span>
    *         ex: if interest rate = 5%, then coupon() => 500 basis points</span></span>
    */</span></span>
    function</span> couponRate</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the date when bonds were issued to investors. This is a Unix Timestamp like the one returned by block.timestamp</span></span>
    */</span></span>
    function</span> issueDate</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the bond maturity date, i.e, the date when the principal is repaid. This is a Unix Timestamp like the one returned by block.timestamp</span></span>
    *         The maturity date MUST be greater than the issue date</span></span>
    */</span></span>
    function</span> maturityDate</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the principal of an account. It is RECOMMENDED to express the principal in the bond currency unit (USDC, DAI, etc...)</span></span>
    * </span>@param</span> _account</span> account address</span></span>
    */</span></span>
    function</span> principalOf</span>(</span>address</span> _account</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the amount of tokens the `_spender` account has been authorized by the `_owner``</span></span>
    *         account to manage their bonds</span></span>
    * </span>@param</span> _owner</span> the bondholder address</span></span>
    * </span>@param</span> _spender</span> the address that has been authorized by the bondholder</span></span>
    */</span></span>
    function</span> allowance</span>(</span>address</span> _owner</span>,</span> address</span> _spender</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    //</span> setter functions</span></span>
    /**</span></span>
    * </span>@notice</span> Authorizes `_spender` account to manage `_amount`of their bond tokens</span></span>
    * </span>@param</span> _spender</span> the address to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to approve</span></span>
    */</span></span>
    function</span> approve</span>(</span>address</span> _spender</span>,</span> uint256</span> _amount</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Lowers the allowance of `_spender` by `_amount`</span></span>
    * </span>@param</span> _spender</span> the address to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to remove from allowance</span></span>
    */</span></span>
    function</span> decreaseAllowance</span>(</span>address</span> _spender</span>,</span> uint256</span> _amount</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Moves `_amount` bonds to address `_to`. This methods also allows to attach data to the token that is being transferred</span></span>
    * </span>@param</span> _to</span> the address to send the bonds to</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to transfer</span></span>
    * </span>@param</span> _data</span> additional information provided by the token holder</span></span>
    */</span></span>
    function</span> transfer</span>(</span>address</span> _to</span>,</span> uint256</span> _amount</span>,</span> bytes</span> calldata</span> _data</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Moves `_amount` bonds from an account that has authorized the caller through the approve function</span></span>
    *         This methods also allows to attach data to the token that is being transferred</span></span>
    * </span>@param</span> _from</span> the bondholder address</span></span>
    * </span>@param</span> _to</span> the address to transfer bonds to</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to transfer.</span></span>
    * </span>@param</span> _data</span> additional information provided by the token holder</span></span>
    */</span></span>
    function</span> transferFrom</span>(</span>address</span> _from</span>,</span> address</span> _to</span>,</span> uint256</span> _amount</span>,</span> bytes</span> calldata</span> _data</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    //</span> batch functions</span></span>
    /**</span></span>
    * </span>@notice</span> Authorizes multiple spender accounts to manage a specified `_amount` of the bondholder tokens</span></span>
    * </span>@param</span> _spender</span> array of accounts to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to approve</span></span>
    *</span></span>
    * OPTIONAL - interfaces and other contracts MUST NOT expect these values to be present. The method is used to improve usability.</span></span>
    */</span></span>
    function</span> batchApprove</span>(</span>address</span>[</span>]</span> calldata</span> _spender</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Decreases the allowance of multiple spenders by corresponding amounts in `_amount`</span></span>
    * </span>@param</span> _spender</span> array of accounts to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to decrease the allowance from</span></span>
    *</span></span>
    * OPTIONAL - interfaces and other contracts MUST NOT expect this function to be present. The method is used to decrease token allowance.</span></span>
    */</span></span>
    function</span> batchDecreaseAllowance</span>(</span>address</span>[</span>]</span> calldata</span> _spender</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Transfers multiple bonds with amounts specified in the array `_amount` to the corresponding accounts in the array `_to`, with the option to attach additional data</span></span>
    * </span>@param</span> _to</span> array of accounts to send the bonds to</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to transfer</span></span>
    * </span>@param</span> _data</span> array of additional information provided by the token holder</span></span>
    *</span></span>
    * OPTIONAL - interfaces and other contracts MUST NOT expect this function to be present.</span></span>
    */</span></span>
    function</span> batchTransfer</span>(</span>address</span>[</span>]</span> calldata</span> _to</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>,</span> bytes</span>[</span>]</span> calldata</span> _data</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Transfers multiple bonds with amounts specified in the array `_amount` to the corresponding accounts in the array `_to` from an account that have been authorized by the `_from` account</span></span>
    *         This method also allows to attach data to tokens that are being transferred</span></span>
    * </span>@param</span> _from</span> array of bondholder accounts</span></span>
    * </span>@param</span> _to</span> array of accounts to transfer bond tokens to</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to transfer.</span></span>
    * </span>@param</span> _data</span> array of additional information provided by the token holder</span></span>
    *</span></span>
    ** OPTIONAL - interfaces and other contracts MUST NOT expect this function to be present.</span></span>
    */</span></span>
    function</span> batchTransferFrom</span>(</span>address</span>[</span>]</span> calldata</span> _from</span>,</span> address</span>[</span>]</span> calldata</span> _to</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>,</span> bytes</span>[</span>]</span> calldata</span> _data</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
}</span></span></code></pre>Additional bond parameters Interface</h3>
The IERC7092ESG</code> interface is OPTIONAL for contracts implementing this proposal. This interface MAY be used to improve the standard usability.</p>

The currencyOfCoupon</code> The currency used for coupon payment may be different from the currency used to repay the principal</li>
The couponType</code> MAY be employed to signify the interest rate that the issuer has committed to paying to investors, which may take various forms such as zero coupon, fixed rate, floating rate, and more.</li>
The couponFrequency</code> refers to how often the bond pays interest to its bondholders, and is typically expressed in terms of time periods, such as: Annual, Semi-Annual, Quarterly, or Monthly.</li>
The dayCountBasis</code> is used to calculate the accrued interest on a bond between two coupon payment dates or other specific periods. Some of the day count basis are: Actual/Actual, 30/360, Actual/360, Actual/365, or 30/365</li>
</ul>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
interface</span> IERC7092ESG</span> /**</span> is ERC165 </span>*/</span> {</span></span>
    /**</span></span>
    * </span>@notice</span> Returns the number of decimals used by the bond. For example, if it returns `10`, it means that the token amount MUST be multiplied by 10000000000 to get the standard representation.</span></span>
    */</span></span>
    function</span> decimals</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint8</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Rreturns the coupon currency, which is represented by the contract address of the token used to pay coupons. It can be the same as the one used for the principal</span></span>
    */</span></span>
    function</span> currencyOfCoupon</span>(</span>)</span> external</span> view</span> returns</span>(</span>address</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the coupon type</span></span>
    *         For example, 0 can denote Zero coupon, 1 can denote Fixed Rate, 2 can denote Floating Rate, and so on</span></span>
    */</span></span>
    function</span> couponType</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint8</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the coupon frequency, i.e. the number of times coupons are paid in a year.</span></span>
    */</span></span>
    function</span> couponFrequency</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Returns the day count basis</span></span>
    *         For example, 0 can denote actual/actual, 1 can denote actual/360, and so on</span></span>
    */</span></span>
    function</span> dayCountBasis</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint8</span>)</span>;</span></span>
}</span></span></code></pre>Cross-chain Interface</h3>
The standard permits the implementation of the IERC7092CrossChain</code> interface for cross-chain management of bond tokens. This interface is OPTIONAL and may be used by applications to allow cross-chain transactions. Any function initiating a cross-chain transaction MUST explicitly define the destination chain identifier destinationChainID</code> and specify the target smart contract destinationContract</code>.</p>
//</span> SPDX-License-Identifier: CC0-1.0</span></span>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
interface</span> IERC7092CrossChain</span> /**</span> is ERC165 </span>*/</span> {</span></span>
    //</span> events</span></span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when bond tokens are transferred or redeemed in a cross-chain transaction</span></span>
    * </span>@param</span> _from</span> bondholder account</span></span>
    * </span>@param</span> _to</span> account the transfer bond tokens to</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to be transferred</span></span>
    * </span>@param</span> _destinationChainID</span> The unique ID that identifies the destination Chain</span></span>
    */</span></span>
    event</span> CrossChainTransfer</span>(</span>address</span> indexed</span> _from</span>, </span>address</span> indexed</span> _to</span>, </span>uint256</span> _amount</span>, </span>bytes32</span> _destinationChainID</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when several bond tokens are transferred or redeemed in a cross-chain transaction</span></span>
    * </span>@param</span> _from</span> array of bondholders accounts</span></span>
    * </span>@param</span> _to</span> array of accounts that receive the bond</span></span>
    * </span>@param</span> _amount</span> array of amount of bond tokens to be transferred</span></span>
    * </span>@param</span> _destinationChainID</span> array of unique IDs that identify the destination Chain</span></span>
    */</span></span>
    event</span> CrossChainTransferBatch</span>(</span>address</span>[</span>]</span> _from</span>, </span>address</span>[</span>]</span> _to</span>, </span>uint256</span>[</span>]</span> _amount</span>, </span>bytes32</span>[</span>]</span> _destinationChainID</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when an account is approved to spend the bondholder's tokens in a different chain than the current chain</span></span>
    * </span>@param</span> _owner</span> the bondholder account</span></span>
    * </span>@param</span> _spender</span> the account to be allowed to spend bonds</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens allowed by `_owner` to be spent by `_spender`</span></span>
    * </span>@param</span> _destinationChainID</span> The unique ID that identifies the destination Chain</span></span>
    */</span></span>
    event</span> CrossChainApproval</span>(</span>address</span> indexed</span> _owner</span>, </span>address</span> indexed</span> _spender</span>, </span>uint256</span> _amount</span>, </span>bytes32</span> _destinationChainID</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> MUST be emitted when multiple accounts in the array `_spender` are approved or when the allowances of multiple accounts in the array `_spender` are reduced on the destination chain which MUST be different than the current chain</span></span>
    * </span>@param</span> _owner</span> bond token's owner</span></span>
    * </span>@param</span> _spender</span> array of accounts to be allowed to spend bonds</span></span>
    * </span>@param</span> _amount</span> array of amount of bond tokens allowed by _owner to be spent by _spender</span></span>
    * </span>@param</span> _destinationChainID</span> array of unique IDs that identify the destination Chain</span></span>
    */</span></span>
    event</span> CrossChainApprovalBatch</span>(</span>address</span> indexed</span> _owner</span>, </span>address</span>[</span>]</span> _spender</span>, </span>uint256</span>[</span>]</span> _amount</span>, </span>bytes32</span>[</span>]</span> _destinationChainID</span>)</span>;</span></span>
</span>
    //</span> functions</span></span>
    /**</span></span>
    * </span>@notice</span> Authorizes the `_spender` account to manage a specified `_amount`of the bondholder bond tokens on the destination Chain</span></span>
    * </span>@param</span> _spender</span> account to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to approve</span></span>
    * </span>@param</span> _destinationChainID</span> The unique ID that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> The smart contract to interact with in the destination Chain</span></span>
    */</span></span>
    function</span> crossChainApprove</span>(</span>address</span> _spender</span>,</span> uint256</span> _amount</span>,</span> bytes32</span> _destinationChainID</span>,</span> address</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Authorizes multiple spender accounts in `_spender` to manage specified amounts in `_amount` of the bondholder tokens on the destination chain</span></span>
    * </span>@param</span> _spender</span> array of accounts to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to approve</span></span>
    * </span>@param</span> _destinationChainID</span> array of unique IDs that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> array of smart contracts to interact with in the destination Chain in order to Deposit or Mint tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainBatchApprove</span>(</span>address</span>[</span>]</span> calldata</span> _spender</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>,</span> bytes32</span>[</span>]</span> calldata</span> _destinationChainID</span>,</span> address</span>[</span>]</span> calldata</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Decreases the allowance of `_spender` by a specified `_amount` on the destination Chain</span></span>
    * </span>@param</span> _spender</span> the address to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to remove from allowance</span></span>
    * </span>@param</span> _destinationChainID</span> The unique ID that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> The smart contract to interact with in the destination Chain in order to Deposit or Mint tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainDecreaseAllowance</span>(</span>address</span> _spender</span>,</span> uint256</span> _amount</span>,</span> bytes32</span> _destinationChainID</span>,</span> address</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Decreases the allowance of multiple spenders in `_spender` by corresponding amounts specified in the array `_amount` on the destination chain</span></span>
    * </span>@param</span> _spender</span> array of accounts to be authorized by the bondholder</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to decrease the allowance from</span></span>
    * </span>@param</span> _destinationChainID</span> array of unique IDs that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> array of smart contracts to interact with in the destination Chain in order to Deposit or Mint tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainBatchDecreaseAllowance</span>(</span>address</span>[</span>]</span> calldata</span> _spender</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>,</span> bytes32</span>[</span>]</span> calldata</span> _destinationChainID</span>,</span> address</span>[</span>]</span> calldata</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Moves `_amount` bond tokens to the address `_to` from the current chain to another chain (e.g., moving tokens from Ethereum to Polygon).</span></span>
    *         This methods also allows to attach data to the token that is being transferred</span></span>
    * </span>@param</span> _to</span> account to send bond tokens to</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to transfer</span></span>
    * </span>@param</span> _data</span> additional information provided by the bondholder</span></span>
    * </span>@param</span> _destinationChainID</span> The unique ID that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> The smart contract to interact with in the destination Chain in order to Deposit or Mint bond tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainTransfer</span>(</span>address</span> _to</span>,</span> uint256</span> _amount</span>,</span> bytes</span> calldata</span> _data</span>,</span> bytes32</span> _destinationChainID</span>,</span> address</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Transfers multiple bond tokens with amounts specified in the array `_amount` to the corresponding accounts in the array `_to` from the current chain to another chain (e.g., moving tokens from Ethereum to Polygon).</span></span>
    *         This methods also allows to attach data to the token that is being transferred</span></span>
    * </span>@param</span> _to</span> array of accounts to send the bonds to</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to transfer</span></span>
    * </span>@param</span> _data</span> array of additional information provided by the bondholder</span></span>
    * </span>@param</span> _destinationChainID</span> array of unique IDs that identify the destination Chains.</span></span>
    * </span>@param</span> _destinationContract</span> array of smart contracts to interact with in the destination Chains in order to Deposit or Mint bond tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainBatchTransfer</span>(</span>address</span>[</span>]</span> calldata</span> _to</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>,</span> bytes</span>[</span>]</span> calldata</span> _data</span>,</span> bytes32</span>[</span>]</span> calldata</span> _destinationChainID</span>,</span> address</span>[</span>]</span> calldata</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Transfers `_amount` bond tokens from the `_from`account to the `_to` account from the current chain to another chain. The caller must be approved by the `_from` address.</span></span>
    *         This methods also allows to attach data to the token that is being transferred</span></span>
    * </span>@param</span> _from</span> the bondholder address</span></span>
    * </span>@param</span> _to</span> the account to transfer bonds to</span></span>
    * </span>@param</span> _amount</span> amount of bond tokens to transfer</span></span>
    * </span>@param</span> _data</span> additional information provided by the token holder</span></span>
    * </span>@param</span> _destinationChainID</span> The unique ID that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> The smart contract to interact with in the destination Chain in order to Deposit or Mint tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainTransferFrom</span>(</span>address</span> _from</span>,</span> address</span> _to</span>,</span> uint256</span> _amount</span>,</span> bytes</span> calldata</span> _data</span>,</span> bytes32</span> _destinationChainID</span>,</span> address</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
</span>
    /**</span></span>
    * </span>@notice</span> Transfers several bond tokens with amounts specified in the array `_amount` from accounts in the array `_from` to accounts in the array `_to` from the current chain to another chain.</span></span>
    *         The caller must be approved by the `_from` accounts to spend the corresponding amounts specified in the array `_amount`</span></span>
    *         This methods also allows to attach data to the token that is being transferred</span></span>
    * </span>@param</span> _from</span> array of bondholder addresses</span></span>
    * </span>@param</span> _to</span> array of accounts to transfer bonds to</span></span>
    * </span>@param</span> _amount</span> array of amounts of bond tokens to transfer</span></span>
    * </span>@param</span> _data</span> array of additional information provided by the token holder</span></span>
    * </span>@param</span> _destinationChainID</span> array of unique IDs that identifies the destination Chain.</span></span>
    * </span>@param</span> _destinationContract</span> array of smart contracts to interact with in the destination Chain in order to Deposit or Mint tokens that are transferred.</span></span>
    */</span></span>
    function</span> crossChainBatchTransferFrom</span>(</span>address</span>[</span>]</span> calldata</span> _from</span>,</span> address</span>[</span>]</span> calldata</span> _to</span>,</span> uint256</span>[</span>]</span> calldata</span> _amount</span>,</span> bytes</span>[</span>]</span> calldata</span> _data</span>,</span> bytes32</span>[</span>]</span> calldata</span> _destinationChainID</span>,</span> address</span>[</span>]</span> calldata</span> _destinationContract</span>)</span> external</span> returns</span>(</span>bool</span>)</span>;</span></span>
}</span></span></code></pre>Rationale</h2>
The design of this ERC aims to simplify the migration to tokenized bonds by maintaining consistency with traditional bond standards. This approach allows fixed-income instruments to be represented as on-chain tokens, manageable through wallets, and utilized by applications like decentralized exchanges, while avoiding the complexities and inefficiencies associated with other standards. This ERC facilitates the creation of new bond tokens with characteristics akin to traditional bonds, enhancing accessibility, liquidity, and cost-efficiency in bond trading and management.</p>
The use of traditional finance terminology, like issueVolume</code> and principalOf</code>, is aimed at maintaining consistency with traditional bond language, which eases the adaptation for traditional entities.</p>
Total Supply and Account Balance</h3>
The totalSupply</code> and balanceOf</code> functions are not defined as they can be derived from issueVolume</code> and principalOf</code>, and denomination</code>. However, these functions can be be added in any contract implementing this standard, ensuring the proper relationship between these values.</p>
    function</span> totalSupply</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span> {</span></span>
        return</span> issueVolume</span>(</span>)</span> /</span> denomination</span>(</span>)</span>;</span></span>
    }</span></span>
</span>
    function</span> balance0f</span>(</span>account</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span> {</span></span>
        return</span> principal</span>(</span>account</span>)</span> /</span> denomination</span>(</span>)</span>;</span></span>
    }</span></span></code></pre>Backwards Compatibility</h2>
This ERC is not backwards compatible with existing standards like ERC-20</a> or ERC-1155</a> due to the absence of certain functions like totalSupply</code> or balanceOf</code>. A pure implementation of this standard is RECOMMENDED for issuing tokenized bonds, as any hybrid solution with other mentioned standards SHOULD fail.</p>
Reference Implementation</h2>
The complete Reference Implementation can be found here</a>.</p>
Bonds with embedded options like callable, puttable, or convertible bonds can be created by inheriting from the reference ERC7092.sol</code></a> that integrates the proposed interface.</p>
CALLABLE BONDS:</h3>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
import</span> 'ERC7092.sol'</span>;</span></span>
</span>
contract</span> ERC7092Callable</span> is</span> ERC7092</span> {</span></span>
    //</span> WRITE THE LOGIC TO ALLOW THE ISSUER TO CALL BONDS</span></span>
    //</span> STATE VARIABLES AND FUNCTIONS NEEDED</span></span>
    </span></span>
    /**</span></span>
    * </span>@notice</span> call bonds owned by `_investor`</span></span>
    *         MUST be called by the issuer only</span></span>
    */</span></span>
    function</span> call</span>(</span>address</span> _investor</span>)</span> public</span> {</span></span>
        require</span>(</span>msg.sender</span> ==</span> _issuer</span>[</span>bondISIN</span>]</span>.</span>issuerAddress</span>,</span> "ERC7092Callable: ONLY_ISSUER"</span>)</span>;</span></span>
        require</span>(</span>_principals</span>[</span>_investor</span>]</span> ></span> 0</span>,</span> "ERC7092Callable: NO_BONDS"</span>)</span>;</span></span>
        require</span>(</span>block</span>.</span>timestamp </span><</span> _bond</span>[</span>bondISIN</span>]</span>.</span>maturityDate</span>,</span> "ERC7092Callable: BOND_MATURED"</span>)</span>;</span></span>
        </span></span>
        uint256</span> principal </span>=</span>  _principals</span>[</span>_investor</span>]</span>;</span></span>
        _principals</span>[</span>_investor</span>]</span> =</span> 0</span>;</span></span>
        </span></span>
        //</span> ADD LOGIC HERE</span></span>
    }</span></span>
}</span></span></code></pre>PUTTABLE BONDS:</h3>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
import</span> 'ERC7092.sol'</span>;</span></span>
</span>
contract</span> ERC7092Puttable</span> is</span> ERC7092</span> {</span></span>
    //</span> WRITE THE LOGIC TO ALLOW INVESTORS TO PUT BONDS</span></span>
    //</span> STATE VARIABLES AND FUNCTIONS NEEDED</span></span>
    </span></span>
    /**</span></span>
    * </span>@notice</span> put bonds</span></span>
    *         MUST be called by investors who own bonds</span></span>
    */</span></span>
    function</span> put</span>(</span>)</span> public</span> {</span></span>
        require</span>(</span>_principals</span>[</span>msg.sender</span>]</span> ></span> 0</span>,</span> "ERC7092Puttable: ONLY_INVESTORS"</span>)</span>;</span></span>
        require</span>(</span>block</span>.</span>timestamp </span><</span> _bond</span>[</span>bondISIN</span>]</span>.</span>maturityDate</span>,</span> "ERC7092Puttable: BOND_MATURED"</span>)</span>;</span></span>
        </span></span>
        uint256</span> principal </span>=</span>  _principals</span>[</span>msg.sender</span>]</span>;</span></span>
        _principals</span>[</span>msg.sender</span>]</span> =</span> 0</span>;</span></span>
        </span></span>
        //</span> ADD LOGIC</span></span>
    }</span></span>
}</span></span></code></pre>CONVERTIBLE BONDS:</h3>
pragma</span> solidity</span> ^0.8.0</span>;</span></span>
</span>
import</span> 'ERC7092.sol'</span>;</span></span>
</span>
contract</span> ERC7092Convertible</span> is</span> ERC7092</span> {</span></span>
    //</span> WRITE THE LOGIC TO ALLOW INVESTOR OR ISSUER TO CONVERT BONDS TO EQUITY</span></span>
    //</span> STATE VARIABLES AND FUNCTIONS NEEDED</span></span>
    </span></span>
    /**</span></span>
    * </span>@notice</span> convert bonds to equity. Here we assumed that the investors must convert their bonds to equity</span></span>
    *         Issuer can also convert invetsors bonds to equity.</span></span>
    */</span></span>
    function</span> convert</span>(</span>)</span> public</span> {</span></span>
        require</span>(</span>_principals</span>[</span>msg.sender</span>]</span> ></span> 0</span>,</span> "ERC7092Convertible: ONLY_INVESTORS"</span>)</span>;</span></span>
        require</span>(</span>block</span>.</span>timestamp </span><</span> _bond</span>[</span>bondISIN</span>]</span>.</span>maturityDate</span>,</span> "ERC7092Convertible: BOND_MATURED"</span>)</span>;</span></span>
        </span></span>
        uint256</span> principal </span>=</span>  _principals</span>[</span>msg.sender</span>]</span>;</span></span>
        _principals</span>[</span>msg.sender</span>]</span> =</span> 0</span>;</span></span>
        </span></span>
        //</span> ADD LOGIC HERE</span></span>
    }</span></span>
}</span></span></code></pre>Identity Registry</h3>
This standard is designed specifically for tokenizing bonds. It does not inherently manage information pertaining to bondholders' identities. However, to enhance compliance with regulatory requirements and improve transparency, an identity registry can be added  on top of this standard to store the identity of all authorized investors.</p>
By maintaining an identity registry, issuers can ensure that bond tokens issued under the ERC7092</code> standard are transferred only to registered and authorized entities. This practice aligns with regulatory compliance measures and provides a structured way to manage and verify the identity of bondholders. It also helps prevent unauthorized or non-compliant transfers of bond tokens.</p>
Security Considerations</h2>
Implementing this ERC requires careful consideration of security risks related to functions approving operators to manage owner's bonds and functions allowing bond transfers. The use of these functions necessitates robust validation to ensure only the bond owner or approved accounts can call them.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


ERC-1155 Supply Extension
2023-05-25T00:00:00+00:00
Abstract</h2>
This ERC standardizes an existing mechanism to fetch token supply data from ERC-1155</a> tokens. It adds a totalSupply</code> function, which fetches the number of tokens with a given id</code>, and an exists</code> function, which checks for the existence of a given id</code>.</p>
Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.</p>
interface</span> ERC1155Supply</span> is</span> ERC1155</span> {</span></span>
  //</span> @notice      This function MUST return whether the given token id exists, previously existed, or may exist</span></span>
  //</span> @param   id  The token id of which to check the existence</span></span>
  //</span> @return      Whether the given token id exists, previously existed, or may exist</span></span>
  function</span> exists</span>(</span>uint256</span> id</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
</span>
  //</span> @notice      This function MUST return the number of tokens with a given id. If the token id does not exist, it MUST return 0.</span></span>
  //</span> @param   id  The token id of which fetch the total supply</span></span>
  //</span> @return      The total supply of the given token id</span></span>
  function</span> totalSupply</span>(</span>uint256</span> id</span>)</span> external</span> view</span> returns</span> (</span>uint256</span>)</span>;</span></span>
}</span></span></code></pre>
Implementations MAY support ERC-165</a> interface discovery, but consumers MUST NOT rely on it.</p>
Rationale</h2>
This ERC does not implement ERC-165</a>, as this interface is simple enough that the extra complexity is unnecessary and would cause incompatibilities with pre-existing implementations.</p>
The totalSupply</code> and exists</code> functions were modeled after ERC-721</a> and ERC-20</a>.</p>
totalSupply</code> does not revert if the token ID does not exist, since contracts that care about that case should use exists</code> instead (which might return false even if totalSupply</code> is zero).</p>
exists</code> is included to differentiate between the two ways that totalSupply</code> could equal zero (either no tokens with the given ID have been minted yet, or no tokens with the given ID will ever be minted).</p>
Backwards Compatibility</h2>
This ERC is designed to be backward compatible with the OpenZeppelin ERC1155Supply</code>.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Lockable Extension for ERC-721
2023-05-25T00:00:00+00:00
Abstract</h2>
An extension of ERC-721</a>, this standard incorporates locking</code> features into NFTs, allowing for various uses while preventing sale or transfer. The token's owner</code> can lock</code> it, setting up locker address (either an EOA or a contract) that exclusively holds the power to unlock the token. Owner can also provide approval for tokenId</code>, enabling ability to lock asset while address holds the token approval. Token can also be locked by approved</code>, assigning locker to itself. Upon token transfer, these rights get purged.</p>
Motivation</h2>
ERC-721</a> has sparked an unprecedented surge in demand for NFTs. However, despite this tremendous success, the NFT economy suffers from secondary liquidity where it remains illiquid in owner’s wallet. There are projects which aim to address the liquidity challenge, but they entail the below mentioned inconveniences and risks for owners as they necessitate transferring the participating NFTs to the projects' contracts.</p>

Loss of utility: The utility value of NFTs diminishes when they are transferred to an escrow account, no longer remaining under the direct custody of the owners.</li>
Lack of composability: The market could benefit from increased liquidity if NFT owners had access to multiple financial tools, such as leveraging loans and renting out their assets for maximum returns. Composability serves as the missing piece in creating a more efficient market.</li>
Smart contract vulnerabilities: NFTs are susceptible to loss or theft due to potential bugs or vulnerabilities present in the smart contracts they rely on.</li>
</ul>
The aforementioned issues contribute to a poor user experience (UX), and we propose enhancing the ERC-721</a> standard by implementing a native locking mechanism:
Rather than being transferred to a smart contract, an NFT remains securely stored in self-custody but is locked.
During the lock period, the NFT's transfer is restricted while its other properties remain unchanged.
NFT Owner retains the ability to use or distribute it’s utility.</p>
NFTs have numerous use cases where the NFT must remain within the owner's wallet, even when it serves as collateral for a loan. Whether it's authorizing access to a Discord server, or utilizing NFT within a play-to-earn (P2E) game, owner should have the freedom to do so throughout the lending period. Just as real estate owner can continue living in their mortgaged house, take personal loan or keep tenants to generate passive income, these functionalities should be available to NFT owners to bring more investors in NFT economy.</p>
Lockable NFTs enable the following use cases :</p>

NFT-collateralized loans: Utilize NFT as collateral for a loan without locking it on the lending protocol contract. Instead, lock it within owner’s wallet while still enjoying all the utility of NFT.</li>
No collateral rentals of NFTs: Borrow an NFT for a fee without the need for significant collateral. Renter can use the NFT but not transfer it, ensuring the lender's safety. The borrowing service contract automatically returns the NFT to the lender once the borrowing period expires.</li>
Buy Now Pay Later (BNPL): The buyer receives the locked NFT and can immediately begin using it. However, they are unable to sell the NFT until all installments are paid. Failure to complete the full payment results in the NFT returning to the seller, along with a fee.</li>
Composability: Maximize liquidity by having access to multiple financial tools. Imagine taking a loan against NFT and putting it on rentals to generate passive income.</li>
Primary sales: Mint an NFT for a partial payment and settle the remaining amount once owner is satisfied with the collection's progress.</li>
Soulbound: Organization can mint and self-assign locker</code>, send token to user and lock the asset.</li>
Safety: Safely and conveniently use exclusive blue chip NFTs. Lockable extension allows owner to lock NFT and designate secure cold wallet as the unlocker. This way, owner can keep NFT on MetaMask and easily use it, even if a hacker gains access to MetaMask account. Without access to the cold wallet, the hacker cannot transfer NFT, ensuring its safety.</li>
</ul>
This proposal is different from other locking proposals in number of ways:</p>

This implementation provides a minimal implementation of lock</code> and unlock</code> and believes other conditions like time-bound are great ideas but can be achieved without creating a specific implementation. Locking and Unlocking can be based on any conditions (e.g. repayment, expiry). Therefore time-bound unlocks a relatively specific use case that can be achieved via smart-contracts themselves without that being a part of the token contract.</li>
This implementation proposes a separation of rights between locker and approver. Token can be locked with approval and approved can unlock and withdraw tokens (opening up opportunities like renting, lending, BNPL etc), and token can be locked lacking the rights to revoke token, yet can unlock if required (opening up opportunities like account-bound NFTs).</li>
Our proposal implement ability to transferAndLock</code> which can be used to transfer, lock and optionally approve token. Enabling the possibility of revocation after transfer.</li>
</ul>
By extending the ERC-721</a> standard, the proposed standard enables secure and convenient management of underlying NFT assets. It natively supports prevalent NFTFi use cases such as staking, lending, and renting. We anticipate that this proposed standard will foster increased engagement of NFT owners in NFTFi projects, thereby enhancing the overall vitality of the NFT ecosystem.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Overview</h3>
ERC-721</a> compliant contracts MAY implement this EIP to provide standard methods of locking and unlocking the token at its current owner address.</p>
Token owner MAY lock</code> the token and assign locker</code> to some address</code> using lock(uint256 tokenId, address _locker)</code> function, this MUST set locker</code> to _locker</code>. Token owner or approved MAY lock</code> the token using lock(uint256 tokenId)</code> function, this MUST set locker</code> to msg.sender</code>. Token MAY be unlocked</code> by locker</code> using unlock</code> function. unlock</code> function MUST delete locker</code> mapping and default to address(0)</code>.</p>
If the token is locked</code>, the lockerOf</code> function MUST return an address that is locker</code> and can unlock</code> the token. For tokens that are not locked</code>, the lockerOf</code> function MUST return address(0)</code>.</p>
lock</code> function MUST revert if token is already locked</code>. unlock</code> function MUST revert if token is not locked</code>. ERC-721 approve</code> function MUST revert if token is locked</code>. ERC-721 functions that transfer ownership of a token MUST revert if token is locked</code>, unless msg.sender</code> is approved</code> and locker</code> both. After ERC-721 token transfer function call, values of locker</code> and approved</code> MUST be purged.</p>
Token MAY be transferred and locked</code>, also assign approval</code> to locker</code> using transferAndLock</code> function. This is RECOMMENDED for use-cases where Token transfer and subsequent revocation is REQUIRED.</p>
Interface</h3>
// SPDX-License-Identifier: CC0-1.0</span></span>
</span>
pragma solidity >=0.7.0 <0.9.0;</span></span>
</span>
/// @title Lockable Extension for ERC721</span></span>
/// @dev Interface for the Lockable extension</span></span>
/// @author StreamNFT </span></span>
</span>
interface IERC7066{</span></span>
</span>
    /**</span></span>
     * @dev Emitted when tokenId is locked</span></span>
     */</span></span>
    event Lock (uint256 indexed tokenId, address _locker);</span></span>
</span>
    /**</span></span>
     * @dev Emitted when tokenId is unlocked</span></span>
     */</span></span>
    event Unlock (uint256 indexed tokenId);</span></span>
</span>
    /**</span></span>
     * @dev Lock the tokenId if msg.sender is owner or approved and set locker to msg.sender</span></span>
     */</span></span>
    function lock(uint256 tokenId) external;</span></span>
</span>
    /**</span></span>
     * @dev Lock the tokenId if msg.sender is owner and set locker to _locker</span></span>
     */</span></span>
    function lock(uint256 tokenId, address _locker) external;</span></span>
</span>
    /**</span></span>
     * @dev Unlocks the tokenId if msg.sender is locker</span></span>
     */</span></span>
    function unlock(uint256 tokenId) external;</span></span>
</span>
    /**</span></span>
     * @dev Tranfer and lock the token if the msg.sender is owner or approved. </span></span>
     *      Lock the token and set locker to caller</span></span>
     *      Optionally approve caller if bool setApprove flag is true</span></span>
     */</span></span>
    function transferAndLock(uint256 tokenId, address from, address to, bool setApprove) external;</span></span>
</span>
    /**</span></span>
     * @dev Returns the wallet, that is stated as unlocking wallet for the tokenId.</span></span>
     *      If address(0) returned, that means token is not locked. Any other result means token is locked.</span></span>
     */</span></span>
    function lockerOf(uint256 tokenId) external view returns (address);</span></span>
}</span></span></code></pre>Rationale</h2>
This proposal set locker[tokenId]</code> to address(0)</code> when token is unlocked</code> because we delete mapping on locker[tokenId]</code> freeing up space. Also, this assertion helps our contract to validate if token is locked</code> or unlocked</code> for internal function calls.</p>
This proposal exposes transferAndLock(uint256 tokenId, address from, address to, bool setApprove)</code> which can be used to transfer token and lock at the receiver's address. This additionally accepts input bool setApprove</code> which on true</code> assign approval</code> to locker</code>, hence enabling locker</code> to revoke the token (revocation conditions can be defined in contracts and approval</code> provided to contract). This provides conditional ownership to receiver, without the privilege to transfer</code> token.</p>
Backwards Compatibility</h2>
This standard is compatible with ERC-721</a> standards.</p>
Existing Upgradedable ERC-721</a> can upgrade to this standard, enabling locking capability inherently and unlock underlying liquidity features.</p>
Test Cases</h2>
Test cases can be found here</a>.</p>
Reference Implementation</h2>
Reference Interface can be found here</a>.</p>
Reference Implementation can be found here</a>.</p>
Security Considerations</h2>
There are no security considerations related directly to the implementation of this standard for the contract that manages ERC-721</a>.</p>
Considerations for the contracts that work with lockable tokens</h3>

Once locked</code>, token can not be further approved</code> or transfered</code>.</li>
If token is locked</code> and caller is locker</code> and approved</code> both, caller can transfer the token.</li>
locked</code> token with locker</code> as in-accesible account or un-verified contract address can lead to permanent lock of the token.</li>
There are no MEV considerations regarding lockable tokens as only authorized parties are allowed to lock and unlock.</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>
Ethereum Improvement Proposals - Final

Diamond Storage

Security Considerations</h2>

Copyright</h2> Copyright and related rights waived via CC0</a>.</p>

Agent Coordination Framework

Interface</h3> Implementations MUST</strong> expose the following interface and events.</p>

Semantics</h3> The functions defined in this specification MUST exhibit the following externally observable behaviours. This standard does NOT prescribe storage layout, execution model, or internal mechanisms.</p>

Purpose-Bound ERC-20 with Conditional Unlock

Specification</h2> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>

Interface</h3> The IPurposeBoundERC20</code> interface defines the standard for programmable token transfers that are conditional. Each transfer, referred to as a purpose binding</em>, includes:</p>

Rationale</h2> Flexibility: Conditions are modular and extensible.</p> Composability: Can be integrated into DAOs, payroll, education, and compliance tokens.</p> Security: Off-chain verification (e.g., KYC) backed by on-chain proofs (e.g., Merkle roots).</p>

Security Considerations</h2> Condition-checking mechanisms (e.g., Merkle roots, timestamps) must be secure against tampering.</p> The claim()</code> function must ensure atomic verification of all conditions.</p> Replay attacks must be mitigated using unique binding IDs and expiration fields.</p>

Copyright</h2> Copyright and related rights waived via CC0</a>.</p>

Precompile for secp256r1 Curve Support

Specification</h2> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>

Precompile</h3> We introduce P256VERIFY</code> a precompile at the address 0x100</code> which performs ECDSA signature verification over the secp256r1 curve with a gas cost of 6900</code> gas</p>

Field Elements Encoding</h4> A base field element (Fp) is encoded as 32</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer must</strong> be less than the field modulus p</code>.</p>

ABI for P256VERIFY</code> Operation</h3> Input</h4> P256VERIFY</code> call expects 160</code> bytes as input that is interpreted as byte concatenation of:</p>

Input</h4> P256VERIFY</code> call expects 160</code> bytes as input that is interpreted as byte concatenation of:</p>

Gas Schedule</h3>

Rationale</h2>

Gas Cost Justification</h3> The 6900 gas cost does not maintain compatibility with L2s, but it matches closer the benchmarks of actual implementations.</p>

Test Cases</h2> A set of test vectors for verifying implementations is located in a separate file</a>.</p>

Security Considerations</h2>

Side-Channel Resistance</h3> We explicitly state that this precompile IS NOT REQUIRED</strong> to perform all the operations using constant time algorithms.</p>

Encode chain id with transaction hash

Abstract</h2> This standard proposes a way to encode the combination of a chain ID and a transaction hash into one string.</p>

Specification</h2> The encoded string has three components:</p>

Count leading zeros (CLZ) opcode

Abstract</h2> Introduce a new opcode, CLZ(x)</code>, which pops x</code> from the stack and pushes the number of leading zero bits in x</code> to the stack. If x</code> is zero, pushes 256.</p>

Specification</h2> A new opcode is introduced: CLZ</code> (0x1e</code>).</p>

Rationale</h2>

Security Considerations</h2> CLZ</code> is a stateless opcode that has a low worst-case constant cost in memory usage, compute and proving costs. It is therefore safe from being exploited for denial of service attacks.</p>

Copyright</h2> Copyright and related rights waived via CC0</a>.</p>

Set default gas limit to 60M

Abstract</h2> The gas limit on mainnet is currently 36M. This should be significantly increased to 60M by the time Fusaka is released by execution layer clients updating their default configurations.</p>

Specification</h2> Execution layer clients have different configuration formats. They should all update the gas limit value generated in their default configurations to 60M.</p>

Rationale</h2> In the past there has been some difficulty coordinating EL clients to update gas limit values in their default configurations. Therefore we suggest tying a new value to a hard fork release.</p>

Backwards Compatibility</h2> A higher gas limit should not break any existing contracts. It is possible that with a higher limit new transactions could exceed the proposed 30M transaction gas limit, so the scheduling of these two EIPs should be coordinated.</p>

RLP Execution Block Size Limit

Abstract</h2> This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 2 MiB to account for beacon block sizes.</p>

Motivation</h2> Currently, Ethereum does not enforce a strict upper limit on the encoded size of blocks. This lack of constraint can result in:</p>

Specification</h2>

Rationale</h2>

Backwards Compatibility</h2> This change is not backward-compatible</strong> with any blocks larger than the newly specified size limit. Validators and miners will need to ensure their block construction logic strictly respects this limit.</p>

Security Considerations</h2> Restricting maximum block size provides inherent protection against deliberate oversized-block attacks.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p>

Copyright</h2> Copyright and related rights waived via CC0</a>.</p>

Blob base fee bounded by execution cost

Specification</h2>

Rationale</h2>

Deterministic proposer lookahead

Abstract</h2> At the start of each epoch, pre-calculate and store in the beacon_state</code> a deterministic proposer_lookahead</code> for the next MIN_SEED_LOOKAHEAD + 1</code> epochs.</p>

`Copyright</h2> Copyright and related rights waived via CC0</a>.</p>`

Semantics</h3>
The functions defined in this specification MUST exhibit the following externally observable behaviours.
This standard does NOT prescribe storage layout, execution model, or internal mechanisms.</p>

Specification</h2>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>

Rationale</h2>
Flexibility: Conditions are modular and extensible.</p>
Composability: Can be integrated into DAOs, payroll, education, and compliance tokens.</p>
Security: Off-chain verification (e.g., KYC) backed by on-chain proofs (e.g., Merkle roots).</p>

`Copyright</h2> Copyright and related rights waived via CC0</a>.</p>`

Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>

Precompile</h3>
We introduce `P256VERIFY</code> a precompile at the address 0x100</code> which performs ECDSA signature verification over the secp256r1 curve with a gas cost of 6900</code> gas</p>`

Field Elements Encoding</h4>
A base field element (Fp) is encoded as `32</code> bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer must</strong> be less than the field modulus p</code>.</p>`

Gas Cost Justification</h3>
The 6900 gas cost does not maintain compatibility with L2s, but it matches closer the benchmarks of actual implementations.</p>

Test Cases</h2>
A set of test vectors for verifying implementations is located in a separate file</a>.</p>

Side-Channel Resistance</h3>
We explicitly state that this precompile IS NOT REQUIRED</strong> to perform all the operations using constant time algorithms.</p>

Abstract</h2>
This standard proposes a way to encode the combination of a chain ID and a transaction hash into one string.</p>

Abstract</h2>
Introduce a new opcode, `CLZ(x)</code>, which pops x</code> from the stack and pushes the number of leading zero bits in x</code> to the stack. If x</code> is zero, pushes 256.</p>`

Security Considerations</h2>
`CLZ</code> is a stateless opcode that has a low worst-case constant cost in memory usage, compute and proving costs. It is therefore safe from being exploited for denial of service attacks.</p>`

`Copyright</h2> Copyright and related rights waived via CC0</a>.</p>`

Abstract</h2>
The gas limit on mainnet is currently 36M. This should be significantly increased to 60M by the time Fusaka is released by execution layer clients updating their default configurations.</p>

Specification</h2>
Execution layer clients have different configuration formats. They should all update the gas limit value generated in their default configurations to 60M.</p>

Rationale</h2>
In the past there has been some difficulty coordinating EL clients to update gas limit values in their default configurations. Therefore we suggest tying a new value to a hard fork release.</p>

Backwards Compatibility</h2>
A higher gas limit should not break any existing contracts. It is possible that with a higher limit new transactions could exceed the proposed 30M transaction gas limit, so the scheduling of these two EIPs should be coordinated.</p>

Abstract</h2>
This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 2 MiB to account for beacon block sizes.</p>

Backwards Compatibility</h2>
This change is not backward-compatible</strong> with any blocks larger than the newly specified size limit. Validators and miners will need to ensure their block construction logic strictly respects this limit.</p>

Security Considerations</h2>
Restricting maximum block size provides inherent protection against deliberate oversized-block attacks.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>

Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>

Abstract</h2>
At the start of each epoch, pre-calculate and store in the `beacon_state</code> a deterministic proposer_lookahead</code> for the next MIN_SEED_LOOKAHEAD + 1</code> epochs.</p>`
