Build a complete in-wallet token-lock voting system for a newly issued ERC-20 whose contract we control. Deliver Solidity contracts, Foundry tests, deployment scripts, a usable web frontend, and documentation in a GitHub repository. This is a source-code development request; do not launch a tradable platform token or deploy to a production network.

Core requirement: users vote without transferring, staking, wrapping, burning, or depositing their tokens into another address. balanceOf(voter) must still include their locked tokens. Only the quantity voluntarily committed to a vote is locked; the rest remains transferable. Implement enforcement inside the custom ERC-20 itself. Do not claim compatibility with arbitrary existing immutable ERC-20s or substitute snapshots, allowance, wallet delegation, UI disabling, or transfer monitoring for actual transfer prevention.

Implement a configurable-name/symbol/fixed-supply demo token and its bound voting contract. One voting instance governs one token on one chain; the same implementation can be deployed again for another compatible token and EVM chain. Token and voting bindings must be fixed after safe one-time initialization; the delivered MVP must have no administrator or upgrade bypass that can move locked balances, shorten existing locks, change recorded votes, seize tokens, or replace enforcement. Only an explicit vote transaction from the token holder may create that holder's lock. An administrator cannot arbitrarily freeze holders.

Voting: allow a configured proposal creator to create proposals with a title, description, future start, and fixed end time. Use For, Against, and Abstain. One vote per wallet per proposal; no delegation or vote replacement in this MVP. Users specify a positive token quantity. Locking and recording voting weight must be atomic; weight equals the committed quantity in token base units. Reject votes outside the window, zero amounts, duplicate votes, and amounts greater than unlocked balance. Existing proposal deadlines and choices cannot be edited. No proposal execution or treasury transfers are required.

For overlapping proposals, add together their still-active locked quantities: the same units cannot back two simultaneous votes in this MVP. Bound active lock entries per user and all loops; document the chosen bound and a maximum proposal duration. Expired entries must never prevent transfers or permanently consume active-lock capacity. Lock expiration depends on block.timestamp at the fixed end time, regardless of whether anyone finalizes the proposal or the frontend/backend is online. Voting weight remains recorded after expiration. Supply changes, if any implementation path exists, must not bypass active locks.

Every debit path must preserve balanceOf(account) >= activeLocked(account). Cover transfer, transferFrom including allowances granted before voting, router/DEX-style spending, burn, and burnFrom if present. New approvals do not override locks; approvals need not be disabled. Incoming transfers are allowed and do not increase an existing vote or extend its deadline. Expose total balance, active locked balance, transferable balance, individual locks/deadlines, vote receipt, and proposal totals with useful events.

Frontend: connect an EVM wallet, verify its chain, list/create proposals, show choices and deadlines, display total/locked/available token balances, let a holder select quantity and vote, show transaction pending/failure/success and on-chain results. Display overlapping locks and unlock times. Use real contract reads and transactions, not mock balances or simulated success. No private keys in the frontend, no custodial backend, no secret APIs, and no DexScreener/dexscreen dependency or fallback. Provide a local test deployment and a clear wallet-to-vote-to-unlock walkthrough.

Multi-chain: provide reusable deployment scripts and frontend configuration keyed by chainId and contract addresses. Target conventional EVM chains such as Ethereum, Base, Arbitrum and BNB Smart Chain after chain-specific validation. Keep governance and balances independent on each chain; do not add bridging or pooled cross-chain vote totals. Document compiler/EVM target assumptions and distinguish chains actually tested from merely configured. Use test fixtures/local networks for validation; no live wallet funds are authorized.

Acceptance: with 1,000 tokens, a 300-token vote leaves balanceOf at 1,000 and transferable balance at 700; transferring 701 fails and transferring 700 succeeds. A pre-approved spender/router also cannot spend the remaining 300. Incoming tokens remain available without changing the vote. At the deadline the lock no longer restricts transfers without an administrator or finalization transaction. Test additive overlapping locks with different deadlines, duplicate/unauthorized votes and locks, boundary timestamps, historical approvals, signature/permit spending paths if included, all burn paths if included, initialization permissions, expiry cleanup, and attempts to borrow/vote/repay the same locked funds in one transaction. Include meaningful fuzz/invariant tests for locked-balance conservation and tally correctness and an adversarial review. Document all trust assumptions and outstanding findings. Deliver reproducible run/test/deploy instructions and a working frontend alongside the source.

Use In-Wallet Voting Demo (symbol VDEMO), 18 decimals, and a fixed supply of 1,000,000 tokens solely as the configurable local test fixture. These are demonstration metadata, not a request to mint or launch a live asset. Deliver source code only in this job.