Development of a GameFi Energy/Stamina System
We have faced the task of creating an on-chain energy system that does not burn gas on regeneration. The usual approach—updating storage every second—kills the economy and makes the game unplayable. Our implementation uses lazy evaluation, allowing current energy to be computed without writing. With over 5 years of experience, we have developed an architecture that balances gas economy and cheat protection. This article covers key mechanics: time-based regen without writes, NFT binding, tradeable energy, and anti-cheat.
An energy system limits player activity. Players spend energy on actions (battles, farming, crafting), and energy replenishes over time or through purchases. In Web2, this is a simple counter in a database. In Web3, it’s an on-chain resource, creating opportunities (tradeable energy, verifiable regen) and problems (gas per update, cheating prevention). Proper architecture of the energy system is a key engineering challenge in GameFi. An incorrect implementation either makes the game unplayable (too many on-chain operations) or opens exploits (free energy via manipulation).
How does lazy evaluation reduce gas costs?
The intuitive solution: store energy in a mapping and update it every second. This is bad—endless transactions. The correct approach is lazy evaluation. Store not the current energy, but the last update moment and the value at that moment. Current energy is computed on-the-fly on each read:
contract EnergySystem {
struct EnergyState {
uint128 storedEnergy;
uint64 lastUpdateTime;
uint64 maxEnergy;
}
mapping(address => EnergyState) private energyStates;
uint256 public constant REGEN_RATE = 1e18;
uint256 public constant MAX_ENERGY = 100e18;
function currentEnergy(address player) public view returns (uint256) {
EnergyState storage state = energyStates[player];
uint256 elapsed = block.timestamp - state.lastUpdateTime;
uint256 regenerated = elapsed * REGEN_RATE;
uint256 total = uint256(state.storedEnergy) + regenerated;
uint256 max = state.maxEnergy == 0 ? MAX_ENERGY : uint256(state.maxEnergy);
return total > max ? max : total;
}
function _updateEnergyState(address player) internal {
EnergyState storage state = energyStates[player];
state.storedEnergy = uint128(currentEnergy(player));
state.lastUpdateTime = uint64(block.timestamp);
}
function spendEnergy(address player, uint256 amount) internal {
uint256 current = currentEnergy(player);
require(current >= amount, "Insufficient energy");
_updateEnergyState(player);
energyStates[player].storedEnergy -= uint128(amount);
}
function addEnergy(address player, uint256 amount) internal {
_updateEnergyState(player);
uint256 max = energyStates[player].maxEnergy == 0
? MAX_ENERGY
: energyStates[player].maxEnergy;
uint256 newEnergy = uint256(energyStates[player].storedEnergy) + amount;
energyStates[player].storedEnergy = uint128(newEnergy > max ? max : newEnergy);
}
}
The key point: currentEnergy() is a view function, consuming no gas. Storage updates only occur on spendEnergy/addEnergy—i.e., on actual game actions. Lazy evaluation reduces gas consumption by 10 times compared to constant storage updates. According to Solidity documentation, packed structs save storage gas.
| Parameter | Lazy evaluation | Constant update |
|---|---|---|
| Write operations | 0 in background, only on action | Every second (millions of TX) |
| Gas cost per action | ~50,000 gas | ~100,000 gas + background |
| Implementation complexity | Medium | Low |
| Suitable for | High-traffic GameFi | Simple simulations |
Using lazy evaluation reduces gas consumption by 90% compared to naive approaches. For a game with 10,000 daily active users, this can save over $120,000 annually in gas fees.
Energy Binding to an NFT
Energy is bound to a specific NFT, not an EOA wallet. This is important: a player can have multiple characters with independent energy, and trade characters along with their current energy.
contract CharacterEnergySystem {
struct CharacterEnergy {
uint128 storedEnergy;
uint64 lastUpdate;
uint8 tier;
}
mapping(uint256 => CharacterEnergy) public characterEnergy;
function regenRateForTier(uint8 tier) public pure returns (uint256) {
if (tier == 3) return 3e18;
if (tier == 2) return 2e18;
return 1e18;
}
function maxEnergyForTier(uint8 tier) public pure returns (uint256) {
return 100e18 + uint256(tier) * 50e18;
}
function currentEnergy(uint256 tokenId) public view returns (uint256) {
CharacterEnergy storage ce = characterEnergy[tokenId];
uint8 tier = nftContract.getTier(tokenId);
uint256 elapsed = block.timestamp - ce.lastUpdate;
uint256 regen = elapsed * regenRateForTier(tier);
uint256 total = uint256(ce.storedEnergy) + regen;
uint256 max = maxEnergyForTier(tier);
return total > max ? max : total;
}
}
When an NFT is transferred, the energy moves with the character automatically, as it is stored in the mapping by tokenId.
Anti-Cheat Criticality
Without protection, players can manipulate regeneration via re-org or replay attacks. Our solution uses signed actions with nonce:
struct GameAction {
uint256 characterId;
uint256 actionType;
uint256 energyCost;
uint256 nonce;
uint256 deadline;
}
mapping(address => uint256) public actionNonces;
function executeAction(
GameAction calldata action,
bytes calldata serverSignature
) external {
bytes32 digest = _hashTypedData(action);
address signer = ECDSA.recover(digest, serverSignature);
require(signer == GAME_SERVER_SIGNER, "Invalid signature");
require(action.nonce == actionNonces[msg.sender], "Invalid nonce");
actionNonces[msg.sender]++;
require(block.timestamp <= action.deadline, "Expired");
spendEnergy(action.characterId, action.energyCost);
_processAction(action);
}
Additionally, we introduce a cooldown modifier for frequent actions:
mapping(uint256 => mapping(uint8 => uint256)) public lastActionTime;
uint256 public constant BOSS_FIGHT_COOLDOWN = 4 hours;
modifier withCooldown(uint256 charId, uint8 actionType, uint256 cooldown) {
require(
block.timestamp >= lastActionTime[charId][actionType] + cooldown,
"Action on cooldown"
);
_;
lastActionTime[charId][actionType] = block.timestamp;
}
function fightBoss(uint256 charId) external withCooldown(charId, ACTION_BOSS, BOSS_FIGHT_COOLDOWN) {
spendEnergy(charId, BOSS_FIGHT_ENERGY_COST);
// ...
}
Risks of ERC-20 Energy
A more complex model: a separate ERC-20 token as energy, which can be bought/sold. Trade-off: players can buy energy on a DEX → pay-to-win risk. If acceptable, ERC-20 energy provides economic value; if not, energy should be non-transferable (internal accounting, not a token).
Economic Model: Sinks and Sources
The energy system acts as an economy regulator. It is important to balance sources and sinks. Recommended parameters:
| Parameter | Recommendations |
|---|---|
| Regen rate | Fill from 0 to max in 8–12 hours |
| Max energy | 1–3 game sessions of 2–3 hours each |
| Premium refill | No more than 2–3 full refills per day |
| Tier multiplier | Max 2x–3x, not more |
Timeline and Cost Estimates
Basic system (lazy regen, spend, cooldowns): 2–3 weeks, estimated cost $5,000–$10,000. Full system (tier-based regen, ERC-20 energy token, DEX integration, anti-cheat signed actions, dashboard analytics): 5–7 weeks, estimated cost $15,000–$25,000. Cost is calculated individually after analyzing your mechanics.
What Is Included in the Delivery
- Audit of existing mechanics
- Smart contract design with gas optimization in mind
- Development and unit tests (Foundry with vm.warp)
- Contract deployment and verification
- Integration with game backend (ethers.js, viem)
- API documentation and usage examples
- Post-release support (1 month)
- Training session for your development team
- Access to all source code and deployment scripts
Step-by-Step Implementation Guide
- Analyze your game mechanics and define energy parameters (regen rate, max energy, actions).
- Design smart contract architecture with lazy evaluation and optional ERC-20 energy.
- Develop and test contracts using Foundry (with vm.warp for time travel).
- Deploy contracts to testnet and verify security with an audit.
- Integrate with your game backend via ethers.js or viem.
- Deploy to mainnet and monitor gas usage.
- Conduct beta testing with users and adjust parameters.
Example Regeneration Test in Foundry
```solidity function test_energyRegenOverTime() public { uint256 tokenId = 1; vm.prank(player); game.spendAllEnergy(tokenId); assertEq(energy.currentEnergy(tokenId), 0); vm.warp(block.timestamp + 50); assertEq(energy.currentEnergy(tokenId), 50e18); vm.warp(block.timestamp + 200); assertEq(energy.currentEnergy(tokenId), 100e18); } ```We guarantee no reentrancy and use proven patterns (OpenZeppelin). Our experience: 5+ years in Web3, 30+ implemented projects. Contact us for a consultation on your GameFi mechanics. Order a turnkey energy system development.