[M1: Audit 2: L-12]: CIP112: Pin allocation and holding policies to a template type

Open
  • Is something wrong?
#96 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
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
markdown
Domain
blockchain

Research direction

Start with the Holding.daml and Registry.daml references in the issue, then inspect Custom.daml, the token-cip112-utils-test harness, and the linked README and changelog sections. Update the signatures and call sites as specified, document the unchecked custom spend-hook and archive-bypass caveats, and run the relevant utility tests. Done when all named call sites and documentation reflect the new constraints and the one-allocation-template-per-batch limit.

Written by the indexing model from the issue text.

Description

Addresses L-12

Changes

Code:

  • pinAllocationTo and consumeByArchive should require HasEnsure t. Of the template classes, it is the only one an interface does not satisfy. Template t would not help, because interfaces satisfy it in SDK 3.5.
  • settleBatchImpl and expireAllocationsImpl should take the accepted allocation template as a type argument with the same constraint, instead of a PinAllocation function. A registry then cannot omit the pin or write it as an interface fetch. Update the call sites in TokenRules, MyRules and the token-cip112-utils-test harness.

Documentation:

  • The consumeHolding law, the Holding.daml module comment and the trust boundary in the token-cip112-utils README.md should say three things:
    • consumeHolding must be built from consumeByArchive @T, or from a spend choice reached through fetchFromInterface at a template type.
    • The compiler checks only the first.
    • consumeByArchive skips any spend choice the template defines.
  • Update the README.md entries that describe PinAllocation and pinAllocationTo to match the new signatures, and add a CHANGELOG.md entry for the signature change.

Complications

  • Custom spend hooks stay unchecked. myOps reaches MyHolding_Spend through fetchFromInterface @MyHolding. fetchFromInterface @Holding also compiles, so this path is protected only by the documented law.
  • consumeByArchive bypasses spend rules. consumeByArchive @MyHolding archives a frozen holding without calling MyHolding_Spend. The documentation must not present consumeByArchive as a drop-in replacement for templates that have a spend rule.
  • One allocation template per batch. A type argument accepts exactly one allocation template, and a PinAllocation function could accept several. No shipped registry uses more than one, and SCU upgrades keep the template identity. The README.md should state the limit.
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.