Skip to main content

Pre-Sign Preview & Wallet Risk Review

This page explains the smart-contract signing-review workflow in plain language.

Use this workspace when somebody on your team is about to:

  • approve a token spender
  • sign a permit or delegated-spend flow
  • grant operator access
  • call a router, multicall, or batch transaction
  • approve a treasury action you do not fully trust yet

If Contract Scanner answers "What kind of contract is this?", Pre-Sign Preview answers "What is this action asking the wallet to do right now?"

Why this matters​

Many costly smart-contract incidents do not start with an obvious exploit. They start with a wallet approval, a broad operator grant, a disguised multicall, or a transaction the signer did not fully understand.

That is why this surface exists.

Pre-Sign Preview combines:

  • what the user is about to sign
  • what Dralvia can decode from the transaction
  • what Dralvia knows about the target contract or spender
  • readable guidance about what the transaction means in practice

The goal is not just to show raw calldata. The goal is to help a workspace decide whether to continue, review further, or stop.

What this workspace shows​

Depending on the transaction and the evidence available, you may see:

  • a human-readable summary of the action
  • the decoded or partially decoded function path
  • warnings about approvals, operator rights, or spender behavior
  • transaction graph context
  • contract posture context
  • decision guidance such as allow, review, or block
  • browser or page context when DOM-intent capture is available

The workspace is now split into clear sections so the first screen is not a wall of forms:

  • Overview: shows whether there are linked tickets, a transaction readout, and a full review available.
  • Page Context: shows TicketBridge page-context evidence and lets you download the EvidencePack (Dralvia's exportable evidence report) when a linked ticket exists.
  • Transaction: collects chain, address, sender/value, and calldata for the wallet-action simulation. If the selected ticket already has saved transaction evidence, this section opens with that readout available.
  • Full Review: combines page context, transaction behavior, guidance, and explanation feedback.

The navigation change does not alter the review APIs or EvidencePack format.

Two types of evidence​

This workflow can combine two different evidence streams.

1. Transaction evidence​

This is the smart-contract side.

Dralvia reviews:

  • the contract address
  • the calldata
  • optional sender and value fields
  • decode source
  • spender or counterparty context
  • transaction-level decision guidance

This is the main part of wallet-risk review.

2. Page or browser context​

If your environment captures DOM intent or browser context, Dralvia can also show what the signer likely saw on the page:

  • prompts
  • wallet-related buttons
  • high-risk intent cues
  • supporting browser context

This is useful when the risk is not only in the raw contract call, but also in how the action was presented to the user.

What the decision is trying to answer​

A good wallet-risk review should answer:

  • Is this a simple approval or a broader delegated-spend grant?
  • Is the spender ordinary, suspicious, or still unclear?
  • Is the action understandable from ABI decode, selector fallback, or only partial evidence?
  • Does the transaction look routine, review-worthy, or unsafe enough to stop?

How to use this page​

Quick workflow​

  1. Open Wallet Risk Review from the workspace menu.
  2. Start on Overview to confirm whether linked evidence already exists.
  3. Open Transaction and enter or load the transaction details you want to review. If the selected ticket already contains a saved transaction graph, the Transaction tab and Overview card show that a readout is ready.
  4. Run the transaction simulation or preview build when the transaction has not already been captured.
  5. Open Full Review and read the summary before the raw details.
  6. Check the recommended action and the reason for it.
  7. Export or preserve the result if another reviewer or approver needs the same context.

For higher-value or higher-risk actions, use this order:

  1. Review the target contract in Contract Scanner.
  2. Open the same action in Wallet Risk Review.
  3. Compare the transaction meaning with the contract posture.
  4. Decide whether the signer should allow, pause, or escalate.

How to read the result​

If you are not deeply technical, use this reading order.

1. Read the summary first​

The summary is meant to tell you, in normal language, what the action appears to do.

Examples:

  • approve a spender
  • grant operator-style control
  • route assets through a multicall path
  • interact with a low-transparency contract

The result may recommend:

  • allow
  • review
  • block

Treat that as guidance, not blind automation. It is there to speed up a workspace decision, not replace judgment.

2A. Check whether you are looking at an initial or final review​

The workspace can now show explicit review states so a workspace does not have to guess whether more analysis is still running.

The most important states are:

  • Initial result: Dralvia finished the first read of the transaction and can already explain the main risk signals.
  • Deep review in progress: Dralvia is still collecting deeper evidence before the review is fully complete.
  • Final result: the review finished for the evidence available in this request.
  • Limited review: Dralvia completed the review with partial depth because one or more deeper checks were unavailable or timed out.

If you are seeing an initial result, keep reading the explanation, but do not assume that every possible supporting signal has already been collected.

If you are seeing a final result, that means the review reached the end of the available steps for the evidence you provided.

If you are seeing a limited review, pause before approving anything sensitive and retry once or escalate the case.

2B. Check the Simulation Summary panel​

When transaction evidence is available, Full Review shows a Simulation Summary panel near the top of the result.

Use it before the raw transaction details. It shows:

  • whether Dralvia simulated the call, decoded it without a provider check, or completed only a limited simulation
  • the practical wallet impact
  • balance movement counts
  • approval change counts
  • immediate outflow counts
  • unlimited approval counts
  • operator-rights changes
  • short explanations for the practical diff

If the panel says Limited simulation, treat the review as incomplete before approval. The panel keeps the degraded reason visible, such as provider timeout, unsupported chain, reverted call, missing state, or opaque delegate call, so reviewers can retry or escalate with the right context.

When a router, multicall, proxy, or batch wrapper contains recoverable inner calls, Full Review also shows a Nested Calls panel. Use that panel to review inner approvals, operator grants, transfers, target contract when available, decode source, and recovered arguments as part of one wallet action instead of treating them as unrelated findings.

If signed EvidencePack replay metadata is attached to the review, Full Review also shows an EvidencePack Replay Metadata panel. Use it to confirm the chain, target contract, signer, calldata, provider mode, block, result hash, fallback path, and nested-call count before sharing the pack with another reviewer or auditor.

When approval blast radius is high, the review can also include generic approval revocation guidance. Use it as a checklist for the asset contract, spender or operator, chain, suggested revocation method, and limitations. It does not mean a specific wallet or marketplace can revoke the approval for you. Always preview the revocation transaction and recheck the approval state after it confirms.

The Transaction and Full Review tabs can also show an Approval Paths panel. Use it to compare the approval target, effective spender, approved asset, scope, duration, blast radius, and confidence before deciding whether the request is safe enough to continue.

3. Check how well Dralvia understood the transaction​

Not every transaction decodes the same way.

Dralvia may understand the action through:

  • ABI decoding
  • selector fallback
  • partially opaque selector recovery

That distinction matters. A transaction can still be risky even when the decode is partial, but the confidence level may be lower.

4. Check the action meaning, not just the raw bytes​

What matters most is the practical consequence for the wallet:

  • decoded balance changes
  • unlimited or broad approval
  • delegated asset movement
  • operator control
  • token or NFT transfer path
  • router, proxy, or batch execution path, including decoded nested calls when a recoverable wrapper is present

The safest workspace habit is to ask:

"If the signer presses confirm, what new power does the other side get?"

The preview includes a normalized simulation summary when transaction evidence is available. It separates balance movement from approval changes so reviewers can see whether value leaves immediately, whether spending rights expand, and whether the review was simulated, decoded only, or degraded. When a chain provider is available, Dralvia also checks the single call against current chain state and records the block and chain used for that check.

The same summary includes short explanations for the practical diff: assets leaving the wallet, assets entering the wallet, delegated movement, spending approval changes, operator rights changes, and unknown state changes.

When Dralvia decodes approval or operator evidence, saved previews and API results can also include approval-path evidence. Use it to confirm the approved asset, wallet owner, effective spender or operator, scope, and whether the spender could not be fully resolved. For Permit2 single approvals, Dralvia can recover the tuple spender and approved token when the calldata is complete enough to decode. Permit2 batch approvals can show one path per recovered token scope so reviewers can see each approved asset separately. For Permit2 transfer payloads, Dralvia can recover the token, owner, recipient, requested amount, nonce, and deadline when those fields are present. Some Permit2 transfer paths do not encode the spender directly, so treat an unknown spender as partial evidence even when the token movement is clear. For recoverable batched calls and targeted wrappers, this evidence can also show the wrapper, target contract, and inner call that produced the approval path.

Standard token approvals may also show an approval safety review. Use it to check whether a nonzero approval was preceded by a same-batch zero reset for the same spender. If Dralvia shows a reset-bypass indicator, it does not prove an old allowance exists. It means the safer reset pattern was not visible in the reviewed signing flow, so the approval needs human review before signing.

Approval paths may also show a blast-radius review. Use it to check whether the approval is limited, unlimited, delegated-transfer based, or collection-wide operator access. The review also calls out when token value or current wallet holdings are not known from the captured evidence. Treat a high blast-radius result as broad wallet exposure, especially when the spender is unknown, watchlisted, clustered with other roles, or paired with batch execution.

Permit-style approvals may also show a replay review. Use it to check whether the signature deadline or Permit2 expiration is already expired, whether a deadline is missing, whether the nonce is visible, and whether typed-data domain or chain binding cannot be fully proven from the transaction calldata alone. If your wallet capture includes typed-data domain evidence, Dralvia also compares the domain chain and verifying contract with the reviewed transaction. A chain mismatch is cross-chain replay risk, and a verifying-contract mismatch means the signed domain does not match the permit contract Dralvia reviewed. If the replay review is high or medium risk, treat the permit as an approval that needs explicit human review before signing, even when the spender and token are visible.

When you export an EvidencePack for a pre-sign review, Dralvia signs the replay metadata with the pack. The export keeps the chain, target, transaction input, provider mode, block, chain ID, result hash, fallback path, and nested-call count together with the decision record. The workspace shows those signed replay fields in Full Review when they are present on the saved ticket or attached pack metadata.

Dralvia validates the review path against routine swaps, drainer-style approvals, approval-only actions, reverted calls, and provider degradation. Treat degraded results as incomplete, not safe.

5. Check the confidence and transparency context​

If confidence or transparency is limited, that does not automatically mean the transaction is malicious.

It means:

  • the workspace should avoid over-trusting a clean-looking result
  • deeper review may still be warranted before signing

What the most common outcomes mean​

allow​

This means Dralvia did not find enough evidence to recommend stopping the action.

It does not mean the workspace should stop paying attention forever. It means the action looks routine enough for normal approval based on the evidence available.

Plain payments to a wallet. A request that only sends the network's coin (no call data) to an address with no contract code is allow with basis plain_transfer_to_wallet ("A plain payment to a wallet"), unless the address is on a known-bad list, which is still block. A wallet with an EIP-7702 delegation counts as a wallet; insights.flags.recipient_delegated_7702 says so. A payment to a contract, or to an address Dralvia could not read, keeps the full review. Before 2026-10-05 every plain payment came back review, because a wallet has no source code to read.

review​

This means the action deserves a deliberate human decision before signing.

Typical reasons include:

  • broad approvals
  • delegated spend behavior
  • low transparency
  • suspicious counterparties
  • mixed or partial decoding
  • elevated contract posture risk

block​

This means Dralvia found strong enough evidence that the action should not be approved in its current form.

Examples can include:

  • obviously dangerous approval behavior
  • high-risk operator grants
  • severe mismatch between the requested action and the contract’s control profile
  • an address in the request (spender, operator, recipient or target) on a known-bad address list, such as the US sanctions list. This is always block, even when other parts of the review are uncertain, and the result says so (final_decision.basis is watchlisted_counterparty).
  • a payment to an address that only looks like one the sender has paid before (address poisoning). This is always block too, with final_decision.basis lookalike_recipient.
  • a payment to a wallet that has been taken over (see below). This is always block, with final_decision.basis compromised_recipient.

Look-alike recipients (address poisoning). Scammers send tiny or zero-value transfers from addresses that share the first and last characters of an address you use, so that the look-alike shows up in your history and gets copied next time. When a request pays someone (a coin send with no call data, or a token transfer / transferFrom of the sender's own tokens) and includes from, Dralvia reads the sender's latest transactions on the network's explorer and lists the addresses the sender has paid. If the recipient is not one of them, but one of them shares at least 3 leading and 3 trailing characters with it (7 or more in total), the request is block. The drivers name both addresses. Only payments the sender signed count, so the scammer's own transfers never make the look-alike count as paid.

insights.recipient_history_review.status tells you what was found:

statusmeaning
lookalikeblocked; lookalike_of is the address the sender actually paid
paid_beforethe sender has paid this address before
new_recipientthe sender has not paid it, and it looks like nothing they have paid
uncheckedthe explorer could not answer; the decision is the same as without this check

Limits:

  • Only the latest 200 transactions are read (50 when the explorer's answer is too large).
  • Payments made through a smart-contract wallet (such as a Safe) are not read.
  • If the sender has already paid the look-alike once, it counts as paid before and is not blocked.
  • Ask without from and this check does not run.

Taken-over wallets (EIP-7702). Since Ethereum's Pectra upgrade a wallet can hand control to a contract (an EIP-7702 delegation). Thieves use this in two ways: on a wallet whose key they stole, the contract forwards every coin sent to it to the thief in the same transaction (the "sweeper" Wintermute named CrimeEnjoyor); and address-poisoning operations run hundreds of look-alike wallets through one contract (a contract verified as "Poisoner"). When a request pays someone (a coin send, or a token transfer / transferFrom of the sender's own tokens), Dralvia reads the recipient's code; if it is delegated to one of these, the request is block, and insights.recipient_delegation gives the wallet, the contract it is delegated to and the family (sweeper or poisoner). The drivers name both.

Measured on Ethereum on 8 October 2026: the Poisoner was the most-used delegation target of all (2,847 of 10,579 delegations in 2,000 blocks); 161 wallets delegated to it and 32 to a sweeper copy within 400 later blocks. The contracts are recognised by the functions they expose, so a new copy is recognised too; none of the 91 other delegation targets seen, which include MetaMask's and other wallets' own, matched. Ordinary wallets and wallets delegated to a real smart-wallet contract stay a plain payment.

Limits: only these two families are named; other contracts thieves write themselves are not. If the chain cannot be read, the decision is the same as without this check.

Step-by-step with the UI​

Before you start​

Confirm these basics first:

  1. You are signed into the correct workspace.
  2. You have the role or entitlement required for this workspace.
  3. You have the contract address and calldata ready.
  4. If browser context is expected, your browser or extension capture path is enabled.

Fields you will usually fill​

  • chain
  • to or contract address
  • data
  • optional from
  • optional value

Standard review flow​

  1. Open the workspace.
  2. Select the relevant ticket or work item if your process uses one.
  3. Check whether Overview already shows a ready transaction readout for the selected ticket.
  4. Fill the transaction simulator fields only when no saved transaction evidence is attached.
  5. Run the review.
  6. Read the summary, simulation status, balance changes, approval changes, warnings, and decision guidance.
  7. Save or export the result if another approver needs it.

API examples​

Transaction review​

curl -X POST "$DRALVIA_BASE_URL/<transaction-review-endpoint>" \
  -H "Authorization: Api-Key $DRALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "Ethereum",
    "to": "0xContract",
    "data": "0x..."
  }'

Build the combined preview​

curl -X POST "$DRALVIA_BASE_URL/<preview-build-endpoint>" \
  -H "Authorization: Api-Key $DRALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "Ethereum",
    "domain": "example-app.test",
    "tx_graph": { "...": "..." }
  }'

Who this is for​

  • Treasury approvers, founders, and signers reviewing wallet actions before approval.
  • Security analysts or smart contract reviewers supporting a high-risk transaction decision.
  • Workspace admins who need a readable explanation before a wallet confirmation step.

Role-based start here​

  • Treasury approver: start with Step-by-step, then read Troubleshooting and FAQ.
  • Security analyst: start with Day-2 operations, then use API and automation.
  • Workspace admin: start with Before you start, then review What each button does.

Step-by-step​

  1. Open the Wallet Risk Review workspace.
  2. Fill in the required chain, target, and calldata fields.
  3. Run the review or preview build.
  4. Read the summary, recommended action, and decode-confidence context before raw details.
  5. Export or preserve the result if another signer or approver must review it too.

Day-2 operations​

  1. Re-run review when transaction inputs change.
  2. Escalate any review, block, limited review, or opaque decode result for human approval.
  3. Compare repeated risky spend or operator patterns against related contract-scan findings.

Self-check playbook​

  1. Confirm the chain, target, and calldata are from the exact action about to be signed.
  2. Confirm you are reviewing the correct workspace and wallet request.
  3. Confirm whether the page also captured browser or DOM intent context when you expect it.
  4. If the decode is partial, retry once before treating the result as final.

What each button does​

  • Run review or equivalent preview action: decodes and evaluates the pending transaction.
  • Export or Save: preserves the review for another approver or audit trail.
  • Any refresh or rerun action: rebuilds the review with the current transaction inputs.

API and automation​

  • Use the workspace transaction-review endpoint from the Wallet Risk Review API reference.
  • Use the workspace preview-build endpoint from the Wallet Risk Review API reference.

Who can call these endpoints​

Wallet Risk Review needs a workspace identity. Three credentials count, and all three are treated the same way:

  • a signed-in workspace user,
  • a workspace API key,
  • an enrolled browser extension. The extension's device token is a workspace-scoped credential in its own right, so the extension can build a preview without the user also holding a separate session. From extension version 1.1.1 the wallet guard calls /pre_sign/txsimulate for each transaction or permit a page asks the wallet to sign, when the workspace has wallet warnings (the pre-sign setting) turned on. A signature permit is sent as the permit(...) call that would redeem it, with its typed-data domain in typed_data_domain. See Wallet guard.

Anonymous callers, and callers whose credential carries no workspace, are rejected — see the error reference below.

Fixed on 2026-08-11

/pre_sign/preview, /pre_sign/dom_intent and /pre_sign/txsimulate previously accepted only a signed-in browser session. Both other credentials were rejected with 401 authentication_required:

  • workspace API keys — so server-to-server wallet review did not work at all, and
  • enrolled browser extensions — even though the extension is expected to call these endpoints.

If a wallet review worked from the workspace UI but failed from your integration or from the extension, that was this defect. No client or extension update is needed.

One response code changed as part of the fix: a credential that is valid but carries no workspace now returns 403 Forbidden (tenant_required) rather than 401, which is what it always should have said. Genuinely anonymous callers still get 401.

API error quick reference​

  • 401 Unauthorized: your workspace session, API key, or extension enrollment is missing or invalid.
  • 403 Forbidden: your role is not allowed to run or view this wallet-risk review path.
  • 404 Not Found: the referenced review, preview artifact, or related object could not be found.
  • 429 Too Many Requests: the workspace hit a rate or workload limit; pause and retry.
  • 500 Internal Server Error: the review backend failed while decoding, enriching, or rendering the transaction analysis; retry once before escalating.

Next best actions​

Related guides:

FAQ​

What if the result is only an initial review?​

Use it as an early warning, but wait for final review or rerun the request before approving anything sensitive.

Does allow mean the transaction is safe?​

No. It means Dralvia did not find enough evidence to recommend stopping it based on the current inputs.

What does a degraded simulation mean?​

It means Dralvia could not complete every review path at full depth. The result can still show decoded balance or approval changes, but the workspace should not treat the output as complete proof. Retry once, then escalate if the action is sensitive.

Common degraded reasons include provider timeout, provider unavailable, unsupported chain, reverted call, missing state, opaque delegatecall, and provider error.

Next steps​

  1. Compare the action with Contract Scanner posture.
  2. Preserve evidence for the signer or approver chain.
  3. Stop or escalate any transaction that still looks unclear after review.

What to do when the result is unclear​

If the result feels incomplete or uncomfortable, do not improvise. Use this order:

  1. review the target contract in Contract Scanner
  2. rebuild the wallet-risk preview with the exact calldata
  3. compare summary, recommended action, and transparency
  4. preserve the result before asking another person to sign

Troubleshooting​

"The action is not decoding cleanly"​

That can happen. Dralvia may still recover meaningful risk context through selector fallback or contract posture.

Do not assume "not fully decoded" means "safe."

"The preview is taking time"​

Some actions are simple. Others require more review context. A slower review does not automatically mean a failure; it usually means Dralvia is still building the transaction understanding and supporting evidence.

"The result says review, but I expected allow"​

That usually means one of these:

  • the spender is broad enough to deserve a second look
  • the contract posture is less transparent than expected
  • the action grants more rights than it first appears to grant

"The user only wants a quick answer"​

Even then, the safest workspace practice is:

  • read the summary
  • read the recommended action
  • confirm whether the action changes who can move funds or assets

That takes less time than undoing a bad approval.

Best practices for workspace teams​

  • Make this part of every approval workflow, not only emergency cases.
  • Preserve evidence before anybody signs.
  • Train operators to distinguish contract posture from action risk.
  • Treat unlimited approvals and operator grants as business decisions, not just technical details.

Known limits and rate limits​

  • Plan quotas apply: scan, render, report, repository, and API-key limits follow your plan tier. See Pricing & Plans for the enforced defaults.
  • API requests are rate limited per workspace. A 429 Too Many Requests response means a rate or quota window was exceeded; wait for the reset window, then retry once and reduce burst volume.
  • Free Evaluation has the tightest limits and is subject to anti-abuse controls. Paid plans raise the limits; Enterprise sets custom limits by contract.