ERC: 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 1 post - 1 participant Read full topic