Product

Virtual Share Lifecycle

This is the chapter giving the reader an overview of the entire virtual share lifecycle by describing the transactions either issuer or recipient can perform with the virtual shares. Most of the details and controls are omitted for clarity. For details on individual flow steps, see later chapters.

Birth

Virtual share is brought to life in an embryonic state where the initial virtual share pool is created within the Virtual Share Program. Actual birth of virtual shares takes place later, at the moment when they are granted to a recipient.

Virtual shares in the initial pool do not exist, similar to the options in start-ups – there is just an agreement to issue new stock in the future against the option contracts the management board can use. Real implication you should understand is that any virtual share remaining in the initial pool do not participate in any benefit sharing when the program will be triggered.

Grant

Grant expresses the intent from the issuer to make the virtual shares available to a particular recipient. An issuer can grant virtual shares to recipients from any active program.

As a result of the grant, virtual shares can end up in different stages:

• reserved, indicating the intent to make the virtual shares available to a recipient. Virtual shares are reserved until the recipient either rejects or accepts them.
• offered, indicating that the recipient is eligible for the virtual shares but has not explicitly expressed his intent to accept them yet.
• accepted, indicating that the recipient is eligible for the virtual shares and has previously already accepted the terms of the virtual shares.
• rejected, indicating that the recipient has previously rejected the terms of the virtual shares or that the eligibility rules of the program reject the recipient based on the age or geographic location.

Virtual shares in the reserved and offered state are equivalent to contracts that are signed by the issuer, but have not yet been signed by the recipient, thus no binding contract is yet created.

Acceptance/Rejectance

Rejecting virtual shares is possible already in the reserved phase. Accepting virtual shares becomes possible if the recipient has identified themselves and is from within the geographies where we do already support the acceptance (e.g., EEA countries).

In offered state, the recipient can decide to:

• reject the Offer – maybe he is a PEP or does not want to be involved with the particular business. All rjected virtual shares will be returned to the initial pool for reuse. Also, all following offers from the same program would fail as rejected already at API call level (not creating any transactions).
• ccept the offer, agreeing to receive the virtual share. Acceptance represents a contract signing between two identified parties. Accepting the offer results in the virtual shares being registered in the name of the recipient.
• … do nothing, resulting in virtual shares being in offer status up until the moment when there is a natural motivation for the recipient to engage. Such motivation arises on trigger, where there is a (monetary) reward in sight, resulting in more motivation for engaging with the platform.

Recall

Reserved/offered and (rarely) accepted virtual shares can be recalled by the issuer. The reasons for recall are the following:

• a human error (typos in Recipient email)
• a programming error (API integrations grant double the number of expected virtual shares)
• a violation of either law or a contract between issuer and recipient (malicious behavior by Recipient which should not be rewarded)

Recall is a two-step process, requiring koos.io Admin to review such requests, acting as a safety net for malicious recalls voiding the entire Program Promise.

Recalled virtual shares are credited back to the initial pool for reuse.

Burn

Burn as the name indicates is a terminal event, resulting in the contract represented by the virtual share to become fulfilled. A burn can happen with accepted virtual shares in following ways:

• initiated by the recipient, on withdrawal of virtual shares from koos.io platform to crypto wallet owned by the recipient.
• initiated by the issuer acting on behalf of a recipient using koos.io API, in return for goods or services provided by the issuer. Such burn requests would need to be verified by a recipient (via OTP), confirming their intent. Using this option requires the issuer to have opted in for our Utility add-on on the subscription.
• initiated by Koos.io, acting on behalf of the issuer in case when the trigger was reached in return of (monetary) reward based on the promise of the program.

Burned virtual shares are not returned to the initial pool, instead such virtual shares are removed from the circulation.

Participation

The issuer grants a virtual share to the recipient with the intent to enter into a contract, represented as terms of the virtual shares attached to the virtual shares. The recipient's intent is unknown at this stage, so the contract is not yet binding. This stage is similar to a recipient receiving a paper contract signed by the issuer in the mail.

Recipient expresses his intent to participate in the program later. If the recipient wants to receive the rewards from the program they elect to do so by accepting the terms of the virtual shares. If they are not interested or able to receive the rewards, they can choose to reject the terms of the virtual shares.

Prerequisite to the acceptance are eligibility checks, based on the identity information provided by the recipient, being different from rejectance which can occur without the identity provisioning.

The recipient must make an explicit decision to accept or reject the terms of the virtual shares for each new program. Subsequent grants from a program whose terms of virtual shares have already been accepted or rejected do not require any action by the recipient.

Program Lifecycle

Virtual share program lifecycle from birth to settlement to termination is described as follows:

Such statuses limit the transactions (grant, accept, reject, transfer, recall, etc) that either by the issuer or the recipient can perform on virtual shares:

Note that the status flow can only move in one direction, except between active and suspended. Active programs can move to suspended and vice versa.

Eligibility Checks

Eligibility checks are based on a rule engine which is basing its decisions upon eligibility rules bound to the program and the identity of the recipient. So, you can imagine the eligibility check to work as:

Eligibility = checkEligibility (programId, recipientId) with three potential outcomes:

• Eligible, indicating that virtual shares from this program can be offered to this recipient
• Not yet eligible, indicating that virtual shares from this program cannot yet be offered to this recipient, but there is a significant chance that in the future this might become possible. Virtual shares for such recipients need to remain reserved. Examples
  • 17yr old coming of age
  • Koos.io expanding its legal perimeter to cover Recipients from within Germany
  • German recipient moving to the UK.
• Not eligible, indicating that the recipient is not eligible and will not become eligible for the virtual shares. Examples:
  • A reward program designed for UK residents, recipient is from Russia.
  • A reward program designed for adults only with the expected termination in 5 years, recipient is 10yr old.

Eligibility might change over time due to various reasons:

• A program might relax its eligibility rules in time. For example: a program that was designed only for recipients from Baltics will be eligible for Poland after three months.
• Recipients will age and become eligible for virtual shares that were restricted for underage recipients.
• Recipients might move to a country where the program is eligible.

If you are interested in legal aspects of the eligibility, please also review the corresponding section in legal reference manual