What this prompt does
This prompt scaffolds a Solidity contract from battle-tested OpenZeppelin patterns instead of hand-rolling security primitives. You define [contract_purpose], [evm_chain], the [asset_type] it manages, and the [user_roles], and it generates a contract using [solidity_version] with [oz_contracts] inherited in the correct order, core functions for [core_functions], proper access control, input validation, and NatSpec docs.
The structure works because it forces the model through the parts engineers skip under time pressure. It defines storage with optimal packing via [storage_optimization], uses [mapping_structures] and an [enumeration_pattern] where iteration is needed, emits [event_list] events with [indexed_params] for off-chain filtering, and applies gas optimizations like custom errors and unchecked blocks for [safe_arithmetic]. Security measures — reentrancy guards on [reentrant_functions], pausability, and rate limiting on [rate_limited_functions] — are specified rather than assumed, and it ends with a test plan outline. Targeting a specific [evm_chain] also nudges decisions like whether L2 gas economics change the optimization priorities.
When to use it
- You are scaffolding a new contract and want OpenZeppelin patterns rather than custom security code
- You need access control mapped to real
[user_roles]from the start - You want events with
[indexed_params]planned for an off-chain indexer - You are packing storage and want
[storage_optimization]reasoned about explicitly - You need reentrancy guards correctly placed on
[reentrant_functions] - You want rate limiting on sensitive setters like
[rate_limited_functions] - You want a test plan outline to drive your Foundry or Hardhat suite
Example output
Expect a complete Solidity file: pragma at [solidity_version], imports and inheritance from [oz_contracts] in the right order, a constructor or initializer for the [upgrade_pattern], the [core_functions] with modifiers and custom errors, storage variables packed per [storage_optimization], the [mapping_structures], event declarations from [event_list], and NatSpec throughout. The state-management section uses an [enumeration_pattern] wherever a collection needs to be iterated, and the contract closes with a structured test plan covering deployment, access control, happy paths, edge cases, and gas benchmarks so you have a clear path to coverage.
Pro tips
- Keep
[contract_purpose]and[core_functions]concrete — a named staking vault with deposit/withdraw/claim gets far better code than "a token contract" - Always review the generated storage layout yourself;
[storage_optimization]packing like two uint128s in one slot is easy to get subtly wrong - Confirm reentrancy guards land on every function in
[reentrant_functions], especially anything moving value out - Run the suggested test plan before any testnet deploy — treat the contract as a starting point, not finished code
- Be explicit about
[upgrade_pattern]; UUPS and transparent proxies need different initializer handling - Check that
[indexed_params]cover the fields your off-chain indexer actually filters on, since you cannot add indexing after deploy - Verify
uncheckedblocks for[safe_arithmetic]are genuinely bounded, since this is where gas tricks turn into overflow bugs
