ERC-8293: Counterfactual Rejection Event Log (CREL)
PR: Add ERC: Counterfactual Rejection Event Log (CREL) by aartikamat · Pull Request #1806 · ethereum/ERCs · GitHub
Abstract
ERC-8293 specifies an on-chain event log for trading candidates that a DEX protocol or filter rejects before execution. Two events: RejectionLogged at the moment of rejection, OutcomeSampled at fixed intervals afterward to record what the rejected token actually did. Protocols that emit these let outside parties measure filter precision, run counterfactual analysis, and compare filter quality across protocols.
Motivation
DEX protocols and filter middleware reject most of the candidate tokens they evaluate, but they do not log those rejections. Accepted trades get full event metadata. Rejected ones leave nothing on-chain. Three consequences:
- You cannot measure filter precision without building your own off-chain capture system.
- You cannot compare filter quality across protocols because rejection reasons are not surfaced on-chain.
- You cannot do counterfactual outcome analysis (what would the rejected token have done if traded?) without private replay infrastructure.
The RED-2400 dataset shows the size of the gap: 6,660 rejection events captured on Solana DEX venues over a 49-day window, all through off-chain instrumentation. CREL makes that capture native to Ethereum.
Open questions
- Should OutcomeSampled sampling intervals be fixed by the spec, or left configurable per implementation?
- Is the event schema compatible with The Graph and Dune indexers as drafted, or does it need adjustment?
- Should this be DEX-agnostic, or scoped to AMM-style venues only?
Looking for input on the schema and on whether the sampling schedule belongs in the spec or with implementers.
Update (July 2, 2026): responding to Q1 (sampling intervals) and Q3 (DEX-agnostic), with pointers to companion methodology work.
On sampling intervals (Q1 above). Recommend FIXED intervals in the spec — [15m, 1h, 4h, 24h] — because cross-protocol comparability breaks if each implementer picks their own schedule. The RED-2400 dataset (DOI 10.21227/c36z-hk34) shows 94% of rejected tokens cease trading within 24h; a fixed 24h terminal sample is sufficient to classify gone / alive_dormant / alive_active. Configurability at finer cadence is fine (a protocol MAY sample more frequently) but the terminal 24h sample should be REQUIRED for interop.
Methodology backing. The Post-Rejection Follow-up Sampling (PRFS) framework this ERC operationalizes is documented in Kamat (2026), “Post-Rejection Follow-up Sampling,” SSRN Working Paper 6607301. The premise that on-chain observables carry outcome signal is supported by Kamat (2026), “Pump.fun Graduation Regime Windows,” SSRN 6915560 + Zenodo DOI 10.5281/zenodo.20633486, which reports a Cox proportional-hazards concordance of 0.858 predicting graduation from on-chain features on 832,941 launches. If similar predictive value holds for the REJECTION distribution (currently only measurable off-chain), CREL would unlock cross-protocol validation of filter quality claims.
On Q3 (DEX-agnostic vs AMM-scoped). Leaning DEX-agnostic. The RejectionLogged event carries rejectReason (16 reserved codes) and a generic filterContext; nothing in the schema requires AMM-specific state. Order-book venues (dYdX v4 style) should be able to emit the same events. Would appreciate confirmation from anyone building on order-book DEXes.
Q2 still open — would appreciate input from anyone actively indexing DEX events on The Graph or Dune. Current schema uses standard indexed topics; I believe it’s Graph-compatible but haven’t confirmed end-to-end.