Loomal - Monetize any MCP server in 5 minutes with no % skim.

@dannyheng  @priya_kushwaha1 Thanks! And great question — you've hit on one of the genuinely unsolved parts of agentic commerce, so I'll be straight with you 😄

Receipts: every payment settles on-chain, so there's already a permanent, verifiable record — seller, amount, timestamp, tx hash. What we don't have yet is a clean human-friendly receipt on top of that (the thing you'd hand an accountant). That's coming very soon — it's high on the roadmap because we know autonomous payments are useless to a business if the finance team can't reconcile them.

VAT is the harder one. Today, tax liability sits with the entities on both ends — the agent is just the payment mechanism, like a corporate card with automation. So you'd handle VAT like any cross-border digital sale. Full tax handling is a Merchant-of-Record problem, and I won't pretend we solve that today.

@golgelisem16238 Thanks — and fair point, this is a real gap. Today you set pricing per endpoint, but throttling per agent is on you. We already identify every paying agent per transaction, so per-agent limits and tiers are very buildable — adding it to the roadmap.

Quick question back: hard cutoffs (429 past a limit), or price-based throttling where heavy users just pay more per call? Curious which you'd actually want.

@worksforme The categories getting the most interest so far: data/search APIs (agents pay per lookup), scraping and enrichment tools, and document processing — the pattern is bursty, mid-task consumption, which is where subscriptions never made sense. Anything an agent needs unpredictably, 40 calls at a time.

Too early to declare a winner from our volume alone — we launched the new model this month.

@uddipta You've actually wandered into our sister product 😄 Loomal handles the payments side; the identity/inbox/vault layer you're describing is Mailgent (mailgent.dev) — same team, built to work together.

To answer directly: yes, that's the whole point of giving each agent its own identity instead of a shared account. Every agent gets its own DID and its own Ed25519 keypair — nothing is shared. So if one agent's vault or inbox is compromised, you revoke that agent's identity and keys, and every other agent keeps running untouched. No blast radius, and the audit trail shows exactly what the compromised agent did before revocation.

That's exactly the failure mode of the "borrowed Gmail password" setup — one leak takes down everything and you can't even tell what happened.

Happy to go deeper on the Mailgent side if useful, but didn't want to hijack the Loomal thread 😅 On the Loomal side: agents pay under scoped spend mandates, so a compromised agent can't drain a wallet either — you revoke the mandate and it's done.

@amjad_shaik Per-call pricing is the first line of defense. A server that changes behavior or degrades burns an agent for cents, not a monthly subscription — the agent just stops paying and routes elsewhere. Bad servers lose revenue immediately.

We don't validate responses or SLA-check servers today. Longer term, the Index builds machine-readable reputation from settled transactions — uptime, consistency, repeat-purchase rate. Reviews that can't be faked, because they're actual paid usage.

@himani_sah1 Thank you! That’s exactly what we’re aiming for—making adoption feel effortless. The one-line integration removes the usual setup overhead so teams can start seeing value almost immediately. Really appreciate your support!

@roopreddy Thats why we think the agent economy is going to explode! Native Shopify and WooCommerce integrations should let sellers expose what they already offer to agents without needing to understand APIs, MCP, or crypto infrastructure first.

@roopreddy This is the part that changes the scale of the whole thing. Developers listing APIs is the beachhead, but the long tail of the agent economy is millions of existing stores where the seller will never read an API doc — and shouldn't have to. A plugin turns "agent-ready" from an engineering project into a checkbox in a dashboard they already use.

The day an agent can buy from a regular WooCommerce store as easily as from a purpose-built API, it stops being a developer economy and starts being the economy

@sabber_ahamed Loomal verifies each signed payment authorization and returns a signed receipt after settlement. We’re also designing the retry flow so a failed request doesn’t accidentally result in duplicate charges, but we don’t want to overstate the current guarantees around idempotency yet. For now, callers should use sensible retry and request-deduplication logic.

@sabber_ahamed Great question — the replay safety is protocol-level, so neither side has to be careful 😄

Every payment is a single-use signed authorization — once it settles, it's spent. A misconfigured agent retrying the same request just re-sends the same authorization, and it simply can't settle twice. And if the call fails before settlement, no money moved at all.

Where we go beyond vanilla x402: we verify before we ever settle (amount and recipient must match what was actually signed), and every settled call gets a signed receipt — so both sides have cryptographic proof of exactly what was paid, once. Stock x402 gives you the rail; we added the paper trail.

@marcin_uchacz1 There's a chance — it's actually two layers.

On Loomal: every payment produces a signed receipt — which agent paid, which endpoint, amount, timestamp. So for transactions, the record exists by default.

"What did it do and who authorized it" beyond payments is an identity problem, and it's exactly why we built Mailgent (launched here last week): each agent gets its own cryptographic identity, actions are signed against it, and permissions are scoped — so you can show which agent did what, under whose authority, with proof.

@marcin_uchacz1 There's very much a chance — this is honestly the whole reason we glued identity to payments.

Every agent on Loomal has its own verifiable identity with its own keys — it's never "someone with the company card," it's that specific agent. Every payment it makes settles on-chain (public tx) and comes with a signed receipt binding the agent, the recipient, the amount, and the exact resource it paid for.

So when your agent does something dumb, you can reconstruct the whole story: which agent, what it paid, to whom, for what, and when — and verify every signature independently, without trusting us. You scope what each agent is allowed to do up front, and the receipts prove what it actually did.

Blaming the intern has never been this cryptographically rigorous.

@kevin_win This is exactly the kind of thing we daydreamed about while building. The OBD agent is a great example because it's the full loop: detect fault, find service, pay, all with zero human in the mood to deal with it 😄

The honest gap you'll hit: your agent can pay today, but the mechanic side needs an agent-payable endpoint too. That's the chicken and egg the Index exists to solve. Even a simple booking API with a deposit endpoint would make your demo work end to end.

Please do experiment with the SDK, and when the headunit agent makes its first payment, I want to see the video. You're in the founding 500 if you list anything. What's your stack on the agent side?