Start with a review package a vendor can estimate
This checklist is for product owners and engineering leads commissioning an Aptos smart contract audit. Its purpose is to turn an open-ended request into a comparable scope, a retest agreement and a release evidence package.
Prepare the repository and exact commit, target network, package and module inventory, Move.toml, compiler and CLI versions, dependency revisions, deployment addresses if any, existing tests and the intended launch date. State which framework and language features the project uses rather than assuming every Aptos package has the same review requirements.
List the business rules the software must preserve: who may create or transfer assets, change fees, upgrade code, pause operations or change an account's entitlement. Include the expected behavior when a transaction fails or an external service is unavailable.
Ask for an Aptos-specific coverage matrix
Request a written map from each module and business rule to the proposed review method. It should identify signer checks, privileged capabilities, asset accounting, dependencies, deployment controls and any off-chain component included in the quote.
Move integer arithmetic uses checked operations that abort on conditions such as overflow, underflow or division by zero; the Aptos Move Book documents these rules. The relevant review questions include whether user actions can trigger unexpected aborts, whether rounding matches the business rules and whether accounting remains consistent across supported operations.
Source for arithmetic behavior: The Move on Aptos Book, Primitive Types — https://aptos-labs.github.io/move-book/primitive-types.html . Ask the reviewer to use the project's pinned language and framework versions when applying these checks.
Include deployment and upgrade authority in the scope
Record the publication pattern, package address, current upgrade policy, authorized operators and the process for approving a change. Review the actual permissions and on-chain configuration rather than relying on a diagram or a label such as immutable.
The current Aptos CLI documentation distinguishes account publishing from code-object publishing. These patterns have different upgrade-authority arrangements, so the review brief should state which one the project uses. The documentation also describes verify-package for comparing local source builds with deployed bytecode; record the applicable checks and their output in the release evidence.
Source for publication patterns and package verification: The Move on Aptos Book, Publish — https://aptos-labs.github.io/move-book/cli-deploy.html . Confirm command support and options against the CLI version used for the release.
Decide which application integrations are included
Inventory the asset standards, event mechanisms and external modules used by the actual project. Ask how the review handles those integrations and the team's assumptions about third-party upgrades. Do not substitute a generic token or event checklist for that inventory.
Mark the frontend, wallet transaction construction, indexer, APIs and administration interface as included or excluded. For an included user journey, require a test that follows the signed transaction through the resulting on-chain state and the application's displayed business state.
Compare quotes on scope, staffing and retest
Send the same review package to each shortlisted vendor. Compare the modules and integrations covered, assigned reviewer roles, manual review time, automated methods, expected report format, exclusions and communication schedule.
Ask which tools are usable on the supplied code and which checks need custom tests or specifications. Formal verification, fuzzing, frontend review and deployment assistance should be explicit work items when required, rather than assumptions attached to the word audit.
The quote should separate the initial review from remediation support, retest and release assistance. Changes to the target commit, new features and unavailable dependencies need a documented effect on schedule and price.
Define findings and retest acceptance before work starts
Agree severity definitions, disclosure handling and the information expected for each finding: affected code, prerequisites, impact, a reproduction or test where applicable, and remediation guidance.
After a fix, identify the remediation commit and record each original finding as resolved, partially resolved, accepted or still open. Ask what regression checks are included and how newly added code is handled. Retest acceptance should not be interpreted as a guarantee that no other issues exist.
Use a separate release evidence checklist
Before launch, collect the reviewed and remediated commits, reproducible build instructions, relevant test results, deployment transactions, final addresses, authority configuration and unresolved findings. Confirm which checks were performed on a local environment, testnet or the actual production deployment.
Assign owners for publishing, operational monitoring, incident response and approving the release. A report about one commit does not establish that another commit or deployment has been reviewed.
Request a scoped DAPPWEB proposal
Share the review package, intended release date and the work you need covered. DAPPWEB will assess the project-specific requirements before proposing coverage, reviewer availability, delivery milestones and retest terms.
If the engagement also includes DApp development, agree who implements fixes, who reviews them and what independent assurance the project requires. Development, security review and ongoing operations should each have clear deliverables and acceptance owners.
Submit the brief through https://dappweb.ai/contact/#project-brief or email admin@dappweb.ai. Do not send private keys, seed phrases or API secrets. This page describes an engagement checklist, not a record of a completed client audit.