ERC-8324: Priority Update Registry (PUR)

,

gm,

Here is a draft contract standard for PropAMMs on the EVM (and similar use cases). An instance of this contract is live on Ethereum since May ‘26 and handles almost all of the propAMM volume across multiple builders. We’re hoping to standardise this across EVM chains.

PR Link; reference implementation

The short version: the Priority Update Registry (PUR) is a single shared contract that holds small pieces of state “owned” by other contracts. An owner authorises some off-chain updaters to write that state, and only the owning contract reads it back during other tx calls. The state is meant to be short-lived and fresh, think a price for a trading pair that gets refreshed every block while the next block is being built.

The primary motivating problem is that propAMMs require/benefit from block producers to prioritise certain kinds of transactions (updates), but, without this standard, it’s difficult for block producers to distinguish updates from transactions that do other things. This standard removes the need for block producers to do transaction tracing during execution or to have trusted relationships with updaters.

We tried hard to be honest about the boundaries. The standard is really two things: (A) the on-chain registry, which the EVM actually enforces, and (B) the block-producer ordering behaviour, which nothing on-chain can fully enforce. PUR just makes that ordering safe to offer for block producers. It also makes analytics much easier to pull off.

A few things we’d love input on:

  • whether to formalise a “commutative” tier for updates that must not depend on anything else in the block, (1271 signatures currently get in the way of commutativity)
  • what error surface, if any, the standard should mandate so simulators and RPCs can tell which update a pending transaction is waiting on,
  • and whether a richer-than-1271 update interface is worth it for the multi-signer and partial-write cases some makers want.

This was coauthored with Vitaliy Drogan, and Tymur Khrushchov

6 Likes

Is it part of the standard that the state updater must be an EOA?

I can guess on why it helps to simplifies things, but wonder if it is aligned with the broader vision of Ethereum.

1 Like

The contract supports ERC-1271 so updaters don’t have to be EOAs!

In practice there are two checks:
1. contract level - pre-registered EOA or ERC-1271 sig verification
2. Producer level (not enforced by contract) - prioritise transactions with to set to the PUR contract

1 Like

If contract can submit via signature, then can you please explain the rationale of why a contract cannot submit with a normal call like the eoa does?

updateState only checks isUpdater[target][msg.sender] . Nothing there requires an EOA, so a contract that’s registered as an updater can write through a normal call and the update lands on-chain just fine.

The catch is at the producer level, not the contract level. The property block producers rely on is: a transaction whose top-level to is the registry can only mutate the registry’s own storage. A transaction sent directly to the registry necessarily originates from an EOA.

1 Like