Skip to content
Services
All servicesFind the right assessmentWeb & APIApplications, roles and tenant boundariesCloudResources and service relationshipsWeb3Contracts, wallets and connected systemsOur approachAI research and human validationDeliverablesEvidence, reporting and retestingWork with usScope an engagement
How it works Scope & safety Findings Review desk Blog Write to us
HomeServicesWeb3 security
Web3 security

Follow the transaction.
Question the assumptions.

Security testing for agreed smart contracts, wallet interactions and offchain components. The environment, contract versions and permitted transaction behavior are defined together.

Discuss your scope ↗See what you receive →
INSIDE THE ASSESSMENT
Intent, authority and execution.Application intent passes through a wallet approval before execution in the explicitly agreed blockchain environment.ApplicationRequested actionWalletUser-approved authorityTransactionAgreed test environment
Intent, authority and execution.
IntentApprovalExecution
01 / Where this helps

Follow the logic.
Keep the assumptions visible.

Illustrative scenarios. Chain, language, wallet and component support are confirmed before an engagement.

Version AChangeVersion BPIN THE VERSION
CONTRACT CHANGES

New logic.
Existing responsibilities.

You are changing a contract, privileged operation or component relationship.

The question
Does the scoped change preserve the intended permissions and invariants?
Assessment focus
Agreed source versions, relevant contract logic and explicit system assumptions.
Useful output
Findings tied to the assessed version, preconditions and observed consequences.
IntentWalletActionAUTHORITY SHOULD MATCH INTENT
WALLET INTERACTIONS

A prompt is part
of the security boundary.

Your application requests wallet authority as part of a user workflow.

The question
Does the requested authority reflect the action the interface presents to the user?
Assessment focus
Selected wallet interactions and the relationship between intent, prompts and requested actions.
Useful output
An explanation of the relevant user context, authority and limits of the observation.
InterfaceServiceContractONCHAIN MEETS OFFCHAIN
CONNECTED COMPONENTS

The contract is not
the entire system.

Your flow depends on interfaces, services and blockchain state working together.

The question
Which cross-component assumptions are essential to the selected workflow?
Assessment focus
Agreed interfaces, dependencies and trust transitions across the application.
Useful output
Evidence tied to the affected components, rather than a claim of ecosystem-wide coverage.
02 / Testing environments

A simulation is useful.
It is not a live observation.

Web3 environment and evidence guide
EnvironmentWhat it can supportWhat remains explicit
Local simulationWhat it can supportControlled evaluation of selected logic and states.What remains explicitConstructed conditions and assumptions; no claim that every live condition was reproduced.
Fork-based testingWhat it can supportEvaluation against selected historical or current state.What remains explicitBlock context, state changes, preserved assumptions and differences from the live environment.
TestnetWhat it can supportApproved interactions using test assets and test deployments.What remains explicitDifferences from the deployed production contracts, infrastructure and economics.
Live environmentWhat it can supportOnly the explicitly authorized checks and transactions.What remains explicitAddresses, permitted actions, balance limits and stop conditions; no blanket transaction authority.
03 / Assigned wallets, defined limits

A test wallet.
Not an open-ended mandate.

Our AI agent model can use assigned wallets with small test balances for approved scenarios. The environment and permitted actions are agreed in advance.

  1. 01

    Define the context

    Specify versions, addresses, environment and the behavior to be assessed.

    SCOPED COMPONENTS
  2. 02

    Set transaction limits

    Agree on wallets, permitted actions and test-balance limits.

    EXPLICIT BOUNDARIES
  3. 03

    Review the evidence

    Our team separates measured effects from simulations and unsupported projections.

    HUMAN TECHNICAL JUDGMENT

A transaction capability is not permission to move customer funds or interact with unrelated third-party assets.

04 / What you receive

A result you can interpret.
Not just a severity label.

The report should make the assessment environment and demonstrated mechanism clear enough for your team to understand what the evidence does—and does not—establish.

Explore assessment deliverables ↗
ILLUSTRATIVE STRUCTURE · NOT A CUSTOMER REPORT
ENGAGEMENT OUTPUT

Context. Evidence.
A useful next step.

01

Version & environment

Repositories, relevant addresses, versions and state context.

02

Mechanism & prerequisites

The behavior and conditions necessary for the observation.

03

Observed impact

Evidence distinguished from simulated conditions and untested consequences.

04

Remediation & retest

Guidance for the affected logic or interaction, with agreed follow-up.

05 / Before we start

Practical questions.
Clear expectations.

Bring your technical constraints and buyer requirements to the scoping conversation.

Do you test on mainnet?

Live-environment testing is not assumed. Any live checks require explicit authorization, defined addresses and actions, and agreed transaction limits.

Do you need funds for every assessment?

No. Some agreed work can be evaluated using local, fork or testnet environments. Requirements depend on the specific assessment; simulated conditions are labeled.

Is this a complete smart-contract audit?

Do not assume exhaustive coverage. The work, component versions, exclusions and deliverables are defined in a written scope. Bring any audit-specific requirements to the initial discussion.

Can you assess a wallet integration without reviewing every contract?

A focused interaction assessment can be discussed. Its results apply to the agreed workflow and components, not to every dependency.

How are known issues handled?

Share known issues and prior assessments during scoping. Findings should be interpreted in their version and remediation context, without presenting previously known behavior as new evidence.

LET’S DEFINE YOUR ENGAGEMENT

Bring us your scope.
We’ll discuss the next step.

Share your system, priorities and target date.
Please do not include credentials or sensitive findings.

Book a call ↗Email hello@zaaf.ai