feat: add /v3/transactions/simulate endpoint#7424
Conversation
Added a new authenticated RPC endpoint `POST /v3/transactions/simulate` which simulates a single transaction on top of the canonical chain tip (discarding all state changes) and reports its result, events, and execution cost.
890e338 to
80176de
Compare
There was a problem hiding this comment.
Pull request overview
Adds a new authenticated RPC endpoint to simulate a single signed Stacks transaction against the canonical chain tip, returning the execution result, events, and execution cost without persisting any state.
Changes:
- Implement
POST /v3/transactions/simulaterequest/response handling and simulation logic in an ephemeral Nakamoto tenure/block context. - Register the endpoint in the RPC router and add API tests covering success + auth/nonce failures.
- Document the endpoint in OpenAPI and add a changelog fragment.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| stackslib/src/net/api/txsimulate.rs | Implements the new /v3/transactions/simulate RPC handler, simulation logic, and client request/response helpers. |
| stackslib/src/net/api/tests/txsimulate.rs | Adds tests for request parsing, error cases, and successful simulation behavior. |
| stackslib/src/net/api/tests/mod.rs | Wires the new txsimulate test module into the API test suite. |
| stackslib/src/net/api/mod.rs | Registers the new RPC endpoint in StacksHttp. |
| docs/rpc/openapi.yaml | Documents the new endpoint contract and response shape. |
| changelog.d/tx-simulate-endpoint.added | Changelog entry announcing the new endpoint. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Make `from_receipt` return a `Result` and properly handle a json serialization failure.
francesco-stacks
left a comment
There was a problem hiding this comment.
Overall LGTM, just a couple of points:
- the OpenAPI CI step is failing
- could we also add the same memory limit mechanism we use on the miners/signers to guarantee that the transaction we are executing actually stays within the limits and would be accepted by the miners/singers?
This cost will always have a value, so no need to complicate the result with an optional.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Coverage Report for CI Build 29847442772Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage increased (+0.8%) to 86.522%Details
Uncovered Changes
Coverage Regressions12006 previously-covered lines in 166 files lost coverage.
Coverage Stats
💛 - Coveralls |
|
I like it, given that the block simulation rpc endpoint supports running transactions in any arbitrary block in the chain, can we have the same feature here? |
Added a new authenticated RPC endpoint
POST /v3/transactions/simulatewhich simulates a single transaction on top of the canonical chain tip (discarding all state changes) and reports its result, events, and execution cost.Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/property-testing.md)changelog.d/README.md)rpc/openapi.yamlfor RPC endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepo