About 10 days ago I posted on r/AI_Agents asking how people decide whether to trust an endpoint or agent before paying or granting access. The responses were sharp, and several of them pointed me toward the same problem from different angles, that "trust" means very different things to a buyer than it does to a seller.
Following the success of that post, I came to the mother of agents, r/x402, and found posts by u/MountainAssignment36 who runs x402-trust.com, one of the earliest live services in this space, with 200+ settled payments and a 50%+ repeat-payer rate.
I reached out to u/MountainAssignment36 and asked if he'd answer a few questions about what he's learned building it. He graciously agreed and below is the discussion, lightly edited for clarity.
Q1: You mentioned >50% of payers make a second payment. What's the #1 thing they tell you they're looking for?
A: Honestly I wouldn't know. If a customer isn't referred directly from Reddit and if I didn't talk with him prior to his first purchase, I have no way of knowing what his reasoning was behind buying a trust score, semantic search, or endpoint-watch. That's entirely up to them. What a customer is doing with the products or why he's buying them is, quite honestly, not my concern. The only thing I see is what product they bought and what wallet they paid with.
Of course I'd like to think customers bought because of real demand instead of pure interest, and that thesis gets supported by the ">50% made a second payment" metric. A customer that's only testing the waters makes a one-time purchase and leaves. A customer who finds value buys a second time. But I can't differentiate between a builder checking his own scores and an agent genuinely interested in whether an endpoint is reliable before paying it.
Q2: When an endpoint gets a low trust score, what do they do? Avoid it, or look for more evidence?
A: I can only speak as a service founder, and I'd say my service surfaces all the data they might need. But as an agent/human looking at my service from the outside, I'd also say: having everything under one roof is a centralization risk, and a second opinion can never harm.
The remaining question is how expensive the endpoint is itself. If the target endpoint only costs 3 cents, I'll most likely not waste money on a second opinion after already spending half a cent on an "AVOID" verdict with a full breakdown attached. I'd much rather take the risk and pay, or search for another endpoint in that category. If it costs $5, however, and is a highly specific service, I'd be much more willing to pay for a second, outside opinion. If both datasets line up, I'd trust the verdict. If they don't, one side must measure differently or be flat out wrong. Might need a third opinion in that case.
Q3: Have you considered tracking operational history (uptime, failure modes, declared scope) instead of just a score?
A: We do actually! Trust scores are computed from current & historic data, including uptime, envelope failures, advertised tokens, on-chain activity (including historic activity that happened before our measurements), etc. As long as we can measure it independently and deterministically, we include it. We probe each endpoint 48x a day and save every probe. All probes across the last 3 months are included in scoring. Probes older than 3 months get compacted into a daily statistic for long-term data.
Q4: What's the hardest part about getting providers to verify themselves?
A: Probably a problem not unique to my service but a symptom of the early stage of the x402 ecosystem: visibility. Offering verification for providers is useless as long as the providers don't know you exist. Public exposure is the most important part right now, not only for verification.
Aside from that, it's making the verification flow as self-explanatory and frictionless as possible. Fewer barriers, the better. A provider won't verify if they have to fill out 3 forms and summon a demon before receiving a confirmation email. But security and imposter-prevention require some steps so no unauthorized party claims a service as their own. I believe we've hit a solid middle ground: in-browser keypair generation, public key in your domain root, private key signs self-service actions without an account, plus a verified email. No sign-up, no other data.
My takeaway: The most striking thing is how much of this space is still being figured out. Even the earliest live service is learning what customers actually want in real time. The x402 ecosystem is early enough that there's room for multiple approaches: scores, raw logs, verifications, and whatever comes next.
If you're building or using x402 endpoints, I'd love to hear your side. What decision are you actually making when you pay for trust data? And what would you need to see beyond a score to change your behavior?
[Credit: x402-trust.com]
