Blocking Lock event shouldn't be done this way:

• It blocks the transfer: The user has sent an initiate_transfer Tx, but he doesn't know the lock has been blocked. He won't be able to get the transfer and will wait without knowing why until the lock releases the fund. He cannot get his money back soon.
• It's unclear what is done with the lock event: it's disregarded, put aside to wait for the end of the 24h, and executed after? This part should be detailed.
• a security issue has been found if the lock_transfer is not called in time.

a security issue has been found if the lock_transfer is not called in time.

"In time" meaning before the timelock has expired, or something else?

I was thinking that the front-end could simple be notified. that the contract has been locked.

We could instead, do a lock for initiateBridgeTransfer but the only way to do this would mean updating the contract itself and having the rate limit set in the contract, which I don't think is a bad thing. What do you think?

I think the contract should reject the initiate_tranfer when the limit is reached. There are different possibilities to indicate to the contract to reject initial_transfer. The contract can do the calculus but it needs to be very strict in time or we indicate a number of blocks. The other way is the relayer detects that the limit has been reached and calls the contract to put it in a locked mode.

The scenario can be:

• Users call Initiate transfer
• The relayer gets Initiate_transfer event and increases the current amount transferred with the new transfer event.
• The relayer detects that the limit is reached.
• The relayer calls the contract to put it in lock mode.
• The relayer still processes all events as before.
• The relayer detects the rate limit time is finished and calls the contract to remove the lock mode.
• The relayer sets the current amount transferred to zero.

So some onlyOwner lock function that the bridge operator can call. Sounds good, I'll implement like this. Thanks for your thoughts!

Have two options to present here:

1. it stores how much budget has been used daily by using a DateTimeLibrary
2. if the difference between the last reset and current time is higher than the window we choose (here it's 1 days but it could be a variable set by us), it resets the time and the budget on both ways.

Second option is a little bit cheaper in average (it will be more expensive for users that bridge during a reset) but it's on average cheaper.

function _rateLimitIncoming(uint256 amount) internal {
        (uint256 year, uint256 month, uint256 day) = block.timestamp.timestampToDate();
        incomingRateLimitBudget[year][month][day] += amount;
        require(incomingRateLimitBudget[year][month][day] <= incomingRateLimit, IncomingRateLimitExceeded());
    }

function _rateLimitIncoming(uint256 amount) internal {
        _resetTime();
        incomingRateLimitBudget += amount;
        require(incomingRateLimitBudget <= outboundRateLimit, IncomingRateLimitExceeded());
    }

    function _resetTime() internal {
        if (block.timestamp - lastReset >= 1 days) {
            lastReset = block.timestamp;
            outboundRateLimitBudget = 0;
            incomingRateLimitBudget = 0;
        }
    }

reset after time passed

| src/NativeBridge.sol:NativeBridge contract |                 |         |        |         |         |
|--------------------------------------------|-----------------|---------|--------|---------|---------|
| Deployment Cost                            | Deployment Size |         |        |         |         |
| 1186577                                    | 5332            |         |        |         |         |
| Function Name                              | min             | avg     | median | max     | # calls |
| batchCompleteBridgeTransfer                | 17741           | 1350969 | 76588  | 5273683 | 512     |
| completeBridgeTransfer                     | 3123            | 37002   | 32256  | 89867   | 1536    |
| idsToIncomingNonces                        | 524             | 524     | 524    | 524     | 13087   |
| initialize                                 | 168107          | 168107  | 168107 | 168107  | 3       |
| initiateBridgeTransfer                     | 2531            | 74476   | 37063  | 183835  | 768     |
| noncesToOutgoingTransfers                  | 944             | 944     | 944    | 944     | 256     |

daily record

| src/NativeBridge.sol:NativeBridge contract |                 |         |        |         |         |
|--------------------------------------------|-----------------|---------|--------|---------|---------|
| Deployment Cost                            | Deployment Size |         |        |         |         |
| 1359377                                    | 6131            |         |        |         |         |
| Function Name                              | min             | avg     | median | max     | # calls |
| batchCompleteBridgeTransfer                | 19393           | 1483221 | 78240  | 5647872 | 512     |
| completeBridgeTransfer                     | 3123            | 38471   | 34019  | 91630   | 1536    |
| idsToIncomingNonces                        | 546             | 546     | 546    | 546     | 13433   |
| initialize                                 | 168107          | 168107  | 168107 | 168107  | 3       |
| initiateBridgeTransfer                     | 2531            | 75651   | 38826  | 185598  | 768     |
| noncesToOutgoingTransfers                  | 944             | 944     | 944    | 944     | 256     |

Wondering what would be better or if there are any logical issues with any of those. Implementations under https://github.com/movementlabsxyz/movement/tree/primata/rate-limiter

Option 1 is better, in my opinion; it's clearer to track the time durations (useful for auditing or analysing historical data) and its more fair to all users. Option 1 is more expensive yes, but the additional cost seems justified for the added precision and fairness. And, its marginally higher.

Between the above options, I like option 1. However, there appears to still be a risk of large amounts of downtime for the bridge, if a few big transfers go through and use up the daily budget quickly.

Is there a plan already for rate-limiting more granularly individual wallets, IP addresses, and/ or starting off with some limit to the amount per transfer?

I wouldn't consider this a risk, but the rate-limiter simple doing its job. For safety's sake we want to limit the bridge by volume for a given time period. If it gets used up quickly, then its functioning as intended and it is safely controlling flow of volume and traffic.

We just need to set a large enough volume so that we allow the level of activity we expect within 24 hours.