4

For the compliance reasons I need to implement account freeze functionality in ab ERC-20 token. Initially, issued tokens are not transferable until the address holder goes through Know Your Customer process. When the process is complete, a centralized system, having the key of the owner account, informs the smart contract that tokens in this address become transferable.

What would be the best data structure to do this? Assuming there will be 1000-2000 token holders are there any scalability issues in smart contracts regarding this area.

4

It sounds like you could use a simple mapping, eg when you got the KYC notification you'd set kyced_customers[customer_address] = true. Then when they try to send funds you do a single read from that mapping for that address. The gas cost of reading a mapping is the same regardless of the number of things in the mapping, as is the approximate computation cost, so this should scale up fine.

5

It makes sense for your balances mapping to be a mapping of structures

struct Account {
    uint256         cash; 
    bool            passedKYC;
}

mapping(address=>Account) balances;

Then balanceOf would lookup the cash component

function balanceOf(address user) public constant returns (uint256) {
    return balances[msg.sender].cash;
}

Transfer to (or from if desired) would be dependent on passedKYC being true)

modifier canTrade {
    if (!balances[msg.sender].passedKYC) throw;
    _;
}

function Transfer(address to, uint256 amount) canTrade {
    .....(usual stuff here)
}
  • Right, this should be more efficient than my suggestion which stores the address of each user twice, once for each mapping. – Edmund Edgar Jun 1 '17 at 2:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.