Timelocks & community retention

What a DevFridge timelock is

A player deposits a supported Solana Token-2022 token into a vault controlled by the DevFridge program (9RY54dNPYTzDyh3TfFqDdt2b2KMM56KW1tw9erRTGQo6) and chooses an unlock time. The vault records the depositor, mint, amount and expiry. The original depositor can redeem after expiry under the program’s rules; there is no early withdrawal.

Games using this stack read timelocks in the existing DevFridge Solana program. Each game defines its supported mint, minimum amount and duration rules. It does not need to deploy its own token vault. A wallet connection alone does not prove that a qualifying lock exists.

The problem it addresses

A meme can attract attention without giving holders an ongoing activity. A game turns shared identity into something to do together. A voluntary timelock ties access to a commitment period, while challenges, friends, progress and fresh content give players reasons to use that access.

Locked tokens cannot be sold from the vault before expiry. That does not prevent selling other holdings, guarantee retention or make a token’s price rise. The game must be worth returning to; the lock is an access mechanism, not a substitute for fun.

Design an honest access policy

• Show the exact mint, human-readable minimum, lock duration, unlock timestamp and benefit before the user signs.
• State whether multiple locks of the same mint are summed or one vault must qualify. Never add amounts across different tokens.
• Define expiry behaviour: when eligibility ends, how progress is preserved and whether practice play remains available.
• Choose an accessible threshold for your own community. World’s 500,000-token rule and ten-character roster are not hackathon defaults.
• Never require a token purchase or mainnet deposit just to inspect a submission. Provide a labelled practice mode and a gate demonstration.

Redemption and the 2% service fee

The current documented redemption flow charges 2% of redeemed tokens, plus separate network costs. The fee applies on redemption whether the player later sells or keeps the tokens. It is not a tax on every token sale and it does not allow early exit.

The fee is used for PASTA buy-and-burn through Jupiter, or direct burning for PASTA. This is the ecosystem’s developer-support model; it is not a direct infrastructure treasury payment or a guarantee of developer income. Non-PASTA redemption needs an executable Jupiter route. A new or illiquid Pump.fun token may not have one: check route availability and explain this limitation before users lock.

The exit cost can make repeated entry and redemption less attractive, but it is modest and must be disclosed. Motivate players with a good experience rather than pressure, price promises or hidden fees.

What “verified” does and does not mean

A verified build lets people compare deployed bytecode with a reproducible source build. Embedded security.txt metadata describes security contacts and policies. Neither is an independent audit or a guarantee that funds are safe.

The program is upgradeable. Review its current authority, source, verification evidence and published security notes. Team checks and on-chain audit records must be described precisely; do not turn them into claims of an independent audit. Do not promise that a lock protects against token price losses.