Content pfp
Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions

Jacek.degen.eth 🎩 pfp
Jacek.degen.eth 🎩
@jacek
If you're a Solidity dev and interested in helping out Degen by auditing or reviewing our Locked Degen ERC-20 contract, we'd love your support. Your help in finding bugs or suggesting code improvements would be greatly appreciated! Thanks! https://github.com/degen-token/degen-smart-contracts/pull/22
28 replies
32 recasts
154 reactions

J. Valeska πŸ¦ŠπŸŽ©πŸ«‚ pfp
J. Valeska πŸ¦ŠπŸŽ©πŸ«‚
@jvaleska.eth
some people is asking about it.. and I had to stop my audit.. after found it.. LN 130 - updateLockDuration() function This allow the owner to change the locking period.. between 0-365 days. LN 118 - if (block.timestamp <= depositTimestamps[msg.sender] + lockDuration) revert... This check on lockDuration in the withdraw function allows the owner to do some tricks with the locking period: - the owner could lock and unlock by managing to do a sandwich: updateLockFunction-withdraw-updateLockFunction, withdrawing without respecting the lock. And, setting it again locking users funds. - the owner could extend the locking period, from an initial 0 days to 1 year. Locking user funds for 1 year without user "permission".
13 replies
0 recast
5 reactions

J. Valeska πŸ¦ŠπŸŽ©πŸ«‚ pfp
J. Valeska πŸ¦ŠπŸŽ©πŸ«‚
@jvaleska.eth
LN 31-32 IERC20 public constant TOKEN = IERC20(0xfee293840D23B0B2De8C55e1Cf7A9F01C157767c); the address should be DEGEN token address!? (I guess it is okay for testing?)
3 replies
0 recast
3 reactions

J. Valeska πŸ¦ŠπŸŽ©πŸ«‚ pfp
J. Valeska πŸ¦ŠπŸŽ©πŸ«‚
@jvaleska.eth
LN 59-62 /** * @dev Amount of tokens to be locked is zero */ error ZeroAmount(); This comment does not represent the functionality. This error is thrown when the amount to WITHDRAW is 0 and has nothing to do with the amount of tokens to be locked.
2 replies
0 recast
4 reactions

J. Valeska πŸ¦ŠπŸŽ©πŸ«‚ pfp
J. Valeska πŸ¦ŠπŸŽ©πŸ«‚
@jvaleska.eth
function transfer(address, uint256) public pure override returns (bool) { revert NotSupported(); } function allowance( address, address ) public pure override returns (uint256) { revert NotSupported(); } function approve(address, uint256) public pure override returns (bool) { revert NotSupported(); } function transferFrom( address, address, uint256 ) public pure override returns (bool) { revert NotSupported(); } This is to make the erc20 LDEGEN non-transferable, first time I see this way to do that, (probably, it is right) but there is an standard to do that (the one I am not using) and there is another way to do that in the _beforeTokenTranfer function by requiring the transfer to be from address zero or to address zero allowing mints and burns. (this is how I do that). That said, this is probably right, someone with more skills and knowledge than me may have a better explanation.
1 reply
0 recast
3 reactions

Ryan J. Shaw pfp
Ryan J. Shaw
@rjs
Just a personal opinion, but I like this way because it is very easy to read and is explicit. In your approach, some stuff would succeed like approve but then the transfer later fails which seems confusing?
1 reply
0 recast
1 reaction