structure updates

still need to fix links

docs/build/builder-guides/layer-1/astar-beta-labs/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "Astar Beta Labs",
+    "position": 11
+}

docs/build/builder-guides/layer-1/astar-beta-labs/account-unification/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "Account Unification",
+    "position": 1
+}

docs/build/builder-guides/layer-1/astar-beta-labs/account-unification/index.md

@@ -0,0 +1,152 @@
+# Account Unification
+
+## Overview
+
+Astar Substrate is a Multi-VM chain that consists of Astar EVM and Astar Native (Wasm) smart contract environments that are interoperable in nature. This allows developers to create impactful and innovative solutions for end users on top of Astar Substrate, however, it comes at the expense of what is considered good UX.
+
+Astar EVM is powered by Frontier (a combination of pallets and client for emulating EVM networks) which enables Astar Substrate to run a highly ETH equivilent L1 chain on top of a Substrate-based chain. Since both EVM and Native Substrate chains have independent address and signature schemes that are distinct from one another, interoperability between them becomes a challenge.
+
+The Astar Substrate chain consists of:
+
+- Astar Substrate EVM: This is powered by [`frontier`](https://github.com/paritytech/frontier) and uses ETH address schemes where user address is `H160`
+- Astar Substrate Native (Wasm): The address scheme is `AccountId32` where user address is described in `SS58` format.
+
+All the solutions that require performing actions on other VMs, i.e interoperability between VMs like `XVM` and `frontier`, require a deterministic way of converting their addresses to the other VM’s address scheme.
+
+:::caution
+Throughout this doc we will use words “address” and “account” interchangeably, although they are different in literal sense, in the context of this doc they are treated the same.
+:::
+
+:::info
+Account Unification codebase has been audited in December 2023 - Audit report is available on [Astar Network Audit Reports](https://github.com/AstarNetwork/Audits)
+:::
+
+### How does `frontier` handle accounts?
+
+Put simply, there are a set of Native Substrate accounts existing in parallel to the EVM accounts managed by the `frontier` pallet, and one-to-one mappings from the Substrate accounts to EVM accounts are defined by a conversion trait called `AddressMapping` in the `frontier` pallet’s config.
+
+For each H160 address, the EVM pallet uses `AddressMapping` to generate a corresponding SS58 address, which is the account that's *actually* used to interact with the native side of chain, including by holding its balance in `pallet-balances`. So, the native balance is *actually* stored in `pallet-balances` via the SS58 address generated by the mapping.
+
+In short, every EVM address used on the Astar Substrate EVM has an SS58 counterpart existing on the Native side, so, in a sense, the generated SS58 account acts as the backend for all the operations of the H160 native account.
+
+
+$$
+AddressMapping(H160_A) => SS58_A
+
+$$
+
+
+This architecture makes it easier for the EVM side chain to interact seamlessly with the native chain. For example we can wrap the pallet’s interfaces via precompiles for EVM users to consume, and all the pallet’s calls will originate from the SS58 address.
+
+Problems associated with this,
+
+- Since the SS58 address is generated using hashed derivation formula, there is no known private key attached to it. Thus, a user can’t control it directly; actually, no one can.
+- The mapping happens in one direction only, i.e from H160 → SS58. We can obtain an SS58 address that's associated with an H160 but it doesn't go the other way around in order to derive an H160 address from a given SS58.
+
+### How does `XVM` handle accounts?
+
+Since XVM allows smart contracts from either VM to call each other, we require a way to convert addresses both ways.
+
+Before Account Unification, the XVM pallet used the same `AddressMapping` trait from the `frontier` pallet for conversions from H160 → SS58 and `AccountMapping` (a new trait) for conversions from SS58 → H160.
+
+Since the conversions are one way only, this is not a complete solution. That means there is no way to derive the original address from a generated address, if wanting to go in the other direction.
+
+## What is Account Unification?
+
+AU is designed to solve the core problems described above:
+
+- **No double mapping**: This has the most impact since without it we can’t go back on a generated address. For example, if we have a SS58 corresponding to H160, we can’t know which H160 it belonged to.
+- **Users can’t control the generated address:** This is more on UX side, since Astar is a Cross-VM, users are encouraged to engage with both EVM and native Wasm ecosystems equally, but managing two different accounts for two VMs that are not interchangeable with one another is bad UX, from user’s perspective.
+
+Account Unification (AU) provides users the ability to bind their H160 and SS58 addresses together and create double mappings, which can then be used by low-level solutions that require address conversions, such as EVM (i.e `frontier`) and XVM.
+
+![Without-Unification](./img/without.png)
+
+![With-Unification](./img/with.png)
+
+## How does AU work?
+
+We introduced a new pallet called [`pallet-unified-accounts`](https://github.com/AstarNetwork/Astar/tree/master/pallets/unified-accounts) responsible for managing double mappings between address schemes (H160 and SS58).
+
+### `pallet-unified-accounts`
+
+The Unified Accounts pallet provides functionality for native account holders to connect their EVM address and have a unified experience across the different VMs by providing an ETH signature to prove their ownership over their EVM Address.
+
+The pallet has two dispatch-able calls,
+
+- `claim_evm_address` : Users can submit a signature to prove their ownership over the EVM address and therefore claim it, thus creating a double mapping between these accounts, SS58 and H160.
+- `claim_default_evm_address`: If a user is not interested in controlling the generated account and only wants to have a double mapping, this is used. It creates a double mapping based on the (existing) default generated EVM address.
+
+The Unified Accounts pallet provides implementations of various address conversion traits that can consumed by other solutions, such as `AddressMapping` for `frontier` and `AccountMapping` for `XVM`.
+
+**Signature Scheme**
+
+Users need to provide a valid [EIP712 signed payload](https://eips.ethereum.org/EIPS/eip-712) of their SS58 address. The payload for EIP712 signatures consists of two parts, domain hash and type hash with the actual payload.
+
+Below is a very simple snippet to produce the signed payload and claim accounts using `ethers.js`,
+
+```jsx
+async function buildSignature(signer, substrateAddress, api, chainId) {
+  return await signer.signTypedData(
+    {
+      chainId: chainId, // evm chain id
+      name: "Astar EVM Claim", // app name
+      version: "1", // version
+      salt: await api.query.system.blockHash(0), // genesis hash
+    },
+    {
+      Claim: [{ name: "substrateAddress", type: "bytes" }],
+    },
+    {
+      substrateAddress,
+    }
+  );
+}
+```
+
+## New Possibilities
+
+After AU there are a lot of new possibilities enabled by the double mappings between account schemes. Some of the impactful ones are below,
+
+### Unified Balance
+
+After the accounts are unifed, they’ll share the same balances across EVM and Substrate Native. This is true for native assets like XC20 (`pallet-assets`), as well as native balances (`pallet-balances`).
+
+### Transfer XC20 to Native Addresses
+
+Previously there was no proper way to transfer XC20 Assets to a native account. AU changes this, and if the recipient user has AU enabled then the user/dapp can fetch the connected EVM address and send the tokens to that address, as both accounts (native and EVM) are unified.
+
+### Transfer funds directly to EVM Address
+
+Users can now transfer funds directly to their EVM address without the need to calculate a derived SS58 address (i.e selecting `Address20` in Lookup values.)
+
+This is valid for all EVM addresses and *does not require AU to be enabled.*
+
+![Lookup-Use](./img/lookup.png)
+
+## Things to consider
+
+If it's too good to be true then it probably is!
+
+### Mappings are immutable
+
+Under the current design, once mappings are in place they cannot be modified. This is a precautionary measure to prevent loss of funds and other potential mishaps since the act of modifying the underlying SS58 address of an EVM account is very sensitive.
+
+Since accounts are dispensable, if a user wishes to change mappings he/she can simply create a new set of accounts to be connected.
+
+### Manually transfer the native state (including funds)
+
+Since before unifying the accounts any interaction from the EVM to the Native side is performed via the default derived account, including all the holdings
+of native funds like XC20, dAppStaking rewards (if interacted with staking precompiles), etc, thus they need to be transferred to the new SS58 account before accounts are unified otherwise the funds will be lost. The pallet only handles the transfer of native balances, and all other native assets need to be transferred manually.
+
+Also for EVM smart contract developers, if a contract is XVM enabled and it calls into a Wasm contract, there should be a mechanism in place to migrate the state to a new SS58 account so that users can do that before unifying accounts.
+
+:::caution
+It is strongly advised to use only the Astar Portal for unifying accounts as it is designed to handle the asset transfer process properly. **If the pallet’s extrinsics are used directly then native funds will be lost forever.**
+:::
+
+### Problems with EVM Indexers & Explorers
+
+Once accounts are unified they share balances (XC20, native balance) and both accounts can control them.
+
+When balances are updated on the native side there are no logs or events emitted on the EVM side, thus indexers and block explorers face problems displaying accurate balances for native assets.

docs/build/builder-guides/layer-1/astar-beta-labs/account-unification/users_guide.md

@@ -0,0 +1,103 @@
+---
+sidebar_position: 2
+---
+# How to create a unified account
+
+import guide01 from "./img/guide01.png"
+import guide02 from "./img/guide02.png"
+import guide03 from "./img/guide03.png"
+import guide04 from "./img/guide04.png"
+import guide05 from "./img/guide05.png"
+import guide06 from "./img/guide06.png"
+
+## What is a Unified Account?
+
+Creating a Unified account is simple, however, it's important to understand that this is still an emerging technology. We do not recommend attempting account unification until you are familiar with how it works.
+
+A Unified account provides a simplified experience for end-users of Astar Substrate-based networks. Since on Astar Substrate, native Wasm and the EVM use two different address formats, new users find it challenging to grasp how they function. While both Astar Native and Astar EVM accounts are *typically* required, with unified accounts, users don't have to worry about which wallet they are connected to. When unifed accounts work in conjuction with XVM, they are designed to form a powerful new way to abstract away the inner workings of the Substrate native VM side from end users, entirely, allowing them to interact with both networks seamlessly using only MetaMask.
+
+## What is possible?
+
+- Two accounts; one balance. When accounts are unified, they share the same balance. The moment ASTR tokens are withdrawn from a CEX exchange to an Astar Native account, the balance is updated on the Astar EVM side. There's no need to transfer between them any longer; users can stake tokens immediately, for example, or use a DEX.
+
+- Furthermore, it's already possible to interact with Wasm dApps using a Unified account, as long as the dApp supports EVM wallets. The core team is currently developing XVM, which allows a Unified account to interact with EVM smart contracts.
+
+## How to create an unified account
+
+:::caution
+At this moment this feature is only available on Shibuya testnet.
+:::
+
+### Disclaimer: Before creating a Unified account, please ensure you understand the following
+
+- Unified accounts are specific to each network. Creating a Unified account on Shibuya using Shibuya Native account A and Shibuya EVM account A does not carry over to Shiden or Astar.
+
+- Staking balances on the EVM must be unstaked first before initiating the process since staked tokens cannot be transferred to the unified balance.
+
+- Custom xcTokens (rather than official XCM tokens) are not included automatically during the account unification process, so they need to be transferred to an EVM wallet separately. To obtain test xcTokens on Shibuya, please contact @kahori on Discord.
+
+- There is a fee (slightly more than 1 SBY) for creating a Unified account. If you have an existing Account ID (Substrate), this charge acts more like a deposit than a fee. However, it can not be refunded as accounts currently cannot be separated after they are unified.
+
+### 1, Start by connecting Native account.
+
+Please prepare following:
+
+- **Shibuya Native account**
+- **Shibuya EVM account**
+- Must have no staking balance.
+- Must have non-zero balances on both accounts (enough for gas) Use the faucet built into the [Portal](https://portal.astar.network) to obtain enough for gas fees, if you need to.
+- To understand the process more thoroughly, obtain some test tokens. Please ask a team member if you do not know how to obtain test tokens.
+
+Make sure you are connected to the Shibuya testnet. You should see a new account icon on the Asset page, and can initiate the process from there.
+
+<div style={{textAlign: 'center'}}>
+  <img src={guide01} style={{width: 600}} />
+  </div>
+
+<div style={{textAlign: 'center'}}>
+  <img src={guide02} style={{width: 600}} />
+  </div>
+
+### 2, Read the disclaimer.
+
+<div style={{textAlign: 'center'}}>
+  <img src={guide03} style={{width: 450}} />
+  </div>
+
+### 3, Connect to EVM wallet.
+
+It is recommended to use a new wallet, but if you wish to use an existing EVM account, please make sure to unstake all tokens first.
+
+<div style={{textAlign: 'center'}}>
+  <img src={guide04} style={{width: 450}} />
+  </div>
+
+### 4, Add your account name.
+
+The account name will be visible on-chain. We are working on adding NFT pfp support in time for when Account Unification comes on Astar.
+
+<div style={{textAlign: 'center'}}>
+  <img src={guide05} style={{width: 450}} />
+  </div>
+
+### 5, Send xcTokens.
+
+xcTokens do not live in the EVM account balance. Before unifying the balance, the portal will send xcTokens to a Unified account. When testing the environment, most of you may not have xcTokens. Please find a team member and ask for them for this purpose. You will be asked to sign an EVM transaction.
+
+<div style={{textAlign: 'center'}}>
+  <img src={guide06} style={{width: 450}} />
+  </div>
+
+### 6, Confirm everything looks okay. Press the button and the accounts will be unified.
+
+### 7, To confirm the accounts were unified:
+
+- Check that the SBY tokens balances are unified.
+
+- Check that xcTokens ERC token balances are available after connecting a Substrate wallet.
+
+- You can send xcTokens from the unified Substrate account.
+
+:::note
+We are working on a wallet modal to create a Unified Account section, where users can use unified accounts without needing to select a specific wallet.
+:::

docs/build/builder-guides/layer-1/astar-beta-labs/index.md

@@ -0,0 +1,12 @@
+# Astar Beta Labs
+
+## Overview
+
+This section is for experimental technologies and features that are still in development that may only be available in testnet environments.
+
+<br/>
+
+import DocCardList from '@theme/DocCardList';
+import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
+
+<DocCardList items={useCurrentSidebarCategory().items}/>

docs/build/builder-guides/layer-1/astar-beta-labs/metamask-snaps/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "MetaMask Snaps",
+    "position": 2
+}

docs/build/builder-guides/layer-1/astar-beta-labs/metamask-snaps/index.md

@@ -0,0 +1,13 @@
+# MetaMask Snaps
+
+## Overview
+
+MetaMask Snaps allow users to add features and functionality to their MetaMask wallet. Individual snaps are features created by third-party developers that MetaMask users can install directly into their wallet. MetaMask Snaps Open Beta is a first look at what's possible when extending the capabilities of the MetaMask wallet. Snaps run in a sandboxed environment and use a permissions model to protect your data and respect your consent. Snaps don’t have access to your MetaMask account data. When installing a Snap, you can always verify the permissions you are granting.
+
+:::note
+Snap-based accounts are derived from the private key associated with your MetaMask account (your seed phrase), so funds cannot be lost even in the event support for a particular Snap is discontinued.
+:::
+
+Learn more about how to use the Astar MetaMask Snap [here.](https://docs.astar.network/docs/use/manage-wallets/wallet-providers/metamask-astar-snap/)
+
+Please note that this section is part of Astar Beta Labs and may contain incomplete or outdated information. For production-ready solutions, please refer to material outside the Astar Beta Labs section.