Hot answers tagged

2

Yes, definitely working with bytes32 instead of string will bring less transaction costs, because string has dynamic size. I find it similar to arrays in solidity where for example if you work with fixed size array it's always cheaper than working with dynamic size array. If you're interested in more gas costs savings you can check the following article ...


2

Hope you are talking aboug HD wallets, In order to get addresses generated from a "Mnemonics" or "seed" , You have to keep track of "address index", Usually it starts from 0. With every incremented value you will get a new hd wallet address get derived from the "Mnemonics" or "Seed". For example: function ...


2

You just need to know the address of the ERC20 token and execute function totalSupply(). If you want to have that in a simple contract, you could have something like this: // SPDX-License-Identifier: MIT pragma solidity ^0.8.1; import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol"; contract ...


1

One way you could achieve that is by: Creating a whitelist of addresses that will be the only ones to transfer your local currency Overriding transfer() to restrict transfers from/to users within the whitelist. In any case, you need an external procedure (off-chain) to determine which users belong to your region, or in other words, you need a centralised ...


1

I've been using such a method and it's safe and also saves some gas. Just why don't you use the transfer() method instead of all that logic? function sendMultiple(address[] memory _redemptions, uint[] memory _values) public returns (bool) { require(_redemptions.length == _values.length); uint256 length = _redemptions.length; for (uint i = 0; ...


1

Using the ERC20 standard as it is cannot solve this problem. Refer to the link below for a proposal to change the ERC20 API to prevent this problem. https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit Commit-reveal is a solution to a front running attack, but its use is slightly different. Even if you commit-reveal your ...


1

It is not possible to exclude your contract as the middleman. DEXes contracts should implement this functionality. Bancor can offer it, but only for his pairs.


1

The ERC-20 spec says you need to have an accessor function name() and symbol(). However, you can internally store them as bytes32 to save gas. Accessors would to the conversion from bytes32 to string in fly. It would be a clever optimisation, in fact.


1

But how can I verify the proof onchain inside the smart contract in the ethereum mainnet? 1,2,3 seem to require some heavy duty functions Inside smart contract it is not possible. There are hundreds of contract calls executed per block in the EVM (Ethereum Virtual Machine) and there is no room for complex logic like you are requesting. The only "...


1

Calling balanceOf on the depricated contract calls balanceOf on the upgraded contract. This same pattern is used for the other functions as well. // Forward ERC20 methods to upgraded contract if this one is deprecated function balanceOf(address who) public constant returns (uint) { if (deprecated) { return UpgradedStandardToken(upgradedAddress)....


Only top voted, non community-wiki answers of a minimum length are eligible