Update Faucet Link, Upgraded guides section

docs/about/networks/README.md

@@ -26,4 +26,4 @@ keywords:
 | CL Explorer        | https://gnosischa.in/            | https://beacon.chiadochain.net       |
 | Fork monitor       | https://forkmon.gnosischain.com  | https://forkmon.chiadochain.net      |
 | EthStats           | https://ethstats.gnosischain.com | https://ethstats.chiadochain.net     |
-| Faucet             | https://gnosisfaucet.com         | https://faucet.chiadochain.net/      |
+| Faucet             | https://faucet.gnosischain.com/  | https://faucet.chiadochain.net/      |

docs/bridges/About Token Bridges/hashi-integration.md

@@ -0,0 +1,116 @@
+---
+sidebar_position: 5
+title: Hashi Integration
+description: How do the bridges work after Hashi integration
+keywords: [amb bridge, arbitrary message bridge, omnibridge, xdai bridge, hashi]
+---
+
+# Hashi integration
+
+The proposal of Hashi integration on Gnosis Chain's bridges (AMB & Omnibridge, xDAI bridge) is [approved by Gnosis DAO members](https://forum.gnosis.io/t/gip-93-should-gnosisdao-support-the-integration-of-hashi-within-gnosis-chains-canonical-bridges/8245/5) on April 2nd, 2024. The integration introduces advanced security measures, mitigates systemic risks, and ensures the Gnosis Chain ecosystem remains resilient against the evolving landscape of security threats. With the efforts from Cross-Chain Alliance and Gnosis team, the integration is going toward production.
+
+## What’s new?
+
+1. Hashi Manager contract: New contract. Set reporters, adapters, and threshold parameters used by the bridge contract.
+2. New variables/function:
+   1. HASHI_ENABLED: New variable. When set to true, every message can be approved by Hashi, but the message need not to be approved by Hashi for it to get executed.
+   2. HASHI_MANDATORY: New variable. When set to true, every message has to be approved by Hashi before execution.
+   3. isApprovedByHashi(bytes32 msgId): New public function. Return whether a message w.r.t a message Id is approved by Hashi.
+   4. setHashiManager(address HashiManager): New function, onlyOwner. Set Hashi Manager contract on the bridge contract.
+3. Modified events:
+   1. xDAI Bridge: in xDAI bridge, a `bytes32 nonce` is added into `UserRequestForAffirmation` and `UserRequestForSignature` events.
+      1. `event UserRequestForAffirmation(address recipient, uint256 value)` is changed to `event UserRequestForAffirmation(address recipient, uint256 value, bytes32 nonce)`
+      2. `event UserRequestForSignature(address recipient, uint256 value)` is changed to `UserRequestForSignature(address recipient, uint256 value bytes32 nonce)`
+
+## AMB & Omnibridge
+
+![](../../../static/img/bridges/hashi/Hashi-Gnosis-AMB.png)
+
+For Omnibridge / AMB:
+
+**Ethereum → Gnosis Chain**
+
+1. User approves token for Foreign Omnibridge
+2. User calls ForeignOmnibridge.relayTokens(address token, address receiver, uint256 amount)
+   1. ForeignOmnibridge calls ForeignAMB.requireToPassMessage()
+   2. ForeignAMB check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage
+   3. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters.
+   4. Reporters relay the messageId and message hash to adapter contract on Gnosis Chain.
+   5. Light Client based oracle only stores hashes on Gnosis Chain.
+3. If Hashi is enabled & mandatory, off chain executor calls Gnosis Chain’s Yaru.executeMessages(), which check if the hash is agreed upon a threshold amount of adapters (set in Hashi Manager contract) adapters and set isApprovedByHashi(messageId) to true eventually.
+4. Bridge validators detects UserRequestForAffirmation event and call HomeAMB.executeAffirmation. If Hashi is enabled & mandatory, this step has to wait after step 3.
+
+**Gnosis Chain → Ethereum**
+
+1. User approves token for Home Omnibridge
+2. User calls HomeOmnibridge.relayTokens(address token, address receiver, uint256 amount)
+   1. HomeOmnibridge calls HomeAMB.requireToPassMessage()
+   2. HomeAMB check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage
+   3. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters.
+   4. Reporters relay the messageId and message hash to adapter contract on Ethereum.
+3. Bridge validators detects UserRequestForSignature event and call HomeAMB.submitSignatures.
+4. If Hashi is enabled & mandatory, off chain executor calls Ethereum’s Yaru.executeMessages(), which check if the hash is agreed upon adapters and set isApprovedByHashi(messageId) to true eventually.
+5. User claims token by calling Ethereum’s ForeignAMB.executeSignatures().
+
+## xDAI briddge
+
+![](../../../static/img/bridges/hashi/Hashi-Gnosis-AMB.png)
+
+**Ethereum → Gnosis Chain**
+
+1. User approves token for Foreign xDAI bridge.
+2. User calls ForeignXDAIBridge.relayTokens(address receiver, uint256 amount)
+   1. ForeignXDAIBridge check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage
+   2. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters.
+   3. Reporters relay the messageId and message hash to adapter contract on Gnosis Chain.
+   4. Light Client based oracle only stores hashes on Gnosis Chain.
+3. If Hashi is enabled & mandatory, off chain executor calls Gnosis Chain’s Yaru.executeMessages(), which check if the hash is agreed upon a threshold amount of adapters (set in Hashi Manager contract) and set isApprovedByHashi(messageId) to true eventually.
+4. Bridge validators detects UserRequestForAffirmation event and call HomexDAIBridge.executeAffirmation. If Hashi is enabled & mandatory, this step has to wait after step 3. Block Reward contract emits AddedReceiver event, which will mint equivalent amount of xDAI to receiver in the next block.
+
+**Gnosis Chain → Ethereum**
+
+1. User calls HomexDAIBridge.relayTokens(address receiver, uint256 amount) or transfer xDAI to HomexDAIBridge without msg.data.
+   1. HomexDAIBridge check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage
+   2. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters.
+   3. Reporters relay the messageId and message hash to adapter contract on Ethereum.
+2. Bridge validators detects UserRequestForSignature event and call HomexDAIBridge.submitSignatures.
+3. If Hashi is enabled & mandatory, off chain executor calls Ethereum’s Yaru.executeMessages(), which check if the hash is agreed upon adapters and set isApprovedByHashi(messageId) to true eventually.
+4. User claims token by calling Ethereum’s ForeignxDAIBridge.executeSignatures(). DAI is transfer to the receiver eventually.
+
+# Testnet environment
+
+For testing purpose, we've set up testnet environemnt. Users are welcome to experiment with the testnet environments:
+
+- Sepolia addresses
+  1. ForeignAMB: [0x2F62433e00168af10c70bc39e2fDbEe5DaCA257b](https://sepolia.etherscan.io/address/0x2F62433e00168af10c70bc39e2fDbEe5DaCA257b)
+  2. Hashi Manager: [0x6C5F4F8a719bF054D6b08E3cCc27a5f208Ec8766](https://sepolia.etherscan.io/address/0x6C5F4F8a719bF054D6b08E3cCc27a5f208Ec8766#writeProxyContract)
+- Chiado addresses
+  1. Home AMB: [0xAF18353BF369897Aab18ec225422F921be9F7eC6](https://gnosis-chiado.blockscout.com/address/0xAF18353BF369897Aab18ec225422F921be9F7eC6?tab=contract)
+  2. Hashi Manager: [0xe505cD6522E9A1c2309a915f83dDCA9addaC0895](https://gnosis-chiado.blockscout.com/address/0xe505cD6522E9A1c2309a915f83dDCA9addaC0895?tab=contract_code)
+  3. AMB BridgeHelper: [0x3fba3D7Ae204a684E4359A3fC211C18EA155cd78](https://gnosis-chiado.blockscout.com/address/0x3fba3D7Ae204a684E4359A3fC211C18EA155cd78)
+
+## Omnibridge
+
+- Sepolia address
+  1. Foreign Omnibridge: [0xc4e06E44B2d1e148beFAa3cB2012A985EFe7032a](https://sepolia.etherscan.io/address/0xc4e06E44B2d1e148beFAa3cB2012A985EFe7032a)
+  2. WETH Router: [0x65E64139f202F89cb6b4bFc140bf01Cda1886465](https://sepolia.etherscan.io/address/0x65E64139f202F89cb6b4bFc140bf01Cda1886465#code)
+- Chiado address
+  1. Home Omnibridge: [0xB866dC5321Ca41a22938A7afD5Bc3c5069975874](https://gnosis-chiado.blockscout.com/address/0xB866dC5321Ca41a22938A7afD5Bc3c5069975874?tab=write_proxy)
+
+## xDAI
+
+- Sepolia addresses
+  1. Foreign xDAI: [0x97589968FA7ef153af44C6F5d0Fb9AcaEA97AC94](https://sepolia.etherscan.io/address/0x97589968FA7ef153af44C6F5d0Fb9AcaEA97AC94)
+  2. Hashi Manager: [0x90d3c0c9BCb317E80A459B0126257665186E59fa](https://sepolia.etherscan.io/address/0x90d3c0c9bcb317e80a459b0126257665186e59fa#code)
+- Chiado addresses
+  1. Home xDAI: [0x867696eA1cfA243aB909797022D0A0C99BdACcF1](https://gnosis-chiado.blockscout.com/address/0x867696eA1cfA243aB909797022D0A0C99BdACcF1?tab=contract)
+  2. Hashi Manager: [0x5b745C021ef62f90862a812EB6763f5758e51eE2](https://gnosis-chiado.blockscout.com/address/0x5b745C021ef62f90862a812EB6763f5758e51eE2?tab=contract)
+  3. xDAI Bridge Helper: [0xA7bE47d1111baFDb2f0E9ce8D6431508aC2fd98e](https://gnosis-chiado.blockscout.com/address/0xA7bE47d1111baFDb2f0E9ce8D6431508aC2fd98e#code)
+
+## Reference
+
+1. AMB contracts: https://github.com/crosschain-alliance/tokenbridge-contracts/tree/feat/hashi-integration-amb
+2. xDAI bridge contracts: https://github.com/crosschain-alliance/tokenbridge-contracts/tree/feat/hashi-integration-xdai-bridge
+3. Test: https://github.com/crosschain-alliance/tokenbridge-contracts-migration-tests
+4. Audits: https://crosschain-alliance.gitbook.io/hashi/v0.2/audit-report#gnosis-bridge-hashi-integration
+5. Hashi: https://crosschain-alliance.gitbook.io/hashi/v0.2/introduction

docs/node/Node Tools/eth-docker.md

@@ -1,18 +1,18 @@
 ---
-title: eth-docker
+title: Eth-docker
 ---
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-# eth-docker
+# Eth-docker
 
-[eth-docker](https://eth-docker.net/) is a docker automation project for Ethereum consensus and execution clients. It aims to make running a Ethereum staking full node simpler than setting everything up manually, while allowing the user choice when it comes to the exact client mix they wish to run.
+[Eth-docker](https://eth-docker.net/) is a docker automation project for Ethereum consensus and execution clients. It aims to make running a Ethereum staking full node simpler than setting everything up manually, while allowing the user choice when it comes to the exact client mix they wish to run.
 
-eth-docker allows user to set up Gnosis clients by answering simple dialog-based questions on terminal.
+Eth-docker allows user to set up Gnosis clients by answering simple dialog-based questions on terminal.
 
 ## References
-1. eth-docker Docs: https://eth-docker.net/
+1. Eth-docker Docs: https://eth-docker.net/
 2. Github: https://github.com/eth-educators/eth-docker
 
 

docs/technicalguides/Confidential Computing/secret-network.md

@@ -0,0 +1,19 @@
+# Secret Network
+
+On most blockchains, all data is public by default. While this works for many of the popular Web3 applications we see today, having the ability to keep some data confidential unlocks powerful new capabilities. Incorporating decentralized confidential computing (DeCC) enables things like private voting for DAOs, secure random number generation for gaming, encrypted databases for various applications, encrypted data tied to NFTs, sealed-bid auctions, and encrypted order books for DeFi applications. All of this can be built on Gnosis by utilizing [Secret Network](https://scrt.network)’s Confidential Computing Layer.
+
+## Integrating Secret's Confidential Computing Layer​
+
+You can integrate Secret’s CCL into an existing Gnosis application, or design a new application from the ground up to take advantage of the unique use-cases it enables.
+
+To start, check out Secret Network’s [Confidential Computing Layer](https://scrt.network/confidential-computing-layer) landing page to get an overview of how it works, and example use-cases for inspiration. From there you’ll find multiple links to Secret's CCL documentation:
+
+1. [Basics](https://docs.scrt.network/secret-network-documentation/confidential-computing-layer/ethereum-evm-developer-toolkit/basics) - explains the cross-chain communication technologies used, and how to connect a MetaMask wallet to Secret Network.
+
+2. [Use-cases](https://docs.scrt.network/secret-network-documentation/confidential-computing-layer/ethereum-evm-developer-toolkit/usecases) - provides tutorials showing how to build various types of EVM applications using Secret’s CCL. All of these tutorials can be used to deploy a contract on Gnosis.
+
+3. [Supported Networks](https://docs.scrt.network/secret-network-documentation/confidential-computing-layer/ethereum-evm-developer-toolkit/supported-networks) - provides a list of gateway contract addresses. This is how your Gnosis application will communicate with Secret.
+
+## Get Support
+
+To get CCL development help, you can join the Secret Network [Discord](https://scrt.network/discord) or [Telegram](https://scrt.network/SCRTCommunity). You can also [get in touch](mailto:info@scrt.network) with the Secret Network team directly.

docs/technicalguides/custom-signers/README.md

@@ -0,0 +1,35 @@
+---
+sidebar_position: 4
+sidebar_label: Custom Signers
+---
+
+# Custom Signers
+
+Custom signers allow developers to inject their own signing mechanisms tailored to specific use cases. This flexibility enhances security, usability, and adaptability in different environments, such as multi-signature wallets or smart contract interactions.
+
+## Why Use Custom Signers?
+
+### Tailored Signing Methods
+With custom signers, you can personalize the signing process to fit your dApp’s specific needs. This could mean automatic signing for trusted operations, requiring additional confirmation for sensitive actions, or integrating unique hardware devices for enhanced security.Users can now interact with dapps by just using their emails or passkeys.
+
+### Enhanced Security
+Custom signers give developers more control over how and where signing keys are stored. This can include signing transactions in hardware security modules (HSMs), using a multi-sig contract, or requiring multi-factor authentication before a transaction is signed.
+
+### Optimized for Specific Use Cases
+Whether you’re dealing with privacy-focused transactions, or social recovery mechanisms, custom signers can be configured to handle the specific logic needed. They allow for flexibility in crafting unique user flows that require specialized transaction signing methods.
+
+
+
+
+<CardContainer>
+    <Card
+        title="Privy"
+        subtitle="Guide to intgerate Privy Wallet and SDK"
+        url="/technicalguides/custom-signers/privy" 
+    />
+    <Card
+        title="Dynamic"
+        subtitle="Guide to intgerate Dynamic Wallet and SDK"
+        url="/technicalguides/custom-signers/dynamic" 
+    />
+</CardContainer>

docs/technicalguides/custom-signers/dynamic.md

@@ -0,0 +1,142 @@
+---
+description: Dynamic offers smart and beautiful login flows for crypto-native users, simple onboarding flows for everyone else, and powerful developer tools that go beyond authentication.
+keywords: [dynamic ,custom-signers]
+---
+
+# Dynamic
+
+Dynamic offers smart and beautiful login flows for crypto-native users, simple onboarding flows for everyone else, and powerful developer tools that go beyond authentication. This is a basic guide which demonstrates the integration of Dynamic wallet with Gnosis chain and generate offchain user signatures.
+
+![Dynamic Image](../../../static/img/signers/dynamic.png)
+
+
+## Guide
+
+- Create a NextJs application from scratch
+
+```
+npx create-next-app dynamic-gnosis
+# install with Tailwind
+```
+- Install Dynamic labs SDK & some other dependencies
+
+```
+npm install @dynamic-labs/ethereum @dynamic-labs/ethers-v6 @dynamic-labs/sdk-react-core
+```
+
+- Create an account at [Dynamic Web App](https://app.dynamic.xyz/) and choose the Ethereum Sandbox option.
+In the dashboard, enable the networks you want to allow your users. For our example we will enable Gnosis network. Also make sure you have Email as an authentication enabled for your users. This helps create a wallet by just using user's email.
+
+- In the [developers section](https://app.dynamic.xyz/dashboard/developer/api), copy the Environment ID, we will need this in the next step.
+
+- Initialize the SDK in your **layout.tsx** file like this. The goal is to initialize the SDK as early as possible when loading you application. Put your Environment ID in the proper variable.
+Make sure you have **EthersExtension** also added in the extensions variable, this will be useful later!
+```
+export default function RootLayout({
+  children,
+}: {
+  children: React.ReactNode;
+}) {
+  return (
+    <html lang="en">
+      <DynamicContextProvider
+        settings={{
+          environmentId: "<Replace with you own Environment ID>",
+          walletConnectors: [EthereumWalletConnectors],
+          walletConnectorExtensions: [EthersExtension],
+        }}
+      >
+        <body className={inter.className}>{children}</body>
+      </DynamicContextProvider>
+    </html>
+  );
+}
+
+```
+
+
+- Create a components folder and inside that create a component **DynamicWidgetButton.tsx** and here we need to declare our DynamicWidget component provided to us by Dynamic SDK.
+
+```
+export const DynamicWidgetButton: React.FC = () => {
+  return (
+    <div style={{ display: 'flex', flexDirection: 'column', alignItems: 'center', marginBottom: '20px' }}>
+      <Title level={3} style={{ marginBottom: '20px' }}>Wallet Interaction</Title>
+      <div style={{ display: 'flex', justifyContent: 'center', alignItems: 'center' }}>
+        <DynamicWidget />
+      </div>
+    </div>
+  );
+};
+
+```
+
+- Now we can use and initialize the Dynamic wallet anywhere in our app by just using the above component!
+
+- Let's create our Main component in **page.tsx** file.
+
+In this file, we will [**useDynamicContext**](https://docs.dynamic.xyz/sdks/react-sdk/hooks/usedynamiccontext#header) provided by the dynamic sdk to fetch the wallet connected. We will also use this same wallet to execute all our ethers expression.
+
+```
+  const { primaryWallet } = useDynamicContext();
+```
+
+- In our application, we have built a basic **Signer** component which uses the connected Dynamic wallet to generate a signature from the user.
+
+
+```
+  const signMessage = async () => {
+    if (!primaryWallet) {
+      console.error("No primary wallet connected");
+      return;
+    }
+
+    try {
+      const signedMessage = await primaryWallet.connector.signMessage('You are signing an example message');
+      if (signedMessage) {
+        setSignature(signedMessage);
+      } else {
+        setSignature(null);
+      }
+    } catch (error) {
+      console.error("Error signing message:", error);
+      setSignature(null);
+    }
+  };
+```
+
+You can also see that the **signMessage** function is provided by the  Dynamic SDK.  So cool!
+
+## Using ethers
+
+The last piece of component, I want to discuss is the **getBalance** component. Although Dybamic also gives a component to fetch user balance, this function is created to demonstrate how you can use standard ethers expression to build out your app further.
+
+```
+  const getBalance = async () => {
+    if (!primaryWallet) {
+      console.error("No primary wallet connected");
+      return null;
+    }
+
+    const provider = await primaryWallet.connector?.ethers?.getRpcProvider();
+
+    if (!provider) {
+      console.error("No provider available");
+      return null;
+    }
+    try {
+      const balance = await provider.getBalance(primaryWallet.address);
+      console.log(balance);
+      return balance;
+    } catch (error) {
+      console.error("Error getting balance:", error);
+      return null;
+    }
+  };
+
+```
+
+## Demo Application
+
+You can check out this [**repository**](https://github.com/gnosischain/developer-resources/tree/main/custom-signers/dynamic-gnosis) for the full stack application demo.
+