Instruction file imported from maykel022/eth (.github/instructions/lottery-dapp.instructions.md). Copyright stays with the author.

LotteryETH Security And Web3 Guidelines

• Scope:

  • Apply this guidance to Solidity contracts, deployment/ops scripts, and frontend web3 integration work.
  • Do not force these rules for unrelated content-only changes (for example docs or static marketing copy).

• Keep smart contract changes security-first:

  • Preserve access control checks on admin-only operations.
  • Follow checks-effects-interactions for state changes plus external transfers.
  • Use Chainlink VRF flow for randomness and do not introduce block-derived randomness (for example block timestamp, blockhash, or msg.sender entropy).
  • If adding payable/external flows that transfer value, ensure reentrancy risk is assessed and guarded.

• Keep frontend web3 interactions separated by intent:

  • Use provider-based contract instances for read-only calls.
  • Use signer-based contract instances only for state-changing transactions.
  • Isolate failures per contract/data source so one read failure does not collapse an entire admin/dashboard load.

• Keep protocol constants and addresses centralized:

  • Prefer a single config source for network IDs, contract addresses, and ABI imports used by multiple pages/components.

• Validate changes on a best-effort basis using touched files:

  • For contract, script, or ABI-related edits: run npm run compile and npm test at workspace root when those areas are changed.
  • For frontend TypeScript edits: run npm run build in frontend/, and run npm run lint when frontend logic/components are changed.

• When requirements are unclear, ask one focused clarifying question before implementing risky logic changes affecting prize distribution, draw timing, or admin controls.