Connectors

Connectors are special facets that specify which existing platform states serve as interference and destination states. Rather than introducing new states, connectors define, in their associated storage, the sets of platform states that control when and how user-driven state transitions can occur.

Depending on the selector, connectors can mediate transitions between states already initialized in the StateFacetStorage. For example, between FRACTIONS_CREATED and PURCHASE states, by enabling conditional approval or rejection transitions.

This conditional mechanism allows the ADMIN or another role with the corresponding permissions to manually decide whether or not the state of the campaign can progress further:

There are different types of connectors that are available both for the Campaign and Campaign with buyback types.

CreateToPurchase Connector

This connector facet type is employed in scenarios where approval is necessary before users can purchase fractions after their creation. Designated accounts have the authority to either approve or reject the purchase phase of campaigns/projects. If the purchase phase is approved, then the campaign’s status progresses from FRACTIONS_CREATED to PURCHASE . Conversely, if the purchase phase is rejected the campaign's status progresses from FRACTIONS_CREATED to REJECTED.

Designated accounts can call the following function exposed by the CreateToPurchase connector to approve the purchase phase of a specified campaign.

/**
 * @notice ApproveFractions
 * @dev Called by designated account(s) to approve the purchase phase of a campaign
 * @param id The ID of the campaign 
 */
 function approveFractions(uint256 id) external;

Designated accounts can call the following function exposed by the CreateToPurchase connector to reject the purchase phase of a specified campaign.

/**
 * @notice RejectFractions
 * @dev Called by designated account(s) to reject the purchase phase of a campaign
 * @param id The ID of the campaign
 */
 function rejectFractions(uint256 id) external;

There are two types of CreateToPurchase connectors available to choose from:

1. CreateToPurchaseRoleApprovalFacet

The respective Diamond’s storage is initialized with the following (ABI-encoded together):

• bytes32[] eligibleRoles : Array with the eligible role(s). Accounts granted these role(s) can approve or reject the purchase phase of campaigns. An administrator will need to grant such role(s) to the desired accounts through the generic AccessControlFacet . This is not needed for the adminRole.
• uint256 interferenceState : The state that campaigns should be (i.e., FRACTIONS_CREATED ) in order for the approval or rejection to take place.
• uint256 approveState : The state that campaigns will progress to, at approval.
• uint256 rejectState : The state that campaigns will progress to, at rejection.

2. CreateToPurchaseAddressAprovalFacet

The respective Diamond’s storage is initialized with the following (ABI-encoded together):

• address[] eligibleAddresses : Array with the address(es) eligible for approving or rejecting the purchase phase of campaigns.
• interferenceState , approveState , rejectState as in the RoleApproval version.

PurchaseToReceive Connector

This connector facet type is employed in scenarios where approval is necessary before the designated recipient can receive funds accumulated during the purchase phase. Designated accounts have the authority to approve the receive phase of campaigns/projects, thus, progressing the status of campaigns (if requirements are met) to RECEIVE.

Designated accounts can call the following function exposed by the PurchaseToReceive connector to approve the receive phase of a specified campaign.

/**
 * @notice ApprovePurchaseComplete
 * @dev Called by designated account(s) to approve the receive phase of a campaign
 * @param id The ID of the campaign
 */
 function approvePurchaseComplete(uint256 id) external;

There are two types of PurchaseToReceiveconnectors available to choose from:

1. PurchaseToReceiveRoleApprovalFacet

   The respective Diamond’s storage is initialized with the following (ABI-encoded together):

   • bytes32[] eligibleRoles : Array with the eligible role(s). Accounts granted these role(s) can approve the receive phase of campaigns. An administrator will need to grant such role(s) to the desired account(s) through the generic AccessControlFacet. This is not needed for the adminRole.
   • uint256 interferenceState : The state that campaigns should be (i.e., PURCHASE ) in order for the approval to take place.
   • uint256 destinationState : The state that campaigns will progress to (i.e., RECEIVE ) at approval.

2. PurchaseToReceiveAddressAprovalFacet

   The respective Diamond’s storage is initialized with the following (ABI-encoded together):

   • address[] eligibleAddresses : Array with the address(es) eligible for approving the receive phase of campaigns.
   • interferenceState, destinationState as in the RoleApproval version.

PurchaseToNonFunded Connector

This sub-connector facet type is employed when NON_FUNDED state is featured in campaigns/projects. Thus, it is added only if NonFunded Sub-Skeleton Facet is integrated.

Accounts can call the following function exposed by the PurchaseToNonFunded sub-connector to set the status of a specified campaign to NON_FUNDED provided that all the necessary requirements are met (e.g., endingTimestamp of purchasePhase has been reached, softCap has not been reached).

/**
 * @notice CheckAndJumpToNonFunded
 * @dev Called by designated account(s) to set the specified campaign as non funded
 * @param id The ID of the campaign
 */
 function checkAndJumpToNonFunded(uint256 id) external;

There is only one type of PurchaseToNonFunded sub-connector available:

1. CheckAndJumpToNonFunded

The respective Diamond’s storage is initialized with the following (ABI-encoded together):

• uint256 interferenceState : The state that campaigns should be (e.g., PURCHASE ) in order for the action to take place.
• uint256 destinationState : The state that campaigns will progress to (e.g., NOT_FUNDED)