Summary
We need to limit the bridge's operations for initial deployment, this is to secure regular flow, safety and maintainability. It is also to ensure we can always recover from an internal exploit (relayer liveness no longer a threat due to refund call restrictions).
We want to limit the amount of transfers possible within a 24h period by volume. This volume amount must be equal to the max amount we can mint on demand.
- Amount must be set on config
- Logic implemented at the relayer level (this to avoid additional changes to contracts)
- Every 24 hour period that passes, relayer increments on volume, if rate limit has been exceeded before current 24 hour period has passed, lock calls are blocked on the relayer and an appropriate Error is bubbled up.
NB. Implementing this at the relayer level is for initial deployment, after this we want to implement this at the contract level via an upgrade with a governing body would be able to vote on proposals to rate limit, that is the volume and the time period.
Summary
We need to limit the bridge's operations for initial deployment, this is to secure regular flow, safety and maintainability. It is also to ensure we can always recover from an internal exploit (relayer liveness no longer a threat due to refund call restrictions).
We want to limit the amount of transfers possible within a 24h period by volume. This volume amount must be equal to the max amount we can mint on demand.
NB. Implementing this at the relayer level is for initial deployment, after this we want to implement this at the contract level via an upgrade with a governing body would be able to vote on proposals to rate limit, that is the volume and the time period.