# 7.1 [Medium] JWT unencrypted in HTTP connections

Acknowledged

This mirrors the behavior of all major execution clients, which also allow JSON-RPC over HTTP even when JWT authentication is enabled. Rollup Boost follows the same model as existing Ethereum execution clients. HTTP should only used in trusted or local environments.

# 7.2 [Medium] Server listening on all interfaces by default, without authentication

Resolved: https://github.com/flashbots/rollup-boost/pull/209

# 7.3 [Low] Debug API authentication

Wontfix

Rollup Boost is not intended to be publicly exposed. Therefore the authentication of the debug API is unnecessary. It's worth mentioning that the same solution is used in op-node's admin RPC.

# 7.4 [Low] JWT tokens timestamped 60 seconds into the future

Resolved: https://github.com/flashbots/rollup-boost/pull/211

# 7.5 [Low] Possible execution_mode inconsistency in get_payload

Resolved: https://github.com/flashbots/rollup-boost/pull/198

# 7.6 [Low] Proxy does not implement rate-limiting

Acknowledged

Rollup Boost is not intended to be publicly exposed. Relays or other trusted components should write directly to the proxy service. Chain operators should ensure that rate limiting is enforced elsewhere in the stack.

# 7.7 [Low] Use of sync::Cache in an async context

Resolved: https://github.com/flashbots/rollup-boost/pull/219

# 7.8 [Info] CI GitHub Action actions-rs unmaintained

Resolved: https://github.com/flashbots/rollup-boost/pull/246

# 7.9 [Info] Code inside the is_fallback_enabled() branch may not be reachable

Resolved: https://github.com/flashbots/rollup-boost/pull/198

# 7.10 [Info] Incoming requests have a large size limit

# 7.11 [Info] boost_sync flag can cause discrepancies between builder and L2 op-geth

Resolved in: https://github.com/flashbots/rollup-boost/pull/206

# 7.12 [Info] getPayload requests to builder when FCU no_tx_pool is true

Resolved: https://github.com/flashbots/rollup-boost/pull/195

# 7.13 [Best Practice] Concurrency in server

Wontfix

There are instances where op-node will send a quick succession of FCUs following derivation which requires that no rate limiting is in place. Further, Tokio is setup by default with number of background workers equal to number of CPU cores and tokio tasks are efficient to spawn. Relays or other trusted components should write directly to the proxy service. Chain operators should ensure that rate limiting is enforced elsewhere in the stack. We believe this finding should not be in the report.

# 7.14 [Best Practice] Different conditions for cache insertion/eviction

Resolved: https://github.com/flashbots/rollup-boost/pull/220

# 7.15 [Best Practice] Do not clone payload in server|fcu_v3

Resolved: https://github.com/flashbots/rollup-boost/pull/210

# 7.16 [Best Practice] Silent failures of tokio::spawn

Wontfix

the underlying methods (`new_payload_v3` and `new_payload_v4`) are instrumented with `tracing` and they are dispatched early.

# 7.17 [Best Practice] Using expect and unwrap in the code

Resolved: https://github.com/flashbots/rollup-boost/pull/243

This PR resolved most unwraps and expects in production code. Some unwraps remain in test code. And some expects remain in prod code - but are limited to service initialization or cases where the panic case is guarded against.

# 7.18 [Best Practice] CI use cargo deny

Resolved: https://github.com/flashbots/rollup-boost/pull/249

# 7.19 [Best Practice] Do not clone payload in rpc|new_payload_v3

Resolved: https://github.com/flashbots/rollup-boost/pull/210

# 7.20 [Best Practice] Logic of forwarding requests should be improved

Resolved: https://github.com/flashbots/rollup-boost/pull/221