Datastore #522
Datastore #522
Conversation
|
Wait. Why does this PR have so many commits :/ Anyway, it's WIP, I'll rebase it later. |
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.
we could make a getter function to return a datastore module address in the module.sol
There was a problem hiding this comment.
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.
Isn't this already done through the onlyOwner modifier?
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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.