Audited/standardised smart contracts #251
Replies: 4 comments
-
It’s a really great callout! We do plan on tackling this to an extent. We would never advocate for completely avoiding a security audit, but our hope is we can can help teams get a defence in depth approach that reduces both the sole reliance on auditing as the security gate and reduce the likelihood of major rework after an audit (and needing multiple expensive audits). some of the plans for this include integrating static code analysis into the Algokit experience and providing pre-built contracts/templates. There may be other things too, but we’re also open to ideas from the community. |
Beta Was this translation helpful? Give feedback.
-
I think, the pool smart contracts touch on this, pools work as vaults do as I have been playing with beaker's examples by Barnji and the similarity is really close, so we can gladly say that part is resolved. Static code analysis is great, but having formal verification as well would increase security coverage, there is a public discussion on Stackoverflow on Static Code Analysis vs Formal Verification and their definitions, find it here: https://stackoverflow.com/questions/35533434/is-static-analysis-really-formal-verification |
Beta Was this translation helpful? Give feedback.
-
You can write formal verification tests by using the kavm framework https://github.com/runtimeverification/kavm-demo |
Beta Was this translation helpful? Give feedback.
-
Thanks, this is super helpful ! |
Beta Was this translation helpful? Give feedback.
-
So, the smart contract development process, especially for high-value DeFi/Open-Finance applications needs security audits, in many cases even 1 or 3 rounds. For NFT apps and the rest, not so much needed, as these other apps don't hold money on-chain.
Everyone is enthusiastic about algokit, but, how exactly will it solve this problem of expensive security audits. I hate to burst our bubbles here, but, audits are not cheap, and for 2 programs we wrote in our team, it went for 24,000$ ( 22,000 $ - negotiated price ) , that's just too much , at least for most teams and is a barrier for everyone and anyone who wants to quickly develop a DeFi app, build and deploy, even an MVP. Reach is an EVM/Algorand DSL, and claimed to solve security audit costs using formal verification, it has not achieved that 100% as formal verifications only helps with tokens not getting lock-in to contracts. Reach contracts, are therefore equally in need of audits if you write them, so, how will algokit & beaker included, solve this issue. One thing that contributes to contract errors is how hard it is to writing/reading or understanding a contract, most errors are developer-caused, unless of course you are a developer from NK and already had bad intentions beforehand.
It would be a good idea to cover this with algokit. I have seen on the docs, that audited/standardized contracts will be possible, curious how this is going to be achieved.
An idea for the best audited/pre-standardized smart contract type we can start with, would be Smart Contract Vaults in TEAL, it would kill more than two birds with one stone.
Why? Vaults are the most common smart contracts for De-Fi apps, just looking out there shows it all:
... and many others
So, Vaults, would be the best option to work on using audited/standardized contracts, and starting with them would have a lot of positive developer impact on Algorand, and also the mission for Algorand which is to be the blockchain for FutureFi!
cc : @johnalanwoods @Loedn @robdmoore
Originally posted by @kcelestinomaria in #204 (comment)
Beta Was this translation helpful? Give feedback.
All reactions