WIP: Implement orderflow transparency attribute

[polymutex]

Work in progress. Updates issue #194.

Current thinking: the way the data collection was augmented in #267 means that a lot of the data we need for orderflow transparency is already present. The only thing it doesn't have is whether or not the wallet UI displays the disclosure.

Current methodology:

Wallets are evaluated based on how transparently they disclose the set of entities that they transmit MEV-susceptible transaction data to, and the share of the kickbacks that the user will receive as a result of sending this information.

To be recognized as transparently disclosing orderflow practices, wallets must disclose which entities may obtain information about user transaction intent as part of the transaction flow, prior to onchain transaction inclusion. A link to these entities' privacy policy or similar public document describing their transaction data handling practices must be included.

Note that this disclosure must recursively include all entities which may profit from orderflow, not just those who are known to. This includes services for swap quotes, cross-chain bridge quotes, transaction simulation services, transaction scam detection services, etc.

Since MEV extraction is often a form of fee-taking from the user, such disclosures must be at least as visually prominent and accessible as the way the wallet displays transaction fees.

Exemptions:

• Transactions that have no MEV value do not need disclosures. This includes simple token transfers, SIWE signature requests, ERC-20 token approvals, as well as non-financial transactions such as ENS record updates or multisig key rotation transactions.
• Wallets which only ever deal with one transaction type (e.g. trading-focused wallets that only support swaps) may provide a single disclosure upfront as part of user onboarding, rather than on each transaction.
• Disclosures are not required if a wallet locally verifies that an entity cannot use transaction data for profit or user data mining. For example, a wallet may locally verify that the scam transaction detection service it is connecting to is running in a secure enclave, and is running code which has been audited to ensure that transaction data never leaks out of the enclave. If such verification is successful, then no disclosure is needed.
• If a wallet only works purely locally (e.g. using a user's own node), then no disclosure is needed.

Still TBD: transparency around how the kickbacks from orderflow sales are distributed. Part of this is already covered under the existing wallet funding transparency attribute. More ideas welcome.

[soispoke]

Nice! I think there is a potentially a nice way to define tiers of orderflow transparency:

Tiers = disclosure quality:

• Grey: Not applicable, or no third-party sees MEV-carrying intents/transactions (or exempt).
• Red: MEV-susceptible intent shared, no public disclosure.
• Yellow: Public disclosure (doc/manifest/repo) lists all counterparties that see or may forward intent (recursive), with policy links.
• Green: Yellow + verifiable evidence: on-chain, or a public, maintained dataset with methods matching the disclosure.

Note: UI display not mandatory :disclosure just needs to be accessible and maintained (link in settings/docs/site or on walletbeat).

Kickbacks could just be a badge (“Rebates Verified”), not a tier criterion.

Here's an example "manifest that could be used for disclosing orderflow deals:

{
  "version": "of-disclosure/1.2-min",
  "updated": "2025-10-15",
  "content_hash": "bafybei...", 
  "wallet": { "name": "Example Wallet", "app_id": "com.example.wallet" },
  "scope": { "chains": ["ethereum:1"], "tx_types": ["swap", "bridge"], "exempt": ["transfer", "approval"] },

  "orderflow_deals": [
    {
      "counterparty": { "role": "ofa", "name": "Flashbots Protect", "policy": "https://protect.flashbots.net" },
      "forwards_to": [
        { "role": "builder", "name": "BuilderNet" },
        { "role": "builder", "name": "Titan" }
      ],
      "relationship": "preferred",               // "exclusive" | "preferred" | "open"
      "route_id": "protect-default",
      "rebates": { "user_bps": 5000 },       

      "evidence": {
        "onchain": {
          "chain": "ethereum:1",
          "distributor": "0xRebatesDistributor...",
          "event": "RebatePaid(address indexed recipient,uint256 amount,bytes32 routeId,uint64 periodStart,uint64 periodEnd)",
          "token": { "symbol": "ETH" },
          "payout_addresses": ["0xabc..."],
          "sample_txs": ["0x...1", "0x..2"],
          "explorer": "https://etherscan.io/address/0xRebatesDistributor..."
        }
        /* If using off-chain evidence instead:
        "dataset": { "url": "https://dune.example/table", "last_updated": "2025-10-10", "methodology": "link-to-methods" }
        */
      }
    }
  ]
}

[polymutex]

Note: UI display not mandatory :disclosure just needs to be accessible and maintained (link in settings/docs/site or on walletbeat).

Can you say more on why UI display should not be mandatory? My view is that the fee-taking nature of MEV feels a lot like transaction fees, hence requiring them to be displayed similarly. Perhaps you are referring to the level of detail shown on the UI, rather than about whether or not the UI discloses anything at all?

Here's an example manifest that could be used for disclosing orderflow deals

I like the level of detail here. I think one philosophical distinction between encoding it like that vs the OP comes down to whether the attribute should be about maximizing the transparency of where and why orderflow data leaves the confines of the local wallet (for any reason, MEV or otherwise), vs maximizing the transparency of what happens to the orderflow data after it has left.

I think there's merit to both. My intent with maximizing the former (where and why orderflow data leaves the confines of the local wallet) is because it is objectively observable from network captures without cooperation from the wallet development team to verify, and because any such data leak is already a privacy problem that needs to be minimized for non-MEV reasons (otherwise it allows external services to link IP addresses to Ethereum addresses, at the very least). But it doesn't really distinguish between e.g. wallets that rebate users vs wallets that don't.

Maximizing the latter (what happens to the orderflow data) is more about shining a light on how much wallets and upstream providers may extract from users. That's less directly observable, and requires cooperation from wallets and upstream services to fully map out, so there's a risk the data gets stale/inaccurate as wallets and their upstream services change. But it gives a better view of the aggregate MEV supply chain, and we can probably cross-correlate the data from multiple wallets to look for inconsistencies (e.g. wallet 1 and 2 both forward to the same builder but the rebates aren't the same).

Curious to know your thoughts about this aspect of what Walletbeat should look for here.

[soispoke]

Can you say more on why UI display should not be mandatory?

I wasn't trying to argue it shouldn't be displayed in the UI at all, but in practice that information is a bit dense and not always easy to interpret for users imo so my worry was more about overcrowding the UI yes (level of details).

I think one philosophical distinction between encoding it like that vs the OP comes down to whether the attribute should be about maximizing the transparency of where and why orderflow data leaves the confines of the local wallet (for any reason, MEV or otherwise), vs maximizing the transparency of what happens to the orderflow data after it has left.

I agree, I think both are valuable tbh, I'm just personally a bit more interested in the latter because of (1) the impact MEV has on the protocol side of things (MEV leaving apps and wallets and going to proposers is not something we want imo) and (2) the fact that users could get much cheaper transactions/swap if MEV was mostly redistributed to them.

I also had a chat with @sui414 about the example manifest and she mentioned trying to categorize what tx type there is for each wallet might be a bit meaningless since most of the big wallets are generic mix of all kinds (I agree).

She also proposed a nice example of what it could look like if going the route of "what happens to the orderflow data after it has left" here: https://sui414.notion.site/Wallet-Beat-orderflow-transparency-28f6da126dcb80b29258f886482fbafa?source=copy_link

^the "exclusivity" part is probably quite difficult to know from looking at the data though

[polymutex]

I wasn't trying to argue it shouldn't be displayed in the UI at all, but in practice that information is a bit dense and not always easy to interpret for users imo so my worry was more about overcrowding the UI yes (level of details).

You're right, it can certainly be overwhelming depending on level of detail. What if the disclosure required a specific format designed to be concise (fixed size regardless of what the wallet orderflow practices are) and objective? Something like one of the following, close to the transaction fee section:

WALLET_NAME does not auction off the orderflow for this transaction.

OR

WALLET_NAME will auction off your orderflow using BLOCK_BUILDER for this transaction. Over the last 30 days, similar transactions incurred an average transaction MEV cost of X Ether, of which Y% was kicked back to users. [optional "Learn more" link]

Requiring a statement of this format incentivizes wallets to either not auction off orderflow, or to maximize kickbacks.

She also proposed a nice example of what it could look like if going the route of "what happens to the orderflow data after it has left" here: https://sui414.notion.site/Wallet-Beat-orderflow-transparency-28f6da126dcb80b29258f886482fbafa?source=copy_link

This is very nice. I can see how this can be derived from the above manifest.

Do you know if any wallet already has published (or would be willing to publish) such a manifest? I'd like to implement this but want to see what this data would look like in practice, not just theoretically, before getting too deep into implementing the logic that makes sense of it and turns it into a wallet rating.

[soispoke]

WALLET_NAME will auction off your orderflow using BLOCK_BUILDER for this transaction. Over the last 30 days, similar transactions incurred an average transaction MEV cost of X Ether, of which Y% was kicked back to users. [optional "Learn more" link]

I think this might be a bit too specific to be accurate, I would keep it the same but exclude the BLOCK_BUILDER field, and make the Learn more link madatory to specific how orderflow is usually auctioned off.

[yizhang0901]

coming in fresh here. from a consumption level, i like @sui414's notion table example. it's comprehensive and easy to understand. however the issue is that a lot of orderflow providers don't publicly disclose their providers (even though most people in the industry end up knowing) and these configurations or providers can change at any moment without any public notice. it'd be very hard to maintain something like that

You're right, it can certainly be overwhelming depending on level of detail. What if the disclosure required a specific format designed to be concise (fixed size regardless of what the wallet orderflow practices are) and objective? Something like one of the following, close to the transaction fee section:

i think a disclosure in some format would be incredibly helpful in wallets. right now there is an industry standard with some ofa providers where most of the tx originator's priority fees aren't even going to the builder to improve chances of getting included, but instead going to the wallet. this is very extractive for the user but because wallets hold a lot of control and disclosure isn't clear + mev is complicated for users, they have no idea this is happening to them. also it's creating the wrong incentives in the industry.

[polymutex]

Thanks all. Here are my conclusions from this discussion as to what this wallet attribute should look for:

• Wallet developers should publicly document their orderflow practices. This could be in the form of a webpage that describes: who gets the orderflow by default, how much is kicked back to users, how users may change the wallet's default configuration and how this affects this (or a statement that says the default behavior cannot be changed), and the last time the page was updated.
• Wallets should be required to add a disclosure similar to the way they display transaction fees. The format of the disclosure should be along the lines of "WALLET_NAME will auction off your orderflow. Over the last 30 days, similar transactions incurred an average transaction MEV cost of X Ether, of which Y% was kicked back to users. ["Learn more" link going to the aforementioned documentation of the wallet developer's orderflow practices page]". Wallets that do not display such a disclosure or make it less visually prominent than transaction fees would fail on the "orderflow transparency" attribute.

Here's a detailed plan from the above.

Data that Walletbeat collects about wallets

Walletbeat's manually-updated data about wallets should include:

• The set of external services that transaction data is currently sent to, regardless of orderflow practices (Walletbeat already collects this under privacy.dataCollection); and whether these external services are verifiably non-extractive (definition for what "verifiably non-extractive" means is explained later in this post).
• If the above set is non-empty, the following fields become required:
  • Does the wallet display the required disclosure in a similarly-prominent way as it does transaction fees?
  • Is orderflow auctioning the default behavior, or something the user has to first consent to?
  • Can the user change the wallet's default configuration to remove orderflow auctioning?
  • A link to the wallet's orderflow practices page, or the absence thereof. If present, a description of the pieces of information the page contains:
    • Does the page explain what each of the above entities does with the transaction data?
    • For any orderflow auctioning that takes place, does the page explain what happens to it?
    • Does the page document how the user may change the wallet's default configuration to remove orderflow auctioning?
    • Does the page document how to verify this data using public onchain evidence?
    • Does the page indicate when it was last updated?

An external service that receives pre-inclusion transaction data is said to operate in a "verifiably non-extractive manner" if all of the following is true:

• The service is running in a TEE.
  • Otherwise, verification is not possible.
• The service is running verifiably-built, source-available software.
  • Otherwise, verification is not possible.
• This source code has been independently audited to produce no logs or I/O that could be used to extract transaction data outside of the TEE prior to onchain transaction inclusion.
  • Otherwise, transaction data may be leaked outside the TEE, so all bets are off regarding what happens to the user's transaction data.
• The wallet accesses the external service through an end-to-end encrypted and authenticated connection.
  • Otherwise, transaction data may be intercepted by a load balancer or similar, so all bets are off regarding what happens to the user's transaction data.
• The connection's end-to-end encryption and authentication ends inside the TEE, not outside.
  • Otherwise, transaction data may be decrypted e.g. by a load balancer sitting in front of (but outside of) the TEE, so all bets are off regarding what happens to the user's transaction data.
• The service provides an attestation of the code it is running, using the TEE's facilities for doing so.
  • Otherwise, there can be no verification of the server's behavior.
• The wallet consistently verifies this attestation locally every time it connects, before sending transaction data to the external service.
  • Otherwise, it is possible for the server to produce a fake attestation.
• The wallet's code for doing such attestation verification is source-available and has been third-party audited.
  • Otherwise, it is possible that the wallet's attestation verification doesn't actually work.

How Walletbeat's data about wallets can be turned into a pass/partial/fail rating

Methodology to turn the above data into a rating ("Pass", "Partial", "Fail") would be:

• If the wallet never sends pre-inclusion transaction data to external services (e.g. fully local wallets against own node would qualify here): PASS, no need to go further down this list.
• (Past this point in the logic, we assume wallets are sending data to external services.)
• If the wallet does not auction orderflow by default:
  • If all external services which receive pre-inclusion transaction data are verifiably non-extractive: PASS. No need to go further down this list.
  • Otherwise, PARTIAL.
• If the wallet does not display the required disclosure or displays it differently/not as prominently as it does transaction fees, or if it does not link to a "Learn more" page, FAIL. No need to go further down this list.
• Does the "Learn more" page contain the following information:
  • If it doesn't list the entities collecting transaction data (recursively): FAIL
  • If it doesn't list what happens to this data by default (including orderflow auctioning): FAIL
  • If it doesn't document how to change this behavior, or if changing this behavior is not possible: FAIL
  • If it doesn't include a "last updated" field: FAIL
  • If it doesn't include a way to verify this data using public onchain evidence: PARTIAL
  • If all of the above are good, then PASS.

Options for wallet developers to comply with this methodology

In order to get a "PASS" rating, wallet developers would need to do any one of the following:

• Either: A. Build a fully-local wallet, and populate Walletbeat's data to indicate this.
• Either: B. Build a wallet and do not do any orderflow auctioning by default, and populate Walletbeat's data to indicate this. (This gets a PARTIAL rating, unless all external services that get pre-inclusion transaction data are verifiably non-extractive, in which case this gets a PASS rating.)
• Either: C. Do all of the following:
  • Include a disclosure of the required format in the transaction UI.
  • Build a Learn More page, linked from the disclosure in the wallet UI and documenting the above things.
  • Required for PASS, but the wallet gets PARTIAL if not done: Come up with a way to publicly verify the wallet's orderflow practices, e.g. make MEV rebates happen in the same block and write a query that finds (user swap, MEV rebate)-transaction pairs within blocks; then document this in the Learn More page.

Thoughts?