Onchain
Simulate a transaction before anyone signs it, and read what happened to a signing request.
The Onchain category is the value-moving story, and it is two tools long. The
category is deliberately not part of Blockchain: Blockchain is a read-only
view of a chain anyone can query, and this is about a transaction belonging to
the caller and a signature only the caller can give. Different trust story, so
a different category.
The two tools
simulate_transaction runs eth_call — and a trace where the RPC supports
one — against the chain's own RPC, and reports whether the transaction would
succeed. It never signs and never sends, so it is safe to run against a
mainnet endpoint. It returns either success with the balance changes and the
emitted events, or a failure carrying the node's own revert reason.
tx_request_status reads one signing request by id. Call it after any
value-moving tool: that tool returns a TxRequest with a status of pending
and a summary of what the transaction would do, and this is how you learn
whether the user signed, whether it confirmed onchain, or whether it reverted.
It works for both caller flavours — a dashboard user posting a Privy access
token, or a non-dashboard caller presenting an sk- key.
Why a request, not a send
A signing request is a record the user approves, not a call the server makes.
The two-step shape — a tool returns a TxRequest, the user signs, a second call
reads what happened — is the same shape the Social category uses before a post
goes out. Nothing in this category can move a value on its own.
trust_receipts
Read a token's trust setup: the trust modules deployed for it, what each module's controls are and what the current values are, the holders and the recipients any fee is split between, the change log, and the version/supersession chain. FREE, unauthenticated, and it reads the chain but spends nothing of yours — it is the same document a holder sees at the public Receipts page, so use it to check a claim before repeating it. **Zero modules is a real answer, not an error**: a token whose creator never registered a trust setup has none, and the document says so out loud rather than rendering an empty shell that reads like a broken page. A failed chain read becomes a named `warnings` entry and the rest still renders, so read `warnings` before treating an absent control as 'not set'. Nothing here is an audit: the document reports what the contracts declare and what the chain shows, and a module being present says nothing about whether it is well configured.
Transactions
Simulate a transaction, and read what happened to a signing request.