Hugging Face's logo

Join the conversation

Join the community of Machine Learners and AI enthusiasts.

Sign Up
Back to feed
sriram1983007 
posted an update 7 days ago
Post
114
Two live agent payment runs with SRA-RiskGate today, plus a day of real x402 data.

Circle Gateway on Arc testnet: one agent task, three proposed payments. One approved, accepted by Gateway and settled to the payee. An unlimited approval was held and a look-alike payee was rejected, neither signed.

Base Sepolia: 0.01 USDC to the known payee approved, sent and verified from the receipt. 2.00 USDC to an unknown payee held before signing. Log: https://gist.github.com/sriram1983007-dev/35eab0e934a512346193bcdb5b12d9cf

Real traffic: 1,500 x402 settlements sampled across 24 hours on Base mainnet. Median signature had under 5 minutes left at settlement, but 23 were still usable for 8 to 41 days, one for 273.75 USDC.

Model: sriram1983007/SRA-RiskGate-4B
dipankarsarkar

The 23 long-lived signatures are the striking number. The one I'd want next is how often your own default fires.

In 0.17.0 a plain USDC authorization is held as LONG_LIVED_AUTHORIZATION past 3600 s, measured at signing: validBefore minus max(now, validAfter).
Your mainnet sample measures time left at settlement instead.
That is lifetime minus settlement delay, so a median under 5 minutes can't tell you what lifetime the client signed for.

validAfter and validBefore are both in the settlement calldata, so the 1,500 can answer it.
How many of them would the one-hour default have held before signing?

·
sriram1983007

Good spot Dipankar, and you’re right: time left at settlement is lifetime minus settlement delay, so it’s only a lower bound on what the client signed for. I’ve rerun the 1,476 settlements with a recovered window against the 0.17.0 rule (validBefore − max(now, validAfter) > 3600):

23 (1.6%) would certainly have been held: even at settlement they had more than an hour left, so they had more at signing.

39 had validAfter set and a total window under an hour: certainly not held.

1,400 had validAfter = 0 and under 10 minutes left: nowhere near the limit.

14 sit right on the boundary: 12 settled with 3,500–3,599 s left, and 2 used a 70-minute window backdated by 10 minutes. Both look like clients signing for exactly one hour.

Those 14 matter. They pass the strict > 3600, but a second of clock skew between signer and gate would hold them. So the next release ought to add a small skew tolerance at the one-hour edge.
dipankarsarkar

The 14 are the finding. A default that sits exactly on the most common client choice is a coin flip on clock skew.

One caveat on the 1,400, by your own lower-bound logic.
With validAfter = 0 the calldata never says when they signed, so "under 10 minutes left" is a floor on their lifetime too.
They are clear of the hour only if they settled within about 50 minutes of signing.

The rows with validAfter set can price that delay, if validAfter tracks signing time.
Your 2 backdated by 10 minutes say it doesn't always.
What does settlement time minus validAfter look like across them?

·
sriram1983007

20 rows at 31–72 s: most at 61–72 s, plus one at 31 s.
21 rows at 602–640 s: most at 602–608 s, plus one at 640 s.

Good point Dipankar, and the 41 rows with validAfter set do price it. Settlement minus validAfter isn’t spread out; it falls into two tight groups. 20 rows sit at 31–72 s (most at 61–72) and 21 at 602–640 s (most at 602–608). That’s what you’d expect from clients that backdate validAfter by a fixed 60 or 600 seconds (the x402 SDK uses 10 minutes) and then settle a few seconds later. Taking the backdate off, the implied delay from signing to settlement is about 2–12 s for most rows and 40 s at the very most. Your two 70-minute windows are in the second group: they settled 2 s after their backdated start, so they were signed for an hour almost exactly.

So validAfter does track signing time, offset by a fixed backdate, and the delay is seconds, not minutes. If the 1,400 validAfter = 0 clients behave like these, their lifetime is their time left plus a few seconds, well clear of the hour. The caveat is that 41 rows come from clients that chose to set validAfter, and the validAfter = 0 clients might queue differently. I can’t rule that out from calldata alone. Pairing each settlement with its x402 /verify call would settle it, but that’s facilitator-side data I don’t have.
dipankarsarkar

Two tight clusters at 60 s and 600 s is the receipt. The backdate is a client default, not a queue.

Your caveat can be tested from calldata too.
validBefore is in the calldata of every row, including the 1,400 with validAfter = 0.
If those clients sign with a fixed lifetime L, then validBefore minus settlement time should pile up a few seconds under L, one pile per client default.
A tight pile means they settle seconds after signing, same as your 41.
A smear below L means they sit in a queue, and the width of the smear is the queue.

Do the 1,400 pile up, and at how many distinct L?

·
sriram1983007

Ran it on the same sample. 1,435 rows have validAfter = 0 (~1,400), and 1,404 of them fall into four piles: just under 60 s, 300 s, 600 s and 3600 s, with 31 outside any pile and none settled after validBefore.

Three are tight. 600 s: 2–17 s under, and all 427 rows are the batch-settlement contract, so batching there doesn’t mean a long wait. 60 s: mostly 2–11 s under, with a few rows up to 64 s, which I’d read as client clocks a few seconds fast rather than another L. 3600 s: 12 rows, 1–31 s under.

The 300 s pile is two clients. One payee (126 rows) sits 2–15 s under, the same pattern as the others. Another (679 rows) is smeared across 232–297 s, about 65 s wide. That’s the only smear in the sample. I’d call it time between signing and settlement rather than a queue, though: in x402 the server usually settles after serving the request, so the smear may be that server’s response time. Calldata can’t separate the two.

Where validAfter is set, the signed lifetimes are more varied (900, 360, 660 and 170 s are the most common), but that’s only 41 rows.
dipankarsarkar

Four piles and nothing settled after validBefore. The lifetime is a client default, same as the backdate.

Your counts close, too.
The 23 that had over an hour left at settlement all have validAfter = 0, and they can't sit just under any L. So they are 23 of your 31 outliers, which leaves 8 unexplained.
The 3600 pile looks like your 12 boundary rows again.

On the 679-row smear, the shape can separate your two readings.
Response time is skewed: a floor a few seconds under 300, then a tail.
A server that settles on a timer is flat: delays spread evenly over one interval. 3 to 68 s is about one minute plus the 2-15 s your other 300 s payee shows.
The settlement side should agree. A timer puts that payee's settlements on a regular beat, often several in one block. Per-request settlement follows its traffic.

Is the 232-297 s spread flat or skewed, and do those 679 settle on a one-minute beat?
In this post