GITBOOK-249: No subject

SUMMARY.md

@@ -2,33 +2,24 @@
 
 * [😀 What is ALEX?](README.md)
 
-## 📈 Trading, Lending and Borrowing
+## 📈 Automated Market Making
 
-* [Our Design](trading-lending-and-borrowing/platform-architecture-that-supports-ecosystem-development.md)
+* [Our Design](automated-market-making/platform-architecture-that-supports-ecosystem-development.md)
-* [Trading Pool](trading-lending-and-borrowing/trading-pool/README.md)
+* [Our Design](automated-market-making/trading-pool.md)
-* [Collateral Rebalancing Pool](trading-lending-and-borrowing/collateral-rebalancing-pool.md)
+* [Collateral Rebalancing Pool](automated-market-making/collateral-rebalancing-pool.md)
-* [Yield Token Pool](trading-lending-and-borrowing/automated-market-making-designed-for-lending-protocols.md)
+* [Yield Token Pool](automated-market-making/automated-market-making-designed-for-lending-protocols.md)
-* [Vault](trading-lending-and-borrowing/vault.md)
+* [Vault](automated-market-making/vault.md)
 
 ## 🧙‍♀️ Bitcoin Oracle
 
 * [What is the Bitcoin Oracle](bitcoin-oracle/what-is-the-bitcoin-oracle/README.md)
   * [Why Bitcoin Oracle - BRC20](bitcoin-oracle/what-is-the-bitcoin-oracle/what-is-the-bitcoin-oracle.md)
 * ["On Demand" Consensus Data](bitcoin-oracle/on-demand-consensus-data.md)
-* [Threshold-based Consensus](bitcoin-oracle/threshold-based-consensus/README.md)
-  * [Threshold Sampling](bitcoin-oracle/threshold-based-consensus/threshold-sampling.md)
 * [Security Audits](bitcoin-oracle/security-audits.md)
 
-## 🩸 Bitcoin Bridge
+## 🩸 XLink
 
-* [What is the Bitcoin Bridge](bitcoin-bridge/what-is-the-bitcoin-bridge.md)
+* [XLink](https://docs.xlink.network)
-* [Reserves](bitcoin-bridge/reserves.md)
-* [Integrations](bitcoin-bridge/integrations/README.md)
-  * [Bitcoin](bitcoin-bridge/integrations/understanding-the-bitcoin-bridge.md)
-  * [Bitcoin L2s](bitcoin-bridge/integrations/bitcoin-l2s.md)
-  * [Non-Bitcoin chains](bitcoin-bridge/integrations/non-bitcoin-chains.md)
-* [🟧 aBTC, a.k.a ALEX BTC](bitcoin-bridge/abtc-a.k.a-alex-btc.md)
-* [Security Audits](bitcoin-bridge/security-audits.md)
 
 ## 🚅 Orderbook
 
@@ -56,5 +47,5 @@
 * [Protocol Contracts](developers/protocol-contracts/README.md)
   * [amm-pool-v2-01.clar](developers/protocol-contracts/amm-pool-v2-01.clar.md)
   * [amm-registry-v2-01.clar](developers/protocol-contracts/amm-registry-v2-01.clar.md)
-  * [amm-vault-v2-01.clar](developers/protocol-contracts/amm-vault-v2-01.clar.md) 
+  * [amm-vault-v2-01.clar](developers/protocol-contracts/amm-vault-v2-01.clar.md)
 * [REST API](developers/api-references.md)

automated-market-making/automated-market-making-designed-for-lending-protocols.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # Yield Token Pool
 
 Please refer to our [white paper](https://docs.alexgo.io/whitepaper/automated-market-making-of-alex) for a more rigorous treatment on the subject.

automated-market-making/collateral-rebalancing-pool.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # Collateral Rebalancing Pool
 
 Please refer to our [white paper](../whitepaper/automated-market-making-of-collateral-rebalancing-pool.md) for a more rigorous treatment on the subject.

automated-market-making/platform-architecture-that-supports-ecosystem-development.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # Our Design
 
 ALEX allows for implementation of arbitrary trading strategies and borrows its design from [Balancer V2](https://docs.balancer.fi).
@@ -10,7 +14,7 @@ Equation triggers Pool rebalancing. This allows creation of any arbitrary rebala
 
 ### Generalised Mean Equation
 
-Generalised Mean Equation is an invariant function associated with generalised mean that underpins the [non-lending Trading Pools](trading-pool/) at ALEX. With a suitable parameterisation, Generalised Mean Equation supports both risky pairs (i.e. $$x y=L$$), stable pairs (i.e. $$x +y=L$$) and any linear combination in-between (i.e. Curve)
+Generalised Mean Equation is an invariant function associated with generalised mean that underpins the [non-lending Trading Pools](trading-pool.md) at ALEX. With a suitable parameterisation, Generalised Mean Equation supports both risky pairs (i.e. $$x y=L$$), stable pairs (i.e. $$x +y=L$$) and any linear combination in-between (i.e. Curve)
 
 ### Weighted Equation
 

automated-market-making/trading-pool.md

@@ -1,10 +1,10 @@
-# Trading Pool
+# Our Design
 
 ## Introduction
 
-In this section you will find an overview of the ALEX on-chain Trading Pool and its automated market making (AMM) protocol.
+In this section you will find an overview of the ALEX "Trading Pool" and its automated market making (AMM) protocol.
 
-At ALEX, we build DeFi primitives targeting developers looking to build ecosystem on Bitcoin, enabled by [Stacks](https://www.stacks.co/). As such, we focus on trading, lending and borrowing of crypto assets with Bitcoin as the settlement layer and Stacks as the smart contract layer. At the core of this focus is the automated market making ("AMM") protocol, which allows users to exchange one crypto asset for another in a trustless manner.
+At ALEX, we build DeFi primitives targeting developers looking to build ecosystem on Bitcoin. As such, we focus on trading of crypto assets with Bitcoin as the settlement layer. At the core of this focus is the AMM protocol, which allows users to exchange one crypto asset for another in a trustless manner.
 
 Trading Pool implements Generalized Mean Equation and, with a suitable parameterisation, supports both risky pairs (i.e. $$x y=L$$), stable pairs (i.e. $$x +y=L$$) and any linear combination in-between (i.e. Curve).
 
@@ -13,8 +13,7 @@ Trading Pool is parameterised with a single parameter $$t$$. $$t$$ can be betwee
 Regarding its implementation, the Trading Pool protocol consists of a set of smart contracts built on the Stacks blockchain that facilitate trading operations within the ALEX DeFi ecosystem. Below, there are listed the main features of the pool.
 
 {% hint style="info" %}
-For more of the theory and fundaments behind the Alex AMM protocol refer to the [ALEX AMM Whitepaper](../../whitepaper/automated-market-making-of-alex/).
+For more of the theory and fundaments behind the Alex AMM protocol refer to the [ALEX AMM Whitepaper](../whitepaper/automated-market-making-of-alex/). If you are looking for technical details and implementation design please refer to the [Developers Protocol Contracts section](../developers/protocol-contracts/#alex-dao-amm-trading-pool).
-If you are looking for technical details and implementation design please refer to the [Developers Protocol Contracts section](../../developers/protocol-contracts/README.md#alex-dao-amm-trading-pool).
 {% endhint %}
 
 {% hint style="danger" %}
@@ -33,9 +32,10 @@ Trading Pool is permission-less in that anyone can register a pair with initial
 
 Certain privileged functions are available to `pool-owner` to govern the pool. The `pool-owner` address is set at the time of a pool creation. ALEX DAO, as part of its governance, has the power to update and replace the `pool-owner` address. Therefore, you can view this as ALEX DAO delegating the governance of each pool to its respective `pool-owner`.
 
-[Refer to the comprehensive list of pool-governed setters](../../developers/protocol-contracts/amm-pool-v2-01.clar.md#setters). 
+[Refer to the comprehensive list of pool-governed setters](../developers/protocol-contracts/amm-pool-v2-01.clar.md#setters).
 
 ## Pool liquidity operations
+
 Users can participate by adding (injecting liquidity with function `add-to-position`) or reducing (withdrawing with function `reduce-position`) assets positions in a specific pool that deals with a pair of tokens. When users add assets, they receive pool tokens (a.k.a. LP Tokens), which represent their share of the pool and potential earnings. When withdrawing assets, users return pool tokens.
 
 ### Adding liquidity
@@ -47,14 +47,14 @@ Once the liquidity is added, the pool will mint a pool token as a proof of propo
 The pool token is transferable and may be used at other protocols (for example, as a collateral).
 
 ### Removing liquidity
+
 When removing liquidity from a pool, you need to specify the percentage of your pool tokens that you want to liquidate, i.e. between 0 and 1.
 
 The percentage will be converted to the number of pool tokens to be burnt and the corresponding amount of token-x and token-y will be sent to you.
 
 ## Trading
 
-When a pool for a specific token pair is funded, it allows users to exchange those tokens, with a fee for each swap.
+When a pool for a specific token pair is funded, it allows users to exchange those tokens, with a fee for each swap. Users can swap one token with another by calling `swap-x-for-y` or `swap-y-for-x`. As the names imply, `swap-x-for-y` swaps token-x into token-y and `swap-y-for-x` swaps token-y into token-x.
-Users can swap one token with another by calling `swap-x-for-y` or `swap-y-for-x`. As the names imply, `swap-x-for-y` swaps token-x into token-y and `swap-y-for-x` swaps token-y into token-x.
 
 Users can specify the slippage limit (the minimum amount of the desired target token they expect to receive: `min-dy` and `min-dx`, respectively), so that the call fails if the swapped amount does not meet your target.
 
@@ -83,59 +83,73 @@ In certain cases, prior information is necessary to perform operations effective
 ## Glossary
 
 ### Base Token
+
 The base token is the cryptocurrency token that a user currently possesses and submits during a swap transaction.
 
 ### Dx
+
 The amount of the token-x involved in liquidity and trading operations.
 
 ### Dy
+
 The amount of the token-y involved in liquidity and trading operations.
 
 ### Factor
+
 The factor is a multiplier (scaling factor) defined within a token pair pool, playing a critical role in determining the value of `dy` (amount of target token) given `dx` (amount of base token) and the pool balances of each token. Together with the token principals, the factor constitutes the pool identifier that is utilized to retrieve the pool details.
 
 ### Fee
-The cost associated with performing a swap or other operations within the platform. It is deducted from each transaction on the "in" leg (i.e., token-x for `swap-x-for-y` and token-y for `swap-y-for-x`).
+
-The fee to be calculated is set at the [pool creation](#pool-creation) and may be updated through the governance.
+The cost associated with performing a swap or other operations within the platform. It is deducted from each transaction on the "in" leg (i.e., token-x for `swap-x-for-y` and token-y for `swap-y-for-x`). The fee to be calculated is set at the [pool creation](trading-pool.md#pool-creation) and may be updated through the governance. Part of the fee may be [rebated](trading-pool.md#fee-rebate) to liquidity providers as a reward.
-Part of the fee may be [rebated](#fee-rebate) to liquidity providers as a reward.
 
 ### Fee Rate
+
 The percentage of the transaction amount that is taken as a fee during a swap or other operations.
 
 ### Fee Rebate
+
 The portion of the swap fee that is reinvested into the relevant pool's liquidity, causing the pool's invariant to increase slightly after each transaction. This mechanism is similar to that of Uniswap V2.
 
 ### In given out
+
 If you want to know the amount of token-x you may need to provide to get a target amount of token-y (or vice versa), you can use `get-x-in-given-y-out` and `get-y-in-give-x-out`, respectively.
 
 ### In given price
+
 If you are an arbitrageur, you may want to know the amount of token-x or token-y you need to provide to rebalance the pool-implied price to a target. In such a case, you can use `get-x-given-price` or `get-y-given-price`.
 
 ### Liquidity Positions
+
 When a user provides liquidity to a pool, they are said to be adding liquidity positions (using the `add-to-position` function). The reverse operation occurs when users withdraw their assets, thus reducing their positions (using the `reduce-position` function). Both operations involve the minting and burning of LP Tokens, respectively, to represent the user's share of the pool.
 
 ### Maximum Dy (`max-dy`)
+
 In the context of an add positions transaction, this amount specifies the maximum quantity of token-y that the user is willing to deposit. If the required amount exceeds this specified limit, the transaction will be reverted with the error `ERR-EXCEEDS-MAX-SLIPPAGE`.
 
 ### Minimum Dy (`min-dy`)
+
 In the context of a swap transaction, this amount defines the minimum quantity of the target token that the user expects to receive. If the resulting amount falls below this specified threshold, the transaction will be reverted with the error `ERR-EXCEEDS-MAX-SLIPPAGE`.
 
 ### Out given in
+
 Sometimes you may want to know the expected amount of token-y if you were to swap certain amount of token-x. Or you may want to know the expected amount of token-x for some token-y. Two read-only functions - `get-y-given-x` and `get-x-given-y` will do that for you.
 
 ### Pool token / LP Token
-Pool token, also known as "LP Token" (Liquidity Provider Token); issued to users who contribute assets to a liquidity pool, representing their share of the pool and potential earnings.
+
-The token contract is `token-amm-pool-v2-01` and it implements [SIP013](https://github.com/stacksgov/sips/pull/42).
+Pool token, also known as "LP Token" (Liquidity Provider Token); issued to users who contribute assets to a liquidity pool, representing their share of the pool and potential earnings. The token contract is `token-amm-pool-v2-01` and it implements [SIP013](https://github.com/stacksgov/sips/pull/42). Each pool is mapped to a unique id (`pool-id`) with associated liquidity mapped to the balance under that id (`token-id`).
-Each pool is mapped to a unique id (`pool-id`) with associated liquidity mapped to the balance under that id (`token-id`).
 
 ### Ratio
+
 The ratio represents the relationship between the amounts of a token pair involved in pool operations. Each pool has two predefined values, `max-in-ratio` and `max-out-ratio`, which set the maximum amounts that can be involved in swap operations.
 
 ### Slippage
+
 In the Automated Market Maker (AMM) Pool contract, slippage refers to the difference between the calculated amount of the target token and the configured maximum or minimum limit during a transaction. If no limit is set, the default limits are `u340282366920938463463374607431768211455` (the maximum value for `uint` type in Clarity language: `2**128 - 1`) for the maximum and `u0` for the minimum. These limits are enforced within the pool contract and are validated using the custom error `ERR-EXCEEDS-MAX-SLIPPAGE`.
 
 ### Swap Transaction
+
 A swap transaction refers to a type of operation whereby a user exchanges a given quantity of one cryptocurrency token for another. Within the context of the ALEX Trading Pool, swap transactions are executed using predefined token pairs existing within a pre-established liquidity pool.
 
 ### Target Token
+
 Also known as the "quoted" token, the target token is the cryptocurrency token that a user will receive as a result of a swap transaction.

automated-market-making/vault.md

@@ -1,10 +1,16 @@
+---
+hidden: true
+---
+
+# Vault
+
 Vault holds and manages the assets of all ALEX pools. The separation of pool and vault has many benefits including, among others, cheaper transaction costs for users and quicker learning curve for developers when building custom pools on ALEX.
 
 {% hint style="info" %}
-If you are looking for technical details and implementation design please refer to the [Developers Protocol Contracts section](../developers/protocol-contracts#vault-amm-vault-v2-01.clar).
+If you are looking for technical details and implementation design please refer to the [Developers Protocol Contracts section](../developers/protocol-contracts/#vault-amm-vault-v2-01.clar).
 {% endhint %}
 
-## Flash Loan
+### Flash Loan
 
 Aggregating the assets of all ALEX pools into a single vault allows for the offering of Flash Loan, [popularized by AAVE](https://aave.com/flash-loans/).
 

bitcoin-bridge/abtc-a.k.a-alex-btc.md

@@ -1,55 +0,0 @@
-# 🟧 aBTC, a.k.a ALEX BTC
-
-### 1 aBTC = 1 BTC
-
-aBTC, or ALEX BTC, is a fully-functional SIP010 token on Stacks, where 1 aBTC represents 1 BTC locked in the multisig operated by ALEX LAB Foundation.
-
-Its role is somewhat similar to the role WETH plays for ETH - it allows BTC to interact with smart contracts on Bitcoin.
-
-When a BTC holder interacts with smart contracts on Stacks, under the hood, [Bitcoin Bridge](broken-reference/) receives BTC into its [multisig](abtc-a.k.a-alex-btc.md#multisig-address) and triggers minting of the corresponding aBTC, which is then sent to the relevant smart contract to interact on behalf of the BTC holder.
-
-aBTC holders can also interact with smart contracts on Stacks (just like they would do with any SIP010 tokens) to receive BTC into their Bitcoin wallet, in which case, Bitcoin Bridge burns aBTC and sends the relevant BTC from its multisig.
-
-### Enabler of Bitcoin Finance
-
-So if we say the combination of Bitcoin as the data layer and Stacks as its smart contract layer is a complete circulatory system that drives the body of Bitcoin economy, Bitcoin Bridge is its blood vessels and aBTC its blood.
-
-### So how is aBTC different from [sBTC](https://sbtc.tech)?
-
-We are introducing aBTC in anticipation of the roll-out of sBTC, to demonstrate to BTC holders what is possible when Bitcoin has its own smart contract layer and prepare our community for the sBTC roll-out.
-
-aBTC gives us an early opportunity to develop the kind of user experience, _that_ Bitcoin DeFi experience, we want to have when sBTC is released and identify the areas of improvement to help its development.
-
-Bitcoin Bridge will readily integrate sBTC when it is available, alongside aBTC.
-
-### So how is aBTC different from [xBTC](https://open.wrapped.com/coins/XBTC)?
-
-ALEX is a big user / supporter of xBTC, which will continue.
-
-xBTC and aBTC are complementary because they follow different custodial models. The former uses institutional custodian and requires KYC for wrap/unwrap, while the latter uses a community-owned multisig and does not require KYC.
-
-We are introducing aBTC because it makes possible the kind of tight integration of BTC with Stacks smart contract we want, to deliver that "native-like" DeFi experience on Bitcoin, which is not possible with xBTC.
-
-### High-level summary of comparison between aBTC, xBTC and sBTC
-
-<table><thead><tr><th></th><th>aBTC</th><th width="186">xBTC</th><th>sBTC</th></tr></thead><tbody><tr><td>Issuer</td><td>ALEX</td><td>Wrapped</td><td>Stacks</td></tr><tr><td>Custodial model</td><td>Community-owned multisig</td><td>Institutional custodian</td><td>Open membership multisig</td></tr><tr><td>Integration with Bitcoin Bridge</td><td>Yes</td><td>No</td><td>Yes</td></tr><tr><td>KYC</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Availability</td><td>Now</td><td>Now</td><td>2024</td></tr></tbody></table>
-
-### Where can I find more information on aBTC?
-
-#### Reserve
-
-{% embed url="https://app.alexlab.co/bridge-reserve" %}
-
-#### Contract deployment
-
-{% embed url="https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.token-abtc?chain=mainnet" %}
-
-#### Multisig address
-
-{% embed url="https://mempool.space/address/bc1pylrcm2ym9spaszyrwzhhzc2qf8c3xq65jgmd8udqtd5q73a2fulsztxqyy" %}
-
-#### Token logo
-
-<figure><img src="https://token-images.alexlab.co/token-abtc" alt=""><figcaption></figcaption></figure>
-
-###

bitcoin-bridge/integrations/README.md

@@ -1,46 +0,0 @@
-# Integrations
-
-Integration requires a deployment of an endpoint smart contract on the target chain.
-
-For EVM-based chains, such endpoints are currently deployed on [Ethereum](https://etherscan.io/address/0xfd9f795b4c15183bdba83da08da02d5f9536748f) and [BNB Chain](https://bscscan.com/address/0xb3955302e58fffdf2da247e999cd9755f652b13b).
-
-Below is a typical integration process, which may take between 1 and 3 weeks.
-
-## Endpoint deployment (1 week)
-
-Endpoints are the smart contracts that handle the asset transfers. They are owned by multisig contracts (for example, [Gnosis Safe](https://safe.global/) on Ethereum and [Executor DAO](https://explorer.stacks.co/txid/0xf4bd95ea0486e6a50ae632c613f1d72b2a5bbbc4211b494cd0f1d3443658544d?chain=mainnet) on Stacks) operated by ALEX LAB Foundation (with a plan to decentralisation).
-
-Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs.
-
-## Configuration of endpoint (< 1 week)
-
-Once the endpoint is deployed, it can be configured to meet the needs of the source chain.
-
-The configuration parameters include, among others,:
-
-* Approved list of tokens to be supported on the Bridge,
-* Approved list of validators whose cryptographic proofs of token transfer event are accepted,
-* Approved list of relayers who can submit the cryptographic proofs from the validators,
-* Validator threshold, and
-* Fee schedule
-
-## Integration with Bitcoin Oracle (> 1 week)
-
-Bitcoin Bridge scales by partnering with [Bitcoin Oracle](broken-reference) which runs the validation network.&#x20;
-
-Bitcoin Oracle observes every endpoint on the Bitcoin Bridge and produces a set of cryptographic proofs for the relevant destination chain to process.
-
-Bitcoin Oracle produces the [consensus data](../../bitcoin-oracle/on-demand-consensus-data.md) based on the computation from the off-chain engines and provides a [consensus model framework](../../bitcoin-oracle/threshold-based-consensus/) that allows the end consumer to customise their consensus model by optimising across the trust and the security budget.
-
-Bitcoin Bridge uses a mixture of required and optional validators (with 51% threshold) to secure its bridge, which brings the following benefits:
-
-* It lowers the barrier to entry to join the validator network, encouraging more members of its community to participate in securing the bridge.
-* Security budget is replaced with a set of trusted validators, which essentially acts as the secondary check against the consensus derived from the network.
-* Larger part of the incentives can be allocated to encouraging the community to join and actively participate in securing the bridge.
-* Smaller part of the incentives needs to be alloacted to the "insurance" fund.
-* 51% threshold and the lower barrier to entry to join the network means it is expensive for the required validators to take over the validator network.
-* Likewise, malicious actors cannot take over the validator network even if they own all optional validators (which is very unlikely) unless they also take over every required validator.
-
-## Wrapped asset deployment (optional)
-
-Where required, an wrapped asset may be deployed on the destination chains to allow the bridging of the asset from its source chain to the destimation chains.

bitcoin-bridge/integrations/bitcoin-l2s.md

@@ -1,14 +0,0 @@
-# Bitcoin L2s
-
-On L2s or non-Bitcoin chains, users interact with "Endpoints" on the source blockchain to lock assets to be bridged ("source asset"), and on the destination blockchain to receive the bridged asset ("destination asset").
-
-Endpoints are the smart contracts that handle the asset transfers. They are owned by multisig contracts (for example, [Gnosis Safe](https://safe.global/) on Ethereum and [Executor DAO](https://explorer.stacks.co/txid/0xf4bd95ea0486e6a50ae632c613f1d72b2a5bbbc4211b494cd0f1d3443658544d?chain=mainnet) on Stacks) operated by ALEX LAB Foundation.
-
-Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs.
-
-That the assets are held by contracts owned by multisig contracts is important because this minimises the risk of a malicious actor stealing the private key and assets sent by users.
-
-## Endpoints
-
-<table><thead><tr><th width="181">Chain</th><th>Contract address</th></tr></thead><tbody><tr><td>Stacks (BRC20)</td><td><a href="https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-bridge-endpoint-v1-07?chain=mainnet">https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-bridge-endpoint-v1-07?chain=mainnet</a></td></tr><tr><td>Stacks (BTC)</td><td><a href="https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.btc-bridge-endpoint-v1-11?chain=mainnet">https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.btc-bridge-endpoint-v1-11?chain=mainnet</a></td></tr></tbody></table>
-

bitcoin-bridge/integrations/non-bitcoin-chains.md

@@ -1,13 +0,0 @@
-# Non-Bitcoin chains
-
-On L2s or non-Bitcoin chains, users interact with "Endpoints" on the source blockchain to lock assets to be bridged ("source asset"), and on the destination blockchain to receive the bridged asset ("destination asset").
-
-Endpoints are the smart contracts that handle the asset transfers. They are owned by multisig contracts (for example, [Gnosis Safe](https://safe.global/) on Ethereum and [Executor DAO](https://explorer.stacks.co/txid/0xf4bd95ea0486e6a50ae632c613f1d72b2a5bbbc4211b494cd0f1d3443658544d?chain=mainnet) on Stacks) operated by ALEX LAB Foundation.
-
-Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs.
-
-That the assets are held by contracts owned by multisig contracts is important because this minimises the risk of a malicious actor stealing the private key and assets sent by users.
-
-## Endpoints
-
-<table><thead><tr><th width="181">Chain</th><th>Contract address</th></tr></thead><tbody><tr><td>Ethereum</td><td><a href="https://etherscan.io/address/0xfd9f795b4c15183bdba83da08da02d5f9536748f">https://etherscan.io/address/0xfd9f795b4c15183bdba83da08da02d5f9536748f</a></td></tr><tr><td>BNB Chain</td><td><a href="https://bscscan.com/address/0xb3955302e58fffdf2da247e999cd9755f652b13b">https://bscscan.com/address/0xb3955302e58fffdf2da247e999cd9755f652b13b</a></td></tr></tbody></table>

bitcoin-bridge/integrations/understanding-the-bitcoin-bridge.md

@@ -1,13 +0,0 @@
-# Bitcoin
-
-On Bitcoin, users interact with Multisigs (operated by ALEX LAB Foundation, with a plan to decentralisation) to lock assets to be bridged ("source asset"), and on L2s to receive the L2 asset ("destination asset").
-
-Additionally, users on Bitcoin may provide additional data (`OP_RETURN`) to trigger certain smart contract interaction on their behalf automatically by Bitcoin Bridge.
-
-Multisigs are Bitcoin wallets that are operated by multiple signers. In contrast to a typicall wallet requiring just one party to sign a transaction, a multisig requires multiple parties or signers to sign a transaction.
-
-ALEX partnered with [Asigna](https://asigna.gitbook.io/asigna/introduction/about-asigna) who is "_a native multisig solution tailored for Bitcoin and Stacks made specifically to offer an extra layer of security to trusted wallets on both ecosystems._"
-
-## Multisigs
-
-<table><thead><tr><th width="152">Asset</th><th>Multisig address</th></tr></thead><tbody><tr><td>BTC</td><td><a href="https://mempool.space/address/bc1pylrcm2ym9spaszyrwzhhzc2qf8c3xq65jgmd8udqtd5q73a2fulsztxqyy">https://mempool.space/address/bc1pylrcm2ym9spaszyrwzhhzc2qf8c3xq65jgmd8udqtd5q73a2fulsztxqyy</a></td></tr><tr><td>BRC20</td><td><a href="https://mempool.space/address/bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq">https://mempool.space/address/bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq</a></td></tr></tbody></table>

bitcoin-bridge/reserves.md

@@ -1,21 +0,0 @@
-# Reserves
-
-Users can monitor the reserves real-time at [https://app.alexlab.co/bridge-reserve](https://app.alexlab.co/bridge-reserve).
-
-## Latest circulating supply of aBTC
-
-For more details on aBTC, please visit [aBTC, a.k.a. ALEX BTC](abtc-a.k.a-alex-btc.md).
-
-You can check the latest circulating supply of aBTC or other L2 BRC20 tokens by calling `get-total-supply` function of the relevant contract (please note the number is in 8-digit fixed notation, i.e. the last 8 digits represent the decimals).
-
-Alternatively the same is also available at, for example, for aBTC
-
-{% embed url="https://api.alexlab.co/v1/stats/total_supply/token-abtc" %}
-
-## Latest circulating supply of sUSDT
-
-You can check the latest circulating supply of sUSDT by calling `get-total-supply` function of the [contract](https://explorer.hiro.so/txid/0xa4157b445d284951436706e2e9f1b5819e48526c8ef363f93df38c461d8a3192?chain=mainnet) (please note the number is in 8-digit fixed notation, i.e. the last 8 digits represent the decimals).
-
-Alternatively the same is also available at
-
-{% embed url="https://api.alexlab.co/v1/stats/total_supply/token-susdt" %}

bitcoin-bridge/security-audits.md

@@ -1,11 +0,0 @@
-# Security Audits
-
-As with all crypto technology, risk is real whether using a centralized or decentralized bridge. Some of the more novel decentralized bridges are relatively untested and even those that have been tested are still subject to exploits.
-
-Bitcoin Bridge is audited by CoinFabrik, covering both the contracts and the backends.
-
-* [https://cdn.alexlab.co/pdf/ALEX\_Audit\_bridge\_coinfabrik\_202212.pdf](https://cdn.alexlab.co/pdf/ALEX\_Audit\_bridge\_coinfabrik\_202212.pdf)
-* [https://cdn.alexlab.co/pdf/ALEX\_Audit\_Bridge\_2023-04.pdf](https://cdn.alexlab.co/pdf/ALEX\_Audit\_Bridge\_2023-04.pdf)
-* [https://cdn.alexlab.co/pdf/ALEX\_Audit\_202310\_Bitcoin\_Oracle\_and\_Bridge.pdf](https://cdn.alexlab.co/pdf/ALEX\_Audit\_202310\_Bitcoin\_Oracle\_and\_Bridge.pdf)
-
-The smart contracts are also subject to our [bug bounty](https://immunefi.com/bounty/alex/) programme on Immunefi.

bitcoin-bridge/what-is-the-bitcoin-bridge.md

@@ -1,54 +0,0 @@
----
-description: Bitcoin Bridge is not a typical cross-chain bridge
----
-
-# What is the Bitcoin Bridge
-
-## Key to providing the "native-like" Bitcoin DeFi experience
-
-Bitcoin Bridge is a key component of ALEX that abstracts the difference between L1 and L2 from the user experience, i.e. providing the "native-like” Bitcoin DeFi experience on L1, whereby users can use native BTC or L1 assets issued on Bitcoin to interact with L2 smart contracts.
-
-Bitcoin Bridge is bi-directional or “two-way” bridge, meaning you can freely transfer assets between Bitcoin and its L2s and vice versa.
-
-On Bitcoin, users interact with [Multisigs](what-is-the-bitcoin-bridge.md#multisigs) (currently operated by ALEX LAB Foundation, but to be upgraded to TSS-based ones soon) to lock assets to be bridged ("source asset"), and on L2s to receive the L2 asset ("destination asset").
-
-Additionally, users on Bitcoin may provide additional data (`OP_RETURN`) to trigger certain smart contract interaction on their behalf automatically by Bitcoin Bridge.
-
-On L2s or non-Bitcoin chains, users interact with "[Endpoints](what-is-the-bitcoin-bridge.md#endpoints)" on the source blockchain to lock assets to be bridged ("source asset"), and on the destination blockchain to receive the bridged asset ("destination asset").
-
-Asset transfers from users to Endpoints are monitored by a group of "[validators](what-is-the-bitcoin-bridge.md#validators)", who produce cryptographic proofs that say "X amount of source asset are sent by address A on the source blockchain for address B on the destination blockchain to receive Y amount of destination asset."
-
-There is a minimum threshold of such proofs that must be provided and verified before the assets received into Endpoint can be sent to the relevant address.
-
-Bitcoin Bridge is being integrated with [Bitcoin Oracle](broken-reference) which provides the [necessary consensus infrastructure](../bitcoin-oracle/threshold-based-consensus/).
-
-Upon meeting such minimum threshold, a "[relayer](what-is-the-bitcoin-bridge.md#relayers)" calls into Endpoint with the proofs to trigger the transfer of the received destination assets to the relevant address.
-
-## Multisigs
-
-Multisigs are Bitcoin wallets that are operated by multiple signers. In contrast to a typicall wallet requiring just one party to sign a transaction, a multisig requires multiple parties or signers to sign a transaction.
-
-ALEX partnered with [Asigna](https://asigna.gitbook.io/asigna/introduction/about-asigna) who is "_a native multisig solution tailored for Bitcoin and Stacks made specifically to offer an extra layer of security to trusted wallets on both ecosystems._"
-
-## Endpoints
-
-Endpoints are the smart contracts that handle the asset transfers. They are owned by multisig contracts (for example, [Gnosis Safe](https://safe.global/) on Ethereum and [Executor DAO](https://explorer.stacks.co/txid/0xf4bd95ea0486e6a50ae632c613f1d72b2a5bbbc4211b494cd0f1d3443658544d?chain=mainnet) on Stacks) operated by ALEX LAB Foundation.
-
-Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs.
-
-That the assets are held by contracts owned by multisig contracts is important because this minimises the risk of a malicious actor stealing the private key and assets sent by users.
-
-## Validators
-
-Validators are responsible for producing cryptographic proofs, which must be verified by the Endpoints before transferring the destination assets to an address. 
-
-[Bitcoin Oracle](broken-reference) runs the validator network for and secures the Bitcoin Bridge.
-
-Validators are important because this set-up minimises the risk of a malicious actor taking over the system (for example, a relayer).
-
-## Relayers
-
-Relayers are responsible for triggering the destination asset transfer upon gathering a minimum threshold of cryptographic proofs produced by the validators.
-
-Relayers, however, cannot move the assets at will and their role is limited only to delivering messages from/to multisigs and Bridge endpoint.
-

bitcoin-oracle/on-demand-consensus-data.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # "On Demand" Consensus Data
 
 ## End consumer of consensus data dictates how it is validated and verified

bitcoin-oracle/threshold-based-consensus/README.md

@@ -1,27 +0,0 @@
-# Threshold-based Consensus
-
-## Consensus model tailor made for each consumer
-
-Using the "on-demand" consensus data, dapps and other end consumers of such data can reach the consensus based on a minimum threshold (i.e. "_m-of-n_") of the relevant community agree to a particular event.
-
-Bitcoin Oracle provides a consensus model framework that allows the end consumer to customise their consensus model by optimising across the trust and the security budget.
-
-Each end consumer may specify a number of required (i.e. trusted) and optional (i.e. non-trusted) validators as its consensus model.
-
-For each event to validate, all required validators must agree **and** a certain threshold (say 51%) of all validators (including required and optional) must agree.
-
-A fast derivation of consensus is achieved through [Threshold Sampling](threshold-sampling.md) among non-trusted nodes.
-
-Some may choose to have only required validators, in which case, effectively, a federated concensus model is run. In this case, a trust element is introduced to eliminate the security budget constraint. 
-
-Some others may choose to have only optional validators, but with staking/slashing mechanism. In this case, the security budget enabled by the staking/slashing mechanism means the consensus model can be run trustlessly.
-
-Bitcoin Bridge, for example, will be incorporating a mixture of required and optional validators (with 51% threshold) to secure its BRC20 bridge, which brings the following benefits:
-
-* It lowers the barrier to entry to join the validator network, encouraging more members of its community to participate in securing the bridge.
-* Security budget is replaced with a set of trusted validators, which essentially acts as the secondary check against the consensus derived from the network.
-* Larger part of the incentives can be allocated to encouraging the community to join and actively participate in securing the bridge.
-* Smaller part of the incentives needs to be alloacted to the "insurance" fund.
-* 51% threshold and the lower barrier to entry to join the network means it is expensive for the required validators to take over the validator network.
-* Likewise, malicious actors cannot take over the validator network even if they own all optional validators (which is very unlikely) unless they also take over every required validator.
-

bitcoin-oracle/threshold-based-consensus/threshold-sampling.md

@@ -1,3 +0,0 @@
-# Threshold Sampling
-
-Threshold sampling allows Bitcoin Oracle to derive consensus from the network of non-trusted nodes without having to download all the consensus data from its data layer. Bitcoin Oracle engages in several rounds of random sampling for subset of the network and, with each successful round, consensus confidence grows. When Bitcoin Oracle achieves a set confidence threshold, an event is deemed to have reached consensus, subject to validation by all trusted nodes.

bitcoin-oracle/what-is-the-bitcoin-oracle/README.md

@@ -2,20 +2,40 @@
 
 ## Consensus layer for all and any off-chain computation engines
 
-Bitcoin Oracle acts as a consensus layer for all and any off-chain computation engines that relies on the Bitcoin data.
+Bitcoin Oracle acts as a consensus layer for all and any off-chain computation engines that builds on Bitcoin.
 
 The consensus is reached when a minimum threshold (i.e. "_m-of-n_") of the relevant community agree to a particular event.
 
 End consumers can then verify the consensus before making a decision or taking an action with respect to that particular event, thus enhancing the security assumptions.
 
-For example, Bitcoin Oracle is used by Xlink for their [BRC20 Bridge](https://app.xlink.network/bridge/brc20-bridge/peg-in), which uses a [smart contract on Stacks](https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.btc-bridge-endpoint-v1-10?chain=mainnet) to verify the consensus and save the validated data on-chain.
+For example, Bitcoin Oracle secures [Xlink](https://app.xlink.network). When Xlink identifies a particular cross-chain transfer to process, it pulls the relevant consensus data from Bitcoin Oracle, verify them using its smart contract before processing them on the relevant destination chain.
 
-When Xlink identifies a particular BRC20 transfer to process, it pulls the relevant consensus data from Bitcoin Oracle, verify them using its smart contract before saving them on-chain.
+## Flexible threshold-based consensus model
 
-This combination of the off-chain computation and the on-chain verification protects Xlink users from a potential security issues associated with BRC20, including that of [double spend](https://en.wikipedia.org/wiki/Double-spending).
+Using the "on-demand" consensus data, dapps and other end consumers of such data can reach the consensus based on a minimum threshold (i.e. "_m-of-n_") of the relevant community agree to a particular event.
 
-## Open to all to participate
+Bitcoin Oracle provides a consensus model framework that allows the end consumer to customise their consensus model by optimising across the trust and the security budget.
 
-The Bitcoin Oracle is actively developed by ALEX and is released under MIT license. We encourage all those interested to check out the below and help contribute!
+Each end consumer may specify a number of required (i.e. trusted) and optional (i.e. non-trusted) validators as its consensus model.
+
+For example, for each event to validate, the end consumer may specify that the required validators must agree and a certain threshold (say 51%) of all validators (including required and optional) must agree.
+
+A fast derivation of consensus is achieved through [Threshold Sampling](./#threshold-sampling) among nodes.
+
+Some may choose to have only required validators, in which case, effectively, a federated concensus model is run. In this case, a trust element is introduced to eliminate the security budget constraint. 
+
+Some others may choose to have only optional validators, but with staking/slashing mechanism. In this case, the security budget enabled by the staking/slashing mechanism means the consensus model can be run trustlessly.
+
+XLink, for example, incorporates a mixture of required and optional validators to secure its infrastructure, where the consensus (100% threshold) of the required validators must be met to validate the consensus (51% threshold) reached by all the validators. This model brings the following benefits:
+
+* It lowers the barrier to entry to join the validator network, encouraging more members of its community to participate in securing the XLink infrastructure.
+* Security budget is replaced with a set of trusted validators, which essentially acts as the secondary check against the consensus derived from the network.
+* Larger part of the incentives can be allocated to encouraging the community to join and actively participate in securing the network.
+* Smaller part of the incentives needs to be alloacted to the "insurance" fund.
+* 51% threshold and the lower barrier to entry to join the network means it is expensive for the required validators to take over the validator network.
+* Likewise, malicious actors cannot take over the validator network even if they own all optional validators (which is very unlikely) unless they also take over every required validator.
+
+### Threshold Sampling
+
+Threshold sampling allows Bitcoin Oracle to derive consensus from the network of nodes without having to download all the consensus data from its data layer. Bitcoin Oracle engages in several rounds of random sampling for subset of the network and, with each successful round, consensus confidence grows. When Bitcoin Oracle achieves a set confidence threshold, an event is deemed to have reached consensus, subject to validation by all trusted nodes.
 
-{% embed url="https://github.com/alexgo-io/bitcoin-oracle" %}

bitcoin-oracle/what-is-the-bitcoin-oracle/what-is-the-bitcoin-oracle.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # Why Bitcoin Oracle - BRC20
 
 ## Bitcoin does not understand you

launchpad/using-the-launchpad.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # Using the Launchpad
 
 ## Deployment
@@ -11,7 +15,7 @@
 * `launch-token-trait` : the trait reference of `project token` (e.g. ALEX)
 * `payment-token-trait` : trait reference of `payment token` (e.g. sUSDT)
 * `launch-owner` : address of the project that launches the `project token`
-* `launch-tokens-per-ticket` : number of `project token` per `ticket` 
+* `launch-tokens-per-ticket` : number of `project token` per `ticket`
 * `price-per-ticket-in-fixed` : `payment token` deposit required per `ticket` (in 8-digit fixed notation)
 * `activation-threshold` : number of tickets required to activate the launch
 * `registration-start-height` : start (inclusive) block-height of registration period
@@ -50,7 +54,7 @@ Assuming (1) registration period has started, (2) registration period has not en
 
 ## Lottery
 
-The lottery will be drawn one block after the registration ended. The claim/lottery period ends at `claim-end` block-height. 
+The lottery will be drawn one block after the registration ended. The claim/lottery period ends at `claim-end` block-height.
 
 `contract-owner` or `launch-owner` will draw the lottery off-chain using the [prescribed rule](what-is-the-launchpad.md#e255) and call `claim` repeatedly with the following parameters
 
@@ -59,7 +63,7 @@ The lottery will be drawn one block after the registration ended. The claim/lott
 * `launch-token-trait` : trait reference of `project token`
 * `payment-token-trait` : trait reference of `payment token`
 
-Upon calling `claim`, assuming (1) registration period has ended, (2) not all tickets are already won, (3) the launch is activated and (4) the claim/lottery period has not ended yet, the contract will verify the validity of `input` and 
+Upon calling `claim`, assuming (1) registration period has ended, (2) not all tickets are already won, (3) the launch is activated and (4) the claim/lottery period has not ended yet, the contract will verify the validity of `input` and
 
 * transfer the proceeds of `payment token`, net of `fee`, to `launch-owner`,
 * transfer `fee` to the platform, and

orderbook/using-the-orderbook.md

@@ -1,3 +1,7 @@
+---
+hidden: true
+---
+
 # Using the Orderbook
 
 ALEX Orderbook is available at [https://app.alexlab.co/orderbook](https://app.alexlab.co/orderbook).