Alright, I drew a picture on how this works and why it's different // a net-new model. Freshest-possible pricing, efficient tx initiation (only done when needed), and onchain composability. Wins everywhere. For reference, this is how traditional pull oracles work with the same outlined work being required: - [1] Must include the work done from [2] - [2] Work is added to dev's workload - [4] isn't possible or available to non-Euphoria contracts as the pricing data is only known to the initiating app from [1] - [5] is dependent on the app implementation, whereas it's ~always optimal for a native implementation As @ChainLinkGod called it, this is "value-added frontrunning." Few teams are leaning in to the superpower of a sequencer construction. We'll maximize it.