GitHub

Staking Platform Deployment

The setup & configuration of any staking platform (also referred to as a staking market) within the Staking Protocol is primarily determined by the Reward Distribution Algorithm(s) it employs (meaning which Reward Distribution Facet is utilized). Currently, the protocol supports 4 (four) distinct Reward Distribution Algorithms referred to as RewardDistribution Facets:

  1. RateBasedLock
  2. RateBasedOpen
  3. PreStake
  4. Complex

Currently, the codebase does not include a Reward Distribution Mixer Facet, which means all potential platforms are limited to generating campaigns using only the specific reward distribution algorithm for which they are configured.

The set up & configuration schema of any platform involves the selection of a subset of appropriate facets, from the total set of facets featured in the protocol.

Foundational Configuration Templates

The following 4 (four) templates outline basic, foundational setups that serve as starting points for platforms’ configuration. These templates are not exhaustive and can be further built upon as needed. Each starting point is based on the skeleton implementations selected for the platform.

1. Both Skeletons Without Leveraging Compilot—NID

  • CampaignCreationSkeleton
  • StakingSkeleton
  • ERC721Facet
  • AccessControlStakingFacet
  • WhitelistedCampaignCreatorsFacet
  • WhitelistedStakersFacet

Once this setup is established, proceed to select implementation(s) from the Reward Distribution category. Subsequently, choose implementations from the remaining categories, ensuring these align with the selected Reward Distribution configuration.

2. Only the Staking Skeleton is leveraging Compilot—NID

  • CampaignCreationSkeleton
  • StakingSkeletonNID
  • ERC721Facet
  • AccessControlStakingFacet
  • WhitelistedCampaignCreatorsFacet

Once this setup is established (excluding the Staker Eligibility Category), proceed to select implementation(s) from the Reward Distribution category. Subsequently, choose implementations from the remaining categories, ensuring these align with the selected Reward Distribution configuration.

3. Only the Campaign Creation Skeleton is leveraging Compilot—NID

  • CampaignCreationSkeletonNID
  • StakingSkeleton
  • ERC721Facet
  • AccessControlStakingFacet
  • WhitelistedStakersFacet

Once this setup is established (excluding the Staker Eligibility Category), proceed to select implementation(s) from the Reward Distribution category. Subsequently, choose implementations from the remaining categories, ensuring these align with the selected Reward Distribution configuration.

4. Both Skeletons are leveraging Compilot—NID

  • CampaignCreationSkeletonNID
  • StakingSkeletonNID
  • ERC721Facet
  • AccessControlStakingFacet

Once this setup is established (excluding both the Creator and Staker Eligibility Category), proceed to select implementation(s) from the Reward Distribution category. Subsequently, choose implementations from the remaining categories, ensuring these align with the selected Reward Distribution configuration.

The next section builds upon the above-mentioned foundational templates, presenting complete setups that extend them without overriding or altering their configurations. Each of these templates introduced in the next section begin with selections from the Reward Distribution category as the starting point.

Comprehensive Configuration Templates

These templates build upon the foundational templates, starting with the Reward Distribution category and proceeding with aligned choices from the remaining categories.

RateBasedLock

When the RateBasedLockRewardDistributionFacet implementation is selected from the Reward Distribution Category, the implementation choices for the remaining categories should be as follows:

  • Campaign Amounts Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.
  • Campaign Times Category: Only the OnlyStartingTimestampFacet implementation is suitable.
  • Lock Variations Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.
  • Virtual Amount Multiplier Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.
  • Virtual Lock Multiplier Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.
  • Withdrawal Variation Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.
  • Transfer Input Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.
  • Transfer Reward Category: Any implementation from this category is suitable, or any combination of explicit implementations, if a Mixer for this category exists.

RateBasedOpen

When the RateBasedOpenRewardDistributionFacet implementation is selected from the Reward Distribution Category, the implementation choices for the remaining categories should be as follows:

PreStake

When the PreStakeRewardDistributionFacet implementation is selected from the Reward Distribution Category, the implementation choices for the remaining categories should be as follows:

Complex

When the ComplexRewardDistributionFacet implementation is selected from the Reward Distribution Category, the implementation choices for the remaining categories should be as follows:

Featured Categories of Facets & Inter-Relations

Skeletons (mandatory & independent)

The Skeletons Category comprises the following implementation contracts:

  1. Non NID (Compilot) leveraging Skeletons
    • StakingSkeleton
    • CampaignCreationSkeleton
  2. NID (Compilot) leveraging Skeletons
    • StakingSkeletonNID
    • CampaignCreationSkeletonNID

All platforms (use case diamonds) must mandatorily have both the StakingSkeleton (or StakingSkeletonNID ) and the CampaignCreationSkeleton (or the CampaignCreationSkeletonNID ) as facets.

ERC721 (mandatory & independent)

The ERC721 Category consists exclusively of the ERC721Facet implementation contract. All platforms (use case diamonds) must mandatorily have the ERC721Facet as a facet.

Generic (mandatory & independent)

The Generic Category consists exclusively of the AccessControlStakingFacet implementation contract. All platforms (use case diamonds) must mandatorily have the AccessControlStakingFacet as a facet.

Creator Eligibility (non mandatory — excluded on condition)

The Creator Eligibility Category consists exclusively of the WhitelistedCampaignCreatorsFacet implementation contract. All platforms (use case diamonds) that integrate the Non-NID Campaign Creation Skeleton version (i.e., CampaignCreationSkeleton) must mandatorily have the WhitelistedCampaignCreatorsFacet as a facet.

This category is not associated with platforms that integrate the NID Campaign Creation Skeleton version (i.e., CampaignCreationSkeletonNID). Consequently, the WhitelistedCampaignCreatorsFacet is not added as a facet in such platforms.

Staker Eligibility (non mandatory — excluded on condition)

The Staker Eligibility Category consists exclusively of the WhitelistedStakersFacet implementation contract. All platforms (use case diamonds) that integrate the Non-NID Staking Skeleton version (i.e., StakingSkeleton) must mandatorily have the WhitelistedStakersFacet as a facet.

This category is not associated with platforms that integrate the NID Staking Skeleton version (i.e., StakingSkeletonNID). Consequently, the WhitelistedStakersFacet is not added as a facet in such platforms.

Rewards Distribution (mandatory)

The Reward Distribution Category comprises the following implementation contracts:

  • RateBasedLockRewardDistributionFacet
  • RateBasedOpenRewardDistributionFacet
  • PreStakeRewardDistributionFacet
  • ComplexRewardDistributionFacet

This category is critical, as its implementations significantly influence the selection of implementations in other categories.

All platforms (use case diamonds) must mandatorily have one implementation of this category as a facet, chosen based on how rewards should be calculated and distributed within the platform's staking campaigns.

Currently, the codebase does not include a Reward Distribution Mixer Facet, restricting all platforms to one of the four available implementations. In the future, a Mixer Facet for this category would allow platforms to support staking campaigns with varied reward distribution mechanics.

Campaign Amounts (mandatory & independent)

The Campaign Amounts Category comprises the following implementation contracts:

  • HardcapAmountFacet
  • TwoBorderAmountFacet

This category is independent of all other existing categories, meaning the implementation selected from this category does not depend on implementations chosen from other categories.

All platforms (use case diamonds) must mandatorily have either the HardcapAmountFacet or the TwoBorderAmountFacet added as a facet.

Currently, the codebase does not include a Campaign Amounts Mixer Facet, restricting all platforms to one of the two available implementations.

Campaign Times (mandatory & highly dependent)

The Campaign Times Category comprises the following implementation contracts:

  • OnlyStartingTimestampFacet
  • TwoBorderTimestampFacet

This category is highly dependent on the Reward Distribution category, meaning the implementation selected from this category relies heavily on the implementation chosen from the Reward Distribution category.

All platforms (use case diamonds) must mandatorily have either the OnlyStartingTimestampFacetor the TwoBorderTimestampFacetadded as a facet, depending on the Reward Distribution Implementation integrated by the platform.

Currently, the codebase does not include a Campaign Times Mixer Facet, restricting all platforms to one of the two available implementations. In the future, a Mixer Facet for this category will only be valuable if a Reward Distribution Mixer Facet is also developed, due to the strong dependency between the two categories.

Lock Variations (mandatory & loosely dependent)

The Lock Variations Category comprises the following implementation contracts:

  • StaticPeriodLockFacet
  • TwoBorderTimeLockFacet

This category is loosely dependent on the Reward Distribution category. The term loosely indicates that while some Reward Distribution implementations are compatible with either Lock Variation implementation, others are only compatible with a specific implementation.

All platforms (use case diamonds) must mandatorily have either the StaticPeriodLockFacetthe TwoBorderTimeLockFacetas a facet, depending on the Reward Distribution Implementation integrated by the platform.

Currently, the codebase does not include a Lock Variations Mixer Facet, restricting all platforms to one of the two available implementations. In the future, a Mixer Facet for this category would be most effective if accompanied by a Reward Distribution Mixer Facet, given the dependency between the two categories.

Virtual Amount Multiplier (mandatory & independent)

The Virtual Amount Multiplier Category comprises the following implementation contracts:

  • NoVirtualAmountMultiplierFacet
  • IntervalVirtualAmountMultiplierFacet
  • ContinuousVirtualAmountMultiplierFacet

This category is independent of all other existing categories, meaning the implementation selected from this category does not depend on implementations chosen from other categories.

All platforms (use case diamonds) must mandatorily have one implementation of this category as a facet, chosen based on whether multipliers for staked amounts are supported and, if so, how such multipliers should be calculated within the platform's staking campaigns.

Currently, the codebase does not include a Virtual Amount Multiplier Mixer Facet, restricting all platforms to one of the three available implementations. In the future, a Mixer Facet for this category would allow platforms to support staking campaigns with varied amount multiplier calculation mechanics.

Virtual Lock Multiplier (mandatory & dependent)

The Virtual Lock Multiplier Category comprises the following implementation contracts:

  • NoVirtualLockMultiplierFacet
  • IntervalVirtualLockMultiplierFacet
  • ContinuousVirtualLockMultiplierFacet

This category is dependent on the Reward Distribution category, meaning the implementation selected from this category relies on the implementation chosen from the Reward Distribution category. Unlike other dependencies, terms like loosely or highly are not used here to emphasize the distinct compatibility constraints. Some Reward Distribution implementations work with either the Continuous or Interval Lock Multiplier, while others are only compatible with the No Lock Multiplier implementation.

All platforms (use case diamonds) must mandatorily have one implementation of this category as a facet, chosen based on the selected Reward Distribution facet and whether multipliers for lock periods (if supported) are needed, as well as how such multipliers should be calculated within the platform's staking campaigns.

Withdrawal Variation (mandatory & independent)

The Withdrawal Variation Category consists exclusively of the LockCheckerWithdrawalVariationFacet implementation contract.

All platforms (use case diamonds) must mandatorily have the LockCheckerWithdrawalVariationFacet as a facet.

In the future, additional implementations for this category would enable platforms to support schemas for penalties in staking campaigns, such as early withdrawals.

Transfer Input (mandatory & independent)

The Transfer Input Category comprises the following implementation contracts:

  1. Mutually Exclusive Input Facets
    • Erc20InputFacet
    • Erc1155InputFacet
  2. Pairing Input Facets
    • TransferInputMixer
    • Erc20InputExplicitFacet
    • Erc1155InputExplicitFacet

This category is independent of all other existing categories, meaning the implementation selected from this category does not depend on implementations chosen from other categories.

There are two valid configuration options:

  1. Mutually Exclusive Facet:

    Either the Erc20InputFacet OR the Erc1155InputFacet must be added as a facet. This configuration will result in a platform that supports staking campaigns that accept as input (staked assets) either only ERC20 (if Erc20InputFacet is selected) or only ERC1155 tokens (if Erc1155InputFacet is selected).

  2. Pairing Facets:

    Both Erc20InputExplicitFacet and Erc1155InputExplicitFacet , along with the TransferInputMixer . This configuration will result in a platform that supports staking campaigns that accept (staked assets) ERC20, or ERC1155, or both ERC20 and ERC1155 tokens as input.

In the future, additional Erc__InputExplicit Facets for this category would allow platforms to support staking campaigns with other token types as input.

Transfer Reward (mandatory & independent)

The Transfer Reward Category comprises the following implementation contracts:

  1. Mutually Exclusive Reward Facets
    • Erc20RewardMinterFacet
    • Erc20RewardTransferFacet
    • Erc1155RewardMinterFacet
    • Erc1155RewardTransferFacet
  2. Pairing Reward Facets
  • TransferRewardMixer
  • Erc20RewardMinterExplicitFacet
  • Erc20RewardTransferExplicitFacet
  • Erc1155RewardMinterExplicitFacet
  • Erc1155RewardTransferExplicitFacet

This category is independent of all other existing categories, meaning the implementation selected from this category does not depend on implementations chosen from other categories.

There are two valid configuration options:

  1. Mutually Exclusive Facet: One of the following facets must be added: Erc20RewardMinterFacet, Erc20RewardTransferFacet, Erc1155RewardMinterFacet, or Erc1155RewardTransferFacet. This configuration supports staking campaigns that provide rewards as either only ERC20 tokens (via minting or transfer if Erc20 Minter or Erc20 Transfer version is selected respectively) or only ERC1155 tokens (via minting or transfer if Erc1155 Minter or Erc1155 Transfer version is selected respectively).
  2. Pairing Facets: Add the TransferRewardMixer along with any combination of the Explicit facets (Erc20RewardMinterExplicitFacet, Erc20RewardTransferExplicitFacet, Erc1155RewardMinterExplicitFacet, Erc1155RewardTransferExplicitFacet). This configuration enables staking campaigns that distribute rewards as ERC20, ERC1155, or both token types, using flexible minting or transfer mechanics.

In the future, additional Erc__RewardExplicit Facets for this category would allow platforms to support staking campaigns with other token types as rewards.

Previous

Combining NID and Non-NID Skeletons

Next

Campaign Creation

On this page

Foundational Configuration Templates1. Both Skeletons Without Leveraging Compilot—NID2. Only the Staking Skeleton is leveraging Compilot—NID3. Only the Campaign Creation Skeleton is leveraging Compilot—NID4. Both Skeletons are leveraging Compilot—NIDComprehensive Configuration TemplatesRateBasedLockRateBasedOpenPreStakeComplexFeatured Categories of Facets & Inter-RelationsSkeletons (mandatory & independent)ERC721 (mandatory & independent)Generic (mandatory & independent)Creator Eligibility (non mandatory — excluded on condition)Staker Eligibility (non mandatory — excluded on condition)Rewards Distribution (mandatory)Campaign Amounts (mandatory & independent)Campaign Times (mandatory & highly dependent)Lock Variations (mandatory & loosely dependent)Virtual Amount Multiplier (mandatory & independent)Virtual Lock Multiplier (mandatory & dependent)Withdrawal Variation (mandatory & independent)Transfer Input (mandatory & independent)Transfer Reward (mandatory & independent)