NID Skeleton Facets

The NID(NexeraID) skeletons are nearly identical to the basic skeletons, with the primary difference being the user verification mechanism. The NID skeletons do not rely on the eligibility interfaces, like non-NID skeleton counterparts. Instead, The NID Skeletons integrate with an off-chain AML service, called ComPilot, which serves as the KYC layer for users. This unique feature enables more granular compliance, making it easier to run tokenization campaigns on your platform.

The basic configuration for both Sale and Sale with Buyback requires the following facets to be selected:

Sale requires 3 skeleton Facets:

• CreateFractionsSkeletonNID - Provides a set of functions to create fractions.
• PurchaseSkeletonNID - Exposes functions that allow users to purchase fractions.
• ReceiveSkeletonNID - Provides functionality to receive funds collected from the sale.

Sale with buyback requires 5 skeleton Facets:

• CreateFractionsSkeletonNID - Provides a set of functions to create fractions.
• PurchaseSkeletonNID - Exposes functions that allow users to purchase fractions.
• ReceiveSkeletonNID - Provides functionality to receive funds collected from the sale.
• BuybackSkeletonNID - Enables the buyback functionality for users.
• ReceiveAfterBuybackSkeletonNID - Allows users to retrieve principal and interest after the buyback.

If a use-case instance falls under the Sale category, then there is no Buyback or ReceiveAfterBuyback facets involved.

Eligibility Verification

The NID Skeletons have user verification mechanism implemented through the TxAuthDataVerifierFacet, which is developed by ComPilot AML platform. To interact with a platform built using the NID skeletons, a user must go through ComPilot's KYC process, which whitelists the user address and provides the necessary call data each time the user wants to interact with the Fraction Platform.

On the smart contract side, the user is required to provide the correct call data containing the signature generated by ComPilot. This third-party functionality is implemented through a function modifier called requireTxDataAuth. For example, before executing the logic in the purchase function, the modifier is executed, and within its context the call data is deconstructed and such data as a signature and block expiration number and validated. If the data is verified successfully, the logic in the purchase function is executed.