1

I have no experience with solidity and haven't yet found any introductory guide that doesn't assume considerable prior knowledge, so I admit I'm struggling somewhat. If there was a true beginners guide around that would indeed be fantastic.

Anyway - the "token" and "crowdsale" sample code on the ethereum foundation website, I've managed to hack and chop up and get things working as I intended, by a process of change-that-and-see-what-happens.

I wonder if someone could point me towards any kind of example for locking tokens until the creator unlocks them. I presume that this can be achieved with a bit of code that somehow adds that characteristic to the token, in the token creation contract. There would need to be an exception for the "crowdsale" contract, of course. And then, what, would the creator send some kind of message to the contract in order to trigger the unlocking?

(NB: I gather that there are very good existing contracts on github such as under the Zeppelin project, but I'm afraid that since they come with no explanation beyond a file name, nor any real guidance as to how to use them, I really have no idea what to do with them or how to modify for my needs, or what exactly they do in the first place!)

Many thanks,

|improve this question
1

The problem might already be solved.

In a typical ERC20 implementation, the contract mints an initial supply via the constructor during the initial deployment. To make them spendable, it awards them to the creator.

There might also be a token sale contract, in which case the "creator" would transfer some portion of the tokens to the token sale contract to trade for ether.

locking tokens until the creator unlocks them

The initial state is 100% of the tokens are in the creator's wallet. The "lock" could be that the creator simply holds on to them

until the creator unlocks them

by transferring the tokens to the token sale contract, or somewhere else.

I suspect you're looking for something more - possibly a vested (time-based) restriction as @cleanunicorn suggested. Possibly something else. As the question is presently worded, there is no need for a contract-side "lock".

We might say it goes without saying that the creator is restricted from spending his own tokens until he/she decides to spend them.

Hope it helps.

|improve this answer
  • You're quite right - and that's the functionality I have from the basic token contract. I, as the creator, get all of the tokens sent to my address and I then choose to distribute them (to a crowdsale contract or where ever else). Indeed, though, I'm looking for the ability to lock all token transfers except those initiated by a particular address (say, the crowdsale contract itself) such that once a token is sent from there, it remains locked in the recipient's address until I/some authorised address triggers a global unlock of them. It seems that there may be a solution below, will test it! – John Mar 12 '18 at 10:45
1

Locking and unlocking tokens can be as easily done as adding

require(block.number > 6000000)

in the transfer() function

There are multiple types of locking the tokens

Time lock

You can either check the date or the block number, thus locking the tokens based on time. This can be done with modifiers similar to this one

require(block.number > 6000000)

At the beginning of the transfer function you can add this check. It means the current block number must be higher than 6 million or the rest of the function does not run. Basically the transfer will not be made. You can approximate pretty well the time in the future because the blocks are created at an average of 15 seconds.

Flag

The owner or some other trusted party can set a boolean flag that defines if the tokens are tradable or not. This should be done with a setter and the boolean value is checked at the beginning of the transfer() function

require(transferrable)

And the setter

function enableTransfers onlyOwner {
    transferrable = true;
}

Using a modifier like onlyOwner is another more readable way to set restrictions

modifier onlyOwner() {
    require(msg.sender == owner);
}
|improve this answer
  • Use require in this case. The effect is the same. – Rob Hitchens - B9lab Mar 10 '18 at 23:05
  • Thanks for the reply. Can you explain how that works? Intuitively, I would guess it means that unless the block number is > 6000000 then the function can not be carried out, right? How does that help in this case? This is the code I'm using to create the token, by the way: ethereum.org/token#the-code – John Mar 11 '18 at 13:02
  • I didn't really understand the "owner" parts, and remix didn't like it, so I think I found this method. I added this at the start: -------- bool public transferrable = true; -------- and then: ------- function transfer(address _to, uint256 _value) public { if (msg.sender == 0x...abc) { _transfer(msg.sender, _to, _value); } if (msg.sender != 0x...abc) { require(transferrable); _transfer(msg.sender, _to, _value); } } ------- So that only the address 0x...abc is allowed to transfer, so long as transferrable = false. – John Mar 12 '18 at 22:22
  • So, I'm thinking I can just add both "my" address (the one that receives all tokens initially created) and also the "crowdsale" contract address, effectively whitelisting two and only two addresses so long as transferrable=false. Would this be legitimate? And then I just need to figure out how to interact with the token contract to flip transferable=true/false as I require. And for that I have literally no idea yet o_0 Also, what is stopping someone else controlling the token contract to change that, someone other than me? – John Mar 12 '18 at 22:28
  • Gosh, sorry, I don't really know this forum layout - if I "comment" then all formatting is lost, should I just make a whole new "reply"? – John Mar 12 '18 at 22:28

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.