Ich lese den Quellcode dieses erc20-Tokens:
https://etherscan.io/address/0xfdfd5db568f2ecf9b06a16116b9201b0500735b4#code
der code ist so:
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);
}
...
}
Nach meinem Verständnis kann der Token-Transfer () nie wirklich passieren, releasedist jetzt falsch, also kann in VelixIDToken nur transferAgent die Prüfung bestehen:
if (released || transferAgents[msg.sender]),
Nun, in ReleasableToken wird der Aufruf zurückgesetzt, weil:
if (released || transferAgents[msg.sender]) {revert();}.
aber ich sehe eine erfolgreiche Token-Übertragung auf Etherscan:
https://etherscan.io/tx/0xfa76397fc5d1d5e155fa969f56095d4ecdad4dc90a64798ca79fa2773923fb07
also wo liege ich falsch?
p.s. Ich habe mich sogar gefragt, ob der auf Etherscan hochgeladene Quellcode falsch ist, kann das passieren?
Ich glaube, das super.transferbezieht sich auf die transferImplementierung in BurnableToken, nicht auf die transferin ReleasableToken. Aus https://solidity.readthedocs.io/en/v0.4.24/contracts.html#multiple-inheritance-and-linearization :
Besonders wichtig ist die Reihenfolge, in der die Basisklassen in der is-Direktive angegeben werden: Sie müssen die direkten Basisverträge in der Reihenfolge von „most base-like“ bis „most derivative“ auflisten.