In your opinion, is it necessary to create a function for destroying tokens on a separate address? Will it create a vulnerability? I thought this feature might be needed since users tend to lose keys or whatever. If there is such a function, then the developer will be able to destroy the tokens at the desired address and transfer other tokens from his wallet to the user. But on condition: to prove at a personal meeting. Yes, from a psychological point of view, this feature will alienate some investors at the beginning of the journey. What are your thoughts?
well people can just approve their tokens to a backup wallet I guess and how you wanna prove that someone had a personal meeting with the dev? makes no sense at all.
If I am the founder of the project, then it turns out that if a person has lost the keys, then he will have to prove to me in person that this is his wallet. If he can prove it, then the function to destroy the tokens at this address is called. And the founder of the project gives him other tokens from his wallet. If this function does not create other vulnerabilities. Then it can help holders in the future. Since according to the theory of probability 100% there will be people who will lose the keys.
well in theory you can just steal all tokens from anyone you like. Tell the person that they should write their keys down or tell em to approve tokens to a backup address.
1 Like
Yes, it definitely creates vulnerabilities. What is the account that controls the destroy functionality? It can be compromised, hacked, socially engineered, or it could be abused for reasons other than simple token recovery.
Note that prominent centralized tokens (USDC, USDT) have functionality similar to this, and they are often a point of criticism, but they also have a strong institutional and legal framework around them so most people feel okay with those particular cases.
1 Like
Will there be a vulnerability from this function if there are 25 administrators in the smart contract ? Any action will require the signature of 25 administrators. If there is such a function. In the future, I will be more respected. Since I provided for user errors, the human factor. If this poses a risk of hacking using artificial intelligence, which quantum computers will use in the future, then this feature is not needed.
Sure you can have a 25/25 multisig, but it's still a problem. How will people know that they are actually 25 different entities?
1 Like
the required signature of >25 admins makes it more secure but be sure that nothing is safe against quantum computers but that's nothing you as a programming need to care about. Same about artificial intelligence no need to worry that it'll hack your code 
1 Like
If I have to add this feature, then I will publish on the site that all signatures of 25 administrators belong to the project owner. And that they are needed so that the bad guys do not take over the smart contract. Users will be glad that only the founder of the project has the keys, who firmly holds all the money in his fist and that there are not 25 different entities that milk the project like a cow from 25 sides. I would like this feature to be. Indeed, in this case, the project will be able to return the tokens that the user sent to the wrong address or lost access to the wallet, provided that it proves this in a personal meeting. But if this feature creates a risk, then you will have to refuse.
I'm not good at programming. ) When hacking, there are three troubles
1 user can lose money
2 I disgraced myself and the whole planet knew it
3 Some hypocrites who know me will be happy about it.
Therefore, I need to create the most secure smart contract in September-October.
well this function poses a simple centralization risk and thus the risk of being exploited by those having access to transfer the tokens. But you could for example keep track of all the tokens sent out by any user so that the user at max can receive whatever he sent out. This still could be bypassed pretty easily and wouldn't help a lot but maybe this gives you any other idea to make the function less vulnerable to exploits by whoever has access to it.
1 Like
Do you mean front running ?
The general idea about multisig wallets is that not 1 person can authorize an actions. Not just because hey key can be stolen, but also for that 1 person to steal all the funds. Requiring an transactions to be signed by 25 different keys from one person is just "strange" to say the least.
Requiring a 25/25 signing is on-realistic on a normal multisig transactions due to keys being lost, people leaving etc. So that's not a viable option. Having 1 person using 25 keys is defeating the person, exposes the same risk to loss of keys and provides very little extra security compared to 2-3 signatures in that case. It would probably even nullify the 25 signatures as it becomes so cumbersom that you'll probably have most of them on computer anyway, making the hacker get all keys anyway.
Its always good to have a rescue function in your contract that allows a depositor to withdraw any accidental deposited invalid tokens to be returned. Having an admin function that's allowed to do whatever they want with the tokens is a bad sign in general, although with upgradable contracts the risk is exactly same as the owner can just upgrade to a contract does that this also. That is why people prefer contract's that have been renounced by their owners. That way they have "some" feeling of security.
But you can look at it from a different angle, perhaps this person wants more security. For example, hackers in the future will get access to a powerful quantum computer and will choose a smart contract to hack, I think they will go through a smart contract with 25 administrators and do something simpler.
Perhaps I will change the plan and stop at 7 admins.
There is still time until autumn, if the truth is that immutability is better, then you need to make an immutable smart contract. But the most important thing is not to regret it in the future, if new situations arise that are not currently known.
My advice would be to use a multi-sig wallet like Gnosis Safe Wallet for the admin role if you are concerned about the risk of one of the wallets being hacked/leaked.
To further protect the project include a pause functionality which prevent any actions except admin actions in case of a hack or some other bug and include a recoverERC20 which allows an admin or maybe anyone to recover any tokens not meant to be sent to the contract.
When you are done with the smart contracts make sure to hire one or more reputable auditor(s) that can check the contract for unexpected issues. Solidity seems like an extremely easy language to start out with (which it is) however it contains a lot of nuances / details making it easy for people to steal funds or lock your contract as it does not function like any βnormalβ program.
If you think you know all the possible attack vectors make sure to try out https://ethernaut.openzeppelin.com/ and see if you know the most common ones and after that check out the different audit reports on https://code4rena.com/
Even the best solidity projects make mistakes, so good audits are a requirement. Just make sure to find got auditors, a lot of so called auditors are just out for a quick buck and have very little knowledge.
1 Like
Thank you, I will study it and apply it, now I am more sure that, for example, stablecoin smart contracts, even if there are three administrators, then each administrator has one such, and not a simple wallet.
I would like to deploy to BEP20 as the old smart contract is to BEP20. Since I think that at the moment the commissions on BEP20 are much less than on Ethereum. I donβt know how it will be in the future, but at the moment, I would like users to lose less money on commissions. Or do you strongly recommend me to deploy a smart contract on Ethereum?
I should have a smart contract within the next two months, I planned in the fall, but we will lose too much time, so we will have to do it faster, after the smart contract is, I will show it to you.
The biggest market share is on the ethereum chain. Other blockchains have a lot lower costs, but ethereum has the most money behind it. If your building just a token ethereum is still the best place to be. If your making an dApp or any kind of real application (or just a quick buck) then other blockchains are definitely viable.
1 Like