Contract Creation Transactions and Deployed Addresses
Distinguish contract creation input, receipt contract addresses and factory deployments, so a deployment inventory does not miss internal creations.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A contract deployment is not always visible as a top-level transaction with an empty destination. Factory contracts can create other contracts during execution. Deployment inventories need a declared method for detecting both forms.
Top-level and factory creation differ
A top-level creation transaction supplies initialisation code and has no ordinary recipient address. Its successful receipt can expose a contractAddress. A transaction sent to a factory has the factory as recipient; created child contracts require additional execution evidence or reliable factory events. A contract address alone does not identify its deployer, bytecode version or verification status.
Worked example: a factory creates two children
Transaction T calls factory F and successfully creates contracts C1 and C2. The top-level receipt is not a list of both deployed addresses. A tracker limited to receipt contractAddress can miss them. Capture the creation operations or a documented factory event interpretation, then confirm that code exists at the relevant block.
State the inventory boundary
Store the creation transaction, creator context, created address and block identity. Distinguish initialisation code from resulting runtime code. Test failed creation, multiple children and repeated factory calls. If internal creation evidence is unavailable, label the inventory as top-level deployments instead of presenting it as every contract created on the network.
A practical acceptance test
Test one top-level deployment and one factory transaction that creates two child contracts. Keep the detection methods visible in the result. If the implementation only supports top-level receipts, its inventory must expose that boundary and must not fabricate child addresses. A failed creation fixture should not appear as an accepted deployed contract.
Questions about the topic
Frequently asked questions
Does every deployment have an empty transaction recipient?
No. A factory can create contracts inside a transaction addressed to the factory.
Does deployed code imply source verification?
No. Source verification is a separate reproducibility claim.
Standards & technical documentation
