Skip to main content

1 - Issuance Platform Requirements

An issuer’s issuance platform should be developed to manage the launch of the issue, as well as act as the primary interaction layer with the issue's Smart Contracts. The issuance platform’s sole responsibility is of the issuer itself, never of the ERIR.

In general, it should be understood that the ERIR must be able to perform the following actions independently of the issuance platform:

  • Access and view, at all times, all investors in an issue, as well as their holdings.
  • As the entity that registers the issue, it must tacitly approve and keep a record of the corporate operations associated with the issue such as dividend distribution requests, holding exchange requests between whitelisted users, etc.
  • It must not allow corporate operations to be carried out without the tacit approval of the ERIR.

1. Required Capabilities of the Issuance Platform​

This platform must provide a dedicated ERIR access, offering of at least two capabilities:

1.1. Supervision​

Through the issuance platform, the ERIR must be able to supervise all sensitive information related to the issue, avoiding the need to extract that information from the issuance platform.

This includes, among other things:

  • Verifying all sensitive information related to the issue and the issuers, including technical documentation, status, or updates.
  • The ERIR must have access to all sensitive information of the issue's investors, including the data from the Digital Onboarding process performed on them, the tokens these investors hold on the platform, their blockchain addresses, and any other information that may be relevant to the ERIR.

1.2. Operations​

In addition to basic supervisory operations, the ERIR must have the ability to "create or launch" actions from the issuance platform itself, which must likewise be approved by the ERIR on the administration platform. These include:

a. Blocking the issue b. Blocking a token holder c. Blocking a set of tokens belonging to a token holder

In other words, the issuance platform must allow the ERIR to create these actions and send them to the administration platform for signing.

2. ERIR Administration Platform​

The ERIR has its own administration platform called ONYZE Capial Markets, from which it manages the various issues it must register and record. This platform is independent of the issuance platform.

2.1. Signing of Operations by the ERIR​

All corporate operations associated by the issue must be explicitly be signed by the ERIR, through the ERIR's administration platform ONYZE Capital Markets, thereby guaranteeing that they were performed by the entity and have not been modified or altered by a third party.

All of this activity must always be carried out by sending the required information from the issuance platform to the ERIR's administration platform, so that the latter can correctly register, store, and sign it.

Therefore, the issuance platform must have the capability to:

  • Send activity requests to the ERIR's administration platform for those corporate operations of the issue that require ERIR validation. These must be sent with a Typed Structured Data / EIP-712 format, to which the ERIR's administration platform will respond OK or KO via a dedicated webhook.
  • Receive information from the ERIR's platform via a dedicated webhook.
  • Correctly transmit the signed orders received from the ERIR via webhook to the issue's Smart Contract.

2.2. Inter-platform Communication​

The issuance platform must communicate with the administration platform primarily for the following purposes:

  1. The issuance platform communicates via API to ONYZE Capital Markets any operation subject to ERIR approval.
  2. The ERIR approves and signs the operation, returning the signed data via Webhook to the issuance platform.
  3. The issuance platform sends the signed information to the issue's Smart Contract.

2.3. ERIR Platform API Overview​

Each issuer has its own API access credentials and must obtain a bearer token before operating with the platform. Communication is always be server-to-server.

In addition, the issuance platform must have a Webhook system in place to receive information from the ERIR's administration platform, mainly the orders signed by the ERIR, which the issuance platform must then transmit to the smart contract.

Among the activities that must be communicated to the ERIR's administration platform are:

Token Holder / Investor Management​

The ERIR must be notified every time a new token holder is registered and added to the issue's whitelist.

This requires that a mandatory notification be sent via API to the administration platform.

POST /v2/issuers/:clientIssuerId/issues/:clientIssueId/holders

Corporate Operations Management​

The ERIR must be notified of all corporate operations or Smart Contract management operations that require its approval and signature.

These operations must send the Typed Structured Data to be signed, along with any additional information necessary for the ERIR.

Once the information is received via API, it is processed asynchronously on the administration platform, and once the ERIR signs the operation, the result is sent via Webhook to the issuance platform, so it can send the signed data to the blockchain.

POST /v2/issuers/:clientIssuerId/issues/:clientIssueId/activities/request

The ERIR's response can be either of approval, together with the signed Typed Structured Data, or rejection.

In any case, this information can be accessed via an API query.

GET /v2/issuers/:clientIssuerId/issues/:clientIssueId/activities/:clientIssueActivityId

Notice and Registration of Other Operations​

In addition to the above, the ERIR's administration platform has the ability to receive information notices from the issuance platform, without the need for these notices to be signed by the ERIR.

POST /v2/issuers/:clientIssuerId/issues/:clientIssueId/activities/message

2.4. Webhook Message Signatures​

Each message sent via webhook by the ERIR Administration Platform includes an HMAC digital signature. This signature is generated with a unique webhook secret for each issuer.

The message signature is included in all emitted webhook messages via the x-hub-signature-256 header.

E.g:

signature-x-hub-256:sha256 = 13ac12305507055ab9a5ada1d5b1f1f809fa9463e8cd4830282a2198a7aeabb6

The issuer may verify the signature with the provided webhook secret, which can be computed with JavaScript like the following:

const signature = crypto.createHmac('sha256', webhookSecret).update(payloadString, 'utf8').digest('hex');

The computed signature can then be compared against the one in the header to verify the message origin.