Why it matters
An older ForkMesh design generated deposit keys in the Worker and automatically swept or paid bounty funds. That design conflicts with the platform’s non-custodial boundary and is no longer an active funding or payout path.
Preservation costs time, disk, bandwidth, and maintenance, so incentives need to point at the nodes and people doing the work. In ForkMesh, issue bounties addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.
How ForkMesh handles it
All legacy wallet creation, funding, sweeping, and automatic bounty-payout endpoints now fail closed. The web, desktop, and mobile interfaces show historical state only and direct an instance owner to the offline custody-audit tool. That tool inventories encrypted legacy rows, requires explicit reconciliation, never prints secrets, and never moves funds automatically.
A future issue incentive must use an owner-controlled external wallet, program, or multisig; publish only public transaction evidence; and independently verify exact finalized transfers. ForkMesh must not create or retain a custodial wallet for the issue or contributor.
Where it fits
The current community reward program supports verified mirror-node incentives on Solana mainnet-beta; explicit development deployments may select a test network. It does not reactivate issue bounties.
Historical status labels are accounting and migration records, not user balances, redeemable claims, or guaranteed payouts.