See what a past or proposed transaction actually entails.

Whether you are considering a past or proposed transaction, the tools below can help you learn more about its properties and behavior. These capabilities can also be used programmatically via the kinetics library.

Transaction Analysis

Examine any past transaction on Sui, Aptos, or Movement: its structure and flows, the value that moves, the state it changes, and its cost. The analysis runs locally in your browser or workflow. Nothing but the RPC request is ever visible to third parties.

Run the analyzer

Transaction Simulation

Take a transfer you set up on Sui, Aptos, or Movement and see what it would do before it is ever signed: the balances it would move, the state it would change, and what it would cost. The transfer is executed against live chain state by the network itself. Nothing is signed or broadcast.

Run the simulator

Transaction Analysis

PTB Analyzer Sui Mainnet

graphql.mainnet.sui.io

On Sui, the analyzer reconstructs the programmable block's dataflow graph and runs critical-path, taint, linear-resource, and gas analyses. On Aptos and Movement — account-model chains with no result-chaining — it decodes (the payload, the balance movements, the events, and the write-set) and attributes gas. Everything runs client-side after a single public RPC request.

01Dataflow graphEvery command and input as a node; result handles resolved into edges you can read.

02Dependency depthThe true serial backbone of the transaction — what genuinely depends on what.

03Taint trackingForward propagation from each input to every transfer, merge, and call sink.

04Resource accountingLinear-resource conservation: what's created, mutated, deleted, and whether it balances.

05Dangling resultsValues a command produces that nothing consumes — a common cause of aborts.

06Gas attributionComputation, storage, and rebate broken out from the transaction's effects.

Transaction Simulation

Set up a transfer the way a wallet would, then see exactly what it does before anything is signed or broadcast: the balances that move, the state it changes, and the gas it costs. Perform a dry run against live chain state.

Simulate a Transfer Sui Mainnet

From — sender account (simulated, no signature) To — destination Amount

SUI

Agent spend policy — optional; gates the payment before it is signed

Spend cap — the most the agent may actually part with

SUI

Allowed recipients — comma-separated allowlist

fullnode.mainnet.sui.io

This is an actual simulated transfer executed against current chain state by the network itself (Sui’s simulateTransaction and the Aptos/Movement simulate endpoint) with signature checks disabled. Nothing is signed and nothing is broadcast; only the RPC request ever leaves the browser.

Attach a spend policy — a cap and an allowlist — and the simulator returns a decision object: allow or deny, bound to these exact parameters, judged against what the transfer actually moves rather than the amount it claims. This is the check an agent’s signer can run before it authorizes an x402 payment: gate on the real effect, refuse (if necessary) before the wallet signs.

Use cases

A wallet developer, a security auditor, and a DeFi engineer look at the same Sui or Aptos transaction and each ask a different question. The tools above answer all three from the transaction's structure alone — statically, client-side, before anything is signed. Every finding shown is real analyzer output on a representative transaction; addresses and amounts are illustrative.

Wallet developer · Aptos

What is my user actually approving?

Decode the payload before the prompt and show in plain words what this signature approves.

See the use case

Security auditor · Sui

Does it send value only where it claims?

Trace taint from inputs to every sink, and check that the object accounting closes.

See the use case

DeFi engineer · Sui

Will it land or strand value?

Map the dataflow, spot the unused value, and catch the abort before submission.

See the use case

APTOS

What is my user actually approving?

wallet developer · signing preview

Situation

A dApp hands your wallet an Aptos transaction and a friendly label: "claim rewards". The confirmation screen you build is the last thing the user sees before their APT can move. You want it to say, in plain words, exactly what this payload does — not what the dApp calls it.

What you do

Before you render the prompt, run the payload through the Move analyzer. It decodes the entry function, its type argument, and its arguments — no execution, no signature.

import @choosek/kinetics → call analyzeMoveTransaction(payload)

What Kinetics shows

function 0x1::aptos_account::transfer_coins
type arg 0x1::aptos_coin::AptosCoin · args [ 0x9f2c…e70a, 50 APT ]

!This is a value-out transfer. 50 APT leaves the signer to 0x9f2c…. Whatever the calling UI named it, the payload's own content is a plain coin transfer — surface that before the tap.

effect transfer out asset APT amount 50 payload entry fn

signer value leaving account decoded from the payload — no signing

Your user sees “Send 50 APT to 0x9f2c…” and not just "confirm". The decode is the transaction's own content — the wallet just makes it legible in the half-second before a signature commits it.

SUI

Does it send value only where it claims?

security auditor · integrator due-diligence

Situation

You're reviewing an unfamiliar transaction before trusting it: it unwinds a liquidity position, swaps one side, consolidates the proceeds, and sends them to an address. You need to confirm the money lands where it should and that nothing unexpected is created or destroyed.

What you do

Paste the digest. Read the value flow into every sink and the object accounting, instead of tracing four commands and their result handles by hand.

go to kinetics.network → paste digest → analyze

What Kinetics shows

→Taint into the transfer sink: reached only by LP token, pool, and the destination address. No stray input feeds the payout.

✓Objects balance. 1 created, 1 deleted (the LP burned), 2 mutated — net object delta 0.

taint → transfer {LP, pool, addr} net objects 0 gas net 0.00107 SUI

input taint path critical path transfer sink

In one read you've confirmed the proceeds go to exactly that address — nothing else reaches the transfer — and that the object accounting closes. The same check against a raw command list is slow and easy to get wrong.

SUI

Will it land or strand value?

DeFi engineer · pre-submit debugging

Situation

You're shipping a one-click zap: take the user's SUI, swap part of it to USDC, add both sides to a pool, send the LP token back. Your happy-path test is green — but a teammate's transaction aborts on-chain with unused value without drop, and the error doesn't say which value.

What you do

Paste the transaction — a digest, or the PTB your SDK just built, before you ever submit it.

go to kinetics.network → paste digest or PTB JSON → analyze

What Kinetics shows

!Dangling result at command 0 — split output never consumed. The LP-side coin has no outgoing edge, so the transaction aborts.

dependency depth 4 · serial dangling 1 package 0xdex

input critical path output dropped / dangling

▶See it as a failing CI testthe same finding, asserted in your test suitekinetics.test.ts

import { describe, it, expect } from "vitest";
import { analyzePtb } from "@choosek/kinetics";
import { buildZapPtb } from "../src/zap";

describe("zap → LP", () => {
  const ptb = buildZapPtb({
    amountToSwap: 1_000_000n,
    amountForLp:  1_000_000n,
    pool: POOL_ID,
    recipient: USER,
  });

  it("strands no value", () => {
    const { resources } = analyzePtb(ptb);
    // A dangling result is a coin nothing consumes — on Sui that
    // aborts the whole transaction with "unused value without drop".
    expect(resources.dangling).toHaveLength(0);
  });

  it("pays only the recipient", () => {
    const { taint } = analyzePtb(ptb);
    const transfer = taint.sinks.find((s) => s.kind === "transfer");
    // input 3 is the recipient address; nothing else should reach it.
    expect(transfer?.taintedBy).toContain(3);
  });
});

Run against the buggy zap, the first test fails with the exact location: dangling → [{ command: 0, reason: "split output never consumed" }]. Wire the stranded coin into add_liquidity and it goes green — the abort is caught in CI, before any gas is spent.

Fix it — thread the stranded coin into add_liquidity — and re-run: dangling results: 0. You found a submit-time abort from the transaction's shape, before spending a cent of gas, and without decoding a single result handle.

Coming Soon

Private analysis · Premium feature

Private Simulations

Protocol teams testing DeFi strategies can't broadcast what they're doing. Kinetics will run your simulation privately: inputs encrypted client-side, results stored securely, and access gated by a Move contract you define. Counterfactual dry-runs against live mainnet state with no trusted third party (not even us).

Encrypted end-to-end Access via Move policy Live mainnet state