https://blog.chain.link/twap-vs-vwap/
https://uniswap.org/blog/uniswap-v3-oracles
http://blog.pessimistic.io/chainlink-vrf-secure-integration-tips-specifications-eafd63e87022
http://blog.pessimistic.io/oracles-entropy-chainlink-vrf-secure-integration-tips-13c27d8fde48?1
#EDUCATION
https://uniswap.org/blog/uniswap-v3-oracles
http://blog.pessimistic.io/chainlink-vrf-secure-integration-tips-specifications-eafd63e87022
http://blog.pessimistic.io/oracles-entropy-chainlink-vrf-secure-integration-tips-13c27d8fde48?1
#EDUCATION
chain.link
TWAP vs. VWAP Price Algorithms | Chainlink
A breakdown of Web3 price data methodologies. Specifically, the difference between time-weighted average price (TWAP) and volume-weighted average price (VWAP).
Forwarded from EthSecurity
🔴Many security vulnerabilities come from faulty assumptions
Identifying the assumptions made by the devs and evaluating if they are correct can uncover big discrepancies between what the code does vs what it is intended to do
Here are examples of common faulty assumptions: 📔
1. Initialization functions will only be called ONCE and/or can be called only by the contract deployer
2. Only admins can call certain functions(access control issues)
3. Functions will always be called in a certain order as expected by the system
Ex. what if there's a function that closes a position but expects that you opened one in the 1st place?
A function that checks if your payment is on time but expects you got a loan before that?
4. Parameters can only have non-zero values or values within a certain threshold
addresses will never be zero-valued
sender will always be different from the receiver
an element of a struct array will always exist so the values won't be the default ones
5. Certain addresses or data values can never be attacker-controlled
6. Function calls will always be successful and so checking for return values is not required
These are just a few examples of common assumptions that don't always hold true
Always try to identify what assumptions are made when writing the code and compare that to how the system could actually behave
@EthSecurity1
Identifying the assumptions made by the devs and evaluating if they are correct can uncover big discrepancies between what the code does vs what it is intended to do
Here are examples of common faulty assumptions: 📔
1. Initialization functions will only be called ONCE and/or can be called only by the contract deployer
2. Only admins can call certain functions(access control issues)
3. Functions will always be called in a certain order as expected by the system
Ex. what if there's a function that closes a position but expects that you opened one in the 1st place?
A function that checks if your payment is on time but expects you got a loan before that?
4. Parameters can only have non-zero values or values within a certain threshold
addresses will never be zero-valued
sender will always be different from the receiver
an element of a struct array will always exist so the values won't be the default ones
5. Certain addresses or data values can never be attacker-controlled
6. Function calls will always be successful and so checking for return values is not required
These are just a few examples of common assumptions that don't always hold true
Always try to identify what assumptions are made when writing the code and compare that to how the system could actually behave
@EthSecurity1
Daily Security
https://dacian.me/series/vulnerability-deep-dives
Vulnerable spots of Lending/Borrowing protocols
https://mixbytes.io/blog/vulnerable-spots-of-lending-protocols
https://dacian.me/lending-borrowing-defi-attacks
https://mixbytes.io/blog/vulnerable-spots-of-lending-protocols
https://dacian.me/lending-borrowing-defi-attacks
mixbytes.io
Vulnerable Spots of Lending Protocols
In this article we will try to go through the core security vulnerabilities common to the lending protocol.
👍1
Forwarded from EthSecurity
nonReentrant modifiers might potentially cause a DoS attack.
https://medium.com/@bloqarl/uncovering-real-life-examples-of-denial-of-service-attacks-on-smart-contracts-8bc220c2cdd0
@EthSecurity1
https://medium.com/@bloqarl/uncovering-real-life-examples-of-denial-of-service-attacks-on-smart-contracts-8bc220c2cdd0
@EthSecurity1
Medium
How to identify Denial of Service attacks on Smart Contracts?
If you have been trying to learn about potential cases of DoS attacks and end up always with the same examples (as I did), you might be…
Forwarded from EthSecurity
Are you familiar with the challenges borrowing and lending protocols face?
#web3sec #defi
Dive into:
- Illiquid liquidations
- Collateral Safeness
- The dangers of governance
- Oracle risk and cost of manipulation
https://tokeninsight.com/en/research/market-analysis/the-7-deadly-sins-of-lending-protocols
@EthSecurity1
#web3sec #defi
Dive into:
- Illiquid liquidations
- Collateral Safeness
- The dangers of governance
- Oracle risk and cost of manipulation
https://tokeninsight.com/en/research/market-analysis/the-7-deadly-sins-of-lending-protocols
@EthSecurity1
Tokeninsight
The 7 Deadly Sins of Lending Protocols
Lending protocols have been a major target for hacks and attacks over the last few years, as many platforms often fail to ensure the security of their code, while others overestimate the safety of their economic designs. However, the industry has been learning…
Forwarded from EthSecurity
Web3 Dev
1)How do you construct a lending protocol that supports arbitrary collateral, has no oracles, and has no expirations?
Read the whitepaper to find out:
paradigm.xyz/2023/05/blend
2) Web3education.dev brought by patrick collins
@EthSecurity1
1)How do you construct a lending protocol that supports arbitrary collateral, has no oracles, and has no expirations?
Read the whitepaper to find out:
paradigm.xyz/2023/05/blend
2) Web3education.dev brought by patrick collins
@EthSecurity1
Paradigm
Blend: Perpetual Lending With NFT Collateral - Paradigm
Paradigm is a research-driven crypto investment firm that funds companies and protocols from their earliest stages.
👍1
Forwarded from EthSecurity
If you see a Solidity method that has an argument of type array, always check for 3 things:
1. What if the array length is 0?
2. What if there are duplicated elements in the array?
3. What if there are zero value elements in the array?
@EthSecurity1
1. What if the array length is 0?
2. What if there are duplicated elements in the array?
3. What if there are zero value elements in the array?
@EthSecurity1
Forwarded from EthSecurity
Heads up! Some Curve ETH pools have a major bug that allows an attacker to manipulate the virtual_price.
https://twitter.com/danielvf/status/1657019677544001536?s=19
@EthSecurity1
https://twitter.com/danielvf/status/1657019677544001536?s=19
@EthSecurity1
X (formerly Twitter)
Daniel Von Fange (@danielvf) on X
Heads up! Some Curve ETH pools have a major bug that allows an attacker to manipulate the virtual_price.
This includes the largest pool on Curve.
1/5
This includes the largest pool on Curve.
1/5
👍1
Audit checklists for CDP( Collaterized Debt Positions)
Give it a star🙏
https://github.com/Decurity/audit-checklists/blob/master/cdp.md
Give it a star🙏
https://github.com/Decurity/audit-checklists/blob/master/cdp.md
👌1
Multichain Auditor
Observations and tips for auditing protocols on multiple chains 🧐
https://github.com/0xJuancito/multichain-auditor
Observations and tips for auditing protocols on multiple chains 🧐
https://github.com/0xJuancito/multichain-auditor
GitHub
GitHub - 0xJuancito/multichain-auditor: Observations and tips checklist for auditing protocols on multiple chains 🧐
Observations and tips checklist for auditing protocols on multiple chains 🧐 - 0xJuancito/multichain-auditor
👍5