-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datastore #522
Conversation
Wait. Why does this PR have so many commits :/ Anyway, it's WIP, I'll rebase it later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use some shorter names for the external functions of DataStore contract. It will make ease to write the data from the other modules. (It will make our code neat and readable).
other than this everything is good.
contracts/modules/Experimental/TransferManager/KYCTransferManager.sol
Outdated
Show resolved
Hide resolved
} | ||
|
||
function _modifyKYC(address _investor, bool _kycStatus) internal { | ||
IDataStore dataStore = IDataStore(ISecurityToken(securityToken).dataStore()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we could make a getter function to return a datastore module address in the module.sol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I didn't do that in this PR because I am split if we should make a getter function or just store the data store address in the constructor.
Using the getter will mean higher gas but every time the latest data store will be fetched. Storing it as a variable will mean lower gas but we'll need to update ds address in each module if we change ds.
data store will rarely (if ever) be changed after deployment but storing the data store in every module may end up being more expensive if/when rent is introduced.
contracts/datastore/DataStore.sol
Outdated
*/ | ||
function setSecurityToken(address _securityToken) external onlyOwner { | ||
if(address(securityToken) != address(0)) { | ||
require(msg.sender == IOwnable(address(securityToken)).owner(), "Unauthorized"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this already done through the onlyOwner
modifier?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will modify to just have the modifier (which is needed to stop someone changing the security token to address(0) which would break things).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
onlyOwner
wasn't supposed to be added to that function. We don't even need onlyOwner
.
My original thinking was that first setSecurityToken call must be free to allow initialization. After the initialization, onlyOwner should kick in.
I don't exactly remember why I added onlyOwner. Probably just a reflex 😂.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to go with proxy deployment and Initialized st address in the proxy so I never had to call the set function before initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking a bit more about this, this seems a slightly dangerous operation. An issuer could assign the security token address to be anything (i.e. not an actual security token) which means that the data could then be updated adhoc. The original ST though would still think the data store belonged to it.
I do think it is useful to be able to assign a dataStore to a new token (so that if an issuer wants to migrate its data to a new token it can do) but wondering whether we should also:
-
- check the new address is a ST (using the STR)
-
- tell the original underlying token that it no longer owns the dataStore
-
- not allow address(0) to be used as the new ST address
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do 1), we won't need 3). If gas limit allows, I think we should add the check just to minimise mistaken address changes.
- I don't think we should prevent or worry too much about this. Issuer has a lot more power anyway. In case of upgrading token, Keeping the data store active for both tokens (read for old, write for new) can be useful to create a bridge that will help people migrate their security tokens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - for now I've just made it so that the function has an onlyOwner modifier. As you say, for initialisation it is done through the constructor, so any subsequent changes should only be made by the ST owner. I'll add checking in the STR as a subsequent PR - not too worried about gas costs as it will be a rare operation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to say code size limit and not gas limit :)
This PR contains the basic data store and a sample module.
Existing modules will be refactored to use data store in individual PRs.