Estoy leyendo el código fuente de este token erc20:
https://etherscan.io/address/0xfdfd5db568f2ecf9b06a16116b9201b0500735b4#código
el código es así:
contract VelixIDToken is ReleasableToken, BurnableToken {
...
function transfer(address _to, uint _value) public returns (bool success) {
// Call StandardToken.transfer()
CanTransferChecked(released || transferAgents[msg.sender], msg.sender, transferAgents[msg.sender], released);
if (released || transferAgents[msg.sender]) {
return super.transfer(_to, _value);
} else {
return false;
}
}
...
}
contract ReleasableToken is ERC20, Ownable {
...
function transfer(address _to, uint _value) public returns (bool success) {
// Call StandardToken.transfer()
CanTransferChecked(released || transferAgents[msg.sender], msg.sender, transferAgents[msg.sender], released);
if (released || transferAgents[msg.sender]) {revert();}
return super.transfer(_to, _value);
}
...
}
Según tengo entendido, la transferencia de token () nunca puede suceder realmente, released
ahora es falsa, por lo que en VelixIDToken, solo transferAgent puede pasar la verificación:
if (released || transferAgents[msg.sender])
,
bien en ReleasableToken, la llamada revertirá la causa:
if (released || transferAgents[msg.sender]) {revert();}
.
pero veo una transferencia de token exitosa en etherscan:
https://etherscan.io/tx/0xfa76397fc5d1d5e155fa969f56095d4ecdad4dc90a64798ca79fa2773923fb07
Entonces, ¿dónde me equivoco?
PD. Incluso me preguntaba si el código fuente subido a etherscan está mal, ¿puede pasar esto?
Creo que super.transfer
se refiere a la transfer
implementación en BurnableToken
, no transfer
en ReleasableToken
. De https://solidity.readthedocs.io/en/v0.4.24/contracts.html#herencia-multiple-y-linealización :
Especialmente, el orden en el que se dan las clases base en la directiva is es importante: debe enumerar los contratos base directos en el orden de "más parecido a la base" a "más derivado".