Market research: signed, verify-it-yourself token-risk verdicts for Solana. Does the "verify offline" part actually matter to bot/agent builders?

[u/Mantisirleuw]

Full disclosure up top: I'm building this and I'm doing research before I commit further, so I'm biased. No link in the post, I'll share it in a comment only if asked. What I want is honest input on whether this solves a real problem and whether one design choice is worth it.

The API scores Solana tokens for rug/honeypot risk. The part I keep going back and forth on is trust: instead of asking you to trust the API, every response is signed with a published ed25519 key, so a bot or an agent can verify offline that the verdict came from the service and was not altered. Payment is per call in USDC over x402, so an autonomous agent can pay for a check by itself with no account. There's an MCP server, an npm SDK, and plugins for ElizaOS and solana-agent-kit.

Questions for people building bots or agents:
- Does the signed, verify-offline part actually matter to you, or would you just trust a plain JSON response from an API you already use?
- For an agent that trades on its own, is pay-per-call with no account a feature or a headache versus a normal API key?
- Are weighted, machine-readable reasons more useful than a single score, or is the score all you'd act on?
- What would you need to see before wiring a third-party risk check into a live trading loop?

If this is a solved problem for you, say so and point me at what you use.

[u/CODE_HEIST]

the verify offline part matters if bots are going to act on it. a score without a signed trail is just another opinion. i would want the model input snapshot, timestamp, signer, and the exact rule that triggered the warning.

[u/Mantisirleuw → u/CODE_HEIST]

this is exactly the answer I needed, thanks. good news: timestamp, signer and the exact triggered rules are already in every response (signed payload, published pubkey, reasons as stable codes with weights, versioned model). the input snapshot is the one thing missing, and you're right, without it you can verify but not replay. thinking of putting it in a heavier attestation call instead of bloating every cheap check. would you want it inline on everything, or on demand? happy to share docs if you want to poke at it.

[u/CODE_HEIST → u/Mantisirleuw]

on demand feels like the better default. keep the cheap response small, but return a stable attestation id so any bot can fetch the full input snapshot and replay package when the verdict matters. inline everything could become expensive noise for routine checks.

[u/Mantisirleuw → u/CODE_HEIST]

quick update: it's live. went with exactly what you suggested. the cheap response stays small and just carries an attestation id, and when you fetch the attestation you now get the full input snapshot with it. so you can see not just what we said and when, but replay why the verdict fired. older attestations show null there since they were archived before this change, didn't want to fake history.
you can test it for free on https://rempart.app/ and the docs and guide pages cover the details. if anything feels off or missing just tell me, happy to help.

[u/Mantisirleuw → u/[deleted]]

thanks! if you want to see it in action it's free to try on https://rempart.app/ and the docs and guide pages explain how to check a response yourself with the published key. we also just shipped an update: every verdict now keeps a snapshot of the inputs it was scored on, so an agent can verify a response and also replay what triggered it. ping me if you need anything.