run formatter

Author: montyly

not-so-smart-contracts/cairo/README.md

@@ -14,14 +14,14 @@ Each _Not So Smart Contract_ consists of a standard set of information:
 
 ## Vulnerabilities
 
-| Not So Smart Contract                                                          | Description                                                  |
-| ------------------------------------------------------------------------------ | ------------------------------------------------------------ |
-| [Arithmetic overflow](arithmetic_overflow)                                     | Insecure arithmetic in Cairo for the felt252 type            |
-| [L1 to L2 Address Conversion](l1_to_l2_address_conversion)                     | Essential L2 address checks for L1 to L2 messaging           |
-| [L1 to L2 message failure](l1_to_l2_message_failure)                           | Messages sent from L1 may not be processed by the sequencer  |
-| [Overconstrained L1 <-> L2 interaction](overconstrained_l1_l2_interaction)     | Asymmetrical checks on the L1 or L2 side can cause a DOS     |
-| [Signature replays](replay_protection)                                         | Necessary robust reuse protection due to account abstraction |
-| [Unchecked from address in L1 Handler](unchecked_from_address_in_l1_handler)   | Access control issue when sending messages from L1 to L2     |
+| Not So Smart Contract                                                        | Description                                                  |
+| ---------------------------------------------------------------------------- | ------------------------------------------------------------ |
+| [Arithmetic overflow](arithmetic_overflow)                                   | Insecure arithmetic in Cairo for the felt252 type            |
+| [L1 to L2 Address Conversion](l1_to_l2_address_conversion)                   | Essential L2 address checks for L1 to L2 messaging           |
+| [L1 to L2 message failure](l1_to_l2_message_failure)                         | Messages sent from L1 may not be processed by the sequencer  |
+| [Overconstrained L1 <-> L2 interaction](overconstrained_l1_l2_interaction)   | Asymmetrical checks on the L1 or L2 side can cause a DOS     |
+| [Signature replays](replay_protection)                                       | Necessary robust reuse protection due to account abstraction |
+| [Unchecked from address in L1 Handler](unchecked_from_address_in_l1_handler) | Access control issue when sending messages from L1 to L2     |
 
 ## Credits
 

not-so-smart-contracts/cairo/arithmetic_overflow/README.md

@@ -2,7 +2,6 @@
 
 The default primitive type, the field element (felt), behaves much like an integer in other languages, but there are a few important differences to keep in mind. A felt can be interpreted as an unsigned integer in the range [0, P], where P, a 252 bit prime, represents the order of the field used by Cairo. Arithmetic operations using felts are unchecked for overflow or underflow, which can lead to unexpected results if not properly accounted for. Do note that Cairo's builtin primitives for unsigned integers are overflow/underflow safe and will revert.
 
-
 ## Example
 
 The following simplified code highlights the risk of felt underflow. The `check_balance` function is used to validate if a user has a large enough balance. However, the check is faulty because passing an amount such that `amt > balance` will underflow and the check will be true.
@@ -20,10 +19,9 @@ fn check_balance(self: @ContractState, amt: felt252) {
 }
 
 ```
+
 ## Mitigations
 
 - Always add checks for overflow when working with felts directly.
 - Use the default signed integer types unless a felt is explicitly required.
 - Consider using Caracal, as it comes with a detector for checking potential overflows when doing felt252 arithmetic operaitons.
-
-

not-so-smart-contracts/cairo/overconstrained_l1_l2_interaction/README.md

@@ -1,6 +1,6 @@
 # Overconstrained L1 <-> L2 interaction
-When interacting with contracts that are designed to interact with both L1 and L2, care must be taken that the checks and validations on both sides are symmetrical. If one side has more validations than the other, this could create a situation where a user performs an action on one side, but is unable to perform the corresponding action on the other side, leading to a loss of funds or a denial of service.
 
+When interacting with contracts that are designed to interact with both L1 and L2, care must be taken that the checks and validations on both sides are symmetrical. If one side has more validations than the other, this could create a situation where a user performs an action on one side, but is unable to perform the corresponding action on the other side, leading to a loss of funds or a denial of service.
 
 ## Example
 
@@ -56,4 +56,4 @@ function _buildPayload(address recipient, address token, uint256 amount) interna
 
 ## Mitigations
 
-- Make sure to validate that the checks on both the L1 and L2 side are similar enough to prevent unexpected behavior. Ensure that any unsymmetric validations on either side cannot lead to a tokens being trapped or any other denial of service.
+- Make sure to validate that the checks on both the L1 and L2 side are similar enough to prevent unexpected behavior. Ensure that any unsymmetric validations on either side cannot lead to a tokens being trapped or any other denial of service.

not-so-smart-contracts/cairo/replay_protection/README.md

@@ -30,5 +30,3 @@ Consider the following function that validates a signature for EIP712-style perm
 ## Mitigations
 
 - Consider using the [OpenZeppelin Contracts for Cairo Account contract](https://github.com/OpenZeppelin/cairo-contracts/blob/main/docs/modules/ROOT/pages/accounts.adoc) or another existing account contract implementation.
-
-

not-so-smart-contracts/cairo/unchecked_from_address_in_l1_handler/README.md

@@ -2,7 +2,6 @@
 
 A function with the `l1_handler` annotation is intended to be called from L1. The first parameter of the `l1_handler` function is always `from`, which represents the `msg.sender` of the L1 transaction that attempted to invoke the function on Starknet. If the `l1_handler` function is designed to be invoked from a specific address on mainnet, not checking the from address may allow anyone to call the function, opening up access control vulnerabilities.
 
-
 ## Example
 
 The following Starknet bridge contract's owner, specified in the `uint256[] calldata payload` array, is designed to be called only from the `setOwnerOnL2()` function. Even though the owner is checked on the solidity side, the lack of validation of the `from_address` parameter allows anyone to call the function from an arbitrary L1 contract, becoming the owner of the bridge on L2.
@@ -36,7 +35,8 @@ fn set_owner_from_l1(ref self: ContractState, from_address: felt252, new_owner:
 }
 
 ```
+
 ## Mitigations
 
 - Make sure to validate the `from_address`, otherwise any L1 contract can invoke the annotated Starknet function.
-- Consider using Caracal, as it comes with a detector for verifying if the `from_address` is unchecked in an `l1_handler` function.
+- Consider using Caracal, as it comes with a detector for verifying if the `from_address` is unchecked in an `l1_handler` function.