From 560ff5aa999637c722f0ddd294f2ce56f26a2768 Mon Sep 17 00:00:00 2001 From: Alex Daddy Date: Fri, 23 Aug 2024 02:32:37 +0000 Subject: [PATCH 1/3] GITBOOK-1: No subject --- README.md | 48 +- SUMMARY.md | 63 +- ....k.a-alex-btc.md => abtc-a.k.a-alex-btc.md | 14 +- .../understanding-the-bitcoin-bridge.md | 13 - bitcoin-bridge/what-is-the-bitcoin-bridge.md | 54 -- bitcoin-oracle/on-demand-consensus-data.md | 547 ------------------ bitcoin-oracle/security-audits.md | 7 - .../threshold-based-consensus/README.md | 27 - .../threshold-sampling.md | 3 - .../what-is-the-bitcoin-oracle/README.md | 21 - .../what-is-the-bitcoin-oracle.md | 35 -- developers/api-references.md | 95 --- developers/smart-contracts/README.md | 5 - .../smart-contracts/amm-pool-mapping.md | 204 ------- developers/smart-contracts/token-list.md | 13 - developers/testnet.md | 16 - .../integrations => integrations}/README.md | 4 +- .../bitcoin-l2s.md | 7 +- .../non-bitcoin-chains.md | 6 +- .../understanding-the-bitcoin-bridge.md | 7 + launchpad/using-the-launchpad.md | 68 --- launchpad/what-is-the-launchpad.md | 37 -- orderbook/understanding-the-orderbook.md | 10 - orderbook/using-the-orderbook.md | 123 ---- orderbook/what-is-orderbook.md | 35 -- bitcoin-bridge/reserves.md => reserves.md | 4 +- .../security-audits.md => security-audits.md | 0 ...t-making-designed-for-lending-protocols.md | 55 -- .../collateral-rebalancing-pool.md | 21 - ...ure-that-supports-ecosystem-development.md | 51 -- trading-lending-and-borrowing/trading-pool.md | 114 ---- trading-lending-and-borrowing/vault.md | 11 - .../automated-market-making-of-alex/README.md | 174 ------ .../automated-market-making-of-alex.md | 365 ------------ ...t-making-of-collateral-rebalancing-pool.md | 176 ------ .../dive-into-collateral-rebalancing-pool.md | 129 ----- 36 files changed, 67 insertions(+), 2495 deletions(-) rename bitcoin-bridge/abtc-a.k.a-alex-btc.md => abtc-a.k.a-alex-btc.md (76%) delete mode 100644 bitcoin-bridge/integrations/understanding-the-bitcoin-bridge.md delete mode 100644 bitcoin-bridge/what-is-the-bitcoin-bridge.md delete mode 100644 bitcoin-oracle/on-demand-consensus-data.md delete mode 100644 bitcoin-oracle/security-audits.md delete mode 100644 bitcoin-oracle/threshold-based-consensus/README.md delete mode 100644 bitcoin-oracle/threshold-based-consensus/threshold-sampling.md delete mode 100644 bitcoin-oracle/what-is-the-bitcoin-oracle/README.md delete mode 100644 bitcoin-oracle/what-is-the-bitcoin-oracle/what-is-the-bitcoin-oracle.md delete mode 100644 developers/api-references.md delete mode 100644 developers/smart-contracts/README.md delete mode 100644 developers/smart-contracts/amm-pool-mapping.md delete mode 100644 developers/smart-contracts/token-list.md delete mode 100644 developers/testnet.md rename {bitcoin-bridge/integrations => integrations}/README.md (85%) rename {bitcoin-bridge/integrations => integrations}/bitcoin-l2s.md (55%) rename {bitcoin-bridge/integrations => integrations}/non-bitcoin-chains.md (62%) create mode 100644 integrations/understanding-the-bitcoin-bridge.md delete mode 100644 launchpad/using-the-launchpad.md delete mode 100644 launchpad/what-is-the-launchpad.md delete mode 100644 orderbook/understanding-the-orderbook.md delete mode 100644 orderbook/using-the-orderbook.md delete mode 100644 orderbook/what-is-orderbook.md rename bitcoin-bridge/reserves.md => reserves.md (81%) rename bitcoin-bridge/security-audits.md => security-audits.md (100%) delete mode 100644 trading-lending-and-borrowing/automated-market-making-designed-for-lending-protocols.md delete mode 100644 trading-lending-and-borrowing/collateral-rebalancing-pool.md delete mode 100644 trading-lending-and-borrowing/platform-architecture-that-supports-ecosystem-development.md delete mode 100644 trading-lending-and-borrowing/trading-pool.md delete mode 100644 trading-lending-and-borrowing/vault.md delete mode 100644 whitepaper/automated-market-making-of-alex/README.md delete mode 100644 whitepaper/automated-market-making-of-alex/automated-market-making-of-alex.md delete mode 100644 whitepaper/automated-market-making-of-collateral-rebalancing-pool.md delete mode 100644 whitepaper/dive-into-collateral-rebalancing-pool.md diff --git a/README.md b/README.md index 6a69d42..19b67ff 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,49 @@ --- -description: From the Co-Founders +description: XLink is not a typical cross-chain bridge --- -# 😀 What is ALEX? +# What is XLink -The DeFi landscape is teeming with possibilities, and at the heart of it all, Bitcoin DeFi is set to take center stage. In the coming years, we expect a surge in growth revolving around Ordinals, BRC20 tokens, Bitcoin L2 in particular Stacks. +## Key to providing the "native-like" Bitcoin DeFi experience -A quick retrospect shows how Ordinals have brilliantly showcased the potential of the Bitcoin blockchain. This revolutionary platform has turned the table, illustrating that Bitcoin’s ledger is more than just a settlement layer. Yet, to build a truly meaningful DeFi ecosystem on Bitcoin, transactions are only one piece of the puzzle. We need a competent smart contract and computing layer to complete the picture. That’s where Stacks steps in. The domino effect triggered by Ordinals has kindled an era where we expect Bitcoin’s Layer 1 (L1) asset issuance to skyrocket. Coupled with Stacks’ prowess in handling DeFi and other economic activities, we see a flourishing ecosystem set for the years ahead. +XLink is a key component of any projects building on Bitcoin 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. -At ALEX, we’re not mere spectators. We’re an integral part of this vibrant, multi-year growth story. Our aim? To deliver a top-notch DeFi platform that caters to the next-gen Bitcoin users, innovators, and the broader ecosystem. +XLink is bi-directional or “two-way” bridge, meaning you can freely transfer assets between Bitcoin and its L2s and vice versa. -So, in essence, ALEX is a concentrated bet on this view of Bitcoin Finance. +On Bitcoin, users interact with [Multisigs](./#multisigs) (operated by XLink DAO Foundation) to lock assets to be bridged ("source asset"), and on L2s to receive the L2 asset ("destination asset"). -Presently, a good number of BRC-20s may appear to be meme coins, but we foresee a significant shift. We are witnessing more established projects considering BRC20 issuance. Moreover, numerous other projects we are in discussion with are considering issuing BRC20 tokens to augment their existing tokenomics and tap into a new audience. Some may argue that Bitcoin began its journey as a “meme” coin, with its initial purpose being to buy pizza amongst friends. However, the essential query is whether the technology enabling the creation of such meme coins can transcend that purpose. We are confident that BRC20 and Ordinals hold a greater potential than just being meme coins. +Additionally, users on Bitcoin may provide additional data (`OP_RETURN`) to trigger certain smart contract interaction on their behalf automatically by Bitcoin Bridge. -Our vision at ALEX is to dissolve the barrier between Bitcoin L1 and L2 to create a seamless Bitcoin DeFi experience. The relationship between Bitcoin and Stacks is fundamentally different from that of Ethereum and e.g. Arbitrum. In the Bitcoin-Stacks pair, L2 equips L1 with smart contract capabilities, while in the Ethereum-Arbitrum duo, both L1 and L2 possess their independent smart contract functionalities. Therefore, a true Bitcoin DeFi experience isn’t about users having to choose between L1 and L2. Instead, it’s about Bitcoin asset holders experiencing DeFi on L1 with L2 running smart contracts unobtrusively in the background. ALEX is not simply adapting to the emerging Bitcoin DeFi landscape — we’re actively shaping it. We’re steadfast in our belief that our efforts will continue to herald an exciting new epoch for Bitcoin DeFi, introducing the benefits of decentralized trading to an even wider audience. And by doing so, we’re facilitating the next generation of Bitcoin users to flourish within this rapidly evolving ecosystem. +On L2s or non-Bitcoin chains, users interact with "[Endpoints](./#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](./#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. + +Upon meeting such minimum threshold, a "[relayer](./#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. + +## 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 XLink DAO 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 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. diff --git a/SUMMARY.md b/SUMMARY.md index 84ad5f7..0d62169 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,57 +1,10 @@ # Table of contents -* [😀 What is ALEX?](README.md) - -## 📈 Trading, Lending and Borrowing - -* [Our Design](trading-lending-and-borrowing/platform-architecture-that-supports-ecosystem-development.md) -* [Trading Pool](trading-lending-and-borrowing/trading-pool.md) -* [Collateral Rebalancing Pool](trading-lending-and-borrowing/collateral-rebalancing-pool.md) -* [Yield Token Pool](trading-lending-and-borrowing/automated-market-making-designed-for-lending-protocols.md) -* [Vault](trading-lending-and-borrowing/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 - -* [What is the Bitcoin Bridge](bitcoin-bridge/what-is-the-bitcoin-bridge.md) -* [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 - -* [What is the Orderbook?](orderbook/what-is-orderbook.md) -* [Understanding the Orderbook](orderbook/understanding-the-orderbook.md) -* [Using the Orderbook](orderbook/using-the-orderbook.md) - -## 🚀 Launchpad - -* [What is the Launchpad](launchpad/what-is-the-launchpad.md) -* [Using the Launchpad](launchpad/using-the-launchpad.md) - -## 📚 Whitepaper - -* [Automated Market Making of Trading Pool](whitepaper/automated-market-making-of-alex/README.md) -* [Automated Market Making of Yield Token Pool](whitepaper/automated-market-making-of-alex/automated-market-making-of-alex.md) -* [Automated Market Making of Collateral Rebalancing Pool](whitepaper/automated-market-making-of-collateral-rebalancing-pool.md) -* [Dive Into Collateral Rebalancing Pool!](whitepaper/dive-into-collateral-rebalancing-pool.md) - -## 🎮 Developers - -* [Testnet](developers/testnet.md) -* [Smart Contracts](developers/smart-contracts/README.md) - * [Token List](developers/smart-contracts/token-list.md) - * [AMM Pool Mapping](developers/smart-contracts/amm-pool-mapping.md) -* [REST API](developers/api-references.md) +* [What is XLink](README.md) +* [Reserves](reserves.md) +* [Integrations](integrations/README.md) + * [Bitcoin](integrations/understanding-the-bitcoin-bridge.md) + * [Bitcoin L2s](integrations/bitcoin-l2s.md) + * [Non-Bitcoin chains](integrations/non-bitcoin-chains.md) +* [🟧 aBTC](abtc-a.k.a-alex-btc.md) +* [Security Audits](security-audits.md) diff --git a/bitcoin-bridge/abtc-a.k.a-alex-btc.md b/abtc-a.k.a-alex-btc.md similarity index 76% rename from bitcoin-bridge/abtc-a.k.a-alex-btc.md rename to abtc-a.k.a-alex-btc.md index c948bae..804bf79 100644 --- a/bitcoin-bridge/abtc-a.k.a-alex-btc.md +++ b/abtc-a.k.a-alex-btc.md @@ -1,12 +1,12 @@ -# 🟧 aBTC, a.k.a ALEX BTC +# 🟧 aBTC ### 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. +aBTC is a fully-functional SIP010 token on Stacks, where 1 aBTC represents 1 BTC locked in the multisig operated by XLink DAO 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. +When a BTC holder interacts with smart contracts on Stacks, under the hood, [Bitcoin Bridge](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. @@ -24,8 +24,6 @@ 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. @@ -38,15 +36,15 @@ We are introducing aBTC because it makes possible the kind of tight integration #### Reserve -{% embed url="https://app.alexlab.co/bridge-reserve" %} +{% embed url="https://app.xlink.network/bridge-reserve" %} #### Contract deployment -{% embed url="https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.token-abtc?chain=mainnet" %} +[https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc?chain=mainnet](https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc?chain=mainnet) #### Multisig address -{% embed url="https://mempool.space/address/bc1pylrcm2ym9spaszyrwzhhzc2qf8c3xq65jgmd8udqtd5q73a2fulsztxqyy" %} +{% embed url="https://mempool.space/address/bc1q9hs56nskqsxmgend4w0823lmef33sux6p8rzlp" %} #### Token logo diff --git a/bitcoin-bridge/integrations/understanding-the-bitcoin-bridge.md b/bitcoin-bridge/integrations/understanding-the-bitcoin-bridge.md deleted file mode 100644 index 1399d81..0000000 --- a/bitcoin-bridge/integrations/understanding-the-bitcoin-bridge.md +++ /dev/null @@ -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 - -
AssetMultisig address
BTChttps://mempool.space/address/bc1pylrcm2ym9spaszyrwzhhzc2qf8c3xq65jgmd8udqtd5q73a2fulsztxqyy
BRC20https://mempool.space/address/bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq
diff --git a/bitcoin-bridge/what-is-the-bitcoin-bridge.md b/bitcoin-bridge/what-is-the-bitcoin-bridge.md deleted file mode 100644 index 836f502..0000000 --- a/bitcoin-bridge/what-is-the-bitcoin-bridge.md +++ /dev/null @@ -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. - diff --git a/bitcoin-oracle/on-demand-consensus-data.md b/bitcoin-oracle/on-demand-consensus-data.md deleted file mode 100644 index dc89644..0000000 --- a/bitcoin-oracle/on-demand-consensus-data.md +++ /dev/null @@ -1,547 +0,0 @@ -# "On Demand" Consensus Data - -## End consumer of consensus data dictates how it is validated and verified - -Bitcoin Oracle produces the consensus data based on the computation from the off-chain engines, but the validation and verification of such consensus data can be implemented by the end consumer as they see fit. - -For example, wallet integrating Bitcoin Oracle may implement a client-side verification of the consensus data, instead of relying on an on-chain validation. - -A website that wants to display users' BRC20 balances, but do not need to verify the consensus data, may simply use the data without verification. - -A BRC20 trading dapp on an EVM-compatible Bitcoin L2 may implement their own smart contract written in Solidity to validate the consensus data, before initiating other smart contract interactions. - -## So how can one fetch the consensus data from Bitcoin Oracle? - -### Summary data - -If you need only the summary data, without its associated consensus data, you can use the following endpoints at [https://api.alexgo.io](https://api.alexgo.io/). - -{% swagger src="https://api.alexlab.co/swagger-ui-yaml" path="/v1/brc20/user-balance" method="get" %} -[https://api.alexlab.co/swagger-ui-yaml](https://api.alexlab.co/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/brc20/bitcoin-tx-indexed" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -#### Examples - -{% tabs %} -{% tab title="User balance" %} -{% code overflow="wrap" %} -```sh -curl --location 'https://api.alexgo.io/v1/brc20/user-balance?tick=ORMM&user=bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq' \ ---header 'Accept: application/json' -``` -{% endcode %} - -**Response** - -{% code overflow="wrap" %} -```json -{ - "balance": "962959356579080000000000", - "up-to-block": "825995" -} -``` -{% endcode %} -{% endtab %} - -{% tab title="Bitcoin tx indexed" %} -{% code overflow="wrap" %} -```sh -curl --location 'https://api.alexgo.io/v1/brc20/bitcoin-tx-indexed?bitcoin-tx-id=9778d139d55f3dca60e4d45942cf6c0ab97e23fd24771696b9ecdfba52303b01&offset=0&output=0' \ ---header 'Accept: application/json' -``` -{% endcode %} - -**Response** - -{% code overflow="wrap" %} -```json -{ - "from": "bc1p42g525vmjry4k66pq39a03375esmmdkqhk76ty9yed6elxtcj9ds9pm7dt", - "to": "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq", - "tick": "ORMM", - "amt": "3700000000000000000000000" -} -``` -{% endcode %} -{% endtab %} -{% endtabs %} - -### Full consensus data - -If you need the full consensus data, you can use the following endpoint at [https://api.bitcoin-oracle.network](https://api.bitcoin-oracle.network/). - -The endpoint performs a match against an array where each item represents a distinct condition. If multiple query parameters are specified, such as `from` and `height`, the returned transactions must satisfy **all** the given conditions. - -The endpoint supports query conditions for addresses in two formats: Bech32 and PKScript. - -{% swagger src="https://api.bitcoin-oracle.network/swagger-ui-yaml" path="/v1/brc20" method="post" %} -[https://api.bitcoin-oracle.network/swagger-ui-yaml](https://api.bitcoin-oracle.network/swagger-ui-yaml) -{% endswagger %} - -#### How to validate the consensus data - -With the consensus data, you can - -1. determine if a minimum threshold you require was reached among data providers -2. (for Stacks smart contracts) determine whether or not the relevant Bitcoin transaction was indeed mined - -#### Validation of off-chain computation - -`order_hash` is the sha256 hash of the following tuple: - -```json -{ - bitcoin-tx: (buff 8192), - output: uint, - offset: uint, - tick: (string-utf8 4), - amt: uint, - from: (buff 128), - to: (buff 128), - from-bal: uint, - to-bal: uint, - decimals: uint -} -``` - -Each data provider then creates and signs a sha256 hash of a concatenation of - -1. Structured data prefix: `0x534950303138` -2. Message domain: `0x6d11cd301d11961e7cfeabd61e3f4da17f42f3d627362c8878aa9cbb5c532be2` -3. `order_hash` - -The addition of the structured data prefix and the message domain mitigates the message replay risk. - -The signatures and public keys of the data providers, who validated the event, are available under `signatures` and `signer_pubkeys`, respectively, together with `signer_types` indicating which implementation or type each signer uses (for example, for BRC20, there are three types - `bis`, `hiro` and `uinsat`). - -End consumer of this consensus data can then use these data to verify that each signer validated this particular BRC20 transfer. - -#### Verification of Bitcoin transaction (Stacks only) - -The consensus data provides additional information to allow smart contracts on Stacks to verify that the relevant Bitcoin transaction is indeed mined, which enhances the security and lessens its dependence on the off-chain data provider. - -For more information, please refer to [https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.clarity-bitcoin-v1-06?chain=mainnet](https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.clarity-bitcoin-v1-06?chain=mainnet). - -#### Examples - -{% tabs %} -{% tab title="Historical transfer by Bitcoin {tx_id}" %} -{% code overflow="wrap" %} -```sh -curl --location --request POST 'https://api.bitcoin-oracle.network/v1/brc20' \ ---header 'x-service-type: INDEXER' \ ---header 'x-version: 0.0.1' \ ---data-raw '{ - "type": "tx_id", - "tx_id":"9778d139d55f3dca60e4d45942cf6c0ab97e23fd24771696b9ecdfba52303b01", - "output": 0, - "offset": 0 -}' -``` -{% endcode %} - -**Response** - -{% code overflow="wrap" %} -```json -{ - "data": [ - { - "tx_hash": "020000000001022f119e4f00a1ea91771cd8dfc8e459cf98b7aac138aef6f4ff9394f53ab28faf0000000000fdffffff3f90f44767460ec0a742fe5320238cd05d8fbd3d292768ea5d5b38b29c7744760100000000fdffffff0322020000000000002251207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba1297318998e0902000000000016001412c625feb11e662805f4923b289a15d6be803ed70000000000000000386a360c0000000204646573740100000000000000000000000000000000047573657205166f4c0cb79258561dddf49ad4b91479324935b0dd01403a09be942697dc269ae4766a2a885911fd477306cd3d5dfad03cad5377d887a7b59c0bf78734df40cd6d44940a20f5f02896911a43231e81b7ee864311cd8cd202473044022035237c80120014629af1b1f1db73f6ed74e748a5afd398e05ce35a81e56130f902204ef75df72cce7fc124ce4696cb8155b5dfad16950eea1c7de0eedc761ffa7ff00121025ce5bd977e990a1e653519333c35fa2d7531a1b5cc6737e2057165ff148aca5b00000000", - "order_hash": "337d20f2431441591a46f8c65569e5e8bea98c70e0d6fa243ed19c4b40c3f9b7", - "amt": "3700000000000000000000000", - "bitcoin_tx": "00000020e7f505d8d9098cca86d39b4889f4ae4d2514929e16b0030000000000000000008d1d3bbee8ca41c87cea86e0d1eef44789a34051b3b48c68c4f358d488e75de8948e9f6569d80317921bb034", - "decimals": "18", - "from": { - "pkscript": "5120aa9145519b90c95b6b41044bd7c63ea661bdb6c0bdbda590a4cb759f9978915b", - "address": "bc1p42g525vmjry4k66pq39a03375esmmdkqhk76ty9yed6elxtcj9ds9pm7dt" - }, - "from_bal": "0", - "offset": "0", - "output": "0", - "tick": "ORMM", - "to": { - "pkscript": "51207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba129731899", - "address": "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - }, - "to_bal": "612741501250300100000000000", - "tx_id": "9778d139d55f3dca60e4d45942cf6c0ab97e23fd24771696b9ecdfba52303b01", - "proof_hashes": [ - "0048801e960dbf63c4602968259b23efc84d01b56f765c748d02b7387fda083c", - "c2ad185f79ab5e04def0b4ae8a1b971f03d738501c999be7b04d453f115d0c99", - "dde8ca635a80f4978049d95e53621f85b81a109e739c8a17e3a87589baff3378", - "3f0a3723a1141af85387d1180c5d25fd5c0ba1de9d140d46b608511659d146e1", - "02c2fe271149f95e3b2ce44441158c0e6459df5a75297df6d3e4733d78ee5577", - "223866a29166b32436d84381dea03193a1fddcabe93d5752a05d42539c754641", - "b58fd40d5861a7a1407315f2d91e328442fa25f4a9f2dc7a937aff2e05fb0c24", - "f2d8b750b230ea7a05ab8c8f9c607410bfa8c85b1066128be835cd7f3fe3e787", - "190320c66700b5bf8decea0a29491b5c3a0f53692823107dbe01b99af615c263", - "fa3e58599aa6573f3702bf0d53bd306f57713a642b696142131b6e009257d600", - "ecf791c893b78c40c2aad6125aea4ee5dd39d92a4ecbd421a9b38c90433dd3d3", - "2c202c28b430c7b7b726b006c55a661af87fdcb349ded3becc5d563baa39cf8a" - ], - "tx_index": "2049", - "tree_depth": "12", - "height": "825254", - "signers": [ - "SP1B0DHZV858RCBC8WG1YN5W9R491MJK88QPPC217", - "SP35D14R1JB3KHE4D55MMN646GFZJ198B7FMBG5PD", - "SP3ZCGVGSQWT6TJAXZRXHCYA6SWGNSNGKHSYA1F2Q" - ], - "signer_pubkeys": [ - "02883d08893252a59cf25aafffe1417bf74a7526621665a4bc0060e4aa95405891", - "0255966348dacd748595af0439e0a1cc947b2e3dc090acd8f90c32c30c3099b0a0", - "03c1a83abd5a199cb502818a110e2d55f67aae0e894f776c189b9f73556f8402a9" - ], - "signer_types": [ - "bis", - "hiro", - "unisat" - ], - "signatures": [ - "0fc66c9a7fe85ce78740fcc07f60ac47d5a05c469b2ca5f1ee16f5cc4b6eda1e41367bd67b03e7fbc6e4ba883c6fad1551373bd786f59afefbed268d08e59fd500", - "cd63d0ffae136ca1ffe1681ec4b062ada335b002b96b2a6153cea0a1f3ed94f14b601202ac2c8ecb229168c1264d0fad3475307df5a493ad98b9fae431f5138401", - "f7045fca2269e91d632f4a259eb47cc9f3ebb17dd64f7b8f4dfc8aa2ecfb2e716bfcce5f3c8ec6be0987c6f620d8c4205cd8d0c9728ee73c8892768ffca211c101" - ], - "created_at": 1704970783160, - "updated_at": 1704970783160 - } - ] -} -``` -{% endcode %} -{% endtab %} - -{% tab title="Historical transfer of {tick} from {from} to {to}" %} -{% code overflow="wrap" %} -```sh -curl --location --request POST 'https://api.bitcoin-oracle.network/v1/brc20' \ ---header 'x-service-type: INDEXER' \ ---header 'x-version: 0.0.1' \ ---data-raw '{ - "from": [ - "bc1p42g525vmjry4k66pq39a03375esmmdkqhk76ty9yed6elxtcj9ds9pm7dt" - ], - "to": [ - "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - ], - "tick": [ - "ORMM" - ], - "limit": 10 -}' -``` -{% endcode %} - -**Response** - -{% code overflow="wrap" %} -```json -{ - "data": [ - { - "tx_hash": "020000000001022f119e4f00a1ea91771cd8dfc8e459cf98b7aac138aef6f4ff9394f53ab28faf0000000000fdffffff3f90f44767460ec0a742fe5320238cd05d8fbd3d292768ea5d5b38b29c7744760100000000fdffffff0322020000000000002251207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba1297318998e0902000000000016001412c625feb11e662805f4923b289a15d6be803ed70000000000000000386a360c0000000204646573740100000000000000000000000000000000047573657205166f4c0cb79258561dddf49ad4b91479324935b0dd01403a09be942697dc269ae4766a2a885911fd477306cd3d5dfad03cad5377d887a7b59c0bf78734df40cd6d44940a20f5f02896911a43231e81b7ee864311cd8cd202473044022035237c80120014629af1b1f1db73f6ed74e748a5afd398e05ce35a81e56130f902204ef75df72cce7fc124ce4696cb8155b5dfad16950eea1c7de0eedc761ffa7ff00121025ce5bd977e990a1e653519333c35fa2d7531a1b5cc6737e2057165ff148aca5b00000000", - "order_hash": "337d20f2431441591a46f8c65569e5e8bea98c70e0d6fa243ed19c4b40c3f9b7", - "amt": "3700000000000000000000000", - "bitcoin_tx": "00000020e7f505d8d9098cca86d39b4889f4ae4d2514929e16b0030000000000000000008d1d3bbee8ca41c87cea86e0d1eef44789a34051b3b48c68c4f358d488e75de8948e9f6569d80317921bb034", - "decimals": "18", - "from": { - "pkscript": "5120aa9145519b90c95b6b41044bd7c63ea661bdb6c0bdbda590a4cb759f9978915b", - "address": "bc1p42g525vmjry4k66pq39a03375esmmdkqhk76ty9yed6elxtcj9ds9pm7dt" - }, - "from_bal": "0", - "offset": "0", - "output": "0", - "tick": "ORMM", - "to": { - "pkscript": "51207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba129731899", - "address": "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - }, - "to_bal": "612741501250300100000000000", - "tx_id": "9778d139d55f3dca60e4d45942cf6c0ab97e23fd24771696b9ecdfba52303b01", - "proof_hashes": [ - "0048801e960dbf63c4602968259b23efc84d01b56f765c748d02b7387fda083c", - "c2ad185f79ab5e04def0b4ae8a1b971f03d738501c999be7b04d453f115d0c99", - "dde8ca635a80f4978049d95e53621f85b81a109e739c8a17e3a87589baff3378", - "3f0a3723a1141af85387d1180c5d25fd5c0ba1de9d140d46b608511659d146e1", - "02c2fe271149f95e3b2ce44441158c0e6459df5a75297df6d3e4733d78ee5577", - "223866a29166b32436d84381dea03193a1fddcabe93d5752a05d42539c754641", - "b58fd40d5861a7a1407315f2d91e328442fa25f4a9f2dc7a937aff2e05fb0c24", - "f2d8b750b230ea7a05ab8c8f9c607410bfa8c85b1066128be835cd7f3fe3e787", - "190320c66700b5bf8decea0a29491b5c3a0f53692823107dbe01b99af615c263", - "fa3e58599aa6573f3702bf0d53bd306f57713a642b696142131b6e009257d600", - "ecf791c893b78c40c2aad6125aea4ee5dd39d92a4ecbd421a9b38c90433dd3d3", - "2c202c28b430c7b7b726b006c55a661af87fdcb349ded3becc5d563baa39cf8a" - ], - "tx_index": "2049", - "tree_depth": "12", - "height": "825254", - "signers": [ - "SP1B0DHZV858RCBC8WG1YN5W9R491MJK88QPPC217", - "SP35D14R1JB3KHE4D55MMN646GFZJ198B7FMBG5PD", - "SP3ZCGVGSQWT6TJAXZRXHCYA6SWGNSNGKHSYA1F2Q" - ], - "signer_pubkeys": [ - "02883d08893252a59cf25aafffe1417bf74a7526621665a4bc0060e4aa95405891", - "0255966348dacd748595af0439e0a1cc947b2e3dc090acd8f90c32c30c3099b0a0", - "03c1a83abd5a199cb502818a110e2d55f67aae0e894f776c189b9f73556f8402a9" - ], - "signer_types": [ - "bis", - "hiro", - "unisat" - ], - "signatures": [ - "0fc66c9a7fe85ce78740fcc07f60ac47d5a05c469b2ca5f1ee16f5cc4b6eda1e41367bd67b03e7fbc6e4ba883c6fad1551373bd786f59afefbed268d08e59fd500", - "cd63d0ffae136ca1ffe1681ec4b062ada335b002b96b2a6153cea0a1f3ed94f14b601202ac2c8ecb229168c1264d0fad3475307df5a493ad98b9fae431f5138401", - "f7045fca2269e91d632f4a259eb47cc9f3ebb17dd64f7b8f4dfc8aa2ecfb2e716bfcce5f3c8ec6be0987c6f620d8c4205cd8d0c9728ee73c8892768ffca211c101" - ], - "created_at": 1704970783160, - "updated_at": 1704970783160 - } - ] -} -``` -{% endcode %} -{% endtab %} - -{% tab title="Batch historical transfer (multiple {tick}, {from} and/or {to})" %} -{% code overflow="wrap" %} -```sh -curl --location --request POST 'https://api.bitcoin-oracle.network/v1/brc20' \ ---header 'x-service-type: INDEXER' \ ---header 'x-version: 0.0.1' \ ---data-raw '{ - "from": [ - "bc1p42g525vmjry4k66pq39a03375esmmdkqhk76ty9yed6elxtcj9ds9pm7dt", - "bc1pgpxqrl8gcykc970kkczswaau4ur4rcjat9y0pvmagkfhhjddzscq6mdpf4" - ], - "to": [ - "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - ], - "tick": [ - "ORMM", - "OXBT" - ], - "limit": 100 -}' -``` -{% endcode %} - -**Response** - -{% code overflow="wrap" %} -```json -{ - "data": [ - { - "tx_hash": "020000000001022f119e4f00a1ea91771cd8dfc8e459cf98b7aac138aef6f4ff9394f53ab28faf0000000000fdffffff3f90f44767460ec0a742fe5320238cd05d8fbd3d292768ea5d5b38b29c7744760100000000fdffffff0322020000000000002251207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba1297318998e0902000000000016001412c625feb11e662805f4923b289a15d6be803ed70000000000000000386a360c0000000204646573740100000000000000000000000000000000047573657205166f4c0cb79258561dddf49ad4b91479324935b0dd01403a09be942697dc269ae4766a2a885911fd477306cd3d5dfad03cad5377d887a7b59c0bf78734df40cd6d44940a20f5f02896911a43231e81b7ee864311cd8cd202473044022035237c80120014629af1b1f1db73f6ed74e748a5afd398e05ce35a81e56130f902204ef75df72cce7fc124ce4696cb8155b5dfad16950eea1c7de0eedc761ffa7ff00121025ce5bd977e990a1e653519333c35fa2d7531a1b5cc6737e2057165ff148aca5b00000000", - "order_hash": "337d20f2431441591a46f8c65569e5e8bea98c70e0d6fa243ed19c4b40c3f9b7", - "amt": "3700000000000000000000000", - "bitcoin_tx": "00000020e7f505d8d9098cca86d39b4889f4ae4d2514929e16b0030000000000000000008d1d3bbee8ca41c87cea86e0d1eef44789a34051b3b48c68c4f358d488e75de8948e9f6569d80317921bb034", - "decimals": "18", - "from": { - "pkscript": "5120aa9145519b90c95b6b41044bd7c63ea661bdb6c0bdbda590a4cb759f9978915b", - "address": "bc1p42g525vmjry4k66pq39a03375esmmdkqhk76ty9yed6elxtcj9ds9pm7dt" - }, - "from_bal": "0", - "offset": "0", - "output": "0", - "tick": "ORMM", - "to": { - "pkscript": "51207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba129731899", - "address": "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - }, - "to_bal": "612741501250300100000000000", - "tx_id": "9778d139d55f3dca60e4d45942cf6c0ab97e23fd24771696b9ecdfba52303b01", - "proof_hashes": [ - "0048801e960dbf63c4602968259b23efc84d01b56f765c748d02b7387fda083c", - "c2ad185f79ab5e04def0b4ae8a1b971f03d738501c999be7b04d453f115d0c99", - "dde8ca635a80f4978049d95e53621f85b81a109e739c8a17e3a87589baff3378", - "3f0a3723a1141af85387d1180c5d25fd5c0ba1de9d140d46b608511659d146e1", - "02c2fe271149f95e3b2ce44441158c0e6459df5a75297df6d3e4733d78ee5577", - "223866a29166b32436d84381dea03193a1fddcabe93d5752a05d42539c754641", - "b58fd40d5861a7a1407315f2d91e328442fa25f4a9f2dc7a937aff2e05fb0c24", - "f2d8b750b230ea7a05ab8c8f9c607410bfa8c85b1066128be835cd7f3fe3e787", - "190320c66700b5bf8decea0a29491b5c3a0f53692823107dbe01b99af615c263", - "fa3e58599aa6573f3702bf0d53bd306f57713a642b696142131b6e009257d600", - "ecf791c893b78c40c2aad6125aea4ee5dd39d92a4ecbd421a9b38c90433dd3d3", - "2c202c28b430c7b7b726b006c55a661af87fdcb349ded3becc5d563baa39cf8a" - ], - "tx_index": "2049", - "tree_depth": "12", - "height": "825254", - "signers": [ - "SP1B0DHZV858RCBC8WG1YN5W9R491MJK88QPPC217", - "SP35D14R1JB3KHE4D55MMN646GFZJ198B7FMBG5PD", - "SP3ZCGVGSQWT6TJAXZRXHCYA6SWGNSNGKHSYA1F2Q" - ], - "signer_pubkeys": [ - "02883d08893252a59cf25aafffe1417bf74a7526621665a4bc0060e4aa95405891", - "0255966348dacd748595af0439e0a1cc947b2e3dc090acd8f90c32c30c3099b0a0", - "03c1a83abd5a199cb502818a110e2d55f67aae0e894f776c189b9f73556f8402a9" - ], - "signer_types": [ - "bis", - "hiro", - "unisat" - ], - "signatures": [ - "0fc66c9a7fe85ce78740fcc07f60ac47d5a05c469b2ca5f1ee16f5cc4b6eda1e41367bd67b03e7fbc6e4ba883c6fad1551373bd786f59afefbed268d08e59fd500", - "cd63d0ffae136ca1ffe1681ec4b062ada335b002b96b2a6153cea0a1f3ed94f14b601202ac2c8ecb229168c1264d0fad3475307df5a493ad98b9fae431f5138401", - "f7045fca2269e91d632f4a259eb47cc9f3ebb17dd64f7b8f4dfc8aa2ecfb2e716bfcce5f3c8ec6be0987c6f620d8c4205cd8d0c9728ee73c8892768ffca211c101" - ], - "created_at": 1704970783160, - "updated_at": 1704970783160 - }, - { - "tx_hash": "020000000001023c99d5e25fac74e9d73d48f524e4a4772fcff9b6515d4383a5b4de1f93734f590000000000fdffffffb5c50d3e99ad5cab208c154047ae24290de2895ff68b19e8237f19ed707d02a30100000017160014df456fbaa7c5f34de88cc94494c14f0d6e83f0b2fdffffff0322020000000000002251207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba1297318999b873b000000000017a9147677a8e87a0b9fdaffcf2837bbfddd82adc7bcbd870000000000000000386a360c0000000204646573740100000000000000000000000000000000047573657205164e928c9b9f2884e66ebc9cffa24146da5c4c35450140f7b6b87eea8059209ec74c7418a59050bd0bd56cdded5cde1e684646628d9b8864803b32d6f5eec08c65887ae065f58687484ca5aad9eb5fcfdbabfa092afced02483045022100c2ea597e0b0948812dccb4cf7ab9700bf6d335d85665dce9d1d1cc729bfeaf1302205f8071e8d6c3ad136cc9543c65ff7ebc927b13955b8b462ffeb71f7eac28c1f2012102877a31bb403b5f261df23397709629e6cc2aa4b33a5d915263dd1b776f4d9d4800000000", - "order_hash": "4576d334224e0e693377d120253ff2bcb80659b523d5e4ba9d240110cf82cd84", - "amt": "24500000000000000000000", - "bitcoin_tx": "0000ff3f498d61c4022daa78511e5813c26548790374795d314e030000000000000000006bf1aaef26015cdfbaab2dbfc90559d16b3323bc2faa8741457cbe9668fd145c025e9f6569d803172c5b5c1a", - "decimals": "18", - "from": { - "pkscript": "5120404c01fce8c12d82f9f6b6050777bcaf0751e25d5948f0b37d45937bc9ad1430", - "address": "bc1pgpxqrl8gcykc970kkczswaau4ur4rcjat9y0pvmagkfhhjddzscq6mdpf4" - }, - "from_bal": "0", - "offset": "0", - "output": "0", - "tick": "OXBT", - "to": { - "pkscript": "51207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba129731899", - "address": "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - }, - "to_bal": "39776330400000000000000", - "tx_id": "08fc19fd8f6d9d51b749ab749681b73cc4f509017e93ba2e8a2057067fbe03af", - "proof_hashes": [ - "b05924a5ebc27daf9e4c098c87cfd221be41eae11e6f1f7f7077fc8cdab920a1", - "bd2c2e28b685e32b87df545df150fbb365ffc6f4c0212e5e91825ffc68ee3b7b", - "cd90c2c8253afe98f9b4b508fe5de98183455dc3c2b038800b6d79392d7ff631", - "35ccbc548dadd37c52a3e2dc5b3e3368b42138eee021b15116c4d28a738b3783", - "3849fc4ef7251102c0455ab8f93d515f07a169bc59c5bc73adcbbbfb9bf6a4f3", - "886d7f840b46fce7deadfe9ab284f01de2ef0aaa02d203bba79988b297aca71e", - "b6819566d285ee1425b5228a22b8ec17866adfc997cc49fdefafd48164d9b2fe", - "91b68bd8fcf5cf071caf70f9eb0baedd4e64fe10340bcd270292c42cf90263e1", - "77a107cc14035c6213eb24edba266619d9d5556469702400e151b06342078a77", - "a6caab6504b9b5211b84e09d86f000d9a76cbbd1c102c7ac1ca16910ea12ba84", - "dc78465cee2705e0e7df2ab1552b0e397d38b73d7e72748bc15b9bcd79943dc7", - "348aa2ad2007818206ad5ba02ace1105ff2aac38d651b987f310afad20644fb6" - ], - "tx_index": "930", - "tree_depth": "12", - "height": "825229", - "signers": [ - "SP1B0DHZV858RCBC8WG1YN5W9R491MJK88QPPC217", - "SP3ZCGVGSQWT6TJAXZRXHCYA6SWGNSNGKHSYA1F2Q" - ], - "signer_types": [ - "bis", - "unisat" - ], - "signatures": [ - "ef56767f067488b242ba87ccee3c7d4a5e8697d05589d83846ff1bf6ae69d7414703059780e04b1fa5a9cab64d80680a287f9c1d5abab71bc7970785e45d960300", - "d0341a786a5a7417eded3afca695ac720cf755b59506a6db8ad8a3b553e1b16324707f774cc63a9d8c6da6a3c2c7a1843da1727108ed6bd5106f86791d73750e01" - ], - "created_at": 1704970835029, - "updated_at": 1704970835029 - } - ] -} -``` -{% endcode %} -{% endtab %} - -{% tab title="Latest balance of {tick} by {from_or_to}" %} -{% code overflow="wrap" %} -```sh -curl --location --request POST 'https://api.bitcoin-oracle.network/v1/brc20' \ ---header 'x-service-type: INDEXER' \ ---header 'x-version: 0.0.1' \ ---data-raw '{ - "from_or_to": [ - "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - ], - "tick": [ - "ORMM" - ], - "limit": 1 -}' -``` -{% endcode %} - -**Response** - -{% code overflow="wrap" %} -```json -{ - "data": [ - { - "tx_hash": "0200000000010269f33e6de0c8d0fa2ad24fb7ab31e62981085c67773072cfebb30ba7e06152230000000000fdffffff14dc94d279bd19377015616ae8a0d7af7debfd4af66a49c4fc84fd1fb7d8d8350100000000fdffffff0322020000000000002251207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba129731899de28080000000000225120b87be26d45435dcf999a5614f87153ba9f12b3ad7d6f7eb89c7096ba55d94a550000000000000000386a360c00000002046465737401000000000000000000000000000000000475736572051676a3e7ab979a2926cac65cf383758c964fd42fad01402130d7dd3c3261b8ffa39397d124b4575e79fae8301fc6240811ed731db4ca3ea1fc92489e0caab3ca70ad4e249cdb3581c39d7cefda14130cd774871c02a6d701408efe9991f8fcc75cf1bcb4b2f905604716abf7f4c6b794a8224955f29dd68fa2952c0b7ac6c2559686241c32b9eaddcaefe146d0ee4e8dea5d1439e0790213b700000000", - "order_hash": "7ed54d9d2390f2c03ebc479c7b85edf4fcba580f1172073c9102e02b8724a99f", - "amt": "2696850000000000000000000", - "bitcoin_tx": "00000024759a2a96f6d4c7b6169e0ec425ce216d6d06ef9e67cb030000000000000000007481d64f1c2113dedb79d8d27b9b3ae829a951aab141428042ec67c5a381bb1accb8a56569d8031718108c2f", - "decimals": "18", - "from": { - "pkscript": "5120b87be26d45435dcf999a5614f87153ba9f12b3ad7d6f7eb89c7096ba55d94a55", - "address": "bc1phpa7ym29gdwulxv62c20su2nh2039vad04hhawyuwztt54weff2suawxly" - }, - "from_bal": "0", - "offset": "0", - "output": "0", - "tick": "ORMM", - "to": { - "pkscript": "51207e875ae46c9f2d28d8d302cfa8c045bfc94df9277dbdf2d7a1fcdba129731899", - "address": "bc1p06r44ervnukj3kxnqt863sz9hly5m7f80k7l94aplnd6z2tnrzvstdkzsq" - }, - "to_bal": "613048439850300100000000000", - "tx_id": "508358f6ddda009c3384b06485d0ab574673cf099a95e8a842d513d6e0ca9988", - "proof_hashes": [ - "78d43aeafbf896c9c08ca81dd0123cee8fe6920ec3704ebe4bb1ab379ddc3237", - "65beee3a9d7539ee0d4bf18ab60e37e0ac4eb8b56eb6a2a6179093d04cbd8bfa", - "b64a594738212c1a174612558fc88dd25a0e916373c8e516874cc8aa6c7a0ac5", - "8fa03e9cce09e81847792f1db0a99cad6a24c17879f84186cbd754959f90a6e2", - "ab41c3f5c9126df65c4a485db493ecf1c7ed6b621469a3bb26143191e47933db", - "ee5b3305dcdd34d89e87e051e200e8eae6808f0b2002f8ea177578f62983ec76", - "a6985409cddec722494d07b4a6b699a9095e9ba6fe3b5c902c33bc6213043573", - "58da9a56a684ac8b76fe1659a0f06bebae67ef17b17352c7cfa3735cf217fc04", - "dfe3fa38798e03ec6304fd40045345ed99fecb90f6aab0e887cc44691c600ab3", - "92249cc6082a2cf61718bd52d9f8506ad9bef28d426524455e7ffc1155e99e0d", - "297e44492b16e57842e2691fbd9c8a1c73677102c81b368b8c10cb538215e686", - "1d98b08c6ff58476fa9c08d56436a09242ff9c300429f5549303cc89559ee7aa" - ], - "tx_index": "2275", - "tree_depth": "12", - "height": "825936", - "signers": [ - "SP1B0DHZV858RCBC8WG1YN5W9R491MJK88QPPC217", - "SP3ZCGVGSQWT6TJAXZRXHCYA6SWGNSNGKHSYA1F2Q" - ], - "signer_pubkeys": [ - "02883d08893252a59cf25aafffe1417bf74a7526621665a4bc0060e4aa95405891", - "03c1a83abd5a199cb502818a110e2d55f67aae0e894f776c189b9f73556f8402a9" - ], - "signer_types": [ - "bis", - "unisat" - ], - "signatures": [ - "c6a17ad9c249f896dc3a9cc46b77c25d05516811dec70b7768e306a8a79e073932148075c2eb887248534ccfde74da2ac5186f01a847ca00195e35ec2745b98a00", - "745f23a5993799c6309820b2c2163dbbc5e3f1f8722c643fa58ef016a7d6240540182e5e61320955109b56dec0fd8f51edf25a34686c860ed8d722807c18804601" - ], - "created_at": 1705359837844, - "updated_at": 1705359837844 - } - ] -} -``` -{% endcode %} -{% endtab %} -{% endtabs %} - - - diff --git a/bitcoin-oracle/security-audits.md b/bitcoin-oracle/security-audits.md deleted file mode 100644 index 50d65b5..0000000 --- a/bitcoin-oracle/security-audits.md +++ /dev/null @@ -1,7 +0,0 @@ -# Security Audits - -Bitcoin Oracle is audited by CoinFabrik. - -* [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. diff --git a/bitcoin-oracle/threshold-based-consensus/README.md b/bitcoin-oracle/threshold-based-consensus/README.md deleted file mode 100644 index 88f02e1..0000000 --- a/bitcoin-oracle/threshold-based-consensus/README.md +++ /dev/null @@ -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. - diff --git a/bitcoin-oracle/threshold-based-consensus/threshold-sampling.md b/bitcoin-oracle/threshold-based-consensus/threshold-sampling.md deleted file mode 100644 index 1722d85..0000000 --- a/bitcoin-oracle/threshold-based-consensus/threshold-sampling.md +++ /dev/null @@ -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. diff --git a/bitcoin-oracle/what-is-the-bitcoin-oracle/README.md b/bitcoin-oracle/what-is-the-bitcoin-oracle/README.md deleted file mode 100644 index 38b543c..0000000 --- a/bitcoin-oracle/what-is-the-bitcoin-oracle/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# What is the Bitcoin Oracle - -## 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. - -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. - -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. - -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). - -## Open to all to participate - -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! - -{% embed url="https://github.com/alexgo-io/bitcoin-oracle" %} diff --git a/bitcoin-oracle/what-is-the-bitcoin-oracle/what-is-the-bitcoin-oracle.md b/bitcoin-oracle/what-is-the-bitcoin-oracle/what-is-the-bitcoin-oracle.md deleted file mode 100644 index 6f24bd9..0000000 --- a/bitcoin-oracle/what-is-the-bitcoin-oracle/what-is-the-bitcoin-oracle.md +++ /dev/null @@ -1,35 +0,0 @@ -# Why Bitcoin Oracle - BRC20 - -## Bitcoin does not understand you - -The DeFi landscape is teeming with possibilities, and at the heart of it all, Bitcoin DeFi is set to take center stage. In the coming years, we expect a surge in growth revolving around Ordinals, BRC20 tokens, Bitcoin L2 in particular Stacks. - -A quick retrospect shows how Ordinals have brilliantly showcased the potential of the Bitcoin blockchain. This revolutionary platform has turned the table, illustrating that Bitcoin’s ledger is more than just a settlement layer. - -The unique character of BRC20 tokens, built on a fundamentally non-fungible blockchain, sparks intrigue among many. Even though Bitcoin’s blockchain doesn’t enforce the token standard rules, and the token operation is often slow and inefficient, the allure of Bitcoin being more than just a payment system is irresistible. - -In order to enforce the token standard rules, a number of "off-chain" indexers has, therefore, been developed and are in use to address these constraints. However, the risk of tampering with a centralized off-chain indexer cannot be ignored, and many in the field, including us, consider the establishment of an on-chain, tamper-proof, and censorship-resistant indexer to be pivotal for wider BRC20 adoption. - -To that end, we’re collaborating with pioneers like Domo, the creator of the BRC20 standard, and the major off-chain indexers like \[BIS], OKX, Hiro and UniSat to construct an "indexer of indexers." This concept capitalizes on Stacks’ unique attributes as Bitcoin’s L2, leading the charge for decentralized consensus on BRC20 indexing. - -## Temper-proof, censorshop-resistant, indexing - -Bitcoin Oracle aims to provide a temper-proof, censorship-resistant, indexing of events of meta-protocols like BRC20, with Bitcoin chain as its ultimate source of truth, removing the needs to rely on a single, centralised, off-chain, indexer. - -
- - - -## Founded on the partnership - -Bitcoin Oracle does not implement an on-chain version of "indexing engine" itself, which, while theoretically possible, is computationally very expensive, but rather runs a federated model that relies on a consortium of off-chain indexers to validate and submit the latest meta-protocol transactions to the on-chain smart contract written by ALEX, which keeps the validators in check by (1) implementing a consensus mechanism and (2) independently verifying that the purported Bitcoin tx is indeed mined (which only Bitcoin L2, like Stacks, can do). - -The consensus is reached when a minimum threshold (i.e. "_m-of-n_") of pre-approved validators agree to a particular event. - -## Combining the best of off-chain and on-chain - -This combination of off-chain computation and on-chain verification allows the Bitcoin Oracle to scale without compromising its security as the governance around a particular meta-protocol evolves. - -For example, the structure means disagreements over the state are easily resolved so long as they concern within the existing rules of the meta-protocol concerned, because Bitcoin network acts as the universal source of truth and all indexers do are indexing that truth according to the rules. - -Disagreements stemming from those that are outside the current rules require update of the rules, but does not require an upgrade of the on-chain indexer, vastly simplifying the process. diff --git a/developers/api-references.md b/developers/api-references.md deleted file mode 100644 index 725f705..0000000 --- a/developers/api-references.md +++ /dev/null @@ -1,95 +0,0 @@ -# REST API - -Front-end developers may use our REST API ([https://api.alexgo.io](https://api.alexgo.io)) to access the latest market data on ALEX. - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/allswaps" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/pool_stats/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/pool_volume/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/volume_24h/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/volume_7d/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/pool_liquidity/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/liquidity/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/fee/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/stats/tvl" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/stats/tvl/{token}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/stats/total_supply/{token}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/price/{token}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/pool_token_price/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/pool_token_stats" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/price_history/{token}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/pairs" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/tickers" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/ticker/{ticker_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/orderbook/{ticker}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/historical_swaps/{pool_token_id}" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v2/coin-gecko/pairs" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v2/coin-gecko/tickers" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} - -{% swagger src="https://api.alexgo.io/swagger-ui-yaml" path="/v1/public/pairs" method="get" %} -[https://api.alexgo.io/swagger-ui-yaml](https://api.alexgo.io/swagger-ui-yaml) -{% endswagger %} diff --git a/developers/smart-contracts/README.md b/developers/smart-contracts/README.md deleted file mode 100644 index d2102c7..0000000 --- a/developers/smart-contracts/README.md +++ /dev/null @@ -1,5 +0,0 @@ -# Smart Contracts - -For the complete token list and the pool mapping, see [Token List](token-list.md) and [AMM Pool Mapping](amm-pool-mapping.md). - -
ContractAddress
DAOSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.executor-dao
VaultSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-vault
Reserve PoolSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-reserve-pool
LaunchpadSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-launchpad-v1-1
LotterySP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-lottery
Trading PoolSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.amm-swap-pool-v1-1
Fixed Weight PoolSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.fixed-weight-pool-v1-01
Simple Weight PoolSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.simple-weight-pool-alex
Swap Router(to route between Fixed Weight Pool and Simple Weight Pool)
SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.swap-helper-v1-03
Swap Bridge (to route between Trading Pool and Fixed Weight Pool / Simple Weight Pool)
SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.swap-helper-bridged
ALEX TokenSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.age000-governance-token
autoALEX TokenSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.auto-alex
Bridge EndpointSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.bridge-endpoint-v1-01
sUSDTSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.token-susdt
diff --git a/developers/smart-contracts/amm-pool-mapping.md b/developers/smart-contracts/amm-pool-mapping.md deleted file mode 100644 index 6a88b4c..0000000 --- a/developers/smart-contracts/amm-pool-mapping.md +++ /dev/null @@ -1,204 +0,0 @@ -# AMM Pool Mapping - -Below table maps the pool listed on [https://app.alexlab.co/pool](https://app.alexlab.co/pool) to smart contracts with the relevant parameters - -## Pool Types - -We have three smart contracts in production that provide AMM. - -### Trading Pool - -[Trading Pool](../../trading-lending-and-borrowing/trading-pool.md) is the latest AMM smart contract that developers should use whenever possible. - -Trading Pool implements Generalised 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). - -Trading Pool is parameterised with a single parameter $$t$$. $$t$$ can be between 0 and 1, with $$t=1$$ being equivalent of constant product formula (i.e. Uniswap V2) and $$t=0$$ being equivalent of constant sum formula (i.e. mStable). $$0TokenAddressSTXSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wstx-v2ALEXSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-alexxBTCSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wxbtcsUSDTSP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-susdtxUSDSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wxusdautoALEXSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.auto-alex-v3USDASP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wusdaDIKOSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wdikoMIASP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wmiaNYCSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wnycBANANASP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wbanSLIMESP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wslmWELSHSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wcorgiVIBESSP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.token-wvibes - -## BRC20 Tokens - -BRC20 tokens on ALEX represent those BRC20 tokens that are pegged in from Bitcoin. - -
TokenAddress
$B20SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-db20
MAXISP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-maxi
SHNTSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-shnt
PIZASP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-piza
LONGSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-long
INSCSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-insc
MAJOSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-majo
DEXMSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-dexm
ATMTSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-aiptp
CVLTSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-cvlt
LBOWSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-lbow
SBTCSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-sbtc
OXBTSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-oxbt
₿SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-spacesignb
ORDSSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-ords
NYTOSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-nyto
BENGSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-beng
TRACSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-trac
SATSSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-sats
TAROSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-taro
10MMSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-10mm
PEPESP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-pepe
VMPXSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-vmpx
@LFGSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-atlfg
ORDISP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-ordi
$BITSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-dbit
MXRCSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-mxrc
IGLISP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-igli
OHMSSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-ohms
JAKESP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-jake
MEMESP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-meme
NALSSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-nals
XINGSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-xing
BANKSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-bank
PASSSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-pass
WZRDSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-wzrd
MOONSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-moon
DRACSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-drac
LOVESP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-love
ZBITSP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-zbit
diff --git a/developers/testnet.md b/developers/testnet.md deleted file mode 100644 index 1293367..0000000 --- a/developers/testnet.md +++ /dev/null @@ -1,16 +0,0 @@ -# Testnet - -We use our own testnet whose API node is hosted at [https://stacks-node-api.testnet.alexlab.co/](https://stacks-node-api.testnet.alexlab.co/), with a few useful modifications (such as [puppet mode controller](http://127.0.0.1:5000/s/sPu0USrFZJvbjvTbkBTh/)) to the stock testnet deployment. - -You can explore the state of the testnet at [https://explorer.testnet.alexlab.co/?chain=mainnet](https://explorer.testnet.alexlab.co/?chain=mainnet). - -Developers generally would interact directly with our contracts deployed on the testnet through the API node above, but we also make available [https://app.testnet.alexlab.co/](https://app.testnet.alexlab.co/) for those who would like to interact from a browser. - -Please note the testnet may be reset from time to time for maintenance and other purposes. We try to minimise the frequency of these resets, but it can and does happen, so please do bear that in mind when interacting with our testnet. - -For any questions / follow-ups, please use our Discord channel ([https://discord.gg/alexlab](https://discord.gg/alexlab)). - -## Smart Contracts - -
ContractAddress
VaultST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.alex-vault
Reserve PoolST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.alex-reserve-pool
Fixed Weight PoolST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.fixed-weight-pool-v1-02
Simple Weight PoolST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.simple-weight-pool-alex
Swap HelperST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.swap-helper-v1-03
ALEX TokenST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.age000-governance-token
autoALEX TokenST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.auto-alex
STX (wrapped)ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wstx
xBTCST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wbtc
xUSDST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wxusd
USDAST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wusda
- diff --git a/bitcoin-bridge/integrations/README.md b/integrations/README.md similarity index 85% rename from bitcoin-bridge/integrations/README.md rename to integrations/README.md index 8921029..c40e0ea 100644 --- a/bitcoin-bridge/integrations/README.md +++ b/integrations/README.md @@ -26,11 +26,11 @@ The configuration parameters include, among others,: ## Integration with Bitcoin Oracle (> 1 week) -Bitcoin Bridge scales by partnering with [Bitcoin Oracle](broken-reference) which runs the validation network. +Bitcoin Bridge scales by partnering with [Bitcoin Oracle](../bitcoin-bridge/integrations/broken-reference/) which runs the validation network. 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 Oracle produces the [consensus data](broken-reference) based on the computation from the off-chain engines and provides a [consensus model framework](broken-reference) 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: diff --git a/bitcoin-bridge/integrations/bitcoin-l2s.md b/integrations/bitcoin-l2s.md similarity index 55% rename from bitcoin-bridge/integrations/bitcoin-l2s.md rename to integrations/bitcoin-l2s.md index c87437c..9fa94d2 100644 --- a/bitcoin-bridge/integrations/bitcoin-l2s.md +++ b/integrations/bitcoin-l2s.md @@ -2,13 +2,8 @@ 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. +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 XLink DAO 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 - -
ChainContract address
Stacks (BRC20)https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.brc20-bridge-endpoint-v1-07?chain=mainnet
Stacks (BTC)https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.btc-bridge-endpoint-v1-11?chain=mainnet
- diff --git a/bitcoin-bridge/integrations/non-bitcoin-chains.md b/integrations/non-bitcoin-chains.md similarity index 62% rename from bitcoin-bridge/integrations/non-bitcoin-chains.md rename to integrations/non-bitcoin-chains.md index 3cff116..d1be6d0 100644 --- a/bitcoin-bridge/integrations/non-bitcoin-chains.md +++ b/integrations/non-bitcoin-chains.md @@ -2,12 +2,8 @@ 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. +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 XLink DAO 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 - -
ChainContract address
Ethereumhttps://etherscan.io/address/0xfd9f795b4c15183bdba83da08da02d5f9536748f
BNB Chainhttps://bscscan.com/address/0xb3955302e58fffdf2da247e999cd9755f652b13b
diff --git a/integrations/understanding-the-bitcoin-bridge.md b/integrations/understanding-the-bitcoin-bridge.md new file mode 100644 index 0000000..c2a40eb --- /dev/null +++ b/integrations/understanding-the-bitcoin-bridge.md @@ -0,0 +1,7 @@ +# Bitcoin + +On Bitcoin, users interact with Multisigs (operated by XLink DAO 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. diff --git a/launchpad/using-the-launchpad.md b/launchpad/using-the-launchpad.md deleted file mode 100644 index 625180e..0000000 --- a/launchpad/using-the-launchpad.md +++ /dev/null @@ -1,68 +0,0 @@ -# Using the Launchpad - -## Deployment - -[https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-launchpad-v1-1?chain=mainnet](https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-launchpad-v1-1?chain=mainnet) - -## Listing - -`contract-owner` calls `create-pool` with the following parameters. - -* `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` -* `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 -* `registration-end-height` : end (inclusive) block-height of registration period -* `claim-end-height` : end (inclusive) block-height of claim (i.e. lottery) period -* `apower-per-ticket-in-fixed` : `apower` required for each `ticket` (can be a list, in 8-digit fixed notation) -* `registration-max-tickets` : maximum number of `ticket` an address can register -* `fee-per-ticket-in-fixed` : listing `fee` charged by the platform as percentage of `price-per-ticket-in-fixed` (in 8-digit fixed notation) - -**Launch price** of `project token` in `payment token` = `launch-tokens-per-ticket` / `price-per-ticket-in-fixed` - -## Project Token Transfer - -Once the pool is created, and before the registration period starts, `launch-owner` must call `add-to-position` with the following parameters: - -* `launch-id` : id of the launch -* `tickets` : number of `tickets` `launch-owner` wants to allocate to -* `launch-token-trait` : trait reference of `project token` - -**Total raise** for `project token` = `tickets` x `launch-tokens-per-ticket` x Launch price of `token`. - -Upon calling `add-to-position`, (`tickets` x `launch-tokens-per-ticket`) of `project token` will be transferred from `launch-owner` to the contract. - -## Registration - -Participants call `register` with the following parameters: - -* `launch-id` : id of the launch -* `tickets` : number of `ticket` the participant wants to register -* `payment-token-trait` : trait reference of `payment token` - -Assuming (1) registration period has started, (2) registration period has not ended and (3) the participant is not already registered, the contract will register the participant and: - -* burn the required number of `apower` from the participant's wallet, and -* transfer `tickets` x `price-per-ticket-in-fixed` of `payment token` from the participant's wallet to the contract. - -## Lottery - -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 - -* `launch-id` : id of the launch -* `input` : list of participants who won the lottery (up to 200) -* `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 - -* transfer the proceeds of `payment token`, net of `fee`, to `launch-owner`, -* transfer `fee` to the platform, and -* transfer the appropriate number of `project token` to the winners. - -Refund will be processed by either `contract-owner` or `launch-owner` in a similar manner to the claim. diff --git a/launchpad/what-is-the-launchpad.md b/launchpad/what-is-the-launchpad.md deleted file mode 100644 index 526fdd8..0000000 --- a/launchpad/what-is-the-launchpad.md +++ /dev/null @@ -1,37 +0,0 @@ -# What is the Launchpad - -
- -Every project needs a platform to launch their project tokens and our Launchpad is a lottery-based token launch platform that uses a hybrid off-chain / on-chain model. - -All user funds related transactions are on chain. These include the submission of the Launch ticket together with the required payment tokens, the distribution or claim of the project tokens won, and the distribution or refund of the payment tokens in the case of not winning the lottery. - -What is computationally expensive, i.e. the lottery drawing itself, is done off chain, but submitted to our on-chain contract for verification. The lottery drawing is also transparent and verifiable as it is based on the random seed available from the latest block height, i.e. anyone can independently verify the winners' table. - -## Off-chain lottery system - -Lottery system is based on a random number generator called “linear congruential generator”, which is [one of the oldest and best-known pseudorandom number generator algorithms](https://en.wikipedia.org/wiki/Linear\_congruential\_generator). - -It starts by firstly drawing a verifiable random function seed (“seed”) from the Stacks block following the registration end. The seed is then - -1. multiplied by a constant (_134775813_), -2. added to another constant (_1_), and, finally, -3. the modulus of its outcome by another constant (_4294967296_) is calculated to serve as the next random number. - -This random number is then scaled by `maximum step size`, the ratio of the total number of registered tickets over the total number of tickets to be won (i.e. oversubscription ratio), multiplied by 1.5 times `walk resolution`. - -This `maximum step size` helps ensure the fair-ness of the lottery system. - -If a random number drawn falls between a particular `walk resolution` within a block that corresponds to a ticket held by a user, the ticket is determined to have won the lottery. - -To generate the next random number, we move to the end of the `walk resolution` of the current random number, and draw another random number using the above linear congruential generator with the current random number as its seed. - -The process is repeated until we reach the end of the chain, with the tickets upon whose corresponding `walk resolution` random numbers fell having won the lottery. - -These “winners” are first determined off-chain, without the need for any on-chain events, thereby greatly increasing the overall efficiency of the lottery system. - -## On-chain verification - -In order to ensure these “winners” are not tempered with or generated in error, upon submission of the list to process claim (whereby the “winners” receive the project tokens) and refund, the contract verifies independently that the list is correct using the same process outlined above, before triggering on-chain events (i.e. processing claims and refunds). - -This hybrid on-chain/off-chain lottery system therefore allows ALEX to create a Launchpad that combines the efficiency/speed of off-chain processing, while maintaining verifiability/immutability of on-chain processing. diff --git a/orderbook/understanding-the-orderbook.md b/orderbook/understanding-the-orderbook.md deleted file mode 100644 index 66910a0..0000000 --- a/orderbook/understanding-the-orderbook.md +++ /dev/null @@ -1,10 +0,0 @@ -# Understanding the Orderbook - -Orderbook uses a hybrid on-chain/off-chain design, whereby a commitment to buy or sell certain asset is communicated in a cryptographically signed message, which is then matched by an off-chain matching engine before settling on-chain. - -
- - - - - diff --git a/orderbook/using-the-orderbook.md b/orderbook/using-the-orderbook.md deleted file mode 100644 index 63f8c22..0000000 --- a/orderbook/using-the-orderbook.md +++ /dev/null @@ -1,123 +0,0 @@ -# Using the Orderbook - -ALEX Orderbook is available at [https://app.alexlab.co/orderbook](https://app.alexlab.co/orderbook). - -## Register with the Orderbook - -Users register with the Orderbook and deploy their own wallet to which they make deposits and withdrawals. - -At the registration, users provide their public keys so the Orderbook can verify their signed orders. - -## Place buy / sell orders gas-free - -Users can place buy / sell orders of any tokens supported by the Orderbook without paying transaction fees. They can cancel orders any time. Orderbook ensures that the user wallet balance is sufficient. - -All orders are signed by the originating users and the orders are validated with the users’ public keys before settlement. - -## Orders are matched and confirmed - -Order Matching Engine continuously matches buy and sell orders. Matched orders are sent to Exchange Contract. - -## Orders are settled in aggregate - -Exchange Contract validates the matched orders, aggregate them and settle in a single transaction. It updates the order fill, which is then used by Order Matching Engine to optimise the order matching. - -## REST API - -Once user registration is complete, you can use our REST API ([https://stxdx-api.alexlab.co/](https://stxdx-api.alexlab.co/)) to interact with the Orderbook. - -For example, [b20-trading-bot](https://github.com/alexgo-io/b20-trading-bot) uses our API to automate grid trading on the Orderbook. - -For more details, please contract your ALEX representatives. - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/login" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts:getByPrincipal" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts/{uid}" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts/pnl/{uid}/today" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/assets" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts/{uid}:updateSettings" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts/{uid}:sendVerificationEmail" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts/{uid}:verifyEmail" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/accounts/{uid}/fund-history" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orders" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orders" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orders:make" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook/{market}" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orders/{order_hash}" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orders/{order_hash}:cancel" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orders:cancel_all" method="post" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook:tickers" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/fills" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook/{market}:fills" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook/{market}:trades" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook/{market}:trading-view" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook:overview" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} - -{% swagger src="https://stxdx-api.alexlab.co/swagger-ui-json" path="/v1/orderbook/{market}:overview" method="get" %} -[https://stxdx-api.alexlab.co/swagger-ui-json](https://stxdx-api.alexlab.co/swagger-ui-json) -{% endswagger %} diff --git a/orderbook/what-is-orderbook.md b/orderbook/what-is-orderbook.md deleted file mode 100644 index cd1d7ee..0000000 --- a/orderbook/what-is-orderbook.md +++ /dev/null @@ -1,35 +0,0 @@ -# What is the Orderbook? - -
- -Orderbook is ALEX's scaling solution layer that brings **instant trade confirmation** to the security of Bitcoin. - -Orderbook uses a hybrid on-chain/off-chain design, whereby a commitment to buy or sell certain asset is communicated in a cryptographically signed message, which is then matched by an off-chain matching engine before settling on-chain. - -Orderbook is designed such that many types of market exchanges, not only a traditional CLOB but also an NFT marketplace or social trading, can be built on top. - -## Why do we need the Orderbook? - -Orderbook is ALEX's scaling solution layer that brings **instant trade confirmation** to the security of Bitcoin. Orderbook therefore addresses a key user experience issue our community has on Stocks - that the trade confirmation requires waiting of 10-15 minutes (along with Bitcoin block confirmation). - -## What are the benefits of using the Orderbook? - -There are a number of benefits for Bitcoin/Stacks users to use Orderbook to trade assets. - -### Instant trade confirmation with Bitcoin finality - -As we said earlier, Orderbook is our scaling solution layer that combines instant trade confirmation with Bitcoin finality. Orderbook therefore addresses a key user experience issue our community has on Stocks - that the trade confirmation requires waiting of 10-15 minutes (along with Bitcoin block confirmation). - -### Gas-free orders - -Orderbook uses a hybrid on-chain/off-chain design, whereby a commitment to buy or sell certain asset is communicated in a cryptographically signed message, which is then matched by an off-chain matching engine before settling on-chain. - -This design means users of Orderbook can create/close orders gas-free and confirm their orders instantly without having to wait for the underlying block confirmation. - -### Security of your assets - -You have the full ownership and control of your assets on Orderbook. Zero credit risk. - -### By developers, for developers - -Ease and fun of development is at the core of Orderbook design. Orderbook is designed such that many types of market exchanges, not only a traditional CLOB but also an NFT marketplace or social trading, can be built on top. diff --git a/bitcoin-bridge/reserves.md b/reserves.md similarity index 81% rename from bitcoin-bridge/reserves.md rename to reserves.md index 16df54c..abfd79e 100644 --- a/bitcoin-bridge/reserves.md +++ b/reserves.md @@ -1,10 +1,10 @@ # Reserves -Users can monitor the reserves real-time at [https://app.alexlab.co/bridge-reserve](https://app.alexlab.co/bridge-reserve). +Users can monitor the reserves real-time at [https://app.xlink.network/bridge-reserve](https://app.xlink.network/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). +For more details on aBTC, please visit [here](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). diff --git a/bitcoin-bridge/security-audits.md b/security-audits.md similarity index 100% rename from bitcoin-bridge/security-audits.md rename to security-audits.md diff --git a/trading-lending-and-borrowing/automated-market-making-designed-for-lending-protocols.md b/trading-lending-and-borrowing/automated-market-making-designed-for-lending-protocols.md deleted file mode 100644 index e299a7e..0000000 --- a/trading-lending-and-borrowing/automated-market-making-designed-for-lending-protocols.md +++ /dev/null @@ -1,55 +0,0 @@ -# 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. - -## Lending and Borrowing Process - -ALEX's core product is essentially a zero coupon bond in conventional finance. A key benefit is reduced uncertainty about a loan's interest rate, resulting in better financial planning. Specifically, prior to entering a loan contract, borrowers and lenders secure the loan's interest rate and tenor on ALEX. - -Here is a concrete example. Rachel has 100 USD. She wants to increase her 100 USD. She chooses to lend her assets out. She's ok with lending out her 100 USD for a fixed term of three months. She goes to ALEX's interface. There, Rachel can see that "three month ayUSD" is currently priced at 0.9 vs USD. Put simply, 1 ayUSD gets her 0.9 USD. She takes her 100 USD and exchanges it for ayUSD. Given the current exchange rate, she gets about 110 ayUSD. Now she waits. Three months pass. Now, Rachel can exchange her 110 ayUSD for USD again. The rate is 1 ayUSD to 1 USD. So Rachel gets 110 USD. That's a gain of 10 USD over 3 months. Pretty nice! - -Here is the general story. Borrowers and lenders enter a loan contract. Specifically, they swap a forward contract based token called "ayToken" with "Token". "Token" is the underlying asset. For example, they swap ayUSD with USD. More generally, the lender lends out "Tokens" and obtains "ayToken" in return. The price of "Token" is lower than its par value. The contract starts when a lender deposits "Token" in an ALEX pool. Then, upon expiration, the lender redeems the underlying asset, "Token", at par value. Because the lender lent out their "Token" at discounted price some time ago, and now redeems "Token" for par value, there is a profit. Pretty nice! - -In mathematical terms, the interest rate r is calculated as $$p_{t}=\frac{1}{e^{rt}}$$, where $$p_{t}$$ is the spot price of ayToken and the interest rate is assumed to compound. The formula utilises one of the most fundamental principles in asset pricing: an asset's present value is the asset's discounted future value. Thus, in our simplified example, $$t$$= 1 and $$r=\log\frac{1}{0.9}\approx10\%$$. - -## Automated Market Making (AMM) Protocol - -When designing the AMM protocol, ALEX believes the following: - -1. AMMs are mathematically neat and reflect economic demand and supply. For example, price should increase when demand is high or supply is low; -2. AMMs are a type of mean, which remains constant during trading activities. This approach is also adopted by popular platforms such as _Uniswap,_ which employ algorithmic means; and -3. AMMs can be interpreted through the lens of modern finance theory. Doing so enables ALEX to grow and draw comparisons with conventional finance. - -After extensive research, our beliefs led us to an AMM first proposed by _YieldSpace_. While we appreciate the mathematical beauty of their derivation, we adapt it in several ways with _ALEX_. For example, we replace a simple interest rate with a compounding interest rate. This change is in line with standard uses in financial pricing and modelling since Black and Scholes. We also develop a new capital efficiency scheme, as explained below. - -In mathematical terms, our AMM can be expressed as: - -$$ -x^{1-t}+y^{1-t}=L -$$ - -where $$x$$, $$y$$, $$t$$ and $$L$$ are, respectively, the balance of "Token", balance of "ayToken", time to maturity and a constant term when $$t$$ is fixed. The interest rate $$r$$ is defined as $$r=\log\left(\frac{y}{x}\right)$$, i.e. the natural logarithm of the ratio of balance between "ayToken" and "Token", while the price of "ayToken" with respect to "Token" is $$\left(\frac{y}{x}\right)^{t}$$. - -Our design depicts an AMM in the of a form of a generalised mean. It makes economic sense because the shape of the curve is decreasing and convex. It incorporates time to maturity $$t$$, which is explicitly built-in to derive ayToken's spot price. We refer readers to our [white paper](https://docs.alexgo.io/whitepaper/automated-market-making-of-alex) for detail. - -## Liquidity Providers (LP) and Capital Efficiency - -LPs deposit both ayToken and Token in a pool to facilitate trading activities. LPs are typically ready to market-make on all possible scenarios of interest rate movements ranging from $$-\infty$$ to $$+\infty$$. However, part of the interest rates curve or movements will never be considered by market participants. On example is the part where the interest rate is negative. Although negative rates can be introduced in the fiat world by central bankers as monetary policy tool, yield farmers in the crypto world are still longing everything to be positive. In ALEX, positive rate refers to spot price of ayToken not exceeding 1 and ayToken reserve is larger than Token. - -Inspired by _Uniswap v3_, ALEX employs virtual tokens - part of the assets that will never be touched, hence is not required to be held by LP. - -![Figure 1](../.gitbook/assets/cecjing.png) - -Figure 1 illustrates an example of adopting virtual tokens in the event of positive interest rate. The blue line is the standard AMM. The blue dot marks an equal balance of Token and ayToken of $$y_{v}$$, meaning there is no, or a 0%, interest rate. $$y_{v}$$ is the boundary amount, as any amount lower than it will never be touched by LP to avoid negative rate, which is represented by blue dashed line. Thus, $$y_{v}$$ is virtual token reserve. Effectively, LP is market-making on the red line, which shifts the blue line lower by $$y_{v}$$. When ayToken is depleted as shown by red dashed line, trading activities are suspended. - -A numerical example provided in Table 1 shows capital efficiency with respect to various interest rate, assuming $$t$$= 0.5 and $$L$$= 20 for illustration's sake. When the current interest rate$$r$$= 10%, LPs are required to deposit 95 token and 105 ayToken according to standard AMM. However, if the interest rate is floored at 0%, LP only needs to contribute 5 ayToken, as the rest 100 ayToken would be virtual. This is a decent saving more than 90%. - -![Table 1: Capital Efficiency when Interest Rate is Floored at 0](../.gitbook/assets/cectable3.png) - -## Yield Curve and Yield Farming - -By expressing the interest rate as $$p_{t}=\frac{1}{e^{rt}}$$, i.e. $$r=-\frac{1}{t}\log p_{t}$$, we can obtain a series of interest rates from trading pool prices with respect to various maturities, based on which we are able to build a yield curve. The Yield curve is the benchmark tool for modelling risk-free rates in conventional finance. The shape of the curve dictates expectations about future interest rate path, which helps market participants understand market behaviours and trends. Currently we might be able to build a Bitcoin yield curve from Bitcoin futures listed on the Chicago Mercantile Exchange (CME). However, not only is the exchange heavily regulated, its trading volume is skewed to the very short dated front end contracts lasting several months only. ALEX aims to offer future contracts up to 1y when the platform goes live. Should markets mature, ALEX may extend to longer tenors. - -Yield farmers can benefit from understanding the yield curve by purchasing ayToken whose tenor corresponds to high interest rates and selling ayToken whose tenor associates with low interest rates. This is a typical “carry" strategy. - -Last but not least, based on the development of the yield curve and solid design work of our AMM, ALEX will be able to provide more products. Specifically, ALEX will be able to offer derivatives, including options and structured products, building on and extending a large amount of literatures and applications in conventional finance. diff --git a/trading-lending-and-borrowing/collateral-rebalancing-pool.md b/trading-lending-and-borrowing/collateral-rebalancing-pool.md deleted file mode 100644 index 34cdf74..0000000 --- a/trading-lending-and-borrowing/collateral-rebalancing-pool.md +++ /dev/null @@ -1,21 +0,0 @@ -# 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. - -Collateral Rebalancing Pool ("CRP") uses [Weighted Equation](https://docs.alexgo.io/protocol/platform-architecture-that-supports-ecosystem-development) and dynamically rebalances between Token and Collateral. - -CRP dynamically rebalances collateral to ensure the ayToken minted (i.e. the loan) remain solvent especially in an adverse market environment (i.e. the value of the loan does not exceed the value of collateral). This dynamic rebalancing, together with a careful choice of the key parameters (including LTV and volatilty assumption) allows ALEX to eliminate the needs for liquidation. Any residual gap risk (which CRP cannot address entirely) is addressed through maintaining a strong reserve fund. - -For example, ayBTC / USD pool (i.e. borrow BTC against USD) will implement a dynamic hedging strategy against BTC upside (i.e. sell USD and buy BTC as BTC spot goes up, and vice versa). The resulting rebalancing between USD and BTC will be then executed by arbitrageurs participating in the pool pricing curve. See some illustration [here](https://docs.google.com/spreadsheets/d/1nSg6L30iedpk\_rLhq3E7Zv8ct3Myb\_D8oWmgJzwtwtw/edit?usp=sharing). The borrower effectively is an LP (and receives ayBTC as the Pool Token) and the USD collateral provided will be automatically converted into a basket of USD and BTC. - -The main benefit of such collateral rebalancing is that we can be (much) more aggressive in LTV and remove liquidation entirely (with appropriate LTV and reserve fund). This also allows aggregation of all ayToken into a single pool (rather than separate pool for each borrower). - -The main drawback is that the collateral received at the time of repayment will not be same in USD value as the original value (due to rebalancing). - -When a Borrower mints ayToken by providing appropriate Collateral, the Collateral is converted into a basket of Collateral and Token, with the weights determined by CRP. CRP determines the weights based on the prevailing LTV and uses the following formula: - -$$ -\begin{split} &w_{Token}=N\left(d_{1}\right)\\ &w_{Collateral}=\left(1-w_{Token}\right)\\ &d_{1}= \frac{1}{\sigma\sqrt{t}}\left[\ln\left(\frac{LTV_{t}}{LTV_{0}}\right) + t\times\left(APY_{Token}-APY_{Collateral} + \frac{\sigma^2}{2}\right)\right] \end{split} -$$ - -Some readers may note the similarity of the above formula to the [Black & Scholes delta](https://en.wikipedia.org/wiki/Black%E2%80%93Scholes\_model), because it is. CRP essentially implements a delta replicating strategy of a call option on Token / Collateral, buying more Token when LTV moves higher and vice versa. diff --git a/trading-lending-and-borrowing/platform-architecture-that-supports-ecosystem-development.md b/trading-lending-and-borrowing/platform-architecture-that-supports-ecosystem-development.md deleted file mode 100644 index fff1bcd..0000000 --- a/trading-lending-and-borrowing/platform-architecture-that-supports-ecosystem-development.md +++ /dev/null @@ -1,51 +0,0 @@ -# Our Design - -ALEX allows for implementation of arbitrary trading strategies and borrows its design from [Balancer V2](https://docs.balancer.fi). - -**Equation** abstracts rebalancing and market making logic, while **Pool** encapsulates the value of a strategy. Pool abstraction allows aggregation of the assets of all ALEX pools into a single **vault**, bringing many advantages over traditional DEX architecture. - -## Equation - -Equation triggers Pool rebalancing. This allows creation of any arbitrary rebalancing strategies to be deployed as a pool. - -### Generalised Mean Equation - -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 - -Weighted Equation is the most basic Equation of all and is a fork of [Balancer](https://balancer.fi/whitepaper.pdf), which generalised the constant product AMM popularised by Uniswap. We implement the following formula: - -$$ -V=\prod_{i}B_{i}^{w_{i}} -$$ - -Where $$V$$is a constant, $$B_{i}$$ is the balance of token i and $$w_{i}$$ is the weight of token i in the pool. - -As the price of each token changes, arbitrageurs rebalance the pool by making trades. This maintains the desired weighting of the value held by each token whilst collecting trading fees from the traders. [Collateral Rebalancing Pool](collateral-rebalancing-pool.md) implements the Weighted Equation. - -### Yield Token Equation - -Yield Token Equation drives [Yield Token Pool](automated-market-making-designed-for-lending-protocols.md). It follows [Yield Space](https://yield.is/YieldSpace.pdf) and is designed specifically to facilitate efficient trading between ayToken and Token. Our main contribution is to extend the model to allow for capital efficiency from liquidity provision perspective (inspired by [Uniswap V3](https://uniswap.org/whitepaper-v3.pdf)). - -For example, if a pool is configured to trade between 0% and 10% APY, the capital efficiency can improve to 40x compared to when the yield can trade between $$-\infty$$ and $$+\infty$$. - -## Pool - -Pools handle the logic of dynamic trading strategies, whose token rebalancing are then handled by Vault. Rebalancing logic is driven by Equation. Pool issues Pool Token to liquidity providers. The number of Pool Tokens are determined based on a liquidity provider's relative contribution to the Pool. Pool Tokens thus represent proportional ownership of that Pool, or assets in that Pool. - -### Trading Pool - -Trading Pool implements Generalised 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). - -### Collateral Rebalancing Pool - -Collateral Rebalancing Pool ("CRP") uses Weighted Equation and dynamically rebalances between Token and Collateral. CRP dynamically rebalances collateral to ensure the ayToken minted (i.e. the loan) remains solvent especially in an adverse market environment (i.e. the value of the loan does not exceed the value of collateral). - -### Yield Token Pool - -Yield Token Pool ("YTP") uses Yield Token Equation and is designed specifically to facilitate efficient trading between ayToken and Token. - -## 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. diff --git a/trading-lending-and-borrowing/trading-pool.md b/trading-lending-and-borrowing/trading-pool.md deleted file mode 100644 index a664fc4..0000000 --- a/trading-lending-and-borrowing/trading-pool.md +++ /dev/null @@ -1,114 +0,0 @@ -# Trading Pool - -## Deployment - -[https://explorer.alexlab.co/address/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.amm-swap-pool-v1-1?chain=mainnet](https://explorer.alexlab.co/address/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.amm-swap-pool-v1-1?chain=mainnet) - -## Introduction - -Please refer to our [white paper](../whitepaper/automated-market-making-of-alex/) for a more rigorous treatment on the subject. - -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 with another trustlessly. - -Trading Pool implements Generalised 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). - -Trading Pool is parameterised with a single parameter $$t$$. $$t$$ can be between 0 and 1, with $$t=1$$ being equivalent of constant product formula (i.e. Uniswap V2) and $$t=0$$ being equivalent of constant sum formula (i.e. mStable). $$0Caution on fixed notation - -Please note we use 8-digit fixed notation to represent decimals. If you interact directly with any of our contracts, you must provide all numbers in the correct format. - -For example, 1 should be passed as 10,000,000 (= 1e8), i.e. 1.00000000. - -## Pool creation - -A pair can be registered (i.e. a pool can be created) by calling `create-pool` with the parameters including the traits of the two tokens (`token-x` and `token-y`), the factor $$t$$, the governance address (`pool-owner`) and the initial liquidity. - -Trading Pool is permission-less in that anyone can register a pair with initial liquidity, so long as the two tokens are pre-approved (this is to prevent introducing malicious tokens to the platform). - -### Pool governance - -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`. - -* `set-fee-rate-x` and `set-fee-rate-y`: set the swap fee (% of swap amount) of `token-x` and `token-y`, respectively. Both `fee-rate-x` and `fee-rate-y` are zero by default; -* `set-start-block` and `set-end-block`: set the block heights before and after, respectively, which the pool is not available. Both `start-block` and `end-block` is set to `u340282366920938463463374607431768211455` by default; -* `set-threshold-x` and `set-threshold-y`: set the amount of `token-x` and `token-y`, respectively, below which a minimum % slippage is applied. Both `threshold-x` and `threshold-y` are zero by default; -* `set-oracle-enabled`: add or remove the pool from the on-chain price oracle. Oracle is disabled by default; -* `set-oracle-average`: set the exponential moving average factor for the `oracle-resilient`. Please note this call will reset the existing `oracle-resilient` value. The `oracle-average` is zero by default. We recommend 0.99e8. - -## Liquidity provision - -Liquidity can be added to or removed from the pool any time by calling `add-to-position` or `reduce-position`, respectively. - -### Adding liquidity - -When adding liquidity to a pool, you need to specify the amount of token-x and have the option of specifying the maximum amount of token-y you are willing to pair with token-x (i.e. slippage control). If adding liquidity requires more token-y than the maximum you specified, then the call will fail. You must also have at least the amount of token-x and the maximum amount of token-y in your wallet - otherwise the call will fail. - -Once the liquidity is added, the pool will mint a pool token as a proof of proportional ownership of the pool liquidity. The number of the pool token being minted is proportional to the amount of liquidity you added compared to the existing liquidity at the pool. - -The pool token is transferrable 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. - -### Pool tokens - -The pool token 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. - -### Fee rebates - -Trading Pool re-invests any fee rebates to the relevant pool liquidity, i.e. the invariant increases slightly after each transaction, similar to Uniswap V2. - -## Trading - -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. - -In both cases you can specify your slippage limit (`min-dy` and `min-dx`, respectively), so that the call fails if the swapped amount does not meet your target. - -### Fee - -Fee 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`. Fee 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-rebates) to liquidity providers as a reward. - -### Swap helper and routing - -It may not be reasonable to expect developers or users to remember the correct order of token pairs. Therefore we provide `swap-helper` function that helps choose between `swap-x-for-y` and `swap-y-for-x` and swaps token-x into token-y without users having to know the correct order. - -It is also useful to be able to combine multiple swaps into one. For example, it will be useful to be able to swap xUSD into xBTC in one transaction, based on two pools of STX/xUSD and STX/xBTC, instead of having to perform two swaps. To that end, we provide three helper functions - `swap-helper-a`, `swap-helper-b` and `swap-helper-c` that facilitates "multi-hop" swaps of two/three/four pools, respectively. - -## Helper functions - -In addition to the swap helpers and routing functions, we provide a few helpful functions. - -### Oracle - -Trading Pool provides two types of on-chain oracles - instant and resilient. Their implementations are similar to Uniswap V2. - -Instant oracle (`get-oracle-instant`) gives you the latest pool-implied price (i.e. most up-to-date), but is subject to a higher manipulation risk. Instant oracle may be suitable for, for example, arbitrage or liquidation. - -Resilient oracle (`get-oracle-resilient`) on the other hand gives you a trade-weighted price that is therefore more resilient to potential manipulation but is less up to date. Resilient oracle may be more suitable for, for example, benchmarking to lending and borrowing. - -### 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. - -### 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 provision - -Lastly, it will be useful to know, for example, to determine the slippage limit, how many token-x and token-y must be provided to mint certain number of pool tokens, to burn certain number of pool tokens, or how many pool tokens may be minted or burnt if certain number of token-x and token-y are provided. The relevant helper functions are `get-position-given-mint`, `get-position-given-burn` and `get-token-given-position`. - - - - - diff --git a/trading-lending-and-borrowing/vault.md b/trading-lending-and-borrowing/vault.md deleted file mode 100644 index a00056a..0000000 --- a/trading-lending-and-borrowing/vault.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. - -## 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/). - -Flash Loans are uncollateralized loans that must be repaid (plus interest) in the same transaction as it is borrowed. Since everything done with the loan must be completed in a single transaction, there are codified guarantees that make it impossible for borrowers to run away with the tokens. - -Flash Loan allows arbitrageurs to take advantages of any price discrepancies in two or more pools without the needs for holding any input tokens. diff --git a/whitepaper/automated-market-making-of-alex/README.md b/whitepaper/automated-market-making-of-alex/README.md deleted file mode 100644 index 91416dc..0000000 --- a/whitepaper/automated-market-making-of-alex/README.md +++ /dev/null @@ -1,174 +0,0 @@ -# Automated Market Making of Trading Pool - -## Abstract - -We introduce a new invariant function associated with generalised mean that underpins the ALEX AMM. ALEX builds DeFi primitives targeting developers looking to build ecosystem on Bitcoin, enabled by [Stacks](https://www.stacks.co/). With a suitable parameterisation, the invariant function 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). We also show that our invariant function maps $$L$$ to the liquidity distribution of [Uniswap V3](https://uniswap.org/whitepaper-v3.pdf). - -## Introduction - -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 with another trustlessly. This paper focuses on technical aspects of AMM. - -## AMM and Invariant Function - -ALEX AMM is built on three beliefs: (i) it is mathematically neat and reflect economic demand and supply and (ii) it is a type of mean, like other AMMs. - -We will firstly review some desirable features of AMM that ALEX hopes to exhibit. - -### Properties of AMM - -AMM protocol, which provides liquidity algorithmically, is the core engine of DeFi. In the liquidity pool, two or more assets are deposited and subsequently swapped resulting in both reserve and price movement. The protocol follows an invariant function $$f(X)=L$$, where $$X=\left(x_1,x_2,\dots,x_d\right)$$ is $$d$$ dimension representing $$d$$ assets and $$L$$ is constant. When $$d=2$$, which is the common practise by a range of protocols, AMM $$f(x_1,x_2)=L$$ can be expressed as $$x_2=g(x_1)$$. Although it is not always true, $$g$$ tends to be twice differentiable and satisfies the following - -* monotonically decreasing, i.e. $$\frac{dg(x_1)}{dx_1}<0$$. This is because price is often defined as $$-\frac{dg(x_1)}{dx_1}$$. A decreasing function ensures price to be positive. -* convex, i.e. $$\frac{d^2g(x_1)}{dx_1^2} \geq 0$$. This is equivalent to say that $$-\frac{dg(x_1)}{dx_1}$$ is a non-increasing function of $$x_1$$. It is within the expectation of economic theory of demand and supply, as more reserve of $$x_1$$ means declining price. - -Meanwhile, $$f$$ can usually be interpreted as a form of mean, for example, [mStable](https://docs.mstable.org) relates to arithmetic mean, where $$x_1+x_2=L$$ (constant sum formula); one of the most popular platforms [Uniswap](https://uniswap.org/whitepaper-v3.pdf) relates to geometric mean, where $$x_1 x_2=L$$ (constant product formula); [Balancer](https://balancer.fi/whitepaper.pdf), which our [collateral rebalancing pool](../automated-market-making-of-collateral-rebalancing-pool.md) employs, applies weighted geometric mean. Its AMM is $$x_1^{w_1} x_2^{w_2}=L$$ where $$w_1$$ and $$w_2$$ are fixed weights. ALEX AMM extends these to create a generalised mean. - -### ALEX AMM - -After extensive research, we consider it possible for ALEX AMM to be connected to generalised mean defined as - -$$ -\left( \frac{1}{d} \sum _{i=1}^{d} x_i^{p} \right)^{\frac{1}{p}} -$$ - -where $$0 \leq p \leq 1$$. The expression might remind readers of $$p$$-norm when $$x_i \geq 0$$. It is however not true when $$p<1$$ as triangle inequality doesn't hold. - -When $$d=2$$ and $$p=1-t$$ $$(0\leq t<1)$$ is fixed, the core component of generalised mean is assumed constant as below. - -$$ -\begin{split}x_1^{1-t}+x_2^{1-t}&=L\\ --\frac{dx_2}{dx_1}&=\left(\frac{x_2}{x_1} \right)^{t}\end{split} -$$ - -This equation is regarded reasonable as AMM, because (i) function $$g$$ where $$x_2=g(x_1)$$ is monotonically decreasing and convex; and (ii) The boundary value of $$t=0$$ and $$t=1$$ corresponds to constant sum and constant product formula respectively. When $$t$$ decreases from 1 to 0, price $$-\frac{dg(x_1)}{x_1}$$ gradually converges to 1, i.e. the curve converges from constant product to constant sum (see [Appendix 1](./#appendix-1-generalised-mean-when-d-2) for the relevant proofs). - -Though purely theoretical at this stage, [Appendix 2](./#appendix-2-liquidity-mapping-to-uniswap-v3) maps $$L$$ to the liquidity distribution of [Uniswap V3](https://uniswap.org/whitepaper-v3.pdf). This is motivated by an independent research from [Paradigm](https://www.paradigm.xyz/2021/06/uniswap-v3-the-universal-amm/). - -## Trading Formulae - -Market transaction, which involves exchange of one crypto asset and another, satisfies the invariant function. Please note the formulae do not account for the fee re-investment, which results in a slight increase of $$L$$ after each transaction, like _Uniswap V2_. - -### Out-Given-In - -In order to purchase $$\Delta y$$ amount of token Y from the pool, the buyer needs to deposit $$\Delta x$$ amount of token X. $$\Delta x$$ and $$\Delta y$$ satisfy the following - -$$ -(x+\Delta x)^{1-t}+(y-\Delta y)^{1-t}=x^{1-t}+y^{1-t} -$$ - -After each transaction, balance is updated as below: $$x\rightarrow x+\Delta x$$ and $$y\rightarrow y-\Delta y$$. Rearranging the formula results in - -$$ -\Delta y=y-\left[x^{1-t}+y^{1-t}-(x+\Delta x)^{1-t}\right]^{\frac{1}{1-t}} -$$ - -When transaction cost exists, the actual deposit to the pool is less than $$\Delta x$$. Assuming $$\lambda\Delta x$$ is the actual amount and $$(1-\lambda)\Delta x$$ is the fee, above can now be expressed as - -$$ -\begin{split} &(x+\lambda\Delta x)^{1-t}+(y-\Delta y)^{1-t}=x^{1-t}+y^{1-t}\\ &\Delta y=y-\left[x^{1-t}+y^{1-t}-(x+\lambda\Delta x)^{1-t}\right]^{\frac{1}{1-t}} \end{split} -$$ - -To keep $$L$$ constant, the updated balance is: $$x\rightarrow x+\lambda\Delta x$$ and $$y\rightarrow y-\Delta y$$. - -### In-Given-Out - -This is the opposite case to above. We are deriving $$\Delta x$$ from $$\Delta y$$. - -$$ -\Delta x=\frac{1}{\lambda}{\left[x^{1-t}+y^{1-t}-(y-\Delta y)^{1-t}\right]^{\frac{1}{1-t}}-x} -$$ - -### In-Given-Price - -Sometimes, trader would like to adjust the price, perhaps due to deviation of AMM price to the market value. Define $$p'$$ the AMM price after rebalancing the token X and token Y in the pool - -$$ -p'=\left(\frac{y-\Delta y}{x+\lambda\Delta x}\right)^{t} -$$ - -Then, the added amount of $$\Delta x$$ can be calculated from the formula below - -$$ -\begin{split} &(x+\lambda\Delta x)^{1-t}+(y-\Delta y)^{1-t}=x^{1-t}+y^{1-t}\\ &1+\left(\frac{y}{x}\right)^{1-t}=\left(1+\lambda\frac{\Delta x}{x}\right)^{1-t}+(\frac{y-\Delta y}{x})^{1-t}\\ &1+p^{\frac{1-t}{t}}=\left(1+\lambda\frac{\Delta x}{x}\right)^{1-t}+p'^{\frac{1-t}{t}}\left(1+\lambda\frac{\Delta x}{x}\right)^{1-t}\\ &\Delta x=\frac{x}{\lambda}\left[\left(\frac{1+p^{\frac{1-t}{t}}}{1+p'^{\frac{1-t}{t}}}\right)^{\frac{1}{1-t}}-1\right]\\ \end{split} -$$ - -## Appendix 1: Generalised Mean when d=2 - -ALEX's invariant function is $$f(x_{1},x_{2};p)=x{_1}^{p}+x_{2}^{p}=L.$$ It can be rearranged as $$x{2}=g(x_{1})=(L-x_{1}^{p})^{\frac{1}{p}}$$. $$x_{1}$$ and $$x_{2}$$ should both be positive meaning the liquidity pool contains both tokens. - -#### Theorem - -When $$0) - -Figure 1 plots $$L_{\text{Uniswap}}$$ against $$r$$ (which is proportional to $$p$$) regarding various levels of $$t$$. When $$0) - -In Figure 2, assume lower bound is 0%, whereas upper bound is 50%. We also set $$t$$= 0.5 and $$L$$= 20. If interest rate is 0%, $$L$$= 20 means holding equal amount of Token and ayToken of 100 each $$\left(100^{0.5}+100^{0.5}=20\right)$$. The figure compares actual holding of Token and ayToken with and without cap and floor. - -According to the figure, when current implied interest rate is 10%, without capital efficiency, liquidity provider is required to deposit 95.06 Token and 105.06 ayToken. This is in comparison with 18.39 Token and 5.06 ayToken after imposing cap and floor. In this example, the capital saving is at least 77%. - -## Appendix 1: Generalised Mean when d=2 - -ALEX's invariant function is $$f(x_{1},x_{2};p)=x{_1}^{p}+x_{2}^{p}=L.$$ It can be rearranged as $$x{2}=g(x_{1})=(L-x_{1}^{p})^{\frac{1}{p}}$$. $$x_{1}$$ and $$x_{2}$$ should both be positive meaning the liquidity pool contains both tokens. - -#### Theorem - -When $$0) - -Figure 3 plots $$L_{\text{Uniswap}}$$ against interest rate $$r$$ regarding various levels of $$t$$. When $$0 Date: Sat, 24 Aug 2024 06:27:07 +0000 Subject: [PATCH 2/3] GITBOOK-2: No subject --- README.md | 12 +++-- SUMMARY.md | 1 - abtc-a.k.a-alex-btc.md | 53 ------------------- integrations/README.md | 33 +++++------- integrations/bitcoin-l2s.md | 2 +- integrations/non-bitcoin-chains.md | 2 +- .../understanding-the-bitcoin-bridge.md | 4 +- reserves.md | 14 ++--- security-audits.md | 2 +- 9 files changed, 31 insertions(+), 92 deletions(-) delete mode 100644 abtc-a.k.a-alex-btc.md diff --git a/README.md b/README.md index 19b67ff..b4dbaf1 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ XLink is a key component of any projects building on Bitcoin that abstracts the XLink 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](./#multisigs) (operated by XLink DAO Foundation) to lock assets to be bridged ("source asset"), and on L2s to receive the L2 asset ("destination asset"). +On Bitcoin, users interact with [Multisigs](./#multisigs) (operated by a decentralised network of validators and verifiers) 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. @@ -28,7 +28,7 @@ Multisigs are Bitcoin wallets that are operated by multiple signers. In contrast ## 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 XLink DAO Foundation. +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 a decentralised network of validators and verifiers. Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs. @@ -38,10 +38,16 @@ That the assets are held by contracts owned by multisig contracts is important b Validators are responsible for producing cryptographic proofs, which must be verified by the Endpoints before transferring the destination assets to an address. -Bitcoin Oracle runs the validator network for and secures the Bitcoin Bridge. +[Bitcoin Oracle](https://docs.alexgo.io/bitcoin-oracle/what-is-the-bitcoin-oracle) runs the validator network for XLink. Validators are important because this set-up minimises the risk of a malicious actor taking over the system (for example, a relayer). +## Verifiers + +Verifiers provide an additional level of protection by verifying those asset transfers requested by Relayers are good and not tempered. Verifiers thus complement the Endpoints verification by incorporating additional off-chain information which may not be available to the Endpoints. + +[Bitcoin Orable](https://docs.alexgo.io/bitcoin-oracle/what-is-the-bitcoin-oracle) runs the verifier network for XLink. + ## Relayers Relayers are responsible for triggering the destination asset transfer upon gathering a minimum threshold of cryptographic proofs produced by the validators. diff --git a/SUMMARY.md b/SUMMARY.md index 0d62169..5adc918 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -6,5 +6,4 @@ * [Bitcoin](integrations/understanding-the-bitcoin-bridge.md) * [Bitcoin L2s](integrations/bitcoin-l2s.md) * [Non-Bitcoin chains](integrations/non-bitcoin-chains.md) -* [🟧 aBTC](abtc-a.k.a-alex-btc.md) * [Security Audits](security-audits.md) diff --git a/abtc-a.k.a-alex-btc.md b/abtc-a.k.a-alex-btc.md deleted file mode 100644 index 804bf79..0000000 --- a/abtc-a.k.a-alex-btc.md +++ /dev/null @@ -1,53 +0,0 @@ -# 🟧 aBTC - -### 1 aBTC = 1 BTC - -aBTC is a fully-functional SIP010 token on Stacks, where 1 aBTC represents 1 BTC locked in the multisig operated by XLink DAO 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](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)? - -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 - -
aBTCxBTCsBTC
IssuerALEXWrappedStacks
Custodial modelCommunity-owned multisigInstitutional custodianOpen membership multisig
Integration with Bitcoin BridgeYesNoYes
KYCNoYesNo
AvailabilityNowNow2024
- -### Where can I find more information on aBTC? - -#### Reserve - -{% embed url="https://app.xlink.network/bridge-reserve" %} - -#### Contract deployment - -[https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc?chain=mainnet](https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc?chain=mainnet) - -#### Multisig address - -{% embed url="https://mempool.space/address/bc1q9hs56nskqsxmgend4w0823lmef33sux6p8rzlp" %} - -#### Token logo - -
- -### diff --git a/integrations/README.md b/integrations/README.md index c40e0ea..18d5a5b 100644 --- a/integrations/README.md +++ b/integrations/README.md @@ -2,45 +2,40 @@ 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). +For the list of currently supported chains, please visit [XLink Contract Deployment](https://app.gitbook.com/s/xagAneFBZMxG6fw5k0WK/). -Below is a typical integration process, which may take between 1 and 3 weeks. +Below is a typical integration process. -## Endpoint deployment (1 week) +## Endpoint deployment -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). +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 a decentralised network of validators and verifiers. 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) +## Configuration of endpoint 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 tokens to be supported on the Endpoint, * 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) +## Integration with Bitcoin Oracle -Bitcoin Bridge scales by partnering with [Bitcoin Oracle](../bitcoin-bridge/integrations/broken-reference/) which runs the validation network. +XLink scales by partnering with [Bitcoin Oracle](https://docs.alexgo.io/bitcoin-oracle/what-is-the-bitcoin-oracle) which runs the validator and verifier networks of XLink. -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 based on the computation from the off-chain engines and provides a consensus model framework that allows the end consumer to customise their consensus model by optimising across the trust and the security budget. -Bitcoin Oracle produces the [consensus data](broken-reference) based on the computation from the off-chain engines and provides a [consensus model framework](broken-reference) that allows the end consumer to customise their consensus model by optimising across the trust and the security budget. +The validators of Bitcoin Oracle observe every Endpoint on the XLink and produce a set of cryptographic proofs for the relevant destination chain to process. -Bitcoin Bridge uses a mixture of required and optional validators (with 51% threshold) to secure its bridge, which brings the following benefits: +The relayers then aggregate those cryptographic proofs and submit to the relevant destination Endpoints upon meeting the validator threshold. -* 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. +The submissions by the relayers are verified by the verifiers, which act as the additional protection to the verification by the Endpoint. -## Wrapped asset deployment (optional) +## Synthetic 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. +Where required, a synthetic asset may be deployed on the destination chains to allow the bridging of the asset from its source chain to the destimation chains. diff --git a/integrations/bitcoin-l2s.md b/integrations/bitcoin-l2s.md index 9fa94d2..fe9e5c5 100644 --- a/integrations/bitcoin-l2s.md +++ b/integrations/bitcoin-l2s.md @@ -2,7 +2,7 @@ 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 XLink DAO Foundation. +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 a decentralsed network of validators and verifiers. Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs. diff --git a/integrations/non-bitcoin-chains.md b/integrations/non-bitcoin-chains.md index d1be6d0..134fd02 100644 --- a/integrations/non-bitcoin-chains.md +++ b/integrations/non-bitcoin-chains.md @@ -2,7 +2,7 @@ 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 XLink DAO Foundation. +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 a decentralised network of validators and verifiers. Users use Endpoints to trigger transfer of source assets. The destination assets are then sent by a relayer by producing cryptographic proofs. diff --git a/integrations/understanding-the-bitcoin-bridge.md b/integrations/understanding-the-bitcoin-bridge.md index c2a40eb..1f50af3 100644 --- a/integrations/understanding-the-bitcoin-bridge.md +++ b/integrations/understanding-the-bitcoin-bridge.md @@ -1,7 +1,7 @@ # Bitcoin -On Bitcoin, users interact with Multisigs (operated by XLink DAO Foundation, with a plan to decentralisation) to lock assets to be bridged ("source asset"), and on L2s to receive the L2 asset ("destination asset"). +On Bitcoin, users interact with Multisigs (operated by a decentralsed network of validators and verifiers) 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. +Additionally, users on Bitcoin may provide additional data (`OP_RETURN`) to trigger certain smart contract interaction on their behalf automatically by XLink. 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. diff --git a/reserves.md b/reserves.md index abfd79e..f29df8c 100644 --- a/reserves.md +++ b/reserves.md @@ -4,18 +4,10 @@ Users can monitor the reserves real-time at [https://app.xlink.network/bridge-re ## Latest circulating supply of aBTC -For more details on aBTC, please visit [here](abtc-a.k.a-alex-btc.md). +For more details on aBTC, please visit [here](broken-reference). -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" %} +{% embed url="https://api.alexgo.io/v1/stats/total_supply/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.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" %} +{% embed url="https://api.alexgo.io/v1/stats/total_supply/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-susdt" %} diff --git a/security-audits.md b/security-audits.md index d920ca5..dfa5d12 100644 --- a/security-audits.md +++ b/security-audits.md @@ -2,7 +2,7 @@ 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. +XLink 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) From abdacdd08b66429cf66aa20a14c8ea781cff8c31 Mon Sep 17 00:00:00 2001 From: sofinico Date: Fri, 13 Sep 2024 13:34:19 +0200 Subject: [PATCH 3/3] feat: structure proposal --- .gitbook.yaml | 1 + SUMMARY.md | 2 +- proposal/SUMMARY.md | 37 +++++++++++++++++++ .../development-and-integrations/README.md | 0 .../new-features.md | 0 .../development-and-integrations/sdk.md | 9 +++++ .../developers/technical-overview/README.md | 7 ++++ .../technical-overview/components.md | 0 .../technical-overview/oracle-integration.md | 0 .../technical-overview/smart-contracts.md | 0 proposal/getting-started/guides.md | 5 +++ proposal/getting-started/prerequisites.md | 3 ++ .../supported-chains-and-tokens.md | 0 proposal/getting-started/using-the-brige.md | 5 +++ proposal/overview/how-xlink-works.md | 7 ++++ proposal/overview/introduction.md | 9 +++++ proposal/resources/faqs.md | 31 ++++++++++++++++ proposal/resources/glossary.md | 3 ++ proposal/resources/networks.md | 3 ++ proposal/special-features/campaigns.md | 0 proposal/special-features/points.md | 0 21 files changed, 121 insertions(+), 1 deletion(-) create mode 100644 .gitbook.yaml create mode 100644 proposal/SUMMARY.md create mode 100644 proposal/developers/development-and-integrations/README.md create mode 100644 proposal/developers/development-and-integrations/new-features.md create mode 100644 proposal/developers/development-and-integrations/sdk.md create mode 100644 proposal/developers/technical-overview/README.md create mode 100644 proposal/developers/technical-overview/components.md create mode 100644 proposal/developers/technical-overview/oracle-integration.md create mode 100644 proposal/developers/technical-overview/smart-contracts.md create mode 100644 proposal/getting-started/guides.md create mode 100644 proposal/getting-started/prerequisites.md create mode 100644 proposal/getting-started/supported-chains-and-tokens.md create mode 100644 proposal/getting-started/using-the-brige.md create mode 100644 proposal/overview/how-xlink-works.md create mode 100644 proposal/overview/introduction.md create mode 100644 proposal/resources/faqs.md create mode 100644 proposal/resources/glossary.md create mode 100644 proposal/resources/networks.md create mode 100644 proposal/special-features/campaigns.md create mode 100644 proposal/special-features/points.md diff --git a/.gitbook.yaml b/.gitbook.yaml new file mode 100644 index 0000000..ff98f0a --- /dev/null +++ b/.gitbook.yaml @@ -0,0 +1 @@ +root: ./proposal/ \ No newline at end of file diff --git a/SUMMARY.md b/SUMMARY.md index 5adc918..69c680d 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -6,4 +6,4 @@ * [Bitcoin](integrations/understanding-the-bitcoin-bridge.md) * [Bitcoin L2s](integrations/bitcoin-l2s.md) * [Non-Bitcoin chains](integrations/non-bitcoin-chains.md) -* [Security Audits](security-audits.md) +* [Security Audits](security-audits.md) \ No newline at end of file diff --git a/proposal/SUMMARY.md b/proposal/SUMMARY.md new file mode 100644 index 0000000..a8ceb24 --- /dev/null +++ b/proposal/SUMMARY.md @@ -0,0 +1,37 @@ +# Table of contents + +## Overview + +* [Introduction](overview/introduction.md) +* [How XLink Bridge Works?](overview/how-xlink-works.md) +* [Supported Blockchains and Tokens](getting-started/supported-chains-and-tokens.md) + +## Getting Started + +* [Prerequisites](getting-started/prerequisites.md) +* [Using the Bridge](getting-started/using-the-brige.md) +* [Guides](getting-started/guides.md) + * [BRC-20 Bridge](getting-started/brc-20-guide.md) + * [Cross-Chain Bridge](getting-started/cross-chain-bridge.md) + +## Special Features + +* [Campaigns](special-features/campaigns.md) +* [Points](special-features/points.md) + +## Developers + +* [Technical Overview](developers/technical-overview/README.md) + * [Components](developers/technical-overview/components.md) + * [Smart Contracts](developers/technical-overview/smart-contracts.md) + * [Oracle Integration](developers/technical-overview/oracle-integration.md) + +* [Development & Integrations](developers/development-and-integrations/README.md) + * [XLink SDK](developers/development-and-integrations/sdk.md) + * [New features, Changelog, Roadmap?](developers/development-and-integrations/new-features.md) + +## Resources + +* [Glossary](resources/glossary.md) +* [FAQs](resources/faqs.md) +* [Networks](resources/networks.md) \ No newline at end of file diff --git a/proposal/developers/development-and-integrations/README.md b/proposal/developers/development-and-integrations/README.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/developers/development-and-integrations/new-features.md b/proposal/developers/development-and-integrations/new-features.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/developers/development-and-integrations/sdk.md b/proposal/developers/development-and-integrations/sdk.md new file mode 100644 index 0000000..8513c4d --- /dev/null +++ b/proposal/developers/development-and-integrations/sdk.md @@ -0,0 +1,9 @@ +# XLink API + +## Overview of the SDK + +## Example use cases + +## Response and error handling + +## Versioning for Developers \ No newline at end of file diff --git a/proposal/developers/technical-overview/README.md b/proposal/developers/technical-overview/README.md new file mode 100644 index 0000000..845b18a --- /dev/null +++ b/proposal/developers/technical-overview/README.md @@ -0,0 +1,7 @@ +# Bridge Architecture + +{% content-ref url="components.md" %} Components {% endcontent-ref %} + +{% content-ref url="smart-contracts.md" %} Smart Contracts Overview {% endcontent-ref %} + +{% content-ref url="oracle-integration.md" %} Oracle Integration {% endcontent-ref %} diff --git a/proposal/developers/technical-overview/components.md b/proposal/developers/technical-overview/components.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/developers/technical-overview/oracle-integration.md b/proposal/developers/technical-overview/oracle-integration.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/developers/technical-overview/smart-contracts.md b/proposal/developers/technical-overview/smart-contracts.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/getting-started/guides.md b/proposal/getting-started/guides.md new file mode 100644 index 0000000..707c90d --- /dev/null +++ b/proposal/getting-started/guides.md @@ -0,0 +1,5 @@ +# Guides + +{% content-ref url="brc20.md" %} BRC-20 Bridge {% endcontent-ref %} + +{% content-ref url="cross-chain.md" %} Cross-Chain Bridge {% endcontent-ref %} diff --git a/proposal/getting-started/prerequisites.md b/proposal/getting-started/prerequisites.md new file mode 100644 index 0000000..c07ca64 --- /dev/null +++ b/proposal/getting-started/prerequisites.md @@ -0,0 +1,3 @@ +# Prerequisites for using the bridge + +## Wallet \ No newline at end of file diff --git a/proposal/getting-started/supported-chains-and-tokens.md b/proposal/getting-started/supported-chains-and-tokens.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/getting-started/using-the-brige.md b/proposal/getting-started/using-the-brige.md new file mode 100644 index 0000000..9c2e4c3 --- /dev/null +++ b/proposal/getting-started/using-the-brige.md @@ -0,0 +1,5 @@ +# Using the Bridge + +## Transferring Assets Across Chains + +## How to execute a transfer \ No newline at end of file diff --git a/proposal/overview/how-xlink-works.md b/proposal/overview/how-xlink-works.md new file mode 100644 index 0000000..70dbfe8 --- /dev/null +++ b/proposal/overview/how-xlink-works.md @@ -0,0 +1,7 @@ +# How XLink Works? + +## Cross-chain transactions + +## Lock and mint mechanism + +## Liquidity and consensus management diff --git a/proposal/overview/introduction.md b/proposal/overview/introduction.md new file mode 100644 index 0000000..6bf7b95 --- /dev/null +++ b/proposal/overview/introduction.md @@ -0,0 +1,9 @@ +# Introduction + +## What is a blockchain bridge? + +## Its importance in decentralized ecosystems + +## Types of blockchain bridges + +## Versioning \ No newline at end of file diff --git a/proposal/resources/faqs.md b/proposal/resources/faqs.md new file mode 100644 index 0000000..8ff9629 --- /dev/null +++ b/proposal/resources/faqs.md @@ -0,0 +1,31 @@ +# Frequently Asked Questions (FAQs) + +## General + +High-level user questions. + +
+ + Question 1 + +
+ +
+ + Question 2 + +
+ +## Technical + +Developer-specific questions. + +
+ + Question 1 + +
+ +
+ + Question 2 \ No newline at end of file diff --git a/proposal/resources/glossary.md b/proposal/resources/glossary.md new file mode 100644 index 0000000..6af0493 --- /dev/null +++ b/proposal/resources/glossary.md @@ -0,0 +1,3 @@ +# XLink Glossary + +Common terms (such as Blockchain Bridge, Cross-chain Transaction, Relayer, etc.) \ No newline at end of file diff --git a/proposal/resources/networks.md b/proposal/resources/networks.md new file mode 100644 index 0000000..7a0d37c --- /dev/null +++ b/proposal/resources/networks.md @@ -0,0 +1,3 @@ +# Networks + +Deployed contract addresses. \ No newline at end of file diff --git a/proposal/special-features/campaigns.md b/proposal/special-features/campaigns.md new file mode 100644 index 0000000..e69de29 diff --git a/proposal/special-features/points.md b/proposal/special-features/points.md new file mode 100644 index 0000000..e69de29