fix typos (#8)

This commit is contained in:
omahs 2024-12-08 21:23:42 +01:00 committed by GitHub
parent b8418464bb
commit f6e3b53c1f
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
6 changed files with 12 additions and 12 deletions

View file

@ -12,7 +12,7 @@
* Bridges also have additional “attack surface” as compared to “regular” DeFi projects. While a yield farm or a decentralized exchange might have a collection of smart contracts and a dapp web page, a bridge usually needs monitoring nodes, validator keys, and secure communication channels on top of those contracts and dapp.
* Most bridges implement "IOU" approcah: users send funds to the bridge protocol, where those funds are locked by the bridge smart contract. The bridge then issues the user an equivalent asset on the second network from the second bridge smart contract. The tokens on the destination chain are wrapped tokens. Bridges accumulate a lot of funds.
* Most bridges implement "IOU" approach: users send funds to the bridge protocol, where those funds are locked by the bridge smart contract. The bridge then issues the user an equivalent asset on the second network from the second bridge smart contract. The tokens on the destination chain are wrapped tokens. Bridges accumulate a lot of funds.
<br>
@ -30,7 +30,7 @@
* Aurora is an implementation of an EVM built on the NEAR network that supports all tools available in the Ethereum ecosystem.
* Aurora developed the Rainbow Bridge which allows users to transfers assets between Ethereum, NEAR, and Aurora.
* Aurora developed the Rainbow Bridge which allows users to transfer assets between Ethereum, NEAR, and Aurora.
* Two contracts in the Aurora Engine are interesting to us: `ExitToNear` and `ExitToEthereum`. They are special, built-in (precompiled) contracts that handle withdraw requests from the Aurora EVM.

View file

@ -22,7 +22,7 @@
### EVM and Ethermint transactions
* Transactions are one of Ethereum's key functionalities, and they are the only thing that can modify or update the state of the blockchain. They are signed messages sent by the Ethereum network to every node via the "flood routing" protocol.
* New transactions looks as follow:
* New transactions look as follow:
1. Nonce: an originating EOA-issued sequence number used to prevent message replay.
2. Gas price: how much Ether (in Wei) the originator is prepared to pay for each unit of gas.
@ -32,7 +32,7 @@
6. Data: variable-length binary data payload.
7. v,r,s: the three components of the original EOA's ECDSA digital signature.
* The Ethermint's chain perform state transitions by using `MsgEthereumTx`. This message provides the relevant transaction data elements and wraps an Ethereum transaction as an SDK message.
* The Ethermint's chain performs state transitions by using `MsgEthereumTx`. This message provides the relevant transaction data elements and wraps an Ethereum transaction as an SDK message.
* When transactions are consumed in Ethermint, they pass via a sequence of handlers. The `AnteHandler` is one of these handlers, and it's in change of conducting preliminary message execution business logic such as fee payment, signature verification, and so on. It only applies to transactions conducted through the Cosmos SDK. Because the EVM handles the same business logic, Ethereum routed transactions will be unaffected.
<br>
@ -49,7 +49,7 @@
<br>
### Vulnerabilty Fix
### Vulnerability Fix
* Check if the `MsgEthereumTx` is contained inside the transaction.

View file

@ -6,7 +6,7 @@
<br>
* Using a flashloan from `IdleTokenGovernance.sol` affected the `totalSupply` fo the Idle tokens, which was used to calculate the price of the token.
* Using a flashloan from `IdleTokenGovernance.sol` affected the `totalSupply` of the Idle tokens, which was used to calculate the price of the token.
* Price calculations were based on the `totalNav / totalSupply` of the tokens.
* It's worth noting the initial Idle Token integration was with v4, which did not have any flashloan logic. That was later added in v5, thus unintentionally introducing a bug into Enzyme's Finance protocol.
@ -50,7 +50,7 @@
### PoC
1. Fund malicious contract with WETH to be able to swap it later for USDC to pay for a flashloan.
2. Make a flashloan of IdleUSCDYield tokens. This will in fact, affect GAV calculations.
2. Make a flashloan of IdleUSDCYield tokens. This will in fact, affect GAV calculations.
3. During a flashloan, call `buyShares`. As GAV calculations are affected, we are buying shares at a discount now.
4. Repay flashloan.
5. Call `redeemShares` to sell all the bought shares of Idle fund for a profit.

View file

@ -24,7 +24,7 @@
<br>
#### create an enviroment for testing
#### create an environment for testing
* static analysis
* fuzzing and poc exploits (use foundry)

View file

@ -7,12 +7,12 @@
<br>
* `tx.origin` needs to bere placed by `msg.sender`, otherwise any contract you call can act on your behalf.
* `tx.origin` needs to be replaced by `msg.sender`, otherwise any contract you call can act on your behalf.
* inline assembly should be used only in rare cases.
* unclear semantics: `now` is alias for `block.timestamp` not current time; use of low level `call`, `callcode`, `delegatecall` should be avoided whenever possible; use `transfer` whenever failure of ether transfer should rollnack the whole transaction.
* unclear semantics: `now` is alias for `block.timestamp` not current time; use of low level `call`, `callcode`, `delegatecall` should be avoided whenever possible; use `transfer` whenever failure of ether transfer should rollback the whole transaction.
* beware of caller contracts: `selfdestruct` can block calling contracts unexpectedly.
* invocation of local functions via `this`: never use `this` to call functions in the same contract, it only consumes more gas than normal call.
* transferring Ether in a for/while/do-while loop should be avoid due to the block gas limit.
* transferring Ether in a for/while/do-while loop should be avoided due to the block gas limit.
* erc20 `decimals` should have `uint8` as return type.
<br>

View file

@ -2,7 +2,7 @@
pragma solidity ^0.7.6;
// This contract is designed to act as a time vault.
// User can deposit into this contract but cannot withdraw for atleast a week.
// User can deposit into this contract but cannot withdraw for at least a week.
// User can also extend the wait time beyond the 1 week waiting period.
/*