valid_before timing issue with high latency deployments

[Suckhept]

Describe the bug

Bug

When using mppx/client to call an MPP-protected endpoint with >1s network latency,
the transaction fails with:

'valid_before' 1774743017 is too close to current time (min allowed: 1774743017)

The valid_before value equals the minimum allowed — meaning the window is too tight
for real-world deployments.

Steps to reproduce

1. Deploy an MPP server on Railway US East (~1.3s latency from client)
2. Call a protected endpoint via mppx.fetch()
3. Transaction fails every time with the above error

Environment

• mppx version: latest
• Server: Railway US East
• Client location: Europe
• Round trip latency: ~1.3s

Expected behavior

The valid_before buffer should account for network latency in global deployments.
A configurable buffer or a larger default window would fix this.

Steps to reproduce

1. Deploy MPP server on Railway (any region)
2. Call protected endpoint via mppx.fetch() from client with >1s latency
3. Transaction fails every time

Logs

'valid_before' 1774743017 is too close to current time (min allowed: 1774743017)

EstimateGasExecutionError: valid_before is too close to current time
Server latency: ~1.3s (measured via curl)

Platform(s)

Mac (Apple Silicon)

Container Type

Not running in a container

What version/commit are you on?

latest / npm install mppx

If you've built from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct