An endorser may "lie" in two different ways:

1. By providing a list of "incomplete" dependencies, this can be detected if an operation goes from valid to invalid while all dependencies remain the same.

2. By returning ready = true to an operation that does not pay enough fees.

Support for (1) already exists, but (2) is not fully implemented yet.

Right now, the built-in senders simulate the operation before doing the relay; if the simulation pays enough fee, they proceed to execute the operation. If the executed operation didn't pay enough fee, then the endorser may get banned.

But if the simulation says that the operation doesn't pay enough fee, the operation is discarded right away. An additional step must be performed to verify that the endorser is in fact returning ready = false.

This must be done carefully, as there are scenarios in which the sender may decide that the operation does not pay enough, but the endorser may say it does. In these cases, the endorser must not be banned.

i.e., the sender may be asking for a minimum higher priority fee, or for a higher markup on the token fee conversion ratio.

The following ERC (number not assigned yet):

ethereum/ERCs#318

can be used to optionally allow the bundler to find receipts for the operations. These receipts aren't of much use internally (as they can't directly be trusted), but these capabilities can still be exposed to consumers of the API.

The general idea is:

• Add an operationReceipt API method.
• It takes an operation hash and uses IPFS (or the internal mempool) to find the contents of the operation.
• It uses the ERC to find the receipt.
• It returns the receipt to the caller.

All operations are currently being shared using a GossipSub topic ERC5189:pool:op:<chain-id>.

However, ERC-5189 allows operations to natively pay each bundler in any ERC20 token; however, not every bundler is obliged to accept any specific ERC20 token.

This means that some bundlers may ignore many of the messages being shared on the pubsub (if they don't want to accept the token). A better approach could be to use a pubsub topic like this:

ERC5189:pool:op:<payment token>:<chain-id>

Right now, ERC-5189 does not specify a message schema for passing operations among peers.

This bundler uses libp2p GossipSub as a temporary solution for this, with peers subscribing to:

ERC5189:pool:op:<chain-id> and ERC5189:pool:archive:<chain-id>, and they pass around JSON marshalled messages. It would be better if either ERC-5189 or some standard could specify how these messages should be passed among peers.

Additionally, it may be worth it to use this opportunity to move to protobuf instead of JSON.

The project contains a generic "endorser registry" at /registry/registry.go. This endorser registry determines if any endorser should be trusted or not.

Right now, there are two possible sources of information for this registry:

1. Statically trusted endorsers

• These endorsers are defined in the configuration and are always trusted. This is directly implemented within the endorser registry.

2. Contract sources

• These are contracts that determine if an endorser has "burned" or not.

For quick testing, these validations can be bypassed by (a) adding any wanted endorsers to the list of trusted endorsers or by (b) setting the min_reputation of the registry configuration to zero.

ERC-5189 defines that the endorser registry should be a "burn eth" operation. Given the early stages of development of this ERC, I would recommend allowing a "lighter" version of this mechanic, an endorser registry that instead of burning, enforces that some ETH has been locked for X amount of time. A sample implementation of this can be found at /contracts/src/TemporalRegistry.sol.

This temporal registry should be easy to integrate using the "contract sources" of the endorser registry.

This contract hasn't been deployed and integrated with the rest of the bundler yet.