When a Safe View Becomes an Unsafe Settlement Input

A settlement calculation should consume the state that defines the economic obligation, not a context-sensitive projection created for another security goal.

TL;DR

• A balance function is not merely a number. It carries assumptions about time, ownership, checkpoints, and purpose.
• Same-block transfer suppression can be appropriate for voting power while being unsafe as the basis of an early-exit penalty.
• Removing suppression globally is not the answer. A public Velocimeter finding describes the opposite risk when alternate voting views omit the transfer protection.
• The structural fix is role-specific reads: settlement state for settlement, voting state for voting, and historical checkpoints for historical queries.
• Tests should cross economic actions with every transition that can alter, suppress, or stale their inputs.

Methodology and evidence boundaries

1. a context-sensitive balance view used in an economic calculation;
2. a transfer-time guard that deliberately changes a voting balance; or
3. a checkpoint interface that distinguishes current state from historical state.

• the Composable Security report for Neverland and its recorded retest;[1]
• the current public Velodrome VotingEscrow implementation;[2]
• Sherlock issue 286 from the Velocimeter review;[3]
• OpenZeppelin's ERC-721 and governance documentation;[4][5]
• the Zealynx case study for attribution and evidence limits.[6]

• Source fact reports what a cited source states or implements.
• Zealynx classification groups behavior by semantic role. It is not a new severity rating.
• Inference is a design conclusion drawn across the sources.
• Limitation identifies what the public evidence does not establish.

The hidden type system inside a balance

1function lockedPrincipal(uint256 tokenId) external view returns (uint256);
2function currentVotingPower(uint256 tokenId) external view returns (uint256);
3function pastVotingPower(uint256 tokenId, uint256 timepoint) external view returns (uint256);

1SettlementAmount(position, time)
2VotingPower(position, time, ownershipContext)
3HistoricalVotes(account, checkpoint)

Anchor: transfer suppression crossed into an exit fee

1position has an active economic obligation
2    -> position ownership changes
3    -> voting view is suppressed for the current block
4    -> exit path reads the suppressed voting view
5    -> obligation is calculated from zero

• the NFT remains transferable;
• recently transferred voting power is not immediately reusable;
• early withdrawal charges a percentage of a balance.

Comparison 1: Velodrome makes the transfer guard explicit

1. ownership transition is security-relevant state, not administrative metadata;
2. a balance read can legitimately depend on the block in which ownership changed.

Comparison 2: the opposite mistake also exists

Define which semantic value each operation requires, then make that choice explicit and testable.

Comparison 3: checkpoints answer a different question

1What voting state was recorded at the proposal's timepoint?

1What economic obligation is attached to this position now?

A taxonomy of context-sensitive read failures

1. Protective suppression leaks into settlement

2. An unguarded read leaks into voting

3. Historical state is treated as current obligation

4. Current projection is treated as stored principal

The invariant: obligations survive unrelated projections

1For every position eligible for early exit:
2
3chargedPenalty
4    == penaltyRule(economicPositionState)

1transfer
2approval change
3delegation
4vote checkpoint
5same-block ownership guard
6metadata update

A transition must not alter settlement merely because it alters a projection used by another subsystem.

1penalty(exit(position))
2    == penalty(transferThenExit(position))

1penalty(exit in transfer block)
2    == penalty(exit one block later)

Design pattern: name values by role, not shape

1function settlementBase(uint256 tokenId) internal view returns (uint256) {
2    LockedBalance memory lock = locked[tokenId];
3    return uint256(uint128(lock.amount));
4}
5
6function votingPower(uint256 tokenId) public view returns (uint256) {
7    if (ownershipChange[tokenId] == block.number) return 0;
8    return decayedWeightAt(tokenId, block.timestamp);
9}

1. Separate interfaces. Put voting projections and settlement accounting behind different functions or modules.
2. Use semantic naming. Encode purpose in names such as settlementBase, currentVotes, and pastVotes.
3. Restrict sensitive reads. Keep raw accounting helpers internal where possible so integrations cannot mistake them for supported voting interfaces.

A transition matrix for review

Review questions for protocol teams

1. Which storage field defines principal, and which functions only project voting power?
2. Can any read return zero because of transfer timing, delegation, checkpoint lag, or flash protection?
3. Which fee, reward, redemption, and withdrawal paths consume those reads?
4. Does a transfer move the obligation, clear it, or leave it unchanged?
5. Are same-block and next-block outcomes economically equivalent when the specification expects them to be?
6. Can integrations call an alternate view that omits a required voting guard?
7. Do split and merge operations conserve principal, penalty basis, and voting checkpoints independently?
8. Does the fix preserve the security property that motivated the original guard?

What this research does not establish

The durable rule

Every economic action must read the state that defines its obligation, across every transition that can change the meaning of a shared view.

FAQ

Glossary

Sources