search

PolymathNetwork / polymath-core-deprecated

Core Ethereum Smart Contracts for Polymath - The Securities Token Platform
MIT License
66 stars 19 forks source link

What's the purpose of maxPoly in SecurityToken #57

Closed pabloruiz55 closed 6 years ago

pabloruiz55 commented 6 years ago

SecurityToken enforces that the issuer sets a cap on funds being raised (in POLY) which can't be modified.

1- What if the issuer wants to raise funds in ETH? 2- This rule is typically enforced at an STO/Crowdsale level. I don't see why this should also be here. 3- There's no way to modify this hardcap. For different reasons the issuer might want to reduce or increase the hardcap for the STO. Even though they could do it at an STO level, they won't be able to change it.

satyamakgec commented 6 years ago

I think we are still dicy at investment through ETH. And I think for changing maxPoly we have to provide some restriction to change the cap. otherwise, an issuer can change it whenever it wants.

adamdossa commented 6 years ago

I read this as being equivalent to the usual "hard cap" you see in ICO models. In practice the final version would need to allow raising in ETH, or POLY or a combination of the two (my understanding is that by contributing in POLY you get the advantage of having voting rights over delegate / owner allocations). I would mark adding ETH as an enhancement for the future. I don't think it should be possible to amend your POLY max (e.g. hard cap) after the start date of the offering.

satyamakgec commented 6 years ago

@adamdossa agreed

pabloruiz55 commented 6 years ago

But why should SecurityToken care about maxPoly? This is a property of a Token Sale, not the token itself. I don't believe this should be enforced by ST as it requires duplicating said limit in both ST and STO.

adamdossa commented 6 years ago

My view is that ST should basically know nothing about the offering process (other than the address of the STO contract) - it should just be a lightweight token with limited transfers.

STO should hold all of the offering (ICO) logic, including start / end times and maxPoly (and in the future other details related to the offering, e.g. bonuses, ETH caps etc.).

However at the moment, things like the Compliance delegate are hooked into the ST contract, rather than the STO contract which feels wrong - similar comment on #40.

everhusk commented 6 years ago

The purposes is to allow investors to cap how much funds they are willing to raise in POLY as a percent of ETH. Only POLY raised funds are able to be burnt and gives investors a quick metric to look at as a vote of confidence in the issuer.

everhusk commented 6 years ago

@pabloruiz55

  1. The issuer can still raise funds in eth
  2. This would be enforced in the STO contract, it's just to be able to set a hardcap on the amount of POLY the issuer is willing to raise/lockup
  3. Adding to @adamdossa's point I like to keep things simple, so would prefer to avoid adding in additional functions at this point unless it is a recurring request from issuers
adamdossa commented 6 years ago

To me this is a larger issue in the sense that the polymath core code is currently focussed on the ST rather that the STO. For KYC this makes sense (as it impacts secondary trading and issuance and is linked to the transfering of STs) but for compliance I think it is better to add hooks on the STO side.

I agree at this point though these changes should not be part of the initial release.

pabloruiz55 commented 6 years ago

Are we leaving this as it is? I believe @satyamakgec moved some of the logic out of ST and into STO in the latest commits (on his branch).