New answers tagged

0

In solidity > 0.4.0 (until current version 0.8.x) the solution is like this: In case of integer literals, you need to type at least one integer explicitly: uint x = uint(5) / 2; x == 2. Otherwise you will get TypeError. In case of variables, it's automatic: uint a = 5; uint b = 2; uint c = a / b; c == 2.


0

You cannot set up cron jobs in Ethereum. The protocol does not natively support this kind of operation. You have to use an automation protocol that runs on top of Ethereum, e.g. Gelato Network.


0

Amplifying @Travis's answer. This line Original original; adds considerable size to SecondContract because it contains Original. That's a separate issue that can be solved with an interface. SecondContract doesn't require the complete bytecode for Original. That is repetitive and unnecessary. It only needs the function signature and address of the instance ...


0

I think smart contracts could be promising if the official currency is a government-issued cryptocurrency. I'm thinking that a government could first create a currency (call it the smartcoin). The smartcoin's design stipulates that the government can offer smart contract bonds (call them smartbonds) that work like this: The smartbonds give their holders ...


0

All these functions are using unsigned integer, uint, So the value can only be positive. In the other hand, msg.value / tokenPrice There are more chances that your value will be decimals represented in WEI but it could never be less than 0. If for a reason the result is negative. your code will revert with underflow error. Because a uint can't be negative. ...


0

Im pretty sure super refers to the contract right before the caller contract in the inheritance tree. Not sure what would happen in the case you're describing. Id suggest testing to find out what happens. If it doesnt check for both maybe make TimedCrowdsale inherits CappedCrowdsale?


0

I am not sure about doing mutation in modifier tho. The following case for example. modifier updateReward(address account) { rewardPerTokenStored = rewardPerToken(); lastUpdateTime = block.timestamp; rewards[account] = earned(account); userRewardPerTokenPaid[account] = rewardPerTokenStored; _; } function stake(uint _amount) external ...


1

While the answer from @Paddy looks correct, it screws up the length of _returnData before passing it to abi.decode. The screwed up length is much bigger than it should be. Hopefully abi.decode will just ignore extra bytes after the decoded string, but it would be better not to rely on this, so here is cleaner version: function extractRevertReason (bytes ...


0

I think this is better handle with better contract design. Instead of handling buy/sell transaction variables one-by-one, you can have a struct defining an escrow transaction. Something like: struct escrowTx { uint256 TransactionID; address Seller; address Buyer; bool Executed; ... } Then each escrow transaction is just a new instance of this ...


0

yes you can. You can make a transaction to ethereum to change the atribute of the nft like name 'Charmander' to 'Charmeleon' or other stuff. Doing It is way cheaper than burn the nft and mint a new one (I dont knoww haven't test it but high chance it is).


0

Actually if your hashing algorithm gives you c89efdaa54c0f20c7adf612882df0950f5a951637e0307cdcb4c672f298b8bc6 when hashing 1 then it is the correct algorithm. It's just that you must encode the value properly before using the hash function, i.e. you must use the hex string 0000000000000000000000000000000000000000000000000000000000000001 instead of simply 1. ...


Top 50 recent answers are included