Liquidation-originated orderflow as a builder input — attribution questions for BuilderNet, datasets for DOWG, throughput questions for MEV-Share

Research
, ,
1

Hi all,

I run AdValorem, an operation that started as a multi-protocol liquidation engine and has grown into what is best described as a liquidation-originated orderflow network. We sit upstream of bundle construction: we continuously monitor a ~40k-borrower universe across Aave v3 (Ethereum + Base), Spark, and Morpho, generate liquidation-adjacent candidate transactions, and fan those out to builders. The block-builder side (our own rbuilder rail) was originally built so we’d have a place to land our own candidates without leaking edge; over time the more interesting asset has turned out to be the orderflow itself, not the building.

I’m posting because I have three specific questions — one for each of BuilderNet, the Data on Orderflow Working Group (DOWG), and MEV-Share — and they’re easier to ask in the open than over DMs. Numbers below are all live from our ops dashboard, not projections.

What we actually operate

Orderflow side (the wedge):

  • Borrower universe under continuous monitoring: 40,732 addresses
    • 19,731 on Aave v3 Ethereum
    • 18,769 on Aave v3 Base
    • 1,479 on Morpho across 251 markets
    • 753 on Spark
  • 24h coverage (positions actually re-checked vs. expected): aave-v3-eth 95.23% (659/692), morpho 35.85% (19/53), overall ~91%. The Morpho number is honest — per-market coverage is uneven and we know which markets are weak.
  • Scheduled audits: 4× per day, blocklist enforced upstream of bundle construction.

Builder side (so candidates have a home):

  • rbuilder v93, uptime 5d 11h at time of writing, reth + lighthouse on the same box (reth up 38d, lighthouse co-resident).
  • Public bundle endpoint: https://builder.advalorem.io/rpc (nginx → autossh reverse tunnel → rbuilder JSON-RPC on private VPC). X-Flashbots-Signature enforced at the nginx layer.
  • 4-relay fanout, all mode=full, max_bid_eth=5.0: flashbots, titan, aestus, agnostic. Ultrasound and manifold are currently disabled with documented reason (past degradation); eden was dropped after it began redirecting to titan; bloxroute_maxprofit / regulated are commented out pending re-eval.
  • Coinbase / fee_recipient EOA: 0x17D6d6658F0072A22fD80e7b896d95F0CBb6F119 (hot, 0.000441 ETH on hand at snapshot; cold sweep wallet 0x6A9b824134ABf7204ba49DF3c0ecDd31A87f47fc, 0.029863 ETH).
  • extra_data tag on landed blocks: “MEV SearcherNet”.
  • Public dashboard: https://mev.advalorem.io — live, including the catalog endpoint at /intelligence/catalog (x402-gated) and ops/status at /intelligence/ops/status (open).

Live builder metrics (5d 11h window, current block 25,252,067):

Metric Value
Submissions to relays 1,888,510 total, 952,705 accepted (50.45%), 22,965 errors, 0 rate-limited
Submit latency p50 192.7 ms, p99 1391.3 ms
Simulation throughput 11.18M ok / 488k failed = 95.81% pass rate
Blocks built locally 5,201,817 (75,316 active slots)
Fill latency p50 18.6 ms, p99 80.9 ms
Trigger→bid latency p50 0.03 ms, p99 0.05 ms
Gas per built block p50 12.97 Mgas, p99 40.03 Mgas

What we are not going to pretend:
In our most recent 209-slot competitive sample, the brand breakdown of winning bids was buildernet-flashbots 26.8%, quasar 26.3%, titan 25.4%, buildernet-nethermind 9.6%, builder-plus 3.8%. Our own slots_we_both_bid against every head-to-head competitor in that window is 0, and landed_subsidies_eth is 0.0. We are not yet winning competitive bids — we are submitting reliably, simulating fast, and landing on visibility, not on bid value. That gap is exactly why the BuilderNet question below matters.

Question 1 — for BuilderNet: orderflow attribution under redistribution

The most useful version of integrating with BuilderNet, for us, is not “we send you bundles.” It is “we contribute liquidation-originated orderflow that BuilderNet routes, and the redistribution accounting attributes value back to the originator.”

Our questions:

  1. How is non-bundle orderflow (raw candidate transactions originating from a partner’s monitoring infrastructure, not pre-packed bundles) currently attributed inside BuilderNet’s redistribution math? Is there a path for an upstream orderflow source to be a distinct accounting entity vs. a builder?
  2. For liquidation-adjacent candidates specifically — where the “value created” is partly the existence of the candidate at all (not just its execution price) — how does the current model treat origination vs. inclusion vs. backrun-of-inclusion?
  3. We’ve been working through the attested-get handshake to BuilderNet’s TEE-attested endpoints from our rbuilder box. Two operator-side findings worth flagging:
    • Port 7936 (https://rpc.buildernet.org:7936/cert) refuses connections from our box across all three published BuilderNet IPs (200.225.47.181, 34.150.234.122, 34.85.211.230). Port 443 is reachable. Is 7936 still expected to be open from external operators, or has the surface moved?
    • attested-get v0.1.9 (built from cvm-reverse-proxy HEAD) fails parsing the current measurements payload with cannot unmarshal array into Go value of type multimeasurements.LegacyMultiMeasurements. The measurements endpoint returns 35 entries spanning v1.0.0 → v1.6.0 azure-tdx (v1.6.0 is current), but the client’s LegacyMultiMeasurements struct doesn’t match that shape. Is there a newer client release we should be tracking, or is the measurements format mid-migration?

Happy to provide raw logs if useful — both the attested-get traces and the measurements JSON are saved server-side and can be shared in DM or a follow-up.

Question 2 — for the Data on Orderflow Working Group (DOWG)

The public discussion around private orderflow datasets has mostly been on the builder-share-of-winning-blocks side (xof.pics, Barter, etc.). What I haven’t seen, and would find genuinely useful to contribute to:

  • A standard schema for origination-side orderflow data — i.e., “this candidate was generated by an upstream monitor watching protocol X, before any builder saw it.”
  • Per-protocol coverage data for liquidation monitoring (which borrowers are being watched, by how many independent operators, with what staleness budget). Right now this is opaque to everyone except the operators themselves.

Question: Is anyone inside DOWG already working on origination-side or coverage-side datasets? If not, would there be appetite for one, and what would the right contribution format look like — direct dataset publication, schema proposal, or something else?

We can publish anonymized snapshots of our 40,732-borrower coverage stream (per-protocol depth, staleness distributions, audit cadence) without leaking strategy. Easier to know up front whether that’s wanted than to publish into the void.

Question 3 — for MEV-Share

MEV-Share has been pitched primarily as a backrun substrate for swap orderflow. The question I haven’t seen answered cleanly anywhere:

Has anyone used MEV-Share hints as a source for liquidation-adjacent backrun generation, and are there throughput / hint-format constraints that make it impractical?

Specifically:

  • Hint-to-bundle latency budgets for backrunning liquidation transactions (which are themselves often time-sensitive against oracle updates).
  • Whether the hint schema exposes enough position-level context to identify a candidate as liquidation-relevant before constructing a backrun.
  • Any operator data on hint volume vs. usable hint volume for non-swap categories.

If this has been written up and I missed it, a pointer is enough.

What we are not asking for

Not asking for a partnership announcement, not asking for inclusion in any program, not asking for capital. Three concrete technical questions, in public, because the answers shape what we build next.

If any of this is better routed to a specific person, channel, or working group meeting, happy to be redirected.

Thanks —
Val / AdValorem
https://mev.advalorem.io
https://mev.advalorem.io/intelligence/catalog