Smart Contract Deployment Manifest

Purpose and scope

Use this smart contract deployment manifest to connect an accepted build artifact with one deployed instance and the implementation it uses. Complete a new record for each deployment under review. Record the observation block and evidence references so a later reviewer can distinguish the inspected state from the latest state.

The ten fields below preserve the minimum record. Keep detailed compiler inputs, initialization checks and chain observations in the linked evidence. A completed form is not a security audit, release authorization or proof of correct contract behavior.

Blank working record

1. chain_id: ________________
2. deployment_tx_ref: ________________
3. contract_address: ________________
4. artifact_revision: ________________
5. compiler_settings_ref: ________________
6. runtime_comparison_method: ________________
7. proxy_type_or_not_applicable: ________________
8. implementation_ref: ________________
9. verification_result: ________________
10. owner: ________________

Copy the record or use the blank downloads. Replace missing evidence with NOT_VERIFIED and an owner; reserve NOT_APPLICABLE for an inapplicable check with a stated reason. Never paste private keys, deployment credentials or secret RPC URLs into the manifest.

Fictional D-17: keep the implementation question open

D-17 is an invented handover scenario. Its supplied artifact revision agrees with the expected revision, but the implementation reference has not been confirmed. No chain was queried, contract deployed or runtime bytecode compared for this example. The unresolved reference keeps verification open.

D-17 example record

1. chain_id: 31337 (fictional local fixture, not a public-chain observation)
2. deployment_tx_ref: D-17/deployment-receipt: NOT_COLLECTED
3. contract_address: D-17/proxy-address: placeholder, no real address
4. artifact_revision: build-D17-r4: MATCH_IN_SCENARIO; no compilation executed
5. compiler_settings_ref: D-17/build-input-r4: fictional settings reference
6. runtime_comparison_method: NOT_RUN: compare deployed runtime with build output at a pinned block; no node queried
7. proxy_type_or_not_applicable: ERC1967 implementation-slot proxy: assumed for this fictional scenario, not inspected
8. implementation_ref: NOT_VERIFIED: implementation reference missing; no slot/code evidence collected
9. verification_result: NOT_VERIFIED: artifact revision agrees in scenario; runtime, implementation and initialization remain open
10. owner: Deployment verification owner (fictional role): obtain implementation evidence before acceptance

What each decision field means

chain_id

Network identity and the reference used to confirm it. Include the observation block number/hash in linked evidence; a chain ID alone does not identify a particular fork.

deployment_tx_ref

Deployment transaction and receipt evidence, including the observation block/hash and the project confirmation policy. For factory deployments, link the trace or event that identifies the created contract.

contract_address

Address of the deployed instance being reviewed. Keep proxy and implementation addresses separate. Do not infer the intended chain from the address alone.

artifact_revision

Immutable build revision and accepted artifact reference or hash. A mutable branch name alone cannot reproduce the reviewed build.

compiler_settings_ref

Pinned compiler version, complete settings and build input/output references. Include optimizer, EVM target, libraries and constructor inputs where applicable; omit credentials.

runtime_comparison_method

How expected deployed runtime was compared with observed code at the specified block. Account explicitly for linked libraries, immutables and metadata; creation bytecode is a different object.

proxy_type_or_not_applicable

Identified proxy pattern and evidence, or NOT_APPLICABLE with a reason for a direct deployment. An empty implementation slot alone does not prove the absence of all proxy patterns.

implementation_ref

Implementation address/code evidence and observation block/hash for the applicable pattern. For a beacon, retain the beacon and its resolved implementation. For a direct deployment, use NOT_APPLICABLE with a reason.

verification_result

PASS_SCOPED, FAIL or NOT_VERIFIED, followed by the actual completed checks and unresolved questions. Acceptance scope must state whether initializer execution and relevant postconditions were checked.

owner

Accountable role for the evidence and open questions. Name the reviewer in the restricted project record when appropriate.

Read the proxy evidence for the actual pattern

ERC-1967 defines distinguished proxy storage slots, including implementation and beacon slots. It does not make a successful deployment receipt evidence that the intended implementation is active. Read and interpret the applicable state at the recorded observation point. Retain the evidence for both the proxy and the implementation code.

For a beacon arrangement, resolve the implementation through the applicable beacon mechanism. Do not apply a single implementation-slot recipe to every proxy or clone. The deployed version and pattern determine the check. If the mechanism is unknown, leave implementation_ref unresolved and assign the investigation.

Initialization needs separate evidence. Record the initializer call or deployment initialization data and inspect the required postconditions in the linked acceptance record. Matching code does not establish the intended initialized state. This form does not prescribe upgrade approval, signing authority or a rollback procedure.

Complete the review against retained observations

1. Confirm the network and observation block/hash before collecting receipt and code evidence.
2. Connect the created instance to its deployment evidence; distinguish a direct creation from a factory-created instance.
3. Compare the accepted artifact with the observed runtime using the recorded method and resolve the applicable implementation reference.
4. Record the checked initialization conditions, remaining questions and accountable owner before assigning a scoped result.

These are proposed review steps, not executed on-chain tests. A PASS_SCOPED label must describe the checks actually completed; it cannot certify every behavior or future upgrade. If state changes after the recorded block, retain the old observation and create a new review rather than silently updating its conclusion.

Use the manifest in the delivery brief

When a handover supplies an artifact but leaves the deployed implementation unexplained, Pharos Production's smart contract development services provide a relevant implementation discussion. Attach this manifest and identify which deployment evidence the team must supply. The published service scope is not evidence that D-17 or your deployment passed verification.

Use the Blockchain Integration Readiness Worksheet for surrounding integration dependencies. Keep this manifest focused on the artifact-to-instance connection.

Download the fictional D-17 example CSV.

Sources and document scope

• OpenZeppelin: Preparing for mainnet: source verification and the limits of audits.
• ERC-1967: Proxy Storage Slots: implementation and beacon references.
• OpenZeppelin proxy documentation: pattern-specific implementation resolution.

Sources checked November 3, 2026. Version 1.0. D-17 is fictional and reports no on-chain inspection or client result. Resource owner: Dmytro Nasyrov, Founder and CTO.

‍