Understand token state and confirmation on a local chain

A local chain can be recreated and reset repeatedly, making it useful for learning contracts and transactions. This exercise issues synthetic completion receipts without value promises, using temporary development accounts and no real assets or public-network credentials.

A token is identified by its contract address and token ID together. ID 1 in two contracts refers to different tokens. Understand identity, authorization, and confirmation before adding pictures, because an image URL does not explain ownership changes.

Record the local network environment

Development networks are Ethereum client environments designed for testing. They commonly seed accounts and balances and produce blocks quickly, depending on configuration. These behaviors are not public-network guarantees. The official network guide lists Hardhat Network; follow its current setup instructions.

Record chain ID, RPC endpoint, compiler version, and deployed address. A wallet or script must use the deployment chain. Check that the chosen address has contract code. Identical address text on different chains does not establish identical contracts.

Resetting invalidates previous state and potentially deployment mappings. Associate records with the current environment, redeploy after resets, and update client configuration. Old UI must not present receipts from a discarded chain as current state.

Understand the ERC-721 contract

ERC-721 defines ownership, balance, approvals, and transfers, with required ERC-165 support. Metadata and enumeration are optional extensions. Basic compliance does not promise an enumeration interface or permanent tokenURI content.

Owners and authorized parties can transfer tokens. Single-token approvals and operator approvals have different scopes. Test revocation and transfer effects separately. Safe transfers to contract addresses involve a receiver interface, so every address cannot be treated as an externally owned account.

On-chain ownership does not automatically confer image copyright or real-world rights. External metadata has availability and mutability independent of chain state. Distinguish chain-query errors from missing resource content.

Establish a compilable exercise project

Initialize a project using the selected framework's current official workflow, retaining configuration and lockfiles. Install OpenZeppelin Contracts 5.x and select a compatible Solidity compiler. The checked documentation uses ^0.8.24; do not mix old constructor patterns with a newer package.

This independently designed fragment uses the documented ERC721 base and minting mechanism, restricted to its deployer. It adds no per-token URI storage extension or public distribution feature. The base still exposes name, symbol, and metadata interfaces; without a configured base URI, this fragment provides no usable external metadata address. It has not been compiled with a Solidity toolchain here; compile and test it before local deployment.

// Teaching fragment: compile and test before use.
pragma solidity ^0.8.24;
import {ERC721} from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
contract LabReceipt is ERC721 {
    address public immutable minter;
    uint256 private nextId;
    constructor() ERC721("LabReceipt", "LAB") {
        minter = msg.sender;
    }
    function mint(address recipient) external returns (uint256) {
        require(msg.sender == minter, "minter only");
        uint256 id = nextId++;
        _mint(recipient, id);
        return id;
    }
}

Write tests invoking mint from the deployer and another temporary account. The former succeeds and the latter reverts. Two successful calls produce distinct IDs; query ownerOf to confirm ownership. _mint does not check receiver callbacks. Limit this exercise to external test accounts and separately design safe minting when contract recipients are required.

Start the local node, explicitly select its RPC as the deployment target, and retain chain and address records. The initial client shows chain identity, contract address, owner queries, and transaction status. A returned hash must not produce a completed-mint message.

Separate submission and confirmation

States include awaiting signature, submitted, waiting for receipt, succeeded, and failed. Rejected signing is different from failed execution. A timeout does not prove a transaction was unprocessed. Retain the hash and chain, inspect the receipt status and contract state, and avoid blindly resubmitting.

Immediate local blocks can hide waiting behavior. Add delayed and failed test adapters so the interface cannot claim final ownership before confirmation. Public chains also need a confirmation and reorganization policy that this local exercise does not verify.

Queries and transactions differ. ownerOf reads state; mint and transfer change it through transactions. Correlate IDs with events or final queries rather than treating diagnostic logs as confirmation.

Check a simplified ownership ledger

The Python example rejects duplicate mint IDs and non-owner transfers. It contains no EVM, gas, signatures, receipts, approvals, events, or reorganization handling and is not an ERC-721 implementation.

owners = {}
def mint(token_id, owner):
    if token_id in owners:
        return False
    owners[token_id] = owner
    return True
def transfer(token_id, actor, recipient):
    if token_id not in owners or owners[token_id] != actor:
        return False
    owners[token_id] = recipient
    return True
assert mint(1, "A") and not mint(1, "B")
assert not transfer(1, "B", "C")
assert not transfer(2, None, "C")
assert transfer(1, "A", "C")
print(owners)

The output is {1: 'C'}. Duplicate minting and B's transfer fail; A transfers to C. Real ERC-721 also permits authorized operators, so this owner's-only model is narrower than the standard.

Uniqueness belongs in contract state rather than button disabling. Test that reverted operations leave counters and ownership consistent. Returning False in Python does not model Solidity revert or gas semantics.

Plan metadata and recovery

Add extensions only after defining the metadata format and version policy. Synthetic course IDs and names need no borrowed game assets. A missing image must not hide confirmed token identity.

When receipts are delayed, inspect chain connectivity, account, and hash before deciding recovery. Restart or reset requires updated environment records. Do not put even temporary private keys into published lessons or repositories; use development tooling's temporary mechanisms.

Tests should query final ownership and approvals instead of only checking that submission did not throw. Event indexes need chain, contract, and block identity and must be reset with the environment. Distinguish disconnected, nonexistent-token, and incorrect-chain states.

Lock the Contracts version and retain compiler and optimization settings. Recompile after contract edits instead of using an old ABI with new code. Keep ABI-to-deployment correspondence in client records.

Exercise: verify transactions and permissions

Run contract tests for unauthorized minting, sequential unique IDs, unauthorized transfers, approvals, and revocation. Include invalid-token and zero-address failures and verify that existing ownership remains unchanged.

Simulate signature refusal, disconnection after submission, failed receipts, and reset in the client. Record actual compiler and receipt results. Only the Python ledger is executed here; Solidity compilation is unverified. Passing local checks supports this teaching exercise, while public deployment requires separate review.