VestingSubSkeletonNID

Implementation of the Vesting sub-skeleton facet with Compilot gating for the TMI-Fraction Protocol.

_This facet serves as a sub-core component (sub-skeleton) of a TMI-Fraction Platform, allowing investors to claim and receive a campaign's underlying wrapped assets when a vesting schedule is configured, through fraction balance redemption.

IMPORTANT:

• This implementation relies on genesisIds and must always be used in conjunction with PurchaseSkeletonGenesisIdsStorage.sol and NonFundedSubSkeletonGenesisIds.sol (if the non-funded state is applicable), as well as sub-internal and internal facets that depend on it.

• It is designed for Platforms with the following traits:

  • Supports campaigns that issue only semi-fungible (ERC1155) genesisIds fractions.
  • Supports campaigns that feature vesting schedules.

• The genesisId identification schema for semi-fungible (ERC1155) fractions enables precise tracking of owed portions within campaigns featuring both discount mechanisms and vesting schedules. This is achieved by offsetting the fractions' ID relative to the campaign's configured upperGenesisId when vested claims are performed.

  For example, if the upperGenesisId for a campaign's fractions is 1, it might reflect the following:

  • Fractions purchased at full price → ID = 0 (genesisId)
  • Fractions purchased at a discount → ID = 1 (upperGenesisId)

  When a user claims the first X portions (including TGE/Cliff release(s), if applicable):

  • Their fraction balance (ID = 0 if purchased at full price, ID = 1 if discounted) is burned.
  • If total portions Y > X, they receive newly minted fractions with ID = upperGenesisId + X (Z = Y - X portions remain).
  • If total portions Y == X, they do not receive newly minted fractions (all portions have been claimed).
  • The user receives the corresponding token amount for the X claimed portions.

The process of investors redeeming genesisIds semi-fungible fractions in exchange for respective portions of their owed underlying wrapped assets is signatured-based gated (see TxAuthDataVerifierFacet) and is triggered when claimVestedAssets() is executed, following a sequential pipeline of three phases:

• State Check: The Platform interacts with its VestingState sub-internal facet to verify that the current state of the targeted campaign allows vested claims to occur.

• Eligibility Check: The Platform interacts with its PurchaseEligibility internal facet to verify that the user (caller) meets the campaign's eligibility criteria.

• Vesting Action: The Platform interacts with its DoVestingActions sub-internal facet to burn the caller's fraction balance and transfer to the caller the respective TGE and/or Cliff release (if TGE and/or Cliff releases are configured) as well as any vested portion(s) owed as per the vesting schedule. If additional releases and/or portions are owed, the user is also minted fractions with the appropriate ID in order to redeem them in future claims._

UnauthorizedInitialization

error UnauthorizedInitialization(address account)

Thrown when trying to initialize from non admin account.

VestedAssetsClaimed

event VestedAssetsClaimed(uint256 campaignId, address receiver, uint256 semiFungibleBurntId, uint256 amountOfFractionsBurnt)

Emitted at claimVestedAssets().

initializeVestingSubSkeleton

function initializeVestingSubSkeleton(address signer_) external

Initializes the TxAuthDataVerifierFacetStorage by registering the attestor address.

_This function can only be called by the Admin (see AccessControlFacet.sol).

IMPORTANT:

• If the platform uses multiple NID skeletons or subskeletons, only one of them can be initialized._

Parameters

claimVestedAssets

function claimVestedAssets(uint256 campaignId, uint256 amountOfFractions, uint256 idToBurn) external

Burns amountOfFractions of idToBurn from the user and transfers the respective vested owed amount(s) of underlying asset(s) to the user. If additional releases and/or portions are owed, the user is minted fractions with the appropriate ID, allowing them to redeem those fractions in future claims.

_Users must meet eligibility criteria (see purchase Eligibility internal facets) and adhere to the campaign's vested schedule (e.g., time-related constraints).

This function can only be executed if the transaction calldata contains the required signature and expiration block (see requireTxDataAuth modifier).

Emits a {VestedAssetsClaimed} event._

Parameters