Struct pallet_fund_admin::pallet::Pallet

pub struct Pallet<T>(_);

The pallet implementing the on-chain logic.

Implementations

impl<T: Config> Pallet<T>

pub fn do_initial_setup() -> DispatchResult

pub fn do_sudo_add_administrator( admin: T::AccountId, name: BoundedVec<u8, ConstU32<100>> ) -> DispatchResult

pub fn do_sudo_remove_administrator(admin: T::AccountId) -> DispatchResult

pub fn do_create_project( admin: T::AccountId, title: BoundedVec<u8, ConstU32<100>>, description: BoundedVec<u8, ConstU32<400>>, image: Option<BoundedVec<u8, ConstU32<100>>>, address: BoundedVec<u8, ConstU32<100>>, banks: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxBanksPerProject>>, creation_date: u64, completion_date: u64, expenditures: BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<ExpenditureType>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>, job_eligibles: Option<BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>>, users: Option<BoundedVec<(<T as Config>::AccountId, ProxyRole, AssignAction), <T as Config>::MaxRegistrationsAtTime>>, private_group_id: BoundedVec<u8, ConstU32<400>> ) -> DispatchResult

pub fn do_edit_project( admin: T::AccountId, project_id: [u8; 32], title: Option<BoundedVec<u8, ConstU32<100>>>, description: Option<BoundedVec<u8, ConstU32<400>>>, image: Option<BoundedVec<u8, ConstU32<100>>>, address: Option<BoundedVec<u8, ConstU32<100>>>, banks: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxBanksPerProject>>, creation_date: Option<u64>, completion_date: Option<u64> ) -> DispatchResult

pub fn do_delete_project( admin: T::AccountId, project_id: [u8; 32] ) -> DispatchResult

pub fn do_execute_assign_users( admin: T::AccountId, project_id: [u8; 32], users: BoundedVec<(<T as Config>::AccountId, ProxyRole, AssignAction), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_execute_users( admin: T::AccountId, users: BoundedVec<(<T as Config>::AccountId, Option<BoundedVec<u8, ConstU32<100>>>, Option<ProxyRole>, CUDAction), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_edit_user( user: T::AccountId, name: Option<BoundedVec<u8, ConstU32<100>>>, image: Option<BoundedVec<u8, ConstU32<100>>>, email: Option<BoundedVec<u8, ConstU32<100>>>, documents: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>> ) -> DispatchResult

Editing your own user data does not require any kind of RBAC permissions, it only requires that the user is registered. This is because permissions are granted to the user’s account when the user is assigned to a project.

WARNING: Editing your own user data does not allow you to change your role. Only the administrator can do it usign the users extrinsic.

pub fn do_execute_expenditures( admin: T::AccountId, project_id: [u8; 32], expenditures: BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<ExpenditureType>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_submit_drawdown( user: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32] ) -> DispatchResult

pub fn do_approve_drawdown( admin: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32] ) -> DispatchResult

pub fn do_reject_drawdown( admin: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32], transactions_feedback: Option<BoundedVec<([u8; 32], BoundedVec<u8, ConstU32<400>>), <T as Config>::MaxRegistrationsAtTime>>, drawdown_feedback: Option<BoundedVec<u8, ConstU32<400>>> ) -> DispatchResult

pub fn do_reset_drawdown( user: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32] ) -> DispatchResult

pub fn do_execute_transactions( user: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32], transactions: BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_up_bulk_upload( user: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32], description: BoundedVec<u8, ConstU32<400>>, total_amount: u64, documents: BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments> ) -> DispatchResult

pub fn do_execute_inflation_adjustment( admin: T::AccountId, projects: BoundedVec<([u8; 32], Option<u32>, CUDAction), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_execute_job_eligibles( admin: T::AccountId, project_id: [u8; 32], job_eligibles: BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_execute_revenue_transactions( user: T::AccountId, project_id: [u8; 32], revenue_id: [u8; 32], revenue_transactions: BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_submit_revenue( user: T::AccountId, project_id: [u8; 32], revenue_id: [u8; 32] ) -> DispatchResult

pub fn do_approve_revenue( admin: T::AccountId, project_id: [u8; 32], revenue_id: [u8; 32] ) -> DispatchResult

pub fn do_reject_revenue( admin: T::AccountId, project_id: [u8; 32], revenue_id: [u8; 32], revenue_transactions_feedback: BoundedVec<([u8; 32], BoundedVec<u8, ConstU32<400>>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_bank_confirming_documents( admin: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32], confirming_documents: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, action: CUDAction ) -> DispatchResult

pub fn pallet_id() -> IdOrVec

Get the pallet_id

pub fn get_global_scope() -> [u8; 32]

Get global scope

pub fn remove_project_role( project_id: [u8; 32], user: T::AccountId, role: ProxyRole ) -> DispatchResult

pub fn is_authorized( authority: T::AccountId, scope: &[u8; 32], permission: ProxyPermission ) -> DispatchResult

Checks if the caller has the permission to perform an action

• This version of is_authorized checks if the caller is an Administrator and if so, it checks the global scope otherwise it checks the project scope
• This is useful for functions that are called by both administrators and project users
• Scope is always required. In workflows where the caller is an administrator, we can get it from the helper private function get_global_scope()

pub fn do_recovery_drawdown( user: T::AccountId, project_id: [u8; 32], drawdown_id: [u8; 32], transactions: BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

pub fn do_recovery_revenue( user: T::AccountId, project_id: [u8; 32], revenue_id: [u8; 32], transactions: BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

impl<T: Config> Pallet<T>

pub fn initial_setup(origin: OriginFor<T>) -> DispatchResult

Initialize the pallet by setting the permissions for each role & the global scope

Considerations:

• This function can only be called once
• This function can only be called usinf the sudo pallet

pub fn sudo_add_administrator( origin: OriginFor<T>, admin: T::AccountId, name: BoundedVec<u8, ConstU32<100>> ) -> DispatchResult

Adds an administrator account to the site

Parameters:

• origin: The sudo account
• admin: The administrator account to be added
• name: The name of the administrator account

Considerations:

• This function can only be called using the sudo pallet
• This function is used to add the first administrator to the site
• If the user is already registered, the function will return an error: UserAlreadyRegistered
• This function grants administrator permissions to the user from the rbac pallet
• administrator role have global scope permissions

pub fn sudo_remove_administrator( origin: OriginFor<T>, admin: T::AccountId ) -> DispatchResult

Removes an administrator account from the site

Parameters:

• origin: The sudo account
• admin: The administrator account to be removed

Considerations:

• This function can only be called using the sudo pallet
• This function is used to remove any administrator from the site
• If the user is not registered, the function will return an error: UserNotFound
• This function removes administrator permissions of the user from the rbac pallet

Note:

WARNING: Administrators can remove themselves from the site, but they can add themselves back

pub fn users( origin: OriginFor<T>, users: BoundedVec<(<T as Config>::AccountId, Option<BoundedVec<u8, ConstU32<100>>>, Option<ProxyRole>, CUDAction), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

This extrinsic is used to create, update, or delete a user account

Parameters:

• origin: The administrator account
• user: The target user account to be registered, updated, or deleted. It is an array of user accounts where each entry it should be a tuple of the following:
• 0: The user account
• 1: The user name
• 2: The user role
• 3: The CUD operation to be performed on the user account. CUD action is ALWAYS required.

Considerations:

• Users parameters are optional because depends on the CUD action as follows:

• Create: The user account, user name, user role & CUD action are required
• Update: The user account & CUD action are required. The user name & user role are optionals.
• Delete: The user account & CUD action are required.

• This function can only be called by an administrator account
• Multiple users can be registered, updated, or deleted at the same time, but the user account must be unique. Multiple actions over the same user account in the same call, it could result in an unexpected behavior.
• If the user is already registered, the function will return an error: UserAlreadyRegistered
• If the user is not registered, the function will return an error: UserNotFound

Note:

• WARNING: It is possible to register, update, or delete administrators accounts using this extrinsic, but administrators can not delete themselves.
• WARNING: This function only registers, updates, or deletes users from the site.
• WARNING: The only way to grant or remove permissions of a user account is assigning or unassigning a user from a selected project.

pub fn users_edit_user( origin: OriginFor<T>, name: Option<BoundedVec<u8, ConstU32<100>>>, image: Option<BoundedVec<u8, ConstU32<100>>>, email: Option<BoundedVec<u8, ConstU32<100>>>, documents: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>> ) -> DispatchResult

Edits an user account

Parameters:

• origin: The user account which is being edited
• name: The name of the user account which is being edited
• image: The image of the user account which is being edited
• email: The email of the user account which is being edited
• documents: The documents of the user account which is being edited. ONLY available for the investor role.

Considerations:

• If the user is not registered, the function will return an error: UserNotFound
• This function can only be called by a registered user account
• This function will be called by the user account itself
• ALL parameters are optional because depends on what is being edited
• ONLY the investor role can edit or update the documents

pub fn projects_create_project( origin: OriginFor<T>, title: BoundedVec<u8, ConstU32<100>>, description: BoundedVec<u8, ConstU32<400>>, image: Option<BoundedVec<u8, ConstU32<100>>>, address: BoundedVec<u8, ConstU32<100>>, banks: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), T::MaxBanksPerProject>>, creation_date: u64, completion_date: u64, expenditures: BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<ExpenditureType>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>, job_eligibles: Option<BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>>, users: Option<BoundedVec<(<T as Config>::AccountId, ProxyRole, AssignAction), <T as Config>::MaxRegistrationsAtTime>>, private_group_id: BoundedVec<u8, ConstU32<400>> ) -> DispatchResult

Registers a new project.

Parameters:

• origin: The administrator account
• title: The title of the project
• description: The description of the project
• image: The image of the project (CID)
• address: The address of the project
• creation_date: The creation date of the project
• completion_date: The completion date of the project
• expenditures: The expenditures of the project. It is an array of tuples where each entry is a tuple of the following:

• 0: The expenditure name
• 1: The expenditure type
• 2: The expenditure amount
• 3: The expenditure NAICS code
• 4: The expenditure jobs multiplier
• 5: The CUD action to be performed on the expenditure. CUD action is ALWAYS required.
• 6: The expenditure id. It is optional because it is only required when updating or deleting

• job_eligibles: The job eligibles to be created/updated/deleted. This is a vector of tuples where each entry is composed by:

• 0: The job eligible name
• 1: The amount of the job eligible
• 2: The NAICS code of the job eligible
• 3: The jobs multiplier of the job eligible
• 4: The job eligible action to be performed. (Create, Update or Delete)
• 5: The job eligible id. This is only used when updating or deleting a job eligible.

• users: The users who will be assigned to the project. It is an array of tuples where each entry is a tuple of the following:

• 0: The user account
• 1: The user role
• 2: The AssignAction to be performed on the user.

Considerations:

• This function can only be called by an administrator account
• For users assignation, the user account must be registered. If the user is not registered, the function will return an error. ALL parameters are required.
• For expenditures, apart from the expenditure id, naics code & jopbs multiplier, ALL parameters are required because for this flow, the expenditures are always created. The naics code & the jobs multiplier can be added later by the administrator.
• Creating a project will automatically create a scope for the project.

Note:

WARNING: If users are provided, the function will assign the users to the project, granting them permissions in the rbac pallet.

pub fn projects_edit_project( origin: OriginFor<T>, project_id: [u8; 32], title: Option<BoundedVec<u8, ConstU32<100>>>, description: Option<BoundedVec<u8, ConstU32<400>>>, image: Option<BoundedVec<u8, ConstU32<100>>>, address: Option<BoundedVec<u8, ConstU32<100>>>, banks: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), T::MaxBanksPerProject>>, creation_date: Option<u64>, completion_date: Option<u64> ) -> DispatchResult

Edits a project.

Parameters:

• origin: The administrator account
• project_id: The selected project id that will be edited
• title: The title of the project to be edited
• description: The description of the project to be edited
• image: The image of the project to be edited
• address: The address of the project to be edited
• creation_date: The creation date of the project to be edited
• completion_date: The completion date of the project to be edited

Considerations:

• This function can only be called by an administrator account
• ALL parameters are optional because depends on what is being edited
• The project id is required because it is the only way to identify the project
• The project id must be registered. If the project is not registered, the function will return an error: ProjectNotFound
• It is not possible to edit the expenditures or the users assigned to the project through this function. For that, the administrator must use the extrinsics:

• expenditures
• projects_assign_user

• Project can only be edited in the Started status
• Completion date must be greater than creation date

pub fn projects_delete_project( origin: OriginFor<T>, project_id: [u8; 32] ) -> DispatchResult

Deletes a project.

Parameters:

• origin: The administrator account
• project_id: The selected project id that will be deleted

Considerations:

• This function can only be called by an administrator account
• The project id is required because it is the only way to identify the project
• The project id must be registered. If the project is not registered, the function will return an error: ProjectNotFound

Note:

• WARNING: Deleting a project will also delete ALL stored information associated with the project. BE CAREFUL.

pub fn projects_assign_user( origin: OriginFor<T>, project_id: [u8; 32], users: BoundedVec<(<T as Config>::AccountId, ProxyRole, AssignAction), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

Assigns a user to a project.

Parameters:

• origin: The administrator account
• project_id: The selected project id where user will be assigned
• users: The users to be assigned to the project. This is a vector of tuples where each entry is composed by:

• 0: The user account id
• 1: The user role
• 2: The AssignAction to be performed. (Assign or Unassign)

Considerations:

• This function can only be called by an administrator account
• This extrinsic allows multiple users to be assigned/unassigned at the same time.
• The project id is required because it is the only way to identify the project
• This extrinsic is used for both assigning and unassigning users to a project depending on the AssignAction.
• After a user is assigned to a project, the user will be able to perform actions in the project depending on the role assigned to the user.
• After a user is unassigned from a project, the user will not be able to perform actions in the project anymore.
• If the user is already assigned to the project, the function will return an error.

Note:

• WARNING: ALL provided users needs to be registered in the site. If any of the users is not registered, the function will return an error.
• Assigning or unassigning a user to a project will add or remove permissions to the user from the RBAC pallet.
• Warning: Cannot assign a user to a project with a different role than the one they have in UsersInfo. If the user has a different role, the function will return an error.
• Warning: Cannot unassign a user from a project with a different role than the one they have in UsersInfo. If the user has a different role, the function will return an error.
• Warning: Do not perform multiple actions over the same user in the same call, it could result in an unexpected behavior.

pub fn expenditures_and_job_eligibles( origin: OriginFor<T>, project_id: [u8; 32], expenditures: Option<BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<ExpenditureType>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>>, job_eligibles: Option<BoundedVec<(Option<BoundedVec<u8, ConstU32<100>>>, Option<u64>, Option<BoundedVec<u8, ConstU32<400>>>, Option<u32>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>> ) -> DispatchResult

This extrinsic is used to create, update or delete expenditures & job eligibles.

Parameters:

• origin: The administrator account
• project_id: The selected project id where the expenditures will be created/updated/deleted
• expenditures: The expenditures to be created/updated/deleted. This is a vector of tuples where each entry is composed by:

• 0: The name of the expenditure
• 1: The expenditure type
• 2: The amount of the expenditure
• 3: The naics code of the expenditure
• 4: The jobs multiplier of the expenditure
• 5: The expenditure action to be performed. (Create, Update or Delete)
• 6: The expenditure id. This is only used when updating or deleting an expenditure.

• job_eligibles: The job eligibles to be created/updated/deleted. This is a vector of tuples where each entry is composed by:

• 0: The job eligible name
• 1: The amount of the job eligible
• 2: The NAICS code of the job eligible
• 3: The jobs multiplier of the job eligible
• 4: The job eligible action to be performed. (Create, Update or Delete)
• 5: The job eligible id. This is only used when updating or deleting a job eligible.

Considerations:

• Naics code and jobs multiplier are always optional.
• This function can only be called by an administrator account
• This extrinsic allows multiple expenditures to be created/updated/deleted at the same time.
• The project id is required because it is the only way to identify the project
• Expenditure parameters are optional because depends on the action to be performed:

• Create: Name, Type & Amount are required. Nacis code & Jobs multiplier are optional.
• Update: Except for the expenditure id & action, all parameters are optional.
• Delete: Only the expenditure id & action is required.

• Multiple actions can be performed at the same time. For example, you can create a new expenditure and update another one at the same time.
• Do not perform multiple actions over the same expenditure in the same call, it could result in an unexpected behavior.

pub fn submit_drawdown( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32], transactions: Option<BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>>, submit: bool ) -> DispatchResult

Submit a drawdown This extrinsic is used to create, update or delete transactions. It also allows that an array of transactions to be saved as a draft or as submitted.

Parameters:

• origin: The user account who is creating the transactions
• project_id: The selected project id where the transactions will be created
• drawdown_id: The selected drawdown id where the transactions will be created
• transactions: The transactions to be created/updated/deleted. This entry is a vector of tuples where each entry is composed by:

• 0: The expenditure id where the transaction will be created
• 1: The amount of the transaction
• 2: Documents associated to the transaction
• 3: The action to be performed on the transaction. (Create, Update or Delete)
• 4: The transaction id. This is only used when updating or deleting a transaction.

• submit: If true, transactions associated to the selected drawdown will be submitted to the administrator. If false, the array of transactions will be saved as a draft.

Considerations:

• This function is only callable by a builder role account
• This extrinsic allows multiple transactions to be created/updated/deleted at the same time.
• The project id and drawdown id are required for the reports.
• Transaction parameters are optional because depends on the action to be performed:

• Create: Expenditure id, Amount, Documents & action are required.
• Update: Except for the transaction id & action, all other parameters are optional.
• Delete: Only the transaction id & action are required.

• Multiple actions can be performed at the same time, but each must be performed on a different transaction. For example, you can create a new transaction and update another one at the same time.
• Do not perform multiple actions over the same transaction in the same call, it could result in an unexpected behavior.
• If a drawdown is submitted, all transactions must be submitted too. If the drawdown do not contain any transaction, it will return an error.
• After a drawdown is submitted, it can not be updated or deleted.
• After a drawdown is rejected, builders will use again this extrinsic to update the transactions associated to a given drawdown.

pub fn approve_drawdown( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32], bulkupload: Option<bool>, transactions: Option<BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>> ) -> DispatchResult

Approve a drawdown

Parameters:

For EB5 drawdowns:

• origin: The administrator account who is approving the drawdown
• project_id: The selected project id where the drawdown will be approved
• drawdown_id: The selected drawdown id to be approved

For Construction Loan & Developer Equity (bulk uploads) drawdowns:

• origin: The administrator account who is approving the drawdown
• project_id: The selected project id where the drawdown will be approved
• drawdown_id: The selected drawdown id to be approved.
• bulkupload: Optional bulkupload parameter. If true, the drawdown will be saved in a pseudo draft status. If false, the drawdown will be approved directly.
• transactions: The transactions to be created/updated/deleted. This is a vector of tuples where each entry is composed by:

• 0: The expenditure id where the transaction will be created
• 1: The transaction amount
• 2: Documents associated to the transaction
• 3: The transaction action to be performed. (Create, Update or Delete)
• 4: The transaction id. This is only used when updating or deleting a transaction.

• This extrinsic allows multiple transactions to be created/updated/deleted at the same time (only for Construction Loan & Developer Equity drawdowns).
• Transaction parameters are optional because depends on the action to be performed:

• Create: Expenditure id, Amount, Documents & action are required.
• Update: Except for the transaction id & action, all parameters are optional.
• Delete: Only the transaction id & action are required.

• Multiple actions can be performed at the same time. For example, you can create a new transaction and update another one at the same time (only for Construction Loan & Developer Equity drawdowns).
• Do not perform multiple actions over the same transaction in the same call, it could result in an unexpected behavior (only for Construction Loan & Developer Equity drawdowns).

Considerations:

• This function is only callable by an administrator account
• All transactions associated to the drawdown will be approved too. It’s not possible to approve a drawdown without approving all of its transactions.
• After a drawdown is approved, it can not be updated or deleted.
• After a drawdown is approved, the next drawdown will be automatically created.
• The drawdown status will be updated to “Approved” after the extrinsic is executed.
• After a drawdown is rejected, administrators will use again this extrinsic to approve the new drawdown version uploaded by the builder.

pub fn reject_drawdown( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32], transactions_feedback: Option<BoundedVec<([u8; 32], BoundedVec<u8, ConstU32<400>>), <T as Config>::MaxRegistrationsAtTime>>, drawdown_feedback: Option<BoundedVec<u8, ConstU32<400>>> ) -> DispatchResult

Reject a drawdown

Parameters:

• origin: The administrator account who is rejecting the drawdown
• project_id: The selected project id where the drawdown will be rejected
• drawdown_id: The selected drawdown id to be rejected

Then the next two feedback parameters are optional because depends on the drawdown type:

EB5 drawdowns:

• transactions_feedback: Administrator will provide feedback for each rejected transacion. This is a vector of tuples where each entry is composed by:

• 0: The transaction id
• 1: The transaction feedback

Construction Loan & Developer Equity drawdowns:

• drawdown_feedback: Administrator will provide feedback for the WHOLE drawdown.

Considerations:

• This function can only be called by an administrator account
• All transactions associated to the drawdown will be rejected too. It’s not possible to reject a drawdown without rejecting all of its transactions. (only for EB5 drawdowns).
• For EB5 drawdowns, the administrator needs to provide feedback for each rejected transaction.
• For Construction Loan & Developer Equity drawdowns, the administrator can provide feedback for the WHOLE drawdown.
• After a builder re-submits a drawdown, the administrator will have to review the drawdown again.
• After a builder re-submits a drawdown, the feedback field will be cleared automatically.
• If a single EB5 transaction is wrong, the administrator WILL reject the WHOLE drawdown. There is no way to reject a single transaction.

pub fn up_bulkupload( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32], description: BoundedVec<u8, ConstU32<400>>, total_amount: u64, documents: BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments> ) -> DispatchResult

Bulk upload drawdowns.

Parameters:

• origin: The administrator account who is uploading the drawdowns
• project_id: The selected project id where the drawdowns will be uploaded
• drawdown_id: The drawdowns to be uploaded
• description: The description of the drawdown provided by the builder
• total_amount: The total amount of the drawdown
• documents: The documents provided by the builder for the drawdown

Considerations:

• This function can only be called by a builder account
• This extrinsic allows only one drawdown to be uploaded at the same time.
• The drawdown will be automatically submitted.
• Only available for Construction Loan & Developer Equity drawdowns.
• After a builder uploads a drawdown, the administrator will have to review it.
• After a builder re-submits a drawdown, the feedback field will be cleared automatically.
• Bulkuploads does not allow individual transactions.
• After a builder uploads a drawdown, the administrator will have to insert each transaction manually.

pub fn inflation_rate( origin: OriginFor<T>, projects: BoundedVec<([u8; 32], Option<u32>, CUDAction), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

Modifies the inflation rate of a project.

Parameters:

• origin: The administrator account who is modifying the inflation rate
• projects: The projects where the inflation rate will be modified. This is a vector of tuples where each entry is composed by:

• 0: The project id
• 1: The inflation rate
• 2: The action to be performed (Create, Update or Delete)

Considerations:

• This function can only be called by an administrator account
• This extrinsic allows multiple projects to be modified at the same time.
• The inflation rate can be created, updated or deleted.
• The inflation rate is optional because depends on the CUDAction parameter:

• Create: The inflation rate will be created. Project id, inflation rate and action are required.
• Update: The inflation rate will be updated. Project id, inflation rate and action are required.
• Delete: The inflation rate will be deleted. Project id and action are required.

• The inflation rate can only be modified if the project is in the “started” status.

pub fn submit_revenue( origin: OriginFor<T>, project_id: [u8; 32], revenue_id: [u8; 32], revenue_transactions: Option<BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime>>, submit: bool ) -> DispatchResult

This extrinsic is used to create, update or delete revenue transactions. It also allows that an array of revenue transactions to be saved as a draft or as submitted.

Parameters:

*/ - origin: The user account who is creating the revenue transactions

• project_id: The selected project id where the revenue transactions will be created
• revenue_id: The selected revenue id where the revenue transactions will be created
• revenue_transactions: The revenue transactions to be created/updated/deleted. This entry is a vector of tuples where each entry is composed by:

• 0: The job eligible id where the revenue transaction will be created
• 1: The amount of the revenue transaction
• 2: Documents associated to the revenue transaction
• 3: The action to be performed on the revenue transaction (Create, Update or Delete)
• 4: The revenue transaction id. This is required only if the action is being updated or deleted.

• submit: If true, the array of revenue transactions will be submitted to the administrator. If false, the array of revenue transactions will be saved as a draft.

Considerations:

• This function is only callable by a builder role account
• This extrinsic allows multiple revenue transactions to be created/updated/deleted at the same time.
• The project id and revenue id are required for the reports.
• revenue_transactions parameters are optional because depends on the action to be performed:

• Create: Job eligible id, Amount, Documents & action are required.
• Update: Except for the revenue transaction id & action, all other parameters are optional.
• Delete: Only the revenue transaction id & action are required.

• Multiple actions can be performed at the same time, but each must be performed on a different transaction. For example, you can create a new transaction and update another one at the same time.
• Do not perform multiple actions over the same transaction in the same call, it could result in an unexpected behavior.
• If a revenue is submitted, all transactions must be submitted too. If the revenue do not contain any transaction, it will return an error.
• After a revenue is submitted, it can not be updated or deleted.
• After a revenue is rejected, builders will use again this extrinsic to update the transactions associated to a given revenue.

pub fn approve_revenue( origin: OriginFor<T>, project_id: [u8; 32], revenue_id: [u8; 32] ) -> DispatchResult

Approve a revenue

Parameters:

• origin: The administrator account who is approving the revenue
• project_id: The selected project id where the revenue will be approved
• revenue_id: The selected revenue id to be approved

Considerations:

• This function is only callable by an administrator role account
• All transactions associated to the revenue will be approved too. It’s not possible to approve a revenue without approving all of its transactions.
• After a revenue is approved, it can not be updated or deleted.
• After a revenue is approved, the next revenue will be created automatically.
• After a revenue is rejected, administrators will use again this extrinsic to approve the rejected revenue new revenue version uploaded by the builder.
• The revenue status will be updated to Approved.

pub fn reject_revenue( origin: OriginFor<T>, project_id: [u8; 32], revenue_id: [u8; 32], revenue_transactions_feedback: BoundedVec<([u8; 32], BoundedVec<u8, ConstU32<400>>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

Reject a revenue

Parameters:

• origin: The administrator account who is rejecting the revenue
• project_id: The selected project id where the revenue will be rejected
• revenue_id: The selected revenue id to be rejected
• revenue_transactions_feedback: Administrator will provide feedback for each rejected transacion. This is a vector of tuples where each entry is composed by:

• 0: The revenue transaction id
• 1: The revenue transaction feedback

Considerations:

• This function is only callable by an administrator role account
• All transactions associated to the revenue will be rejected too. It’s not possible to reject a revenue without rejecting all of its transactions.
• Administrator needs to provide a feedback for each rejected transaction.
• After a builder re-submits a revenue, the feedback field will be cleared automatically.
• If a single revenue transaction is wrong, the administrator WILL reject the WHOLE revenue. There is no way to reject a single revenue transaction.

pub fn bank_confirming_documents( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32], confirming_documents: Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, action: CUDAction ) -> DispatchResult

The following extrinsic is used to upload the bank confirming documents for a given drawdown.

Parameters:

• origin: The administrator account who is uploading the confirming documents
• project_id: The selected project id where the drawdown exists
• drawdown_id: The selected drawdown id where the confirming documents will be uploaded
• confirming_documents: The confirming documents to be uploaded. This field is optional because are required only when the action is Create or Update.
• action: The action to be performed. It can be Create, Update or Delete
  • Create: project_id, drawdown_id and confirming_documents are required
  • Update: project_id, drawdown_id and confirming_documents are required
  • Delete: project_id and drawdown_id are required

Considerations:

• This function is only callable by an administrator role account
• The confirming documents are required only when the action is Create or Update.
• The confirming documents are optional when the action is Delete.
• After the confirming documents are uploaded, the drawdown status will be updated to “Confirmed”. It will also update the status of all of its transactions to “Confirmed”.
• Update action will replace the existing confirming documents with the new ones.
• Delete action will remove the existing confirming documents. It will also update the drawdown status to “Approved” and the status of all of its transactions to “Approved”. It does a rollback of the drawdown.

pub fn reset_drawdown( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32] ) -> DispatchResult

The following extrinsic is used to cancel a drawdown submission.

Parameters:

• origin: The builder account who is cancelling the drawdown submission
• project_id: The selected project id where the drawdown exists
• drawdown_id: The selected drawdown id to be cancelled

Considerations:

• This function is only callable by a builder role account
• The drawdown status will be rolled back to “Draft”.
• All of its transactions will be deleted.
• The whole drawdown will be reset to its initial state, so be careful when using this

pub fn recovery_drawdown( origin: OriginFor<T>, project_id: [u8; 32], drawdown_id: [u8; 32], transactions: BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

Execute a recovery drawdown on a project. This function can only be called by an admin.

Parameters:

• origin: The administrator account who is executing the recovery drawdown
• project_id: The ID of the project from which the recovery drawdown will be executed
• drawdown_id: The ID of the drawdown from which the recovery drawdown will be executed
• transactions: The list of transactions that will be executed in the recovery drawdown

Errors

This function returns an error if:

• The transaction origin is not a signed message from an admin account.
• The project with the given ID does not exist.
• The drawdown with the given ID does not exist.

Considerations:

• This function is only callable by an administrator role account
• The drawdown status won’t be changed

pub fn recovery_revenue( origin: OriginFor<T>, project_id: [u8; 32], revenue_id: [u8; 32], transactions: BoundedVec<(Option<[u8; 32]>, Option<u64>, Option<BoundedVec<(BoundedVec<u8, ConstU32<100>>, BoundedVec<u8, ConstU32<100>>), <T as Config>::MaxDocuments>>, CUDAction, Option<[u8; 32]>), <T as Config>::MaxRegistrationsAtTime> ) -> DispatchResult

Execute a recovery revenue on a project. This function can only be called by an admin.

Parameters:

• origin: The administrator account who is executing the recovery revenue
• project_id: The ID of the project from which the recovery revenue will be executed
• revenue_id: The ID of the revenue from which the recovery revenue will be executed
• transactions: The list of transactions that will be executed in the recovery revenue

Errors

This function returns an error if:

• The transaction origin is not a signed message from an admin account.
• The project with the given ID does not exist.
• The revenue with the given ID does not exist.

Considerations:

• This function is only callable by an administrator role account
• The revenue status won’t be changed

pub fn kill_storage(origin: OriginFor<T>) -> DispatchResult

Kill all the stored data.

This function is used to kill ALL the stored data. Use it with caution!

Parameters:

• origin: The user who performs the action.

Considerations:

• This function is only available to the admin with sudo access.

pub fn set_new_admin_permissions(origin: OriginFor<T>) -> DispatchResult

impl<T: Config> Pallet<T>

pub fn global_scope() -> [u8; 32]

impl<T: Config> Pallet<T>

pub fn users_info<KArg>(k: KArg) -> Option<UserData<T>>where KArg: EncodeLike<T::AccountId>,

impl<T: Config> Pallet<T>

pub fn projects_info<KArg>(k: KArg) -> Option<ProjectData<T>>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn users_by_project<KArg>( k: KArg ) -> BoundedVec<T::AccountId, T::MaxUserPerProject>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn projects_by_user<KArg>( k: KArg ) -> BoundedVec<[u8; 32], T::MaxProjectsPerUser>where KArg: EncodeLike<T::AccountId>,

impl<T: Config> Pallet<T>

pub fn expenditures_info<KArg>(k: KArg) -> Option<ExpenditureData>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn expenditures_by_project<KArg>( k: KArg ) -> BoundedVec<[u8; 32], T::MaxExpendituresPerProject>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn drawdowns_info<KArg>(k: KArg) -> Option<DrawdownData<T>>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn drawdowns_by_project<KArg>( k: KArg ) -> BoundedVec<[u8; 32], T::MaxDrawdownsPerProject>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn transactions_info<KArg>(k: KArg) -> Option<TransactionData<T>>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn transactions_by_drawdown<KArg1, KArg2>( k1: KArg1, k2: KArg2 ) -> BoundedVec<[u8; 32], T::MaxTransactionsPerDrawdown>where KArg1: EncodeLike<[u8; 32]>, KArg2: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn job_eligibles_info<KArg>(k: KArg) -> Option<JobEligibleData>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn job_eligibles_by_project<KArg>( k: KArg ) -> BoundedVec<[u8; 32], T::MaxJobEligiblesByProject>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn revenues_info<KArg>(k: KArg) -> Option<RevenueData<T>>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn revenues_by_project<KArg>( k: KArg ) -> BoundedVec<[u8; 32], T::MaxDrawdownsPerProject>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn revenue_transactions_info<KArg>( k: KArg ) -> Option<RevenueTransactionData<T>>where KArg: EncodeLike<[u8; 32]>,

impl<T: Config> Pallet<T>

pub fn transactions_by_revenue<KArg1, KArg2>( k1: KArg1, k2: KArg2 ) -> BoundedVec<[u8; 32], T::MaxTransactionsPerRevenue>where KArg1: EncodeLike<[u8; 32]>, KArg2: EncodeLike<[u8; 32]>,

Trait Implementations

impl<T: Config> Callable<T> for Pallet<T>

type RuntimeCall = Call<T>

impl<T> Clone for Pallet<T>

fn clone(&self) -> Self

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<T> Debug for Pallet<T>

fn fmt(&self, fmt: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<T: Config> GetStorageVersion for Pallet<T>

fn current_storage_version() -> StorageVersion

Returns the current storage version as supported by the pallet.

fn on_chain_storage_version() -> StorageVersion

Returns the on-chain storage version of the pallet as stored in the storage.

impl<T: Config> Hooks<<T as Config>::BlockNumber> for Pallet<T>

fn on_finalize(_n: BlockNumber)

The block is being finalized. Implement to have something happen.

fn on_idle(_n: BlockNumber, _remaining_weight: Weight) -> Weight

This will be run when the block is being finalized (before on_finalize). Implement to have something happen using the remaining weight. Will not fire if the remaining weight is 0. Return the weight used, the hook will subtract it from current weight used and pass the result to the next on_idle hook if it exists.

fn on_initialize(_n: BlockNumber) -> Weight

The block is being initialized. Implement to have something happen.

fn on_runtime_upgrade() -> Weight

Perform a module upgrade.

fn offchain_worker(_n: BlockNumber)

Implementing this function on a module allows you to perform long-running tasks that make (by default) validators generate transactions that feed results of those long-running computations back on chain.

fn integrity_test()

Run integrity test.

impl<T: Config> IntegrityTest for Pallet<T>

fn integrity_test()

Run integrity test.

impl<T: Config> OffchainWorker<<T as Config>::BlockNumber> for Pallet<T>

fn offchain_worker(n: <T as Config>::BlockNumber)

This function is being called after every block import (when fully synced).

impl<T: Config> OnFinalize<<T as Config>::BlockNumber> for Pallet<T>

fn on_finalize(n: <T as Config>::BlockNumber)

The block is being finalized. Implement to have something happen.

impl<T: Config> OnGenesis for Pallet<T>

fn on_genesis()

Something that should happen at genesis.

impl<T: Config> OnIdle<<T as Config>::BlockNumber> for Pallet<T>

fn on_idle(n: <T as Config>::BlockNumber, remaining_weight: Weight) -> Weight

The block is being finalized. Implement to have something happen in case there is leftover weight. Check the passed remaining_weight to make sure it is high enough to allow for your pallet’s extra computation.

impl<T: Config> OnInitialize<<T as Config>::BlockNumber> for Pallet<T>

fn on_initialize(n: <T as Config>::BlockNumber) -> Weight

The block is being initialized. Implement to have something happen.

impl<T: Config> OnRuntimeUpgrade for Pallet<T>

fn on_runtime_upgrade() -> Weight

Perform a module upgrade.

impl<T: Config> PalletInfoAccess for Pallet<T>

fn index() -> usize

Index of the pallet as configured in the runtime.

fn name() -> &'static str

Name of the pallet as configured in the runtime.

fn module_name() -> &'static str

Name of the Rust module containing the pallet.

fn crate_version() -> CrateVersion

Version of the crate containing the pallet.

impl<T: Config> PalletsInfoAccess for Pallet<T>

fn count() -> usize

The number of pallets’ information that this type represents.

fn infos() -> Vec<PalletInfoData>

All of the pallets’ information that this type represents.

impl<T> PartialEq<Pallet<T>> for Pallet<T>

fn eq(&self, other: &Self) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

This method tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl<T: Config> StorageInfoTrait for Pallet<T>

fn storage_info() -> Vec<StorageInfo>

impl<T: Config> WhitelistedStorageKeys for Pallet<T>

fn whitelisted_storage_keys() -> Vec<TrackedStorageKey>

Returns a Vec<TrackedStorageKey> indicating the storage keys that should be whitelisted during benchmarking. This means that those keys will be excluded from the benchmarking performance calculation.

impl<T> Eq for Pallet<T>