Manifests: General Info

A contract manifest is the consensus-facing description of a NOOSChain smart contract. It tells validators what runtime the contract uses, which WASM exports may be called, which other contracts it may call, and which migration entrypoints are available.

The manifest is not just documentation. It is hashed, stored with the contract instance, checked during calls, used during readiness evaluation, included in package provenance, and matched by registry approval.

Manifest Map

A manifest has several layers:

• contract identity fields: name, version, and runtime;
• callable methods under exports.methods;
• optional initialization under exports.init;
• outbound contract-to-contract declarations under calls;
• contract-defined migration declarations under migrations;
• canonical hashing material used by package descriptors, provenance, and the registry.

Use the focused pages for the deeper authoring details:

• Methods covers exports.init, exports.methods, entrypoint, invoke.allow, buckets, maxFuel, and abi.
• Calls covers the calls array and contract-to-contract dependencies.
• Migrations covers the migrations array and contract-defined migration entrypoints.

Minimal Shape

The current manifest schema has schemaVersion: 1 and runtime wasm-assemblyscript-v1.

{
  "schemaVersion": 1,
  "name": "report-store",
  "version": "0.1.0",
  "runtime": "wasm-assemblyscript-v1",
  "exports": {
    "methods": {
      "saveReport": {
        "entrypoint": "saveReport",
        "invoke": {
          "allow": [
            { "principalType": "organization", "principalId": "org-noos" }
          ]
        },
        "buckets": []
      }
    }
  },
  "calls": [],
  "migrations": []
}

This example has one public method and no declared nested calls or migrations. Production contracts usually add ABI metadata, bucket requirements, method fuel ceilings, C2C edges, or migration declarations.

Top-Level Fields

Field	Required	Meaning
schemaVersion	Yes	Manifest schema version. The current value is 1.
name	Yes	Human-readable contract/package name. It is not the deployed contractId.
version	Yes	Contract author's version string, usually semantic versioning.
runtime	Yes	Runtime profile. The current value is wasm-assemblyscript-v1.
exports	Yes	WASM exports that NOOSChain is allowed to call.
calls	No, defaults to []	Outbound contract-to-contract dependencies.
migrations	No, defaults to []	Contract-defined migration entrypoints.

schemaVersion

schemaVersion identifies the manifest schema. It is not the contract version and not the chain protocol version. It changes only when the manifest format itself changes. Historical schema versions must remain replayable.

name

name is the human-readable contract name. It usually matches the package name, for example report-store. It is not the same as the deployed contract id. Multiple contract instances can use packages with the same name.

version

version is the contract author's version string. Use it to distinguish contract generations for package review, release workflow, and migration planning. Change it when methods, ABI, authorization, bucket requirements, outbound calls, migrations, or behavior change.

runtime

runtime declares the contract runtime profile. Current smart contracts use:

{ "runtime": "wasm-assemblyscript-v1" }

The manifest runtime must match the package descriptor and protocol-pinned runtime requirements. Do not use this field to select a local sidecar variant; runtime behavior is consensus-significant.

exports

exports groups callable WASM exports. It contains the optional init export and the required method map. The chain does not call arbitrary WASM exports just because they exist in the module.

calls

calls is the caller-side declaration for nested contract calls. If contract A wants to call contract B, contract A's manifest must name contract B and the target methods. See Calls.

migrations

migrations declares contract-defined migration entrypoints. Migration jobs use these declarations when the target contract's WASM code must transform state. See Migrations.

Manifest Hashing

NOOSChain hashes the canonical JSON representation of the parsed manifest. The hash is stored as manifestHash, included in package descriptors, checked by package provenance, and matched by registry entries.

Do not rely on whitespace or object key order. Hash the canonical parsed manifest and keep the exact manifest file with the package forever so old blocks remain replayable.

What Requires A New Manifest Version

Publish a new package and update the manifest version when you:

• add, remove, or rename a method;
• change a WASM entrypoint;
• change method authorization;
• add, remove, or change bucket requirements;
• change maxFuel;
• change ABI input, output, or event schemas;
• add, remove, or change outbound C2C dependencies;
• add, remove, or change migration declarations;
• change runtime;
• make any behavior change that callers or reviewers need to distinguish.

Do not overwrite old manifest files in package artifacts. Historical blocks must remain replayable against the old manifest hash.

Author Checklist

Before packaging:

• [ ] schemaVersion is 1.
• [ ] name and version match the package descriptor.
• [ ] runtime is wasm-assemblyscript-v1.
• [ ] Every public method is documented in Methods.
• [ ] Every C2C dependency is documented in Calls.
• [ ] Every contract-defined migration is documented in Migrations.
• [ ] The canonical manifest hash has been regenerated.
• [ ] The package descriptor uses the new manifestHash.
• [ ] Old manifest and package artifacts remain archived for replay.

Next Steps

• Methods
• Calls
• Migrations
• Authorization
• Package Provenance