Fix some broken links

Author: elopez

README.md

@@ -1,6 +1,6 @@
 # Building Secure Smart Contracts
 
-![](https://github.com/crytic/building-secure-contracts/actions/workflows/slither.yml/badge.svg) ![](https://github.com/crytic/building-secure-contracts/actions/workflows/echidna.yml/badge.svg) ![](https://github.com/crytic/building-secure-contracts/actions/workflows/medusa.yml/badge.svg)
+![](https://github.com/crytic/building-secure-contracts/actions/workflows/echidna.yml/badge.svg) ![](https://github.com/crytic/building-secure-contracts/actions/workflows/medusa.yml/badge.svg)
 
 Brought to you by [Trail of Bits](https://www.trailofbits.com/), this repository offers guidelines and best practices for developing secure smart contracts. Contributions are welcome, you can contribute by following our [contributing guidelines](https://github.com/crytic/building-secure-contracts/blob/master/CONTRIBUTING.md).
 

development-guidelines/incident_response.md

@@ -49,11 +49,10 @@ Additionally, consider conducting a threat modeling exercise. This exercise will
   - An approachable guide for incident response. Chapter 4 includes examples for how to approach practicing your process.
 - [PagerDuty Incident Response](https://response.pagerduty.com/)
   - A _very_ detailed handbook of how PagerDuty handles incident response themselves. Some useful ideas and resources, but more practical for larger organizations.
-- [How to Hack the Yield Protocol](https://docs.yieldprotocol.com/#/operations/how_to_hack)
-- [Emergency Procedures for Yearn Finance](https://github.com/yearn/yearn-devdocs/blob/master/docs/developers/v2/EMERGENCY.md)
+- [Emergency Procedures for Yearn Finance](https://github.com/yearn/yearn-devdocs/blob/master/docs/developers/security/EMERGENCY.md)
 - [Rekt pilled: What to do when your dApp gets pwned and how to stay kalm - Heidi Wilder (DSS 2023)](https://www.youtube.com/watch?v=TDlkkg8N0wc)
 - [Crisis Handbook - Smart Contract Hack (SEAL)](https://docs.google.com/document/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/edit)
 
 ### Community Incident Retrospectives
 
-- [Yield Protocol](https://medium.com/yield-protocol/post-mortem-of-incident-on-august-5th-2022-7bb70dbb9ada)
+- [Yield Protocol](https://web.archive.org/web/20230105183841/https://medium.com/yield-protocol/post-mortem-of-incident-on-august-5th-2022-7bb70dbb9ada)

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

@@ -4,7 +4,7 @@ In Starknet, addresses are of the `felt` type, while on L1 addresses are of the
 
 # Example
 
-Consider the following code to initiate L2 deposits from L1. The first example has no checks on the `to` parameter, and depending on the user's address, it could transfer tokens to an unexpected address on L2. The second example, however, adds verification to ensure this does not happen. Note that the code is a simplified version of how messages are sent on L1 and processed on L2. For a more comprehensive overview, see here: [https://www.cairo-lang.org/docs/hello_starknet/l1l2.html](https://docs.cairo-lang.org/hello_starknet/l1l2.html).
+Consider the following code to initiate L2 deposits from L1. The first example has no checks on the `to` parameter, and depending on the user's address, it could transfer tokens to an unexpected address on L2. The second example, however, adds verification to ensure this does not happen. Note that the code is a simplified version of how messages are sent on L1 and processed on L2. For a more comprehensive overview, see here: [https://www.cairo-lang.org/docs/hello_starknet/l1l2.html](https://web.archive.org/web/20250117175431/https://docs.cairo-lang.org/hello_starknet/l1l2.html).
 
 ```solidity
 contract L1ToL2Bridge {

not-so-smart-contracts/cosmos/abci_panic/README.md

@@ -43,6 +43,6 @@ func validateTotalBorrows(ctx sdk.Context, k keeper.Keeper) {
 
 ## External examples
 
-- [Gravity Bridge can `panic` in multiple locations in the `EndBlocker` method](https://giters.com/althea-net/cosmos-gravity-bridge/issues/348)
+- [Gravity Bridge can `panic` in multiple locations in the `EndBlocker` method](https://github.com/althea-net/cosmos-gravity-bridge/issues/348)
 - [Agoric `panic`s purposefully if the `PushAction` method returns an error](https://github.com/Agoric/agoric-sdk/blob/9116ede69169ebb252faf069d90022e8e05c6a4e/golang/cosmos/x/vbank/module.go#L166)
 - [Setting invalid parameters in `x/distribution` module causes `panic` in `BeginBlocker`](https://github.com/cosmos/cosmos-sdk/issues/5808). Valid parameters are [described in the documentation](https://docs.cosmos.network/v0.45/modules/distribution/07_params.html).

not-so-smart-contracts/substrate/randomness/README.md

@@ -61,4 +61,4 @@ Note that the quality of randomness provided to the `pallet-bad-lottery` pallet
 - https://docs.substrate.io/reference/how-to-guides/pallet-design/incorporate-randomness/
 - https://ethresear.ch/t/rng-exploitability-analysis-assuming-pure-randao-based-main-chain/1825/7
 - https://ethresear.ch/t/collective-coin-flipping-csprng/3252/21
-- https://github.com/paritytech/ink/issues/57#issuecomment-486998848
+- https://github.com/use-ink/ink/issues/57#issuecomment-486998848

not-so-smart-contracts/substrate/verify_first/README.md

@@ -1,6 +1,6 @@
 # Verify First, Write Last
 
-**NOTE**: As of [Polkadot v0.9.25](https://github.com/substrate-developer-hub/substrate-docs/issues/1215), the **Verify First, Write Last** practice is no longer required. However, since older versions are still vulnerable and because it is still best practice, it is worth discussing the "Verify First, Write Last" idiom.
+**NOTE**: As of [Polkadot v0.9.25](https://github.com/polkadot-developers/substrate-docs/issues/1215), the **Verify First, Write Last** practice is no longer required. However, since older versions are still vulnerable and because it is still best practice, it is worth discussing the "Verify First, Write Last" idiom.
 
 Substrate does not cache state prior to extrinsic dispatch. Instead, state changes are made as they are invoked. This is in contrast to a transaction in Ethereum where, if the transaction reverts, no state changes will persist. In the case of Substrate, if a state change is made and then the dispatch throws a `DispatchError`, the original state change will persist. This unique behavior has led to the "Verify First, Write Last" practice.