matthewwoo-zz / bot_2 Goto Github PK

This task is not a development task.
Intent with the task is to capture the action item with our Legal Advisory (Perkins)

This task is not a development task.
Intent with the task is to capture the action item with our Legal Advisory (Perkins)

## Objective
Allow an issuer to mark which providers they are planning to work with.

## Solution
Issuers should be able to set the status of their engagement with Service Providers to one of 4:

1. Pending (set when the application is sent)
2. Engaged (when the SP and the Issuer connect off-chain)
3. Selected (when the SP and the issuer both agree to work together)
4. Declined (when the SP passes on the opportunity)

## Case 1: Selected Provider to Work With
When a Service Provider is status is updated to "Selected", the Issuer should be presented with a model that indicates:

• Header Copy:
• Notify Other Service Providers
• Body Copy:
• Now that you have selected a Service Provider in that category. Should we inform all other service providers in that category that you are withdrawing your engagement request?
• Button Copy:
• Yes / No

If the Issuer clicks "Yes" - A notification email is sent to all Service Providers (except the one that is "Selected")
If the Issuer clicks "No" - The modal closes and no message is sent.

### Email
Subject Copy:
Engagement Request Withdrawn

Body Copy:
Please be advised that from has elected to withdraw their engagement request with your firm.
If you should require any follow-up communication, please follow-up with directly.

## Case 2: Updated Selected Provider to Decline
In the case that an issuer after engaging with their "Selected" service provider decides they are no longer suitable and would like to select another, they should be able to:

1. Update that service provider's status to "Declined"
2. Able to apply again to the other providers

If they apply to the other providers again we will prompt the with the same application form that was used previously.

See below.
Captured on Macbook using Chrome.

┆Attachments: screenshot_76.png | Screen Shot 2018-05-24 at 11.13.14 AM.png

As Issuers drop from our funnel, we need to be able to re-engage with them using the email address captured when they sign-up.

Objective

Under Canadian securities regulations, Issuers may be able to set a permanent lockup on secondary trades.

We have that ability through the Permissions Module, which would allow the issuer to define other addresses that can manage the GTM's whitelist. We need to figure out how to work with that in the UI.

• include ability to re-engage with issuers as they move away from the dApp for an extended (defined) period of time
• use ticker expiry date from smart contract
• support multiple Ethereum networks

An example of an attack that we need to prevent:

1. Issuer creates a token and begins going through the process of creating their STO.
2. Shortly before Issuer is going to launch their token, a malicious creates an STO with a ticker symbol that looks exactly the same as Issuer's but actually has a special character such as the invisible zero-width space (which is not currently blocked by the smart contracts).
3. The malicious user, having signed up with one of Issuer's email addresses, launches their own STO.
4. Issuer receives an email from Polymath that appears to indicate that their STO has launched.
5. Issuer takes the address of the STO from the email they received (the malicious user's STO address) and instructs investors to send money to it.

Since we're going to start storing the user's email address and verifying that they own it, emails that are sent to the user that triggered them (such as the example above) won't be usable in scams or for spamming.

For emails that are sent to email addresses other than the user's own address (such as service provider emails) some more thought may be needed.

A few questions popped into my mind that we might want to capture somewhere and address them:

• Should the issuer be able to mint tokens for shareholders even after the STO has been attached?
• How about after the STO has finished?
• Should we have them set a maximum supply at minting stage?
• The cappedSTO won't mint unsold tokens from the cap. What are the implications of that?

Clicking on the button does not open the modal.

See https://help.fullstory.com/general-data-protection-regulation/gdpr

Take into account that we have 3 different types of footers. 1 for the splash screen, another one for the single-box pages and one more for the dashboard pages.

Chromium
Linux

1. Visit https://5af376db8df8944830c371c1--polymath-issuer.netlify.com/ on one day and provision your token through the Token Registration, issuance, configure STO and submitting approved investors
2. Then on a different day revisit the dapp https://5af376db8df8944830c371c1--polymath-issuer.netlify.com/ and not from the (https://5af376db8df8944830c371c1--polymath-issuer.netlify.com/dashboard/DIG1 ) URL.
3. User is presented the initial screen again and asked to type their name and email and
4. User has to "sign the transaction again" in metamask to show he controls his particular address
5. user is then presented to create a new STO
6. User is not sure how to get back to the token they previously were setting up Dashboard area

If a user wants to return to where they left off in the dashboard they would need the URL https://5af376db8df8944830c371c1--polymath-issuer.netlify.com/dashboard/DIG1 it doesn't seem they have a way to return where they left off.
Desired outcome: Perhaps loading screen would say New or returning users. Then if you sign from metamask the address you control the dapp would display your other tokens you had in progress or tokens you deployed from that address before and allow you to select one to navigate to https://5af376db8df8944830c371c1--polymath-issuer.netlify.com/dashboard/DIG1
This would be similar to how in the ChronoLogic ETH Alarm Clock dapp we show tx history from someone's particular address.

Under Canadian securities regulations, Issuers may be able to set a permanent lockup on secondary trades.

Was: As an Existing Shareholder to whom Tokens were minted, what should I be able to do with my Tokens before, during and after the STO?

Issuers launching their first STOs are not expected to be blockchain savvy, and as such may not be clear on where the information they are entering is stored.

As it stands today, the dApp will be capturing information that will be stored in:

• Blockchain, OR
• Local storage, OR
• IPFS (aka Decentralized File System), OR
• Centrally (for engagement purposes), OR
• Shared over email with the selected providers.

Whenever entering information, the issuer should instantly identify where the information will be stored.

Check links inside of the different types of footers, sign up page and ticker reservation page

┆Attachments: Token Creation Page Issues.jpg

Error message should show the format for time so the user knows what information to enter. Link to FullStory is here: FullStory Session

The Issuer cannot elect to start a fundraise at 00:00 as this time is considered invalid.
Issuers should be able to pick any start/end time for an STO, as long as it is in the future

┆Attachments: image.png

We need contents for the Sample.csv file that is downloaded on Import Whitelist modal

Affects polymath-issuer, polymath-auth, polymath-offchain repos and Quiknode configurations.

## Objective
To help an issuer be able to select if they would like to limit the % that investors can own and which investors are exempt from that limit.

## Solution
This solution will involve the following components:

1. Enable and set the % ownership limit
2. Select investors who are exempt

## Enable and set the % ownership limit
An issuer can enable and set the % ownership limit for their STO on the whitelist view by:

1. Check the % ownership limit box
2. Set the % ownership limit
   NOTE - Ownership limit is set by wallet address.

% Ownership Setting

• Setting Label: % Ownership
• Setting Copy: Investors can own up to ___% of outstanding tokens
• Type: Checkbox + Numeric Field

## Select investors who are
An issuer can select whether they would like an investor to be exempt from the % ownership in the following places:

1. Individual Whitelist Investor Modal
2. Whitelist Investor CSV
   NOTE - Issuer should be able to provision ageing on any entry on that list.

It will then be displayed in the Whitelist table so that issuer can easily identify which investors are exempt from the % ownership:

• Column Copy: % Ownership Exemption
• Position: After

## Individual Whitelist Investor Modal
When an issuer is adding an investor via the whitelist modal they can select if the investor is exempt from the % ownership limit

• Setting Copy: Exempt from % Ownership
• Type: Checkbox

## CSV Whitelist Investor Modal
When an issuer is uploading a list of investors via CSV they can select if the investor is exempt from the % ownership limit by inputting TRUE in the exempt from % ownership column:

• Column Copy: Exempt from % Ownership
• Type: Boolean

Per screenshot below, the Token screen shows a link to the TxHash for the ticker registration, but not the security token itself.
This screen should be updated to reflect this information and link to Etherscan

┆Attachments: Screenshot 2018-05-23 at 00.12.45.png

Toast notification:

1. Change green accent color to #00AA5E
2. Change font to Overpass Link to FullStory is here: FullStory Session

1. Create one token (say ABC1), proceed with STO and complete the fundraise
2. Clear cache
3. Start the process over and create another token (ABC2)
4. Enter email address
5. Activate email account
6. Issuer receives a confirmation email for the ABC1 token registration created in (1)
7. Issuer is redirected to the initial token ABC1 that was created during (1) instead of the token ABC2 created in (3).

┆Attachments: Mismatch wallet address shows STO.png | Matching wallet addresses redirects to account creation.png

Shares cannot be sub-divided into smaller entities when traded on exchanges or peer-to-peer.

Issuers for our initial STOs require indivisible tokens to align with their regulatory requirements

We should provide a better visual cue to the user that he/she has clicked on "I HAVE MY OWN"

┆Attachments: Screenshot 2018-05-31 at 09.50.24.png

Particularly whitelist code, but not including email flow (which is included in Reconsider, refactor and refine email flow

Was: BUG: Limit on the length of URL for "Additional information"
https://cl.ly/2J3K3K0v1r37

"All smart contracts listed below were independently audited. Polymath does however recommend you select a Smart Contract Auditor to perform additional fication on the smart contract you selected."

Should read:
All smart contracts listed below were independently audited. Polymath does however recommend you select a Smart Contract Auditor to perform additional verification on the smart contract you selected.

┆Attachments: Screenshot 2018-05-31 at 09.42.56.png

Third field associated with each ETH address in the whitelist.
When that date is reached, the owner of the ETH address can sell, but not buy.

The same timer (Time left to create your token) is represented in 2 different formats from one screen to the next. Both should use the format as seen on the "Choose Your Providers" screen.

┆Attachments: Screenshot 2018-05-16 at 08.45.26.png | Screenshot 2018-05-16 at 08.49.09.png

┆Attachments: image.png | 1. Token overview-1920.png | 1. Token overview-1024.png