Path Manifest Standard (ARC-26)

ARC-26 defines a Path Manifest standard for Arweave, enabling builders to organize multiple data transactions into a single, coherent directory structure. This is the foundational standard for deploying websites, complex NFT collections, or any application where a root transaction ID must resolve to a hierarchy of files with specific paths (e.g., index.html, images/logo.png). Without a manifest, each file exists as an isolated transaction, making it impossible to link a complete application or dataset to one root identifier. The standard specifies a JSON-based manifest format that maps logical file paths to Arweave transaction IDs, along with resolution logic for gateways to serve content correctly.

The operational impact centers on gateway compatibility and data integrity. Gateways like arweave.net implement the ARC-26 resolution algorithm to translate a request for https://arweave.net/<txid>/path/to/file into the correct underlying data transaction. The manifest itself is a transaction containing a JSON object with a manifest key, specifying the arweave/paths version and an index object for path-to-ID mapping, plus an optional paths map for human-readable fallback. A critical detail for builders is that the manifest transaction's content type must be application/x.arweave-manifest+json for gateways to interpret it correctly. Failure to adhere to this standard results in broken deployments where gateways cannot resolve sub-paths, returning 404 errors instead of the intended content.

For operators and integration engineers, ARC-26 introduces specific trust and permanence assumptions. The manifest itself is a permanent, immutable transaction on Arweave, but the data it points to is only as permanent as the individual file transactions. If a referenced transaction is not mined or is pruned, the path will break. This creates a dependency chain that deployment tools and CI/CD pipelines must verify. Furthermore, the standard interacts with bundling services (ANS-104) that batch-upload files; the manifest must correctly reference the bundled transaction IDs, not intermediate IDs. Teams building on Arweave should audit their deployment scripts to ensure manifest generation is idempotent and that all referenced transactions are confirmed before the manifest is considered live. Chainscore Labs can review manifest construction logic, gateway resolution behavior, and integration pipelines to prevent silent path-resolution failures in production applications.

The ARC-26 Path Manifest Standard provides the canonical method for representing hierarchical file structures on Arweave's flat storage model. A manifest is a JSON document containing a paths object where keys are file paths and values are transaction IDs. This construction allows a single root transaction ID to resolve an entire directory tree, which is the foundational mechanism for deploying websites, hosting NFT collections, and serving any multi-file application on the permaweb. The standard specifies that paths must be relative, use forward slashes, and that the root of the site is represented by an entry for index.html or a similar key mapped to the entry-point transaction.

Resolution logic is deterministic and client-driven. A gateway or resolver receiving a request for https://arweave.net/<manifest-txid>/path/to/file must parse the manifest JSON, look up the key path/to/file in the paths map, and return the data stored at the corresponding transaction ID. The standard defines conflict resolution for overlapping paths and mandates that implementations treat paths as case-sensitive. Critically, the manifest itself is an immutable Arweave transaction; updating a website requires deploying a new manifest with a new root transaction ID, which has direct implications for DNS linking strategies and the Arweave Name System (ArNS).

Operationally, the integrity of a deployed application depends entirely on the completeness and correctness of the manifest. A missing path key or an incorrect transaction ID will result in a broken link or a 404 error, as there is no server-side logic to fall back on. This shifts the burden of build-time verification onto developers and CI/CD pipelines. For builders, the standard requires tooling that can recursively hash a local directory, upload each file as an individual transaction, and construct the final manifest. Any mismatch between the local file tree and the generated manifest constitutes a deployment failure, making pre-upload validation a critical step in the release process.

For integrators and risk teams, the manifest resolution model introduces a trust assumption: the gateway performing the resolution must faithfully parse the manifest and serve the correct data. While the manifest and its constituent files are content-addressed and verifiable, a malicious or compromised gateway could serve a manipulated manifest or refuse to resolve paths. Chainscore Labs can assist teams in auditing their deployment pipelines, verifying manifest integrity on-chain, and designing monitoring systems that independently resolve and hash application assets to detect gateway misbehavior or data availability issues.