Operations

Token operations are used to affect the token balance of an account of a customer in some way. Some types of operations need the consent of the customer and some do not. Consent is given by the customer through signing with the secret key of their account.

NOTE

The functionality of fiat operations like transferring fiat currency to your trust bank account, or from your trust bank account to a customer's bank account, does not sit within Nexus, and needs to be implemented on the client's side if needed.

Types

We have 4 different types of token operations.

NOTE

The different states that fundings and payouts can be in allow for a 4-eye principle to be applied in the portal, given that your operators' permissions and roles are set up correctly.

Funding

A funding operation consists of a customer optionally transferring fiat currency to your trust bank account in return for tokens, depending on your business model. In an exemplary scenario, the customers would select on your interface which payment method they want to use to send the fiat currency; once the payment has been executed, new tokens will be issued by you and assigned to the balance in their account. The consent of the customer is not needed to process a funding operation.

The funding process is organized into a series of defined states, each indicating the current position of a funding operation within the workflow. The following diagram illustrates the full flow, with explanations provided for each stage.

Funding Confirming: This status allows you to request a funding to be created but not initiated just yet. You (or preferably a second person) then have the option to either confirm the request, so it moves to an initiated state, or to even place the request on hold if additional consideration is needed.
Funding On Hold: After a funding's creation was requested but was not yet initiated, it will be in a confirming state. From there, you have the option to place it on hold. This state indicates that the process of receiving the fiat value of the funding from the customer has been placed on hold due to some circumstances that need further investigation. After being placed on hold, the funding can either be set back to confirming or declined.
Funding Declined: A funding in an on hold state can be declined, if it has been decided to decline the receiving of the fiat value of the funding from the customer, or if the fiat value was never received at all. This is an end state.
Initiated: A funding in an initiated state is awaiting to be processed by submitting its signed envelope.
Pending: After an initiated funding has been signed and submitted, it goes into a pending state while we ensure the success or failure on the related blockchain, if needed.
Cancelled: If the funding's envelope expires before being signed and submitted, the operation's status will be set to cancelled. This is an end state and the operation cannot be retried.
Submission Failed: The funding's envelope was submitted but submission failed. This is an end state and the operation cannot be retried.
Submission Completed: The funding's envelope was submitted and was successful. This is an end state.

Payment

The concept of payment in the tokenization model refers to the exchange of value through transfers of tokens. For instance, if a merchant supports one of your tokens, customers owning the same token could buy goods from them. The merchant could show a QR code, which embeds the address of his own wallet and potential additional information such as the price. Once the customer scans it and confirms the payment, the tokens will be subtracted from the customer's account and added to the merchant's one. The consent of the customer who is sending the tokens, is needed to process the payment. The merchant who is receiving the tokens do not have to give consent.

See below the flow of a clawback operation and its different states explained.

Initiated: A payment in an initiated state is awaiting to be processed by submitting its signed envelope.
Pending: After an initiated payment has been signed and submitted, it goes into a pending state while we ensure the success or failure on the related blockchain, if needed.
Cancelled: If the payment's envelope expires before being signed and submitted, the operation's status will be set to cancelled. This is an end state and the operation cannot be retried.
Submission Failed: The payment's envelope was submitted but submission failed. This is an end state and the operation cannot be retried.
Submission Completed: The payment's envelope was submitted and was successful. This is an end state.

Payout

A payout transaction should be carried out once a customer or merchant decides to cash out their tokens, optionally, in exchange for fiat currency, depending on your business model. When the request is processed, the tokens will be removed from the customer or merchant, and will so be deleted ("burned"), and the corresponding amount in fiat currency will be sent to the customer or merchant, depending on the payment method they set up in their account. The consent of the customer or merchant is needed to process a payout operation.

NOTE

Due to MICA Regulations, defining a minimum on the redemption amount of EMTs is not allowed. Hence, a payout with a fiat value less than the fees will be allowed, but will be set to 0, and the fee will be adjusted, not according to what is configured, but to what is available.

The diagram below provides an overview of the payout process, illustrating each stage in the workflow. A detailed explanation of each state follows.

Initiated: A payout in an initiated state is awaiting to be processed by submitting its signed envelope.
Pending: After an initiated payout has been signed and submitted, it goes into a pending state while we ensure the success or failure on the related blockchain, if needed.
Cancelled: If the payout's envelope expires before being signed and submitted, the operation's status will be set to cancelled. This is an end state and the operation cannot be retried.
Submission Failed: The operation's envelope was submitted but submission failed. This is an end state and the operation cannot be retried.
To Payout: The payout's envelope was submitted successfully. Payouts use this status instead of being set to completed immediately because submission is not necessarily the final step for the payout. An optional fiat transaction may still need to occur after the request was successfully submitted and completed. Additionally, enabling the Create External Payout and Payments feature could also cause payouts to automatically be created in Nexus in this state.
Payout Confirming: After a payout's submission was completed, it could be moved to this state to indicate that it is in the process of paying out the fiat value of the payout to the customer.
Payout Completed: This state indicates that a payout's fiat value has been paid out to the customer. This is an end state.
Payout On Hold: After a payout's submission was completed, this state indicates that the process of paying out the fiat value of the payout to the customer has been placed on hold due to some circumstances. Enabling the Create External Payout and Payments feature could also cause payouts to automatically be created in Nexus in this state, if some validation prevented it from being created with a To Payout status. Any payout placed in an on hold state will always include an accompanying operation comment that explains the reason for the hold.
Payout Declined: A payout in an on hold state can be declined if it has been decided to withhold the paying out of the fiat value of the payout to the customer. This is an end state.

Clawback

A clawback operation is similar to a payout operation in the sense that tokens will be removed from a customer, but with the difference that this is not by the request of the customer and that a fiat exchange is not expected for the clawed back tokens. When the request is processed, the tokens will be deleted ("burned") and no corresponding amount in fiat currency will be sent to the customer. Another difference to the payout operation is where the payout operation needs the consent (signature) of the customer to process the operation, it is not needed for a clawback operation.

See below the flow of a clawback operation and its different states explained.

Initiated: A clawback in an initiated state is awaiting to be internally signed and submitted.
Pending: After an initiated clawback has been internally signed and submitted, it goes into a pending state while we ensure the success or failure on the related blockchain, if needed.
Submission Failed: The clawback's envelope was submitted but submission failed. This is an end state and the operation cannot be retried.
Submission Completed: The clawback's envelope was submitted and was successful. This is an end state.

Comments

Comments on operations can be created, updated and viewed on a separate tab when viewing that operation in the portal. They can also be retrieved per customer through our comment specific APIs and created through the update operation API. History of comment updates through the portal will be stored and can also be viewed and retrieved.