Smart Contract External Security Audit Package

This package is the entry point for an external review of the production smart contract layer. It gathers the architecture, source map, tests, operational runbooks, known boundaries, and reviewer questions in one place.

Review ticket header:

Network:
Release/build:
Node commit/tag:
Wasmtime sidecar commit/tag:
Runtime profile:
Protocol version:
Audit firm/reviewer:
Review window:
Status: draft | in-review | findings-open | approved | blocked

Scope

In scope:

• deterministic WASM execution through the Rust Wasmtime sidecar;
• fuel, memory, timeout, argument, event, return, and host IO limits;
• host import allowlist and ABI behavior;
• contract manifest parsing, method auth, and bucket declarations;
• contract registry/catalog enforcement and release workflow;
• runtime activation, rollout policy, and validator attestations;
• contract-to-contract auth, depth, fuel sharing, ordering, and rollback;
• bucket access, encrypted-record metadata writes, and local ciphertext availability behavior;
• contract state isolation and state-root materialization;
• state migration proposals, jobs, batches, contract-defined migrations, and rollback procedures;
• events, call results, metrics, monitoring, and production alerts;
• replay, runtime compatibility vectors, snapshots, backup, and restore;
• operator procedures for activation, readiness, deactivation, failure spikes, sidecar rollout, and disaster recovery.

Out of scope unless separately contracted:

• upstream cryptographic primitive implementation audits;
• PostgreSQL, Wasmtime, Node.js, or operating system internals;
• cloud infrastructure, IAM, network perimeter, or Kubernetes/IaC hardening;
• application-specific contract business logic written by contract authors;
• operator secret custody beyond the NOOSChain documented expectations;
• Byzantine consensus safety beyond the current crash-fault-tolerant production assumptions.

System Overview

Contracts are WASM modules authored with the AssemblyScript SDK and executed by a Rust Wasmtime sidecar. The TypeScript node owns consensus execution, host intent validation, state-root materialization, snapshots, registry policy, and operator APIs. The sidecar only executes bounded WASM requests and reports deterministic execution outcomes through the sidecar protocol.

Production smart contracts are protected by several gates:

• governance-controlled runtime activation;
• protocol-pinned runtime profiles;
• sidecar capability handshake and preflight;
• contract package registry and release workflow;
• manifest-declared bucket and method authorization rules;
• node-local readiness checks;
• deterministic metering and host-call limits;
• replay and snapshot verification.

Contract writes are staged as deterministic intents. Storage writes, events, encrypted-record metadata writes, return values, and contract-to-contract effects are applied only through the chain execution path, then included in the state root when they are consensus state.

Primary Documents

• Smart Contracts V1 Foundation
• Smart Contract Author Guide
• Smart Contract Author Security Guide
• Smart Contract Template Library
• Smart Contract Publishing Tutorial
• Smart Contract Audit Readiness Bundle
• Smart Contract Package Signing Policy
• Smart Contract Layer Readiness
• Smart Contract Operations Runbooks
• Production Readiness
• Backup, Restore, And Recovery
• Snapshots
• Smart Contract Security Review Checklist
• Smart Contract Threat Model
• Smart Contract Runtime Reproducible Builds
• Contract Fuzz And Soak Testing

Source Map

Runtime and execution:

src/contracts/
external/noos-contract-executor-wasmtime/
src/chain/domain-handlers/contract-handlers.ts
src/chain/domain-handlers/state-values.ts
src/chain/state-root.ts

Contract API, ABI, and host surface:

src/api/routes/contract-routes.ts
src/api/schemas/
src/contracts/host-api.ts
src/contracts/wasm-host-session.ts
src/contracts/abi.ts
apps/noos-contract-sdk-as/

Registry, release workflow, activation, readiness, and operations:

src/contracts/registry*.ts
src/contracts/runtime-*.ts
src/contracts/readiness*.ts
src/contracts/release*.ts
src/cli/commands/contracts*.ts
src/cli/commands/production.ts

Contract-to-contract and migration:

src/contracts/contract-call*.ts
src/contracts/state-migration*.ts
src/chain/domain-handlers/contract-handlers.ts

Snapshots, replay, and disaster recovery:

src/snapshots/
src/replay/
src/sync/chain-verifier.ts
src/db/migrations/040_smart_contract_foundation.sql
src/db/migrations/041_contract_package_registry.sql
src/db/migrations/042_contract_call_results.sql
src/db/migrations/043_contract_event_query_indexes.sql
src/db/migrations/044_contract_call_metrics.sql
src/db/migrations/045_contract_state_migrations.sql
src/db/migrations/046_contract_state_migration_jobs.sql
src/db/migrations/047_contract_defined_state_migrations.sql
src/db/migrations/048_contract_deactivation.sql
src/db/migrations/049_contract_runtime_activation.sql
src/db/migrations/050_contract_runtime_rollout.sql
src/db/migrations/051_contract_release_workflow.sql
src/db/migrations/052_contract_event_index.sql

Test Matrix

Runtime, sidecar, metering, and compatibility:

npm run test:contract-wasmtime-sidecar
npm run test:contract-wasmtime-sidecar-lifecycle
npm run test:contract-runtime-security
npm run test:contract-runtime-compatibility
npm run test:contract-deterministic-metering
npm run test:contract-execution-limits
npm run test:contract-mainnet-launch-gate
npm run test:contract-runtime-provenance
npm run test:contract-fuzz

Host imports, ABI, returns, SDK:

npm run test:contract-wasm-host-imports
npm run test:contract-host-api
npm run test:contract-abi
npm run test:contract-return-values
npm run contracts:as-sdk:test

Registry, provenance, release workflow, activation, readiness:

npm run test:contract-registry
npm run test:contract-on-chain-provenance
npm run test:contract-release-workflow
npm run test:contract-runtime-activation
npm run test:contract-runtime-rollout-policy
npm run test:contract-runtime-preflight
npm run test:contract-readiness
npm run test:contract-readiness-operator-surface

Contract-to-contract, isolation, deactivation:

npm run test:contract-to-contract-calls
npm run test:contract-c2c-adversarial
npm run test:contract-deactivation
npm run test:contract-deactivation-dependencies
npm run test:contract-deactivation-policy

Migrations:

npm run test:contract-state-migration
npm run test:contract-state-migration-jobs
npm run test:contract-defined-state-migration

Events, observability, monitoring:

npm run test:contract-events
npm run test:contract-event-query-api
npm run test:contract-observability
npm run test:contract-production-alerts
npm run test:contract-production-monitoring-integration

Replay, snapshots, rehearsals:

npm run test:snapshots
npm run test:contract-backup-disaster-recovery
npm run test:contract-production-rollout-rehearsal
npm run test:contract-production-multinode-rehearsal
npm run test:contract-operator-launch-rehearsal
npm run soak:contracts:smoke
npm run verify:chain
npm run verify:replay

Auditor Questions

• Can a contract escape the Wasmtime sandbox or import an unreviewed host function?
• Can a contract consume unbounded CPU, memory, host calls, event bytes, return bytes, or nested call depth?
• Are all execution failures deterministic and replayable?
• Can host imports be abused to apply writes before a call is committed?
• Can one contract write another contract's state outside approved contract-to-contract or migration semantics?
• Can contract-to-contract calls bypass auth, deactivation, fuel, depth, or rollback rules?
• Can a contract access bucket metadata or write encrypted-record metadata without manifest declaration and bucket access policy?
• Can local ciphertext availability leak into consensus state?
• Can registry policy be bypassed by package substitution, stale manifests, or suspended packages?
• Can migrations overwrite or delete state unexpectedly?
• Can a restored snapshot produce a different state root, event ordering, or call-result history?
• Can operators safely detect and recover sidecar mismatch, stuck readiness, deactivation dependency issues, and failure spikes?

Known Boundaries

• Formal verification is not part of this package.
• Deterministic fuzz/property testing is present for core protocol-facing inputs. It is bounded by configured case counts and should be expanded with new generators when new contract surfaces are added.
• Each contract's business logic still requires a per-contract review.
• Operator key custody and secret-manager posture are external operational controls.
• The production consensus posture is crash-fault-tolerant, not Byzantine fault-tolerant.
• Upstream Wasmtime and platform supply-chain risk are inherited dependencies and should be covered by release engineering controls. Runtime provenance output records the expected profile and binary hash, but it does not replace release signing.

Audit Evidence Checklist

• [ ] Architecture and source map reviewed.
• [ ] Threat model reviewed.
• [ ] Prod-SC3.7 security checklist completed.
• [ ] Runtime profile and sidecar build identified.
• [ ] Mainnet launch gate report generated.
• [ ] Runtime provenance report generated and attached.
• [ ] Test matrix run on the release candidate.
• [ ] Backup drill completed on a production-like contract fixture.
• [ ] Open findings triaged with severity, owner, and target release.
• [ ] Launch blockers resolved or activation blocked.