Agents already do real things: they send messages, make payments, decide on someone's behalf. When a dispute starts, there is nothing to point at. Provyn hashes, signs and anchors every meaningful action, so you can prove later what the agent did and when.
Status: an early-access pilot running on the TAC SPB testnet. Contract, API and verification endpoints below are live and public - you can check every claim on this page yourself.
"The agent bought the wrong thing." "I never authorised that." Today the only record of what happened is a log file held by the operator of the agent - who is also the party being accused. A notary of their own deeds.
Provyn turns that log line into evidence. At the moment of the action, the agent hashes what it did, signs the hash with its own key, and sends only the hash to us. We batch those hashes into a Merkle tree and anchor the root in a public smart contract. From then on the record cannot be edited retroactively - not by the operator, not by the agent, and not by us. Anyone holding the attestation ID can verify inclusion against the chain, without asking us for permission.
| The agent's own logs | With Provyn attestation | |
|---|---|---|
| Who holds the record | the operator (interested party) | a public contract |
| Can it be edited after the fact | yes, silently | no - not even by us |
| Who can verify | only the operator | anyone, independently |
| What the counterparty must do | trust you | check a Merkle proof |
| What leaves your servers | whatever you export | a hash and a signature |
| Reputation basis | self-reported | anchored history |
Three calls. The blockchain stays out of your way: we run the relayer, we pay the gas, and your code never touches a wallet.
One call registers a DID for your agent (did:provyn:your-agent) and binds it to your platform. From that point the agent has a stable identity that its attestations and its reputation hang off.
You canonicalise the action, hash it, sign it with the agent's key, and POST the hash. Not the prompt, not the payload, not the user's data - just sha256 and a signature. We queue it, put it in a Merkle batch and anchor the root.
Two public endpoints, no API key required. One returns the attestation with its Merkle proof and the anchoring transaction; the other returns the agent's score and the signals behind it. That is the whole trust model: don't trust us, check the chain.
None of these rest on a promise from us. They are consequences of where the record lives and what leaves your servers.
This widget calls the public API from your browser - no key, no account, no server of ours in the loop beyond returning the proof. Paste an attestation ID and follow the transaction to the explorer.
› the same two endpoints your counterparty would call. Nothing here is privileged.
A score built only from your own activity is a score you can farm. So the weights are arranged around one idea: the signals that are hard to fake alone are worth the most.
Every weight above is chosen against one attack: an operator inflating their own agent's standing. Volume and age are easy to manufacture, so together they are worth a quarter. A co-signature and a diverse set of counterparties require other people to participate - so together they are worth close to half.
The score is recomputed from the anchored history and returned by a public endpoint, alongside the raw signals. You can always see why a number is what it is, rather than being handed a rating.
The contract is deployed, the API answers, the endpoints below need no key. This is a testnet pilot, and we would rather say so than dress it up.
| Stage | Early access · testnet pilot. Not production. Access keys are issued manually. |
| Network | TAC SPB Testnet · chain ID 2391 |
| Contract | ProvynAttestationRegistry 0xFa0f9a36473FCA38406dEf81ae06339A3389B412 |
| API | https://api.provyn.cloud |
| Public endpoints | GET /v1/attestations/{id} → status, tx, Merkle proof GET /v1/agents/{did}/reputation → score and signals Both without an API key - by design. |
| What we receive | A hash and a signature. Never the action, the prompt or user data. |
| Anchoring | Merkle batches; the root is written on-chain by our relayer |
| Identity | DID per agent, bound to an operator platform |
| Gas | Paid by Provyn. No wallet or tokens on your side. |
| Integration | Register once, then one POST per action. About an hour of work. |
| Not this product | This layer is anchoring - hash, signature, immutability. Zero-knowledge proofs are a separate Provyn product; we do not conflate the two. |
If yours isn't here, email sales@provyn.cloud.
No, and that's structural rather than a policy. Your side computes sha256 over the canonical form of the action and sends us the hash plus a signature. The action itself never crosses the boundary. We could not show you a prompt if you asked us to, because we never had it.
Not once it's anchored. The Merkle root is in a public contract on a chain we don't control. We could stop accepting new attestations, but we cannot rewrite the ones already there - which is the entire point of putting them outside our own database.
No. Our relayer holds the wallet and pays the gas. Your code makes an HTTPS request with a bearer key, exactly like any other API. The chain is an implementation detail of durability - if it were replaced tomorrow, your integration wouldn't change.
No, and we're careful about this. This layer is anchoring: a hash, a signature, and immutability. It proves that an action was recorded at a point in time - it does not prove statements about hidden data. That is ZK Validation, a separate Provyn product. Mixing the two words would be misleading.
An early-access pilot on the TAC SPB testnet. The registry contract is deployed, the relayer is anchoring batches, and the public verification endpoints work - you can confirm all of it from this page. We're not claiming production status or announcing mainnet dates, because neither is decided.
The other party signs the same canonical action hash with their own key and submits it against the attestation. Because both signatures cover the identical leaf, agreement is verifiable by anyone later. This is the signal that carries the most weight in the reputation score, precisely because one side cannot produce it alone.
Keys are issued by hand at this stage - there's no self-service signup for attestation yet. Use the form below and tell us roughly what your agent does; we'll send a key and a quickstart.
Tell us what your agent does and we'll send an access key and a quickstart. Keys are issued manually while this is in early access - so a human reads every request, and you get a straight answer about whether it fits.