DeFi analysis and reporting

Complex, high-value crypto actions deserve analysis before signing and a verifiable record afterward. BEX brings the browser page, pending wallet request and provider results into the same workflow so Codex or another connected agent can explain what is happening and document the decision.

Watch: A professional DeFi workflow.

This workflow is useful for treasury swaps, spending approvals, loan repayments, collateral changes and position adjustments. These are use-case examples, not claims that the video executed those trades. Begin with Agent Mode setup and profile selection.

Define the intended action

Write down the network, account, assets, amounts, protocol and intended recipient or spender before opening an approval. Include limits such as maximum spend, minimum output, slippage, deadline and allowed approval amount where relevant. State which browser profile the agent may use and which steps require your authorization.


Prepare a decision brief for the action I describe. Use only the selected
browser and account. Compare my intent with the live page and pending
wallet request. Identify costs, permissions, risks and unresolved facts.
Include source URLs and observation times. Do not submit or sign while
preparing the brief. Stop if the network, account or request differs.

Use explicit amounts and units. “Move my funds” or “optimize the position” leaves too much unspecified for a material action.

Prepare the decision brief

Have the agent separate observed evidence from inference:

Check	What the brief should record
Identity	Browser/profile selection, site origin, chain, account and protocol.
Actual request	Method and parameters from the pending request, not just the page’s button label.
Assets and permissions	Token contract, decimals, amount, recipient/spender, and allowance scope where applicable.
Economic effect	Expected input/output, fees, price impact, slippage or collateral consequences, with the source and time of each estimate.
Uncertainty	Missing data, undecodable payloads, stale quotes, unsupported simulations or assumptions that still need checking.
Decision	Proceed, revise, reject or gather more evidence, with the reasons and required human review.

An agent should not claim it simulated a transaction, verified contract code or checked a security audit unless it actually performed that work and can identify the evidence. A quoted output or successful simulation is not a guarantee of execution. Recheck a changed quote or request before signing.

For token approvals, pay particular attention to the spender and spending limit. Disconnecting a website later does not remove an on-chain allowance. See Signing and approvals and Verifying transactions.

Review and authorize

Pause when the pending request arrives. Compare it with your brief and the browser page. If it changed, update the brief before making a decision. Review what the device can display and reject a request whose consequences you cannot establish. See the wallet-request walkthrough.

KeepKey’s physical confirmation remains required for hardware signing. It does not certify the protocol, the agent’s analysis or the investment decision. Browser changes, including form submissions, may happen without a device press; authorize their scope separately.

Verify the outcome

Record the actual state reached, rather than labeling every finished agent turn “complete”:

State	Evidence to retain
Rejected or cancelled	The request identity, rejection result and subsequent queue state. No transaction hash is expected when nothing was submitted.
Signed	The signing result. A signature alone does not prove submission or settlement.
Submitted	Transaction hash and network, with submission time and explorer or node evidence.
Confirmed or failed	Receipt/status and confirmation evidence for that network. Check execution success separately from inclusion.
Result reconciled	Expected versus observed balances, positions, allowances or protocol state, including fees and any discrepancies.

For an on-chain action, inspect the block explorer evidence and relevant protocol state. Shielded operations have different visibility limits; do not demand public recipient or amount evidence that the protocol intentionally hides. A missing balance update can be a cache or sync problem; it is not proof that a transaction failed. Use missing-payment troubleshooting before retrying a transfer.

Keep an operational record

Save intent, sources and timestamps; exact request identity; the human decision; outcome evidence; and unresolved issues. Preserve original evidence privately, then redact a copy for sharing. Reports can expose account addresses, positions and business activity even when they contain no private keys. Exclude bearer tokens, recovery words and unrelated personal data.

The video includes this practice rejection, not a DeFi trade:


{
  "scope": "Practice signature request",
  "origin": "http://localhost:1746/wallet",
  "chain": "ethereum",
  "method": "personal_sign",
  "message": "I agree to the Example dApp terms",
  "decision": "rejected",
  "pendingRequestsAfter": 0,
  "signed": false,
  "transactionHash": null,
  "reason": "The request was rejected; no transaction was submitted."
}

For a real transaction, add the hash only when one exists, then record receipt and state checks separately. Provider logs are temporary and may be clipped or cleared when the extension service worker restarts. Export the necessary evidence while it is available; an absent log entry later does not prove nothing happened.

These records support operational audits, reconciliation, activity reports and handoffs. They are distinct from an independent smart-contract security audit or a determination of tax treatment. Portfolio reports provide a separate balance/history export and should be reconciled with the action record.