Skip to content

docs: expand priority updates section (conditional inclusion, best practices, routing against propAMMs) - #100

Open
quintuskilbourn wants to merge 5 commits into
BuilderNet:mainfrom
quintuskilbourn:propamm-docs-update
Open

docs: expand priority updates section (conditional inclusion, best practices, routing against propAMMs)#100
quintuskilbourn wants to merge 5 commits into
BuilderNet:mainfrom
quintuskilbourn:propamm-docs-update

Conversation

@quintuskilbourn

Copy link
Copy Markdown

What

Rewrites the Priority updates section of the API reference (propAMM-related content only; nothing else on the page is touched):

  • propAMM context in the intro; the Priority Update Registry requirement is now a standalone bold sentence.
  • Modes list now states the cost profile of each mode.
  • New: How conditional inclusion works: the two consumption checks (registered maker event emitted; update state read in a successful call, reads in reverted subcalls don't count) and what each integrator class must do. Notes that the event registration flow will be upgraded soon.
  • New: Submission best practices: replacement_uuid/seq discipline, next-block targeting.
  • New: "Reach out to get API keys" pointer.
  • New: Routing against propAMMs: links IPropAMM as a common interface and the Lambda Class PropAMMRouter reference integration; mentions just-in-time routing as in progress.

Confirm before merge

  • Wording of the event registration step (how/where makers register consumption events). The mechanism description matches the builder implementation.

🤖 Generated with Claude Code

@vercel

vercel Bot commented Aug 18, 2026

Copy link
Copy Markdown

Someone is attempting to deploy a commit to the Flashbots Team on Vercel.

A member of the Team first needs to authorize it.

Comment thread docs/api.mdx Outdated
* **Top-of-Block:** to land at the **top of the next block**
* **Conditional:** to land only on the condition that another transaction reading the update is also included in the same block. Conditional updates are not guaranteed to be at the top of the block. This is an experimental gas savings feature subject to change.
* **Top-of-Block:** the update lands at the top of the next block, unconditionally. The maker pays gas every block the update lands.
* **Conditional:** the update lands only if a transaction consuming it is also included in the same block. Conditional updates are not guaranteed to be at the top of the block. The maker pays gas only on fills. This is an experimental gas savings feature subject to change.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's not experimental but the main way to use it

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 1a8a0c0: conditional listed first as the main way to use priority updates; the experimental line is replaced with a general note that the implementation is new and behaviour may change.

Comment thread docs/api.mdx

A taker transaction that touches priority-update state is only eligible for inclusion once the builder has held it for at least 50 ms. This protects makers from takers attempting to snipe stale quotes.

#### How conditional inclusion works <!-- omit in toc -->

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't use slots to decide if we want to do final inclusion. We only use event since doing this reverting call stack is redundant

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 1a8a0c0: consumption is now described as event-only; the slot-read condition is removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants