Shares Requestors

A "shares requestor" is a contract that receives requests to buy shares in a fund, custodies the asset necessary to buy shares, and then features some mechanism for executing the requests.

A fund would generally use a shares requestor in tandem with the BuySharesCallerWhitelist policy, so that only the shares requestor contract has access to ComptrollerProxy.buyShares() .

AuthUserExecutedSharesRequestor

The first shares requestor included in this release.

It is a shares requestor in which submitted requests are manually executed by authenticated users (either the fund owner or fund owner-appointees).

Each fund gets their own proxy, which will generally be deployed via the provided factory.

Setup

The pipeline to setup the shares requestor is:

• The fund owner deploys a AuthUserExecutedSharesRequestorProxy via the AuthUserExecutedSharesRequestorFactory

• The fund owner adds the BuySharesCallerWhitelist policy with the newly deployedAuthUserExecutedSharesRequestorProxy as the only caller

• The fund owner adds authorized users who can execute requests by calling addRequestExecutors() on their proxy

Creating, executing, canceling requests

The pipeline for requests is:

• An investor creates a request to buy shares by calling createRequest() with the amount of the fund's denomination asset they wish to spend and the minimum amount of shares they will accept for that amount. The shares requestor proxy custodies the investment asset.

• A fund owner or auth user calls executeRequests() with the investor addresses of the requests they wish to execute. This will purchase the shares in each request via ComptrollerProxy.buyShares(), and remove each stored request.

• An investor can cancel their request at any time and have their investment asset refunded.

• An investor can only have one request at any given time, and if they cancel a request, they must wait for a cooldown period before they are allowed to create another request.

Fund migration notes

Since funds can migrate to new releases and since upon doing so the old ComptrollerProxy is no longer used, the shares requestor will also cease to function after a migration.

The expected behavior surrounding migration is:

• When a fund has a pending MigrationRequest in the Dispatcher, calls to ComptrollerProxy.buyShares() are prohibited.

• When a fund has migrated to a new release, calling ComptrollerProxy.buyShares() is also not possible for a multitude of reasons.

• Therefore, in both of these cases, the exectueRequests() function on the shares requestor will also fail.

• The shares requestor does not validate whether or not a fund is in either of these states when creating new requests, so it will continue to accept requests and allow cancellations, but will revert upon execution.