Describe the feature
Not a bug or a strict feature ask — this is builder feedback + a question
about the recommended path for higher settle throughput. Filing under
feature request since there's no "question / feedback" template. Happy to
move it if there's a better place.
I'm Maks, co-founder of THE LINE — we're building an agent-to-agent
settlement layer on Moderato testnet (escrow + oracle-verified results,
settling in USDC over MPP). Sharing some real feedback from running a
fleet of agents that settle over MPP, plus one throughput question.
What's working well
Sub-second finality has been great for our case — agents hiring agents
need settlement to feel synchronous, and MPP delivers that. The
MPP-native fee-token flow (--tempo.fee-token via Foundry) has been solid.
One thing we hit — concurrent MPP receipts from one wallet
Under load (multiple intents dispatched to the same agent wallet), we
started seeing nonce too low / replacement transaction underpriced
on concurrent MPP receipt submissions. We solved it our side with a
per-wallet serialization lock + horizontal agent replication (one wallet
per replica), which restored a clean nonce sequence. Sharing in case it's
useful signal on how concurrent MPP settlement behaves from a single sender.
Main question — public testnet RPC ceiling
On the public endpoint (rpc.moderato.tempo.xyz) we start getting 429
at roughly ~30 parallel settlements. Totally reasonable for a shared
testnet endpoint — but we're hitting it in stress tests now (10,446+
settled so far, 0 disputes). What's the recommended path for builders who
need higher settle throughput on Moderato — a paid/builder RPC tier,
running our own node, or is batched settlement the intended pattern? On our
side we drain an off-chain settlement queue and group pending payouts per
provider into a single on-chain transfer as a workaround — but wanted to
check what you'd recommend.
Happy to share more detail on our setup if useful. Really enjoying
building on Tempo.
— Maks (THE LINE)
Additional context
No response
Describe the feature
Not a bug or a strict feature ask — this is builder feedback + a question
about the recommended path for higher settle throughput. Filing under
feature request since there's no "question / feedback" template. Happy to
move it if there's a better place.
I'm Maks, co-founder of THE LINE — we're building an agent-to-agent
settlement layer on Moderato testnet (escrow + oracle-verified results,
settling in USDC over MPP). Sharing some real feedback from running a
fleet of agents that settle over MPP, plus one throughput question.
What's working well
Sub-second finality has been great for our case — agents hiring agents
need settlement to feel synchronous, and MPP delivers that. The
MPP-native fee-token flow (
--tempo.fee-tokenvia Foundry) has been solid.One thing we hit — concurrent MPP receipts from one wallet
Under load (multiple intents dispatched to the same agent wallet), we
started seeing
nonce too low/replacement transaction underpricedon concurrent MPP receipt submissions. We solved it our side with a
per-wallet serialization lock + horizontal agent replication (one wallet
per replica), which restored a clean nonce sequence. Sharing in case it's
useful signal on how concurrent MPP settlement behaves from a single sender.
Main question — public testnet RPC ceiling
On the public endpoint (
rpc.moderato.tempo.xyz) we start getting429at roughly ~30 parallel settlements. Totally reasonable for a shared
testnet endpoint — but we're hitting it in stress tests now (10,446+
settled so far, 0 disputes). What's the recommended path for builders who
need higher settle throughput on Moderato — a paid/builder RPC tier,
running our own node, or is batched settlement the intended pattern? On our
side we drain an off-chain settlement queue and group pending payouts per
provider into a single on-chain transfer as a workaround — but wanted to
check what you'd recommend.
Happy to share more detail on our setup if useful. Really enjoying
building on Tempo.
— Maks (THE LINE)
Additional context
No response