Simple Smart contract without any extra function best way to avoid exploit

Hi

I’m about to deploy Smart contract Token for a project tokenomic.

After few reads and understanding of the few historic exploit that happened on various projects,
Can we conclude that the best way to avoid “exploit” & “hack” is to write the simpliest smart contract, with only mandatory function like send / receive / read and avoid to add any extra function.

No burn, no mint, no transferowner, nothing :slight_smile:

Handle the lock/unlock manualy from seed wallet and ensure the seedpassphrase of this wallet is never compromised by anyone else who isn’t in charge of this wallet.

Am I correct ?

Thank you for your help :slight_smile:

You’re asking a very controversial and philosophical question.

You should do your best to follow best security practices no matter how simple or how complex a project is. The solution is not “make a simple product” because that philosophy generally makes lackluster products that does not appeal to customers. Great products and security can coexist. If you’re pushing for security, just don’t be the block that stops innovation.

https://consensys.github.io/smart-contract-best-practices/recommendations/
https://docs.soliditylang.org/en/latest/security-considerations.html
https://docs.openzeppelin.com/contracts/4.x/api/security

I think it would be funny if you told the bZx team that the solution to their problem was to just include the simplest smart contract functions.

1 Like

Hi

Thank you a lot for the answer :slight_smile:

I get your point, security can be associated with functionnality.

When there’s lending process involved, obviously it become way more complex and open to potential breach.

I still have a lot to learn about smart contract possibilities ^^

Lets go study :slight_smile:

Cheers.

@Tsushima_Yoshiko raises important considerations. That being said, it’s true that reducing code complexity can result in a system easier to understand and to implement, less prone to bugs or confusion. Reduced functionality also results in reduced attack surface.

Nevertheless, there is no direct relationship between code size and security. Sometimes you need to add code to fix something, sometimes you need to remove it ¯\(ツ)

Ok thanks :slight_smile:

I spend whole day trying to understand how to implement one function ^^

Based on your openZeppelin pattern on github, but I must admit I’m pretty lost.

I will start a new thread, I guess it can help someone else in my case, very noob to smart contract, to go step by step from scratch into something functionnal.

If you’re new follow this guide, you will need to use hardhat.

You might want to follow the hardhat guide first.

1 Like