On the UIs we'll still limit to 4 max.

For some reason it allows transfers even if an account was not added to any whitelist.
Before, tests were passing because GeneralTransferManager was malfunctioning.

Say issuer has ticker and token ZZZ. They make a mistake at some point and they want to start over and still use ZZZ.

In a typical ICO scenario, they would just forget about the token they had and create a new one.

Here, it's a bit more tricky as they would have to "delete" the reservation on the ticker and on the ST Registries.

Does it make sense to support this feature?

Names for modules are not unique. We need to figure out a different way of doing this or at least enforcing module name uniqueness

• All registry upgrades (STR, TR & MR) will be done in-place using a proxy / delegate call pattern.
• This means that anyone using these contracts (e.g. SecurityToken or Modules) has no control over whether they get the upgrade or not.
• As a result of this, any dependencies on these contracts are subject to breaking (i.e. if Polymath self-destructs the contract), which implies no existing functionality should have any dependencies on the registry contracts.
• AFAICT this is true for all of our modules and security token. The security token has a dependency on the module registry for adding new modules, but this is fine as it doesn't contravene the aims above which relate to existing functionality, not new modules.
• Registries do have interdependencies (e.g. module registry depends on STR, STR depends on TR), so when upgrading registries we'll need to make sure they are upgraded in a consistent manner.

TickerRegistry: The expiry date is general for everyone. The system uses a single expiryLimit (say 15 days) across all tickers. Changing the expiryLimit to 6 months means everyone will get 6 months.

As per the business logic, Type 3 module factory always have the locked value true. So once it gets attached to the ST it will not be replaced by another STO?

@adamdossa @pabloruiz55 Thoughts?

Split out implementations vs. interfaces and create true interface files for Polymath contracts.

If we are to support exchanges, we need to have a separate whitelist (or the ability for exchanges to add addresses to the original whitelist) so exchanges can add addresses to enable them to withdraw tokens acquired through the exchange.

We should keep track of who added someone to the whitelist, specially since there could be several delegates and if there's a problem with an address added the issuer should be able to know who added it.

 function modifyWhitelist(address _investor, uint256 _time) public onlyOwnerOrDelegates {
        //Passing a _time == 0 into this function, is equivalent to removing the _investor from the whitelist
        whitelist[_investor] = _time;
    }

If a symbol is entered as "POLY" or "poly" they will be considered different symbols.
It shouldn't matter if the symbol is entered in capital letters or not. They should be the same symbol.
Let's convert to uppercase (or lowercase) strings entered as symbol.

function verifyTransfer(address _from, address _to, uint256 /* _amount */) public view returns(Result) {
        if (!paused) {
            if (maxHolderCount < ISecurityToken(securityToken).investorCount()) {
                // Allow transfers to existing maxHolders
                if (ISecurityToken(securityToken).balanceOf(_to) != 0) {
                    return Result.VALID;
                }
                return Result.INVALID;
            }
            return Result.NA;
        }
        return Result.NA;
    }

Since

                if (ISecurityToken(securityToken).balanceOf(_to) != 0) {
                    return Result.VALID;
                }

returns VALID, this could enable a transfer even if _from/_to are not in the GTM's whitelist since the GTM does not ever return Result.INVALID

Delegates

3rd party entities (marketing, legal, consulting, developer etc.) can be added as Delegates to a token in return for a POLY fee. There is no obvious way to enforce that all parties collaborating on an issuance (issuer, legal, marketing etc.) use this approach, but if they want to be “officially” attached to the Security Token then they would need to go through the Polymath ecosystem and we can oversee that sensible fees are levied. Interacting through the Polymath ecosystem also allows Delegates to build reputation on the platform which has intrinsic value.

Questions:

1. Perhaps we should consider changing the current GeneralDelegateManager module to a PermissionManager module and build out Delegates separately with a DelegateRegistry and Reputation for each Delegate etc. similar to the ModuleRegistry? We can try and think of a way to push this to after the V1 release.

I think permissions and “delegates” are separate things. I think we should change the name of GeneralDelegateManager to GeneralPermissionManager.

I think Delegates should be similar to Modules perhaps instead (so they have a Reputation & Cost).

A string to enter some usage intructions (specially for STOs for the author do leave some remarks)

Necessary for the CLI, front-end and stats

Attached to each token, this contract holds all balances for POLY and allows incumbents to collect their fees as well as serving for the vault for POLY raise.​

What happens with the ticker registry after the token is deployed?

If it expires, will it allow someone to register the ticker?

function _getTokenAmount(uint256 _investedAmount) internal view returns (uint256) {
        return _investedAmount.mul(rate);
    }

This will give an incorrect amount of tokens if decimals is not 18.

Add the functionality through which we can access the ticker or token list owned by the issuer

TickerRegistry: 2- While I can register a ticker on behalf of someone else by entering their address instead of mine, I can not transfer ownership of the ticker. If we registered the tickers under our own account, then we would have to be the ones deploying their token and only then we would be able to transfer ownership of the ST.

If the burn would result in the holder not having anymore tokens, the investor count should be reduced.

What would happen if someone called registerModule thousands of times?

moduleList would probably stop working.
We should have a way to restrict this and/or also be able to unregister modules.

Typically, token symbols are shown in uppercase. We are transforming them to lowercase instead.

Let's use toUpper instead of toLower like we are doing now.

Move oracle address registry into PolymathRegistry (and out of the SecurityTokenRegistry),

Say we added 5 modules to the ST, the last one being not replaceable.
removeModule "deletes" a module by replacing it with the last one and then eliminating the last one.

So, if we were to remove module 3, now the last module is number 4, which is replaceable.

Don't know if it is a big deal though.

Under our current version, would it be possible for PM to register symbol, deploy token, add ourselves as delegate, cede ownership of token to them and still have us attach STO and add investors from a csv file to the whitelist?

Wondering if we can issue the ST/STO on behalf of some of the first issuers.
What would be the steps involved?

ST's are ownable, so the current owner may choose to change the owner to a new address. If this happens then the owner held in the STR for a ST would become stale.

It may be better for the STR to just call ST(securityToken).owner() to get the ST owner rather than holding a duplicated reference.

Polymath-Core Bug Bounty

Polymath wishes to operate this bug bounty program in order to upkeep the utmost of trust and security in our solidity contracts. The developer community is invited to understand and pick-apart our open source "Polymath-core" code base.

We are supplying the following rewards structure:

• 8 ETH for Critical severity bugs
• 5 ETH for High severity bugs
• 3 ETH for Medium severity bugs
• 1 ETH for Low severity bugs

It is highly advised to read through the following links for context and architecture information: Our Whitepaper, Release of the core code base, Blog: Intro to Polymath-Core architecture, and Blog: Deeper into the architecture

Scope and Architecture Explanation

We are solely interested in having our core solidity contracts audited for bugs. Below, we explain which files from our repository are "in scope" and briefly what each of them does.

TAGGED RELEASE VERSION v1.0.0 ONLY - We ONLY want code reviewed at this snapshot of the codebase. This is at commit d913d00. We do not want to completely discourage you from notifying us of bugs in newer releases, but there is no guarentee we will give awards.

• /contracts/TickerRegistry.sol
  • Users should be able to register a token symbol to it. Only unique symbols allowed. After a pre-set time the symbol becomes available again if the user didn't deploy the actual token.
• /contracts/SecurityTokenRegistry.sol
  • Deploys SecurityToken instances (through a "Proxy" mechanism). Only allows tokens whose symbols have been previously registered in TickerRegistry under the user's account. Has a versioning mechanism that changes which version of the SecurityToken would be deployed.
• /contracts/tokens/STVersionProxy001.sol
  • Proxy contract for version 1 of the SecurityToken. The SecurityTokenRegistry initially points to this one, which deploys the SecurityToken V1. Later on, SecurityTokenRegistry would be changed to point to STVersionProxy002 which would deploy a SecurityTokenV2 with added features.
• /contracts/tokens/SecurityToken.sol
  • Inherits from IST20 interface which is an ERC20 contract with a verifyTransfer() function added to it. Modules can be attached to it to extend its functionality. Should work exactly as ERC20 tokens, save for the transfer restrictions applied to it.
• /contracts/ModuleRegistry.sol
  • Repository for registered modules. For modules to be used by SecurityToken, they first need to be added to the registry and approved by Polymath owner. (The author of the module may also use it for their own SecurityToken, but for it to be available to anyone, the author has to get Polymath to verify it first).
• /contracts/modules/*/*ManagerFactory.sol
  • Factories are the ones registered to the ModuleRegistry and when a SecurityToken has a module attached, the corresponding Factory will instantiate its corresponding module. Module Factories hold the general module information and reputation.
  • Note: * = wildcard; There are multiple directories and files with *ManagerFactory.sol files in them
• /contracts/modules/TransferManager/GeneralTransferManager.sol
  • Has an internal whitelist and it's verifyTransfer() method is called by SecurityToken to decide if the token transfer is allowed. If the tokens are to be transferred from the initial issuance, the requirement for verifyTransfer is that the token buyer is on the whitelist. If we are talking about a transfer between two whitelisted addresses, both should be on the whitelist and their sell/purchase lockups must have ended.
• /contracts/modules/TransferManager/ExchangeTransferManager.sol
  • A transfer manager module that is in control of an exchange. They can add addresses to the whitelist and verifyTransfer should succeed as long as one of the involved parties is the exchange and the other party is in this whitelist.
• /contracts/modules/PermissionManager/GeneralPermissionManager.sol
  • Handles delegation of permissions to other accounts. For example, owner can set permissions over the GeneralTransferManager to some other account so that they can modify the whitelist on the owner's behalf. This might come in useful for 3rd party KYC or handlers businesses that watch-over and help with the entire process.
• /contracts/modules/STO/CappedSTO.sol
  • STOs (Security Token Offerings) are the equivalent to crowdsale contracts in ICOs. The CappedSTO is one simple example of how it would be construed. We need to make sure the STO works as intended and that there is no vulnerabilities that allow an attacker to drain funds, DoS it, etc.

Bug Examples

• Here are examples of 3rd party audits that found bugs on a different code base of ours.
• NOTE: THIS IS NOT THE CODE BASE YOU ARE TO FIND BUGS ON. The Scope section above defines where you are limited to.

Compensation / Classification

We will utilize the OWASP risk rating model to assist us in classifying and awarding bounties. We also define the various levels in terms of Polymath technologies below.

• Critical severity bugs - 10 ETH:
  • Bugs that enable an arbitrary attacker to steal POLY from any of the contracts or actors of the platform. Bugs that enable an arbitrary attacker to steal Security Tokens created through Polymath Core from any of the contracts or actors of the platform.
• High severity bugs - 6 ETH:
  • Bugs that would render the Polymath Core protocol unusable and/or make Security Tokens issued through Polymath Core vulnerable to attacks.
• Medium severity bugs - 3 ETH:
  • Bugs that break specified or reasonably assumed protocol invariants that do not enable an arbitrary attacker to steal anything without action on the part of the user whose assets / funds are stolen, but enable certain parties to obtain funds or assets in unexpected ways.
• Low severity bugs - 1 ETH:
  • Bugs that break specified or reasonably assumed protocol invariants but do not have a financial incentive for anyone and do not significantly impair contract functionality or could easily be avoided during protocol use.

Submission Process

1. Create a new/seperate github issue on the polymath-core repository.
2. Your submission must include the following details:
   • Description of the location and potential impact of the vulnerability
   • Observed behavior
   • Expected behavior
   • How to replicate - A detailed description of the steps required to reproduce the vulnerability – POC scripts, steps taken, and screenshots will all be helpful
3. The Polymath team will respond to reported bugs within 72 to 96 hours from the time of submission. We will review each report and remain responsible for deciding the severity of each bug submitted. High quality, easy to read reports can be rewarded extra for the sake of making communication easier for both parties.
4. Payouts on bugs will come through either:
   • gitcoin platform (we can send as a 'tip' to your github acct name) or
   • via an ETH address that you directly supply to us in the issues comments

You may (optionally) use gitcoin's system to 'grab' this issue which lets us know your intention to work on it. Many people can. However, you should still make sure to follow the instructions above. Gitcoin allows you get paid ETH through your github tag (you wont have to give us an ETH address).

Most of the rules on https://bounty.ethereum.org apply:

• First come, first serve.
• Issues that have already been submitted by another user or are already known to the Polymath team are not eligible for bounty rewards. (Make sure that the issue has not been previously submitted or fixed in other commits)
• Public disclosure of an actively exploitable vulnerability makes it ineligible for a bounty.
• Determinations of eligibility, rewards and all terms related to an award are at the sole and final discretion of the Polymath team.

Responsible Disclosure

• Don’t make the details of any actively exploitable vulnerability you find public until after we have confirmed to you that it’s fine to do so. You can create an issue with a generalized title, explaining that you wish to speak further in private.
• Do not try to actively exploit any security issue you find

Questions

Clarification questions can come here in this issue's discussion thread.

useModule calls getSecurityTokenData in the SecurityTokenRegistrar, which in turn checks the owner of the referenced security token address. However, this call will succeed provided the referenced security token address has an owner variable, even if the address is not actually a security token.

A better option would be to check that the address is in the STR registry, but this is not possible for modules deployed via the STVersionProxy*.sol contracts as they add modules before the token has been added to the STR registry.

• I don't think we should be looking to facilitate upgrading in place for security tokens for a host of reasons (gives issuers too much power / ability to screw up).
• It would however be quite nice to allow an issuer to create a new token as a clone from a previous one, which should be possible given the checkpoint functionality. This means that if an issuer wants to upgrade to a later version of the security token they can do, carrying over existing balances (similar to the clone behaviour of MiniMe). This would need some thought as to the exact mechanics of how this would work.

ModuleRegistry's useModule func can be called to increase the reputation without actually attaching the module.

Say we have one of our modules, the TransferManagerModule (and factory).

We want to release a V2 of it for some reason (detected a bug or adding new feature).

We don't want people to be able to use V1 of TransferManagerModule anymore. But we don;t want existing tokens using that module to break if they don't want to replace it.

What mechanism do we have now to deprecate an old module without breaking existing tokens?

Do we need something beyond what we already have? What is the downside to this approach:

• deploy new CappedSTOFactory contract with updated logic.
• un-verify the previous CappedSTOFactory contract in the module registry
• verify the new CappedSTOFactory in the module registry
• in the dApp change over to the new CappedSTOFactory address
  At this point, the only CappedSTO that users will be able to add to their token is the new version (they can't add the old version as it was deployed by Polymath, so address won't match issuer address).
  Any existing tokens w/ capped STOs attached should not be affected.
  Module names are not unique (someone else could register a CappedSTOFactory with the same tags & names in the module registry), only their addresses are, so I don't think it is a problem having two CappedSTOs in the module registry, provided only one of them is verified.
  We should add an additional function in the module registry to allow module owners to remove their modules from the registry if they wish to, but we don't need to rely on this happening.
  NB - if we change the way we manage modules as per @stephane meeting then this may need to be reviewed.

Questions:

• Is it reasonable to "not allow" modules to have any dependencies on the STR? There may be use-cases where this it is useful for a module to have a view of the overall security token registries (e.g. to look up other tokens owned by the same issuer).
• We could have a "DataFeed" module type of which the oracles would be one example of. This would allow us to charge for data feeds if we wanted to. We would need to decide whether every e.g. POLYUSD data feed used the same source (i.e. as it works today) or whether everyone get's their own oracle that they need to maintain (I'm not a fan of this).

changeExpiryLimit should enforce that the limit set is at least 1 day.