Why do addresses get lowercased when stored in contracts? - solidity

I'm asking this, because I'm not sure if it's a bug or a normal behaviour. Here's a simple contract.
pragma solidity ^0.4.0;
contract Contract {
address public someAddress;
function storeAddress(address someAddress_){
someAddress = someAddress_;
}
}
Store vs Get:
0x203D17B4a1725E001426b7Ab3193E6657b0dBcc6
0x203d17b4a1725e001426b7ab3193e6657b0dbcc6
If EVM understands only lowercased addresses then why do some services generate addresses that are mix-cased?

Capitalization simply means the address has a checksum.Both will work well.
Refer to Is Ethereum wallet address case sensitive? and How can I check if an Ethereum address is valid? for details.

Related

Confused about a withdraw function in a contract I am studying

I am fairly new to Solidity and at this point, reviewing contracts that are active and on chain. I am trying to understand every detail. This withdraw function has got me stumped.
function withdraw(address token, uint256 amount) external onlyOwner {
if(token == address(0)) {
payable(_msgSender()).transfer(amount);
} else {
IERC20(token).transfer(_msgSender(), amount);
}
}
Particularly the two parts that are "if(token == address(0))" and "payable(_msgSender()).transfer(amount);".
The best explanation for address(0) is here What is address(0) in Solidity but I have to admit, both answers have me bewildered.
I have read that payable() is casting the address to be payable and that this has been deprecated. Just looking for a short explanation as if to a child.
A decent amount of time searching to no avail.
This code seems to aim to be an universal function for two separate features:
withdraw native token
withdraw ERC-20 token
If you pass 0x0000000000000000000000000000000000000000 as the value of address token, the code transfers amount of native token from the contract balance to the _msgSender() address. Each network has usually different native token - ETH on Ethereum, BNB on Binance Smart Chain, MATIC on Polygon, ...
If you pass any other value as address token, the contract assumes that there's an ERC-20 contract on that address, and tries to transfer out amount of the ERC-20 token from the contract balance to the _msgSender() address.
payable extension of address is not deprecated. Since Solidity v0.8.0, all native transfers need to be performed to an address payable type - while older versions also allowed transfers to the regular address type.
The use of transfer() function might be a bit confusing, though. When it's called on an address payable type, it's the native transfer. And when it's called on an interface or contract type (in your case IERC20), it invokes a function on the specified contract - in this case the external contract function is also called transfer().

*big.int and *types.transaction issues during interaction of solidity smart contract using Go-ethereum package

I want to interact solidity simple smart contract using Golang based Go-ethereum package, which showing me the error of *types.transaction and *big.int (returning these instead of string and uint) while functions are:
function Vote() public payable returns (string memory)
function Result() public view returns (uint)
My question is how can I manage them, so that I can get exactly the same value as required.
I think this is because transaction is being performed before this function call, which may be the cause.
By your guess, you have to wait for the transaction to be mined before you can see any resulting value of the transaction.
However, in your case the results are *types.Transaction and *big.Int, this indicates that you are using the deploy-time contract instance, or not initializing the deployed contract (need RPC connection).
You can refer section "Accessing an Ethereum contract" from here, hope you can find the answer

What is the purpose of symbol and name in ERC721?

I'm new to ERC721 and have some question on it.
I was following some tutorial and have question on constructor.
The question parts are below.
constructor(string memory baseURI) ERC721("NFT Collectible", "NFTC") {
setBaseURI(baseURI);
}
I understood what is memory but still don't know what is symbol and name in there.
Can I change it randomly?
What is the purpose of those?
And Where can I find that symbol and name?
That's my question.
I'm freshman in blockchain so some terms are unfamiliar.
So it will be great help if someone tells in details.
Yes, you can change it randomly. It does not matter if you have ERC20 or ERC721 token. Both of them need to have a name and a symbol. Let's say we have us dollar. So the name is "United States dollar" and symbol is "USD".
It is same for your tokens, you need to give them some name and symbol according to the ERC721 technical standard.
#dev Initializes the contract by setting a name and a symbol to the token collection.
// Token name
string private _name;
// Token symbol
string private _symbol;
constructor(string memory name_, string memory symbol_) {
_name = name_;
_symbol = symbol_;
}
you can give your own token name and symbol
for more info you can read this openzeppelin doc
I do not know the purpose of name and symbol but I think that the purpose of ERC721 is to not effect on our nft that we posted on any nft platform example like opensea, Rarible etc. if some how nft marketplaces are hacked then it not be effected.

Remix not recognizing WMATIC address in an array

I am stuck trying to compile a contract using Remix. I am initializing an array as follows:
address[] public wmaticToUsdcPath =[0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270, 0x2791bca1f2de4661ed88a30c99a7a9449aa84174];
But Remix won't compile and is complaining that 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270 is not an error. The exact error is, this looks like an array but has an invalid checksum. It is suggesting I prepend '00' to it and directing me to https://docs.soliditylang.org/en/develop/types.html#address-literals but I can't seem to understand what to do. Prepending '00' will change the address. I am working on the MATIC/Polygon network.
The funny thing is if I declare an address variable and assign the WMATIC address to it, it is accepted by the compiler.
Does anyone know why the MATIC address is not accepted in an array.
It turns out I just need to follow the instruction in the error message. I prefix the address with '00' and it solved the issue. The issue was caused because WMATIC (and also USDC) have address format that will not pass checksum for later versions of solidity. By adding the '00' it will make it pass the checksum during compilation but the address will still be the same on deploying (I was worried adding this will change the address of the token). My final solution looked like this:
address[] public wmaticToUsdcPath =[address(0x000d500b1d8e8ef31e21c99d1db9a6444d3adf1270), address(0x002791bca1f2de4661ed88a30c99a7a9449aa84174)];
You need to checksum the addresses.
Checksum of an address is basically adjusting capitalization of the letters (hex values a-f) based on values of the address hash. There are some tools to calculate the address checksum, for example this one. You can see the second half of this answer for more detailed explanation.
pragma solidity ^0.8;
contract MyContract {
address[] public wmaticToUsdcPath = [
0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270, // instead of 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270
0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174 // mind the capitalization of the letters
];
}

web3.js - how to check if a Token Contract implements ERC223 standard?

I would like to receive payments in any given ERC20 Token.
For that, the user must fisrt approve the transaction calling...
function approve(address, uint)
... on the Token's contract and then call to a specific function on MyContract that will triggers the actual transfer, calling...
function transferFrom(address from, address to, uint tokens)
... again on the Tokens's contract
That works fine but is very tedius and has double gas spending.
Now I found out the ERC223 standard that solves this (and other issues) but is not implemented by the mayority of the current popular tokens. It would be great to give the user the opportunity to pay just making a single transaccion when posible.
So, how can I dynamicaly check if a given token address implements ERC223 standar using web3 v0.x (im using v0.20.4) ?