[M1: Audit 2: L-09]: CIP112: Saturate time arithmetic so an oversized `maxTTL` or `lockGrace` cannot overflow

Open
  • Is something wrong?
#93 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Domain
blockchain

Research direction

Start with computeStorageExpiry in Holding.daml as the existing saturation example, then read the timestamp calculations and invariants in Transfer.daml, Allocation.daml, Registry.daml, and the TransferInstructionState and AllocationState templates. Add coverage for transfers, mint offers, and allocation creation and settlement with large maxTTL and lockGrace values, and update the token-cip112-utils README.md. Done when these paths saturate at Time bounds, the invariants accept a lock expiry at maxTime, and the tests pass.

Written by the indexing model from the issue text.

Description

Addresses L-09

Changes

Code:

  • Every timestamp computed from maxTTL or lockGrace should saturate at the bounds of Time instead of raising an ArithmeticError, as computeStorageExpiry already does for maxTTL. This covers:
    • the maxTTL window and request-age bounds in validateTransfer (Transfer.daml) and allocationFactoryImpl (Allocation.daml), in the form they take after #91 (executeBefore - maxTTL, requestedAt + maxTTL);
    • the lockGrace additions on the transfer, mint (Registry.daml), allocation creation, and allocation settlement paths.
  • The expiresAt < lockExpiresAt invariant in TransferInstructionState and AllocationState should also accept lockExpiresAt == maxTime, so a saturated lock expiry does not fail the template's ensure.
  • isValidRegistryConfig and isValidAllocationState keep accepting any positive maxTTL and lockGrace. A value that saturates means the window or lock never expires in practice.

Tests:

  • Cover transfers, mint offers, and allocation creation and settlement under a maxTTL and a lockGrace large enough to saturate.

Documentation:

Dominant language
Haskell
Stars
5
Forks
0
Avg merge
1d 36m
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenZeppelin/canton-contracts

All issues in OpenZeppelin/canton-contracts

Similar issues

More Haskell issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.