Reputation scoring and throttling/banning for global entities
UserOperation's storage access rules prevent them from interfering with each other. But "global" entities - paymasters, factories and aggregators are accessed by multiple
UserOperations, and thus might invalidate multiple previously-valid
To prevent abuse, we throttle down (or completely ban for a period of time) an entity that causes invalidation of a large number of
UserOperations in the mempool. To prevent such entities from carrying out sybil-attacks (opens in a new tab), the protocol requires them to stake with the system, and thus make such DoS attacks very expensive. Note that this stake is never slashed, and can be withdrawn at any time (after an unstake delay period).
When staked, an entity is also allowed to use its own associated storage, in addition to sender's associated storage.
The stake value is not enforced on-chain, but specifically by each node while simulating a transaction. The stake is expected to be above
MIN_STAKE_VALUE, and unstake delay above
MIN_UNSTAKE_DELAY. The value of
MIN_UNSTAKE_DELAY is 84600 (one day). The value of
MIN_STAKE_VALUE is determined per chain, and specified in the "bundler specification test suite"
Under the following special conditions, unstaked entities still can be used:
- An entity that doesn't use any storage at all, or only the sender's storage (not the entity's storage - that does require a stake)
- If the
UserOperationdoesn't create a new account (that is
initCodeis empty), then the entity may also use storage associated with the sender
- A paymaster that has a
postOp()method (that is,
“context”) must be staked