diff --git a/SUMMARY.md b/SUMMARY.md index 6295219..36191fe 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -27,11 +27,11 @@ ## 🎮 Developers * [Smart Contracts](developers/contracts/README.md) * [btc peg-in endpoint](developers/contracts/btc-peg-in-endpoint.md) - * [btc-peg-out-endpoint-v2-01](developers/contracts/btc-peg-out-endpoint-v2-01.md) - * [meta peg-in endpoint v2-02](developers/contracts/meta-peg-in-endpoint-v2-02.md) + * [btc-peg-out-endpoint](developers/contracts/btc-peg-out-endpoint.md) + * [meta peg-in endpoint](developers/contracts/meta-peg-in-endpoint.md) * [meta peg-out endpoint](developers/contracts/meta-peg-out-endpoint.md) - * [cross-peg-in-endpoint-v2-03](developers/contracts/cross-peg-in-endpoint-v2-03.md) - * [cross-peg-out-endpoint-v2-01](developers/contracts/cross-peg-out-endpoint-v2-01.md) + * [cross-peg-in-endpoint](developers/contracts/cross-peg-in-endpoint.md) + * [cross-peg-out-endpoint](developers/contracts/cross-peg-out-endpoint.md) * [xlink-staking](developers/contracts/xlink-staking.md) . -- Location: `xlink/packages/contracts/bridge-stacks/contracts/cross-peg-in-endpoint-v2-03.clar` -- [Deployed contract]() - -This technical document provides a detailed overview of the contract responsible for managing the peg-in process, enabling the transfer of assets from external EVM-like blockchains into the Stacks network. The contract serves as the operational interface for relayers to submit orders, which are validated against a threshold of required validators as determined in the `cross-bridge-registry-v2-01`. The contract's primary functionality is implemented through a suite of public functions. Let's review them. +This technical document provides a detailed overview of the module responsible for managing the peg-in process, enabling the transfer of assets from external EVM-like blockchains into the Stacks network. The contract serves as the operational interface for relayers to submit orders, which are validated against a threshold of required validators as determined in the `cross-bridge-registry-v2-01`. The module's primary functionality is implemented through a suite of public functions that are distributed across the following contracts: +- `cross-peg-in-endpoint-v2-04`: handles bridging tokens from EVM-like blockchains to Stacks, leveraging cross-router to manage the routing of tokens to the appropriate destination. +- `cross-peg-in-v2-04-launchpad`: facilitates bridging tokens from EVM-like blockchains to Stacks, specifically for participation in launchpad activities. +- `cross-peg-in-v2-04-swap`: enables token bridging from EVM-like blockchains to Stacks while performing token swaps through predefined routes. ## Storage +###### _(all contracts include the following variables unless otherwise specified)_ ### `is-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | -A flag indicating whether the peg-in operations are currently active. If set to `true`, all operations are paused, preventing relayers from submitting new peg-in orders. The contract is initialized in a paused state by default. +A flag that indicates whether the peg-in process is paused. If set to `true`, all operations are paused, preventing relayers from submitting new peg-in orders. The contract is initialized in a paused state by default. ### `use-whitelist` | Data | Type | | -------- | ------ | | Variable | `bool` | -A flag that determines whether the whitelist mechanism is enforced. When set to `true`, only whitelisted users are authorized to perform restricted actions within the contract. By default, this value is `false`. - -### `order-hash-to-iter` -| Data | Type | -| -------- | ------ | -| Variable | `buff 32` | - -A temporary variable used internally to store the hash of the current order being processed. - -### `src-chain-id-to-iter` -| Data | Type | -| -------- | ------ | -| Variable | `uint` | - -A temporary variable used to store the source chain ID of the order currently being processed. +A flag that determines whether the whitelist mechanism is enforced. When set to `true`, only whitelisted users are authorized to perform restricted actions. By default, this value is `false`. ### `whitelisted-users` | Data | Type | | -------- | ------ | -| Map | `principal → bool`| +| Map | `principal bool`| A map that keeps track of the whitelist status of specific users. Each entry associates a user's principal with a boolean value indicating whether they are authorized to interact with the contract under a whitelist-enabled configuration. If `true`, the user is allowed to perform actions that are otherwise restricted. ### Relevant constants -* `structured-data-prefix`, `message-domain-main`, `message-domain-test`: These constants are utilized in the `validate-order` function to verify the signature consistency with the order hash. +* `structured-data-prefix`, `message-domain-main`, `message-domain-test`: these constants are utilized in the `validate-order` function to verify the signature consistency with the order hash. ## Features - -### Peg-in features - -#### `transfer-to-cross` -This function enables peg-in operations to transfer tokens from an external EVM-like blockchain to Stacks. It validates the provided order by checking its hash and verifying signatures to meet a threshold of validators defined in `cross-bridge-registry-v2-01`. If the order is valid, it mints or transfers the bridged tokens and updates the token reserve for the source EVM chain. It then utilizes `cross-router-v2-02` to route the tokens based on the destination chain. In the event of validation failure, the function initiates a refund process. - -##### Parameters -```lisp -(order { - from: (buff 128), - to: (buff 128), - token: principal, - amount-in-fixed: uint, - src-chain-id: uint, - dest-chain-id: (optional uint), - salt: (buff 256) - }) -(token-trait ) -(signature-packs (list 100 { - signer: principal, - order-hash: (buff 32), - signature: (buff 65) - })) -``` - -#### `transfer-to-cross-swap` -This function facilitates advanced peg-in operations by incorporating token swapping during cross-chain transfers. It validates the order hash and signatures using `cross-bridge-registry-v2-01`, ensuring compliance with routing configurations, such as token paths and output amounts. Upon successful validation, the bridged tokens are swapped and routed to the recipient using `cross-router-v2-02`, following the same logic outlined in the `transfer-to-cross` feature. If validation fails, the function processes a refund. +### `transfer-to-cross` +###### _(in contract cross-peg-in-endpoint-v2-04)_ +This function enables peg-in operations to transfer tokens from an external EVM-like blockchain to Stacks. It validates the provided order by checking its hash and verifying signatures to meet a threshold of validators defined in `cross-bridge-registry-v2-01`. If the order is valid, it mints or transfers the bridged tokens to the sender of the transaction (`tx-sender`), and updates the token reserve for the source EVM chain. It then utilizes `cross-router-v2-03` to route the tokens based on the destination chain. In case the validation fails, the function initiates a refund process. ##### Parameters ```lisp (order { from: (buff 128), to: (buff 128), + token-in: principal, + token-out: principal, amount-in-fixed: uint, - routing-tokens: (list 5 principal), - routing-factors: (list 4 uint), - min-amount-out-fixed: (optional uint), src-chain-id: uint, dest-chain-id: (optional uint), - salt: (buff 256) - }) -(routing-traits (list 5 )) + salt: (buff 256) + }) +(token-in-trait ) +(token-out-trait ) (signature-packs (list 100 { signer: principal, order-hash: (buff 32), @@ -96,8 +61,38 @@ This function facilitates advanced peg-in operations by incorporating token swap })) ``` -#### `transfer-to-launchpad` -This function enables peg-in operations linked to launchpad projects. It validates the order and signatures through `cross-bridge-registry-v2-01` and confirms compatibility with the launchpad parameters. Once validated, the function mints bridged tokens, transfers them to the recipient, and registers the operation in the `alex-launchpad-v2-01` contract. In case of validation failure, a refund is processed. +### `transfer-to-cross-swap` +###### _(in contract cross-peg-in-v2-04-swap)_ +This function facilitates advanced peg-in operations by incorporating token swapping during cross-chain transfers. It validates the order hash and signatures using `cross-bridge-registry-v2-01`, ensuring compliance with routing configurations, such as token paths and output amounts. Upon successful validation, the bridged tokens are swapped and routed to the recipient using `cross-router-v2-03`, following the same logic outlined in the `transfer-to-cross` feature. If validation fails, the function processes a refund. + +##### Parameters +```lisp +(order { + from: (buff 128), + to: (buff 128), + amount-in-fixed: uint, + token-in: principal, + routing-tokens: (list 5 principal), + routing-factors: (list 4 uint), + token-out: principal, + min-amount-out-fixed: (optional uint), + src-chain-id: uint, + dest-chain-id: (optional uint), + salt: (buff 256) + }) +(token-in-trait ) +(routing-traits (list 5 )) +(token-out-trait ) +(signature-packs (list 100 { + signer: principal, + order-hash: (buff 32), + signature: (buff 65) + })) +``` + +### `transfer-to-launchpad` +###### _(in contract cross-peg-in-v2-04-launchpad)_ +This function enables peg-in operations linked to [launchpad projects](https://docs.alexlab.co/features/launchpad). It validates the order and signatures through `cross-bridge-registry-v2-01` and confirms compatibility with the launchpad parameters. Once validated, the function mints bridged tokens, transfers them to the recipient and registers the operation in the `alex-launchpad-v2-03` contract. In case of validation failure, a refund is processed. ##### Parameters ```lisp @@ -108,16 +103,25 @@ This function enables peg-in operations linked to launchpad projects. It validat dest: (buff 128), token: principal, amount-in-fixed: uint, - salt: (buff 256) + salt: (buff 256) }) (token-trait ) -(signature-packs (list 100 { +(signature-packs (list 100 { signer: principal, order-hash: (buff 32), signature: (buff 65) })) ``` +### Supporting features + +The following functions are tools to assist the off-chain activities. + +1. Validation helpers (`validate-cross-order`, `validate-cross-swap-order`, `validate-launchpad-order`). +2. Order creation helpers (`create-cross-order`, `create-cross-swap-order`, `create-launchpad-order`). +3. Decoding helpers (`decode-cross-order`, `decode-cross-swap-order`, `decode-launchpad-order`). +4. Relayer helper (`is-approved-relayer-or-default`). + ### Governance features #### `is-dao-or-extension` This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. @@ -137,7 +141,7 @@ A public function, governed through the `is-dao-or-extension`, that can change t ``` #### `apply-whitelist` -A public function that toggles the use of the whitelist in the contract. When enabled, only users who are on the whitelist are authorized to execute restricted actions within the contract. +A public function, governed through the `is-dao-or-extension`, that toggles the use of the whitelist in the contract. When enabled, only users who are on the whitelist are authorized to execute restricted actions within the contract. ##### Parameters ```lisp @@ -145,7 +149,7 @@ A public function that toggles the use of the whitelist in the contract. When en ``` #### `whitelist` -A public function that allows authorized extensions, to add or remove a single user from the whitelist. It updates the `whitelisted-users` map, where the user's principal is mapped to a `bool` value (`true` for accepted users and `false` for denied users). +A public function, governed through the `is-dao-or-extension`, that allows authorized extensions, to add or remove a single user from the whitelist. It updates the `whitelisted-users` map, where the user's principal is mapped to a `bool` value (`true` for accepted users and `false` for denied users). ##### Parameters ```lisp @@ -154,7 +158,7 @@ A public function that allows authorized extensions, to add or remove a single u ``` #### `whitelist-many` -A public function that allows to batch add or remove multiple users from the whitelist. This function iteratively calls `whitelist`, which handles the mapping of each user's principal to a bool value in the `whitelisted-users` map. +A public function, governed through the `is-dao-or-extension`, that allows to batch add or remove multiple users from the whitelist. This function iteratively calls `whitelist`, which handles the mapping of each user's principal to a bool value in the `whitelisted-users` map. ##### Parameters ```lisp @@ -162,16 +166,8 @@ A public function that allows to batch add or remove multiple users from the whi (whitelisted (list 2000 bool)) ``` -#### `execute` -A public function that deactivates earlier versions of the `cross-peg-in-endpoint` contract and ensures that only the latest version (`cross-peg-in-endpoint-v2-03`) remains active. - -##### Parameters -```lisp -(sender principal) -``` - ### Getters -#### `get-use-whitelist`` +#### `get-use-whitelist` #### `get-validator-or-fail` ##### Parameters ```lisp @@ -200,12 +196,12 @@ A public function that deactivates earlier versions of the `cross-peg-in-endpoin ``` ## Contract calls (interactions) -- `executor-dao`: Calls are made to verify whether a certain contract-caller is designated as an extension. -- `cross-bridge-registry-v2-01`: This contract is called to validate key components of the peg-in process, such as approved tokens, chain IDs, and relayers. It also handles updates to transaction statuses, token reserves, and validator signatures. -- `cross-router-v2-02`: This contract is used to validate routing details and execute cross-chain token transfers and swaps. It ensures that the provided routing tokens and factors align with the transfer requirements, performs swaps through `amm-pool-v2-01` when multiple tokens are involved, validates minimum output amounts, and handles the final routing process for peg-in operations, including cross and cross-swap transactions. -- `alex-launchpad-v2-01`: This contract is used to validate and register peg-in operations specifically related to launchpad projects on the Stacks network. -- `token-trait`: In cross peg-in operations (featuring `transfer-to-cross`, `transfer-to-cross-swap`, and `transfer-to-launchpad`) this trait is employed to interact with relevant tokens for obtaining their principals, minting, and executing necessary transfers within the transaction. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. -- `cross-peg-out-endpoint-v2-01`: This contract is invoked to manage refunds for peg-in operations that failed external validations. +- `executor-dao`: calls are made to verify whether a certain contract-caller is designated as an extension. +- `cross-bridge-registry-v2-01`: this contract is called to validate key components of the peg-in process, such as approved tokens, chain IDs, and relayers. It also handles updates to transaction statuses, token reserves, and validator signatures. +- `cross-router-v2-03`: this contract is used to validate routing details and execute cross-chain token transfers and swaps. It ensures that the provided routing tokens and factors align with the transfer requirements, performs swaps through `amm-pool-v2-01` when multiple tokens are involved, validates minimum output amounts, and handles the final routing process for peg-in operations, including cross and cross-swap transactions. +- `alex-launchpad-v2-03`: this contract is used to validate and register peg-in operations specifically related to launchpad projects on the Stacks network. +- `token-trait`: in cross peg-in operations (featuring `transfer-to-cross`, `transfer-to-cross-swap`, and `transfer-to-launchpad`) this trait is employed to interact with relevant tokens for obtaining their principals, minting, and executing necessary transfers within the transaction. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. +- `cross-peg-out-endpoint-v2-01`: this contract is invoked to manage refunds for peg-in operations that failed external validations. ## Errors diff --git a/developers/contracts/cross-peg-out-endpoint-v2-01.md b/developers/contracts/cross-peg-out-endpoint.md similarity index 96% rename from developers/contracts/cross-peg-out-endpoint-v2-01.md rename to developers/contracts/cross-peg-out-endpoint.md index e74520e..5b085f5 100644 --- a/developers/contracts/cross-peg-out-endpoint-v2-01.md +++ b/developers/contracts/cross-peg-out-endpoint.md @@ -1,7 +1,7 @@ # cross-peg-out-endpoint-v2-01.clar - Location: `xlink/packages/contracts/bridge-stacks/contracts/cross-peg-out-endpoint-v2-01.clar` -- [Deployed contract]() +- [Deployed contract](https://explorer.hiro.so/txid/SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.cross-peg-out-endpoint-v2-01?chain=mainnet) This technical document provides a detailed overview of the contract responsible for managing the peg-out process, enabling the transfer of `SIP-010` bridged tokens from the Stacks network to EVM-compatible blockchain networks as the EVM-based assets. The contract manages token transfers by validating amounts, applying fees, and maintaining a whitelist for authorized users if enabled. During the process, tokens are either burned or transferred (depending on the token's configuration) to a designated address on the EVM chain. The core functionalities of the contract are implemented through a series of public and governance functions, as described below. @@ -32,6 +32,8 @@ This map stores the whitelist status of users. Each entry associates a `principa ### Peg-out feature #### `transfer-to-unwrap` +###### _(in contract cross-peg-out-endpoint-v2-01)_ + This function manages the peg-out process, enabling users to transfer `SIP-010` bridged tokens from the Stacks network to EVM-compatible blockchains. It begins by validating the transfer through the `validate-transfer-to-unwrap` function, performing checks such as token and chain approval, whitelist status, amount thresholds, and sufficient reserves for the operation. Once validated, the function calculates the required fee and determines the net amount to be transferred. Depending on the token's properties, the function either burns the net amount directly from the user's balance or transfers the entire amount (including the fee) to the `cross-bridge-registry-v2-01`. At the end of the process, the function logs key destination details, including the `settle-address`, which represents the recipient's address on the EVM-compatible blockchain. diff --git a/developers/contracts/meta-peg-in-endpoint-v2-02.md b/developers/contracts/meta-peg-in-endpoint-v2-02.md deleted file mode 100644 index e20f5fb..0000000 --- a/developers/contracts/meta-peg-in-endpoint-v2-02.md +++ /dev/null @@ -1,318 +0,0 @@ -# meta-peg-in-endpoint-v2-02.clar - -- Location: `xlink/packages/contracts/bridge-stacks/contracts/meta-peg-in-endpoint-v2-02.clar` -- [Deployed contract]() - -This technical document provides a comprehensive overview of the contract responsible for the peg-in (bridging) of Bitcoin's BRC-20 assets to the Stacks network. BRC-20 is a token standard on Bitcoin's metaprotocol layer, enabling fungible assets similar to Ethereum's ERC-20. The primary operation of the contract is to facilitate the peg-in process, which involves transferring these BRC-20 assets from Bitcoin to the Stacks blockchain as a specific token. This functionality is implemented through several public functions, each designed to operate with slight variations tailored to specific use cases. Let's explore them. - -## Storage - -### `paused` - -| Data | Type | -| -------- | ------ | -| Variable | `bool` | - -This data variable serves as a flag to control the operational status of the contract within the system. When set to 'paused,' it blocks all meta peg-in transactions. By default, the contract is deployed in 'paused' mode. Refer to the [pause](meta-peg-in-endpoint-v2-02.md#pause) governance feature to change this status. - -### `fee-to-address` - -| Data | Type | -| -------- | ------ | -| Variable | `principal` | - -This is the address to which the fee in Bridged BTC tokens (`token-abtc`) is transferred. By default, this address is the `tx-sender` who deployed the contract. - -### `peg-in-fee` - -| Data | Type | -| -------- | ------ | -| Variable | `uint` | - -This value represents the minimum fee to be deducted for the peg-in operation, expressed in fixed BTC (Bitcoin's base unit: satoshis). Fee amounts below this limit will be rejected with the error `err-invalid-amount`. By default, this value is set to `u0`. - -### Relevant constants - -#### `burn-height-start` - -| Type | Value | -| ------ | ----- | -| `uint` | `burn-block-height` | - -This constant denotes the block height at which the contract was deployed on the underlying burn blockchain. It serves to restrict operations to only include transactions minted from this block onward. - -## Features - -### Peg-in features - -#### `finalize-peg-in-on-index` - -In its simplest form, the peg-in operation is a function that processes a Bitcoin transaction involving a token transfer on that blockchain (e.g., BRC-20), effectively wrapping the foreign token into a local Stacks token. This token represents the asset from which net funds will be transferred to the designated order address. The function requires proofs and validation data, provided by other protocol participants, to confirm the authenticity of the external blockchain transaction. Additionally, the function call may include information about a fee charged in the origin blockchain's base-coin (e.g., BTC), which will be minted in favor of the sender in Stacks as the special Bridged BTC token (`token-abtc`). For the transaction's assets, both the destination (`to`) address and the token must be registered in the auxiliary contract `meta-bridge-registry-v2-03`. Similarly, the address receiving the fees must be previously approved in the contract `btc-peg-in-endpoint-v2-03` (see interaction below). - -##### Parameters - -```lisp -(tx { - bitcoin-tx: (buff 32768), - output: uint, - tick: (string-utf8 256), - amt: uint, - from: (buff 128), - to: (buff 128), - from-bal: uint, - to-bal: uint, - decimals: uint - }) -(block { header: (buff 80), height: uint }) -(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) -(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) -(order-idx uint) -(fee-idx (optional uint)) -(token-trait ) -``` - -#### `finalize-drop-peg-in-on-index` - -This variation of the peg-in feature involves obtaining the order address for asset transfer from the reveal transaction, which is received as an argument. - -##### Parameters - -```lisp -(tx { - bitcoin-tx: (buff 32768), - output: uint, - tick: (string-utf8 256), - amt: uint, - from: (buff 128), - to: (buff 128), - from-bal: uint, - to-bal: uint, - decimals: uint - }) -(block { header: (buff 80), height: uint }) -(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) -(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) -(reveal-tx { tx: (buff 32768), order-idx: uint }) -(fee-idx (optional uint)) -(token-trait ) -``` - -#### `finalize-peg-in-cross-on-index` - -This peg-in-cross feature processes the order recipient specified in the reveal transaction, which is provided as an argument. In this scenario, the recipient may be on a different blockchain. To facilitate this, the contract calls the supporting contract `cross-router-v2-02`, which uses the following logic: - -``` -chain-id > 1000 // BRC-20 -chain-id == 0 // BTC -chain-id < 1000 // EVM networks -chain-id == None // Stacks -``` - -As this peg-in feature is designed for Bitcoin metaprotocol tokens (e.g., BRC-20), the primary objective of this function is to facilitate 'crossing' to an EVM network. In such cases, the `cross-router-v2-02` contract will subsequently call `cross-peg-out-endpoint-v2-01` to execute the transfer. This function includes a refund feature to handle any errors that may occur during cross-transaction data validation. - -##### Parameters - -```lisp -(tx { - bitcoin-tx: (buff 32768), - output: uint, - tick: (string-utf8 256), - amt: uint, - from: (buff 128), - to: (buff 128), - from-bal: uint, - to-bal: uint, - decimals: uint - }) -(block { header: (buff 80), height: uint }) -(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) -(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) -(reveal-tx { tx: (buff 32768), order-idx: uint }) -(fee-idx (optional uint)) -(token-trait ) -``` - -#### `finalize-peg-in-cross-swap-on-index` - -Similar to the peg-in-cross, the peg-in-cross-swap involves a cross-blockchain operation with an additional asset swapping capability. This feature is useful when the desired target token requires intermediate swap operations. The function achieves this by receiving a list of token traits involved in the operation up to the target token. Refer to the [AMM Pool documentation](https://docs.alexgo.io/developers/protocol-contracts#amm-trading-pool) for more details. In addition to the "from" and "to" addresses, the order details in the reveal transaction include information about the swap route. This swap route is validated against the `amm-pool-v2-01` contract through the `cross-router-v2-02` contract to check pool parameters. Additionally, this function includes a refund mechanism to handle errors during cross-swap transaction validation. - -##### Parameters - -```lisp -(tx { - bitcoin-tx: (buff 32768), - output: uint, - tick: (string-utf8 256), - amt: uint, - from: (buff 128), - to: (buff 128), - from-bal: uint, - to-bal: uint, - decimals: uint - }) -(block { header: (buff 80), height: uint }) -(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) -(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) -(reveal-tx { tx: (buff 32768), order-idx: uint }) -(fee-idx (optional uint)) -(routing-traits (list 5 )) -``` - -#### `finalize-peg-in-add-liquidity-on-index` - -This function enables a peg-in operation that injects liquidity into ALEX's AMM Trading Pool system (contract `amm-pool-v2-01`). Instead of transferring the pegged assets (`token-trait`), it initiates an operation to add to positions with the token pair `token-abtc` and the `token-trait` provided in the function arguments. This liquidity operation is recorded in the `meta-bridge-registry-v2-03`, including the order generator. It's important to note that the order generator (`from`), the factor, and the maximum target token amount (`max-dy`) are extracted from the order details in the `reveal-tx` argument. The function includes a refund feature to reimburse any difference between the net amount and the injected target token in the pool operation, as well as to handle errors in the add-liquidity transaction data validation. - -##### Parameters - -```lisp -(tx { - bitcoin-tx: (buff 32768), - output: uint, - tick: (string-utf8 256), - amt: uint, - from: (buff 128), - to: (buff 128), - from-bal: uint, - to-bal: uint, - decimals: uint - }) -(block { header: (buff 80), height: uint }) -(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) -(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) -(reveal-tx { tx: (buff 32768), order-idx: uint }) -(dx-idx uint) -(fee-idx (optional uint)) -(token-trait ) -``` - -#### `finalize-peg-in-remove-liquidity` - -This operation performs the inverse of the add liquidity feature, focusing on reducing positions. After removing positions from ALEX's AMM Trading Pool system and recording the liquidity removed (`meta-bridge-registry-v2-03`), the function initiates two peg-out requests due to the injected liquidity being for the pair `token-abtc` + `token-trait`. For the first token of the pair, which represents the burn blockchain base-coin (BTC), the function calls `btc-peg-out-endpoint-v2-01`. For the second token, which wraps the BRC-20 assets, the function calls `meta-peg-out-endpoint-v2-03`. These two contracts manage the peg-out requests. - -##### Parameters - -```lisp -(commit-tx { tx: (buff 32768), fee-idx: (optional uint) }) -(block { header: (buff 80), height: uint }) -(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) -(reveal-tx { tx: (buff 32768), order-idx: uint }) -(token-trait ) -``` - -### Supporting features - -The following functions are tools to assist the off-chain activities. - -1. Validation helpers (`validate-tx-cross`, `validate-tx-cross-swap`, `validate-tx-add-liquidity`). -2. Order creation helpers (`create-order-cross-or-fail`, `create-order-cross-swap-or-fail`, `create-order-add-liquidity-or-fail`, `create-order-remove-liquidity-or-fail`). -3. Decoding helpers (`decode-order-cross-or-fail`, `decode-order-cross-swap-or-fail`). -4. Token pair helpers (`get-pair-details-many`, `is-approved-pair`). - -### Governance features - -#### `is-dao-or-extension` - -This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. - -#### `is-paused` - -A read-only function that checks the operational status of the contract. - -#### `pause` - -A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. - -##### Parameters - -```lisp -(new-paused bool) -``` - -#### `transfer-all-to-many` - -This contract feature is designed to transfer its entire balance of a specified list of tokens to a new owner. Access to this feature is restricted by the `is-dao-or-extension` function. - -##### Parameters - -```lisp -(new-owner principal) (token-traits (list 10 )) -``` - -#### `set-fee-to-address` - -This contract feature sets the address to which the fee in Bridged BTC tokens (`token-abtc`) will be transferred. - -##### Parameters - -```lisp -(new-fee-to-address principal) -``` - -#### `set-peg-in-fee` - -This feature establishes the fee to be deducted for the peg-in operation. - -##### Parameters - -```lisp -(fee uint) -``` - -### Getters - -* `get-fee-to-address` -* `get-peg-in-fee` -* `get-pair-details` -* `get-pair-details-or-fail` -* `get-pair-details-many` -* `get-tick-to-pair-or-fail` -* `get-peg-in-sent-or-default` - -### Relevant internal functions - -* `index-tx` -* `refund` - -## Contract calls (interactions) - -* `executor-dao`: Calls are made to verify whether a certain contract-caller is designated as an extension. -* `meta-bridge-registry-v2-03`: This interaction is used by the peg-in contract to check and set token pair information. It also facilitates liquidity operations to set balances and manage pool operations. -* `btc-peg-in-endpoint-v2-03`: This contract is called to verify Bitcoin operations, ensuring that a given Bitcoin transaction hasn't been processed before and that the approved address is used to receive the burn blockchain base-coin. -* `btc-peg-out-endpoint-v2-01`: The `request-peg-out-0` function of this contract is used by the peg-in contract to remove liquidity and refund BTC amounts. -* `btc-bridge-registry-v2-02`: The peg-in contract calls the `set-peg-in-sent` function of this contract to register a processed Bitcoin transaction. -* `meta-peg-out-endpoint-v2-03`: The `finalize-peg-in-remove-liquidity` feature and the internal `refund` function call this contract to request a peg-out in their respective contexts. -* `cross-router-v2-02`: The peg-in cross and peg-in cross swap operations use this contract to validate and route peg-ins involving other blockchains. -* `oracle-v2-01`: This contract is called to verify that a transaction was mined and to index Bitcoin transactions. -* `clarity-bitcoin-v1-07`: The peg-in contract uses this contract to obtain legacy transaction IDs from a SegWit native transaction. -* `amm-pool-v2-01`: This contract manages all liquidity operations, including adding and reducing positions, within the peg-in features. Additionally, it acts as a helper to retrieve pool information and details. -* `token-abtc`: This is the Bridged BTC token used throughout the peg-in contract to operate with native Stacks' SIP-010 token transactions involving the burn blockchain base-coin (BTC). -* Tokens (`token-trait`) During peg-in operations, this trait is used to invoke the relevant tokens to perform the necessary transfers involved in the transaction. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. -* `bridge-common-v2-02`: This contract provides common helper functions to all xLink contracts, including order creation, transaction decoding, and cross-chain routing validations. - - -## Errors - -| Error Name | Value | -| --------------------------------- | ------------- | -| `err-unauthorised` | `(err u1000)` | -| `err-paused` | `(err u1001)` | -| `err-peg-in-address-not-found` | `(err u1002)` | -| `err-invalid-amount` | `(err u1003)` | -| `err-token-mismatch` | `(err u1004)` | -| `err-invalid-tx` | `(err u1005)` | -| `err-already-sent` | `(err u1006)` | -| `err-address-mismatch` | `(err u1007)` | -| `err-request-already-revoked` | `(err u1008)` | -| `err-request-already-finalized` | `(err u1009)` | -| `err-revoke-grace-period` | `(err u1010)` | -| `err-request-already-claimed` | `(err u1011)` | -| `err-invalid-input` | `(err u1012)` | -| `err-tx-mined-before-request` | `(err u1013)` | -| `err-commit-tx-mismatch` | `(err u1014)` | -| `err-invalid-burn-height` | `(err u1003)` | -| `err-tx-mined-before-start` | `(err u1015)` | -| `err-slippage-error` | `(err u1016)` | -| `err-bitcoin-tx-not-mined` | `(err u1017)` | - - - diff --git a/developers/contracts/meta-peg-in-endpoint.md b/developers/contracts/meta-peg-in-endpoint.md new file mode 100644 index 0000000..d04780b --- /dev/null +++ b/developers/contracts/meta-peg-in-endpoint.md @@ -0,0 +1,319 @@ +# meta-peg-in-endpoint +- Location: `xlink/packages/contracts/bridge-stacks/contracts` +- Deployed contracts: [meta-peg-in-endpoint-v2-04](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-in-endpoint-v2-04?chain=mainnet), [meta-peg-in-endpoint-v2-04-lisa](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-in-endpoint-v2-04-lisa?chain=mainnet), [meta-peg-in-v2-06-swap](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-in-v2-06-swap?chain=mainnet). + +This technical document provides a comprehensive overview on the module responsible for the peg-in (bridging) of Bitcoin's BRC-20 assets to the Stacks network. BRC-20 is a token standard on Bitcoin's metaprotocol layer, enabling fungible assets similar to Ethereum's ERC-20. The module's core functionality is implemented through a series of public functions distributed across multiple specialized contracts, each addressing specific aspects of the peg-in process. + +This functionality is implemented and distributed across the following contracts: + +- `meta-peg-in-endpoint-v2-04`: facilitates the bridging of BRC-20 tokens from Bitcoin to Stacks, leveraging cross-router for routing to the appropriate destination. +- `meta-peg-in-endpoint-v2-04-lisa`: facilitates peg-in operations for BRC-20 tokens from Bitcoin that involve burning LiaBTC tokens within the ALEX system. +- `meta-peg-in-v2-06-swap`: facilitates peg-in operations for BRC-20 tokens from Bitcoin to Stacks with integrated asset swapping capabilities. + +## Storage +###### _(all contracts include the following variables unless otherwise specified)_ +### `paused` + +| Data | Type | +| -------- | ------ | +| Variable | `bool` | + +This data variable serves as a flag to control the operational status of the contract. When set to `true`, all meta peg-in transactions are suspended. By default, the contract is deployed in *paused* mode. Refer to the [pause](meta-peg-in-endpoint.md#pause) governance feature to know more on how to change this status. + +### `fee-to-address` + +| Data | Type | +| -------- | ------ | +| Variable | `principal` | + +This is the address where fees, charged in Bridged BTC tokens (token-abtc), are sent. By default, this address is the `tx-sender` who deployed the contract. + +### `peg-in-fee` + +| Data | Type | +| -------- | ------ | +| Variable | `uint` | + +This value represents the fee required for peg-in operations, expressed in fixed BTC (Bitcoin's base unit: satoshis). Fee amounts below this limit will be rejected with the error `err-invalid-amount`. By default, this value is set to `0`. + +### `btc-peg-out-fee` +###### _(only present in meta-peg-in-v2-06-swap)_ + +| Data | Type | +| -------- | ------ | +| Variable | `uint` | + +This variable represents the percentage fee applied to BTC peg-out operations during cross-swap transactions. By default, it is initialized to `u0` and can be updated via governance functions. Refer to the [set-btc-peg-out-fee](meta-peg-in-endpoint.md#set-btc-peg-out-fee) governance feature to know more about updating this variable. + +### `btc-peg-out-min-fee` +###### _(only present in meta-peg-in-v2-06-swap)_ + +| Data | Type | +| -------- | ------ | +| Variable | `uint` | + +This variable sets the minimum fee required for BTC peg-out operations during cross-swap transactions. By default, it is initialized to `u0` and can be updated via governance functions. Refer to the [set-btc-peg-out-min-fee](meta-peg-in-endpoint.md#set-btc-peg-out-min-fee) governance feature to know more about updating this variable. + +### Relevant constants + +#### `burn-height-start` + +| Type | Value | +| ------ | ----- | +| `uint` |`burn-block-height` [(see more)](https://docs.stacks.co/reference/keywords#burn-block-height) | + +This constant denotes the block height at which the contract was deployed on the underlying burn blockchain. It serves to restrict operations to only include transactions minted from this block onward. + +## Features + +#### `finalize-peg-in-cross-on-index` +###### _(in contract meta-peg-in-endpoint-v2-04)_ + +This function processes the order recipient, which is extracted and decoded from the provided reveal transaction. The reveal transaction contains additional details about the peg-in operation, such as the recipient's address and the `order-idx`. In this scenario, the recipient may be on a different blockchain. To facilitate the peg-in process, the contract calls the supporting contract `cross-router-v2-03`, to route the tokens based on the destination chain. +As this peg-in feature is designed for Bitcoin metaprotocol tokens (e.g., BRC-20), the primary objective of this function is to facilitate 'crossing' to an EVM network. In such cases, the `cross-router-v2-03` contract will subsequently call `cross-peg-out-endpoint-v2-01` to execute the transfer of BRC-20 tokens from Bitcoin to an EVM chain. If any errors occur during the cross-transaction data validation, the function triggers a refund mechanism. + +##### Parameters + +```lisp +(tx { + bitcoin-tx: (buff 32768), + output: uint, + tick: (string-utf8 256), + amt: uint + , from: (buff 128), + to: (buff 128), + from-bal: uint, + to-bal: uint, + decimals: uint + }) +(block { header: (buff 80), height: uint }) +(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(signature-packs (list 10 { + signer: principal, + tx-hash: (buff 32), + signature: (buff 65) + })) +(reveal-tx { tx: (buff 32768), order-idx: uint }) +(reveal-block { header: (buff 80), height: uint }) +(reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(fee-idx (optional uint)) +(token-trait ) +(token-out-trait ) +``` + +#### `finalize-peg-in-cross-swap-on-index` +###### _(in contract meta-peg-in-v2-06-swap)_ + +Similar to the peg-in-cross, the peg-in-cross-swap involves a cross-blockchain operation with an additional asset swapping capability. This feature is useful when the desired target token requires intermediate swap operations. The function achieves this by receiving a list of token traits (interfaces that define the behavior of tokens in the operation) involved in the operation up to the target token. Refer to the [AMM Pool documentation](https://docs.alexgo.io/developers/protocol-contracts#amm-trading-pool) for more details. In addition to the sender (from) and recipient (to) addresses, the order details in the reveal transaction include information about the swap route. This swap route is validated against the `amm-pool-v2-01` contract through the `cross-router-v2-03` contract to check pool parameters. Additionally, this function includes a refund mechanism that gets triggered in case any errors occur during the cross-swap transaction validation. + +##### Parameters + +```lisp +(tx { + bitcoin-tx: (buff 32768), + output: uint, + tick: (string-utf8 256), + amt: uint, + from: (buff 128), + to: (buff 128), + from-bal: uint, + to-bal: uint, + decimals: uint + }) +(block { header: (buff 80), height: uint }) +(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) +(reveal-tx { tx: (buff 32768), order-idx: uint }) +(reveal-block { header: (buff 80), height: uint }) +(reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(fee-idx (optional uint)) +(routing-traits (list 5 )) +(token-out-trait ) +``` + +#### `finalize-peg-in-request-burn-liabtc-on-index` +###### _(in contract meta-peg-in-endpoint-v2-04-lisa)_ +This function handles a peg-in operation that involves requesting the burn of LiaBTC tokens in the ALEX system. It begins by indexing the provided Bitcoin transaction using the `oracle-v2-01` contract to verify its validity and ensure it has not been processed before. Once the transaction is validated, the function calls `finalize-peg-in-request-burn-liabtc` to complete the burn request. +The function interacts with the `meta-bridge-registry-v2-03-lisa` contract to retrieve and validate token pair details, which refer to the registered combination of a token and its target chain ID, and with the `liabtc-mint-endpoint` to register the burn request. Additionally, it utilizes the `clarity-bitcoin-v1-07` contract to extract transaction details such as the SegWit transaction ID. Any accrued rewards or updates, which are likely tied to the use or staking of LiaBTC tokens within the ALEX system, are processed through the provided `liabtc-message` and validated using signature packs. +The function includes mechanisms to handle fees, using the `btc-bridge-registry-v2-01` contract to register these transactions and to ensure the peg-in-fee is properly accounted for. + +##### Parameters + +```lisp +(tx { + bitcoin-tx: (buff 32768), + output: uint, + tick: (string-utf8 256), + amt: uint, + from: (buff 128), + to: (buff 128), + from-bal: uint, + to-bal: uint, + decimals: uint + }) +(block { header: (buff 80), height: uint }) +(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(signature-packs (list 10 { signer: principal, tx-hash: (buff 32), signature: (buff 65) })) +(reveal-tx { tx: (buff 32768), order-idx: uint }) +(reveal-block { header: (buff 80), height: uint }) +(reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(fee-idx (optional uint)) +(liabtc-message { token: principal, accrued-rewards: uint, update-block: uint }) +(liabtc-signature-packs (list 100 { + signer: principal, + message-hash: (buff 32), + signature: (buff 65) + })) +``` + +#### `finalize-peg-in-update-burn-liabtc` +###### _(in contract meta-peg-in-endpoint-v2-04-lisa)_ +This function finalizes or revokes a burn request for LiaBTC tokens initiated in the ALEX system. It validates the Bitcoin transaction through the `oracle-v2-01` contract, ensuring it was mined and indexed correctly. It interacts with the `meta-bridge-registry-v2-03-lisa` contract to verify the status of the burn request and update its details. +If the burn request is finalized (status `0x01`), the function confirms the burn through the `liabtc-mint-endpoint` and completes the operation. For revocations (status `0x02`), the function handles re-minting of LiaBTC tokens and executes a peg-out process using the `meta-peg-out-endpoint-v2-04`. + +##### Parameters + +```lisp +(commit-tx { tx: (buff 32768), fee-idx: (optional uint) }) +(block { header: (buff 80), height: uint }) +(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(reveal-tx { tx: (buff 32768), order-idx: uint }) +(reveal-block { header: (buff 80), height: uint }) +(reveal-proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint }) +(message { token: principal, accrued-rewards: uint, update-block: uint }) +(signature-packs (list 100 { + signer: principal, + message-hash: (buff 32), + signature: (buff 65) + })) +``` + +### Supporting features + +The following functions are tools to assist the off-chain activities. + +1. Validation helpers (`validate-tx-cross`, `validate-tx-cross-swap`, `validate-tx-request-burn`, `validate-tx-update-burn`). +2. Order creation helpers (`create-order-cross-or-fail`, `create-order-cross-swap-or-fail`, `create-order-request-burn-or-fail`). +3. Decoding helpers (`decode-order-cross-or-fail`, `decode-order-cross-swap-or-fail`). +4. Token pair helpers (`get-pair-details-many`, `is-approved-pair`). + +### Governance features + +#### `is-dao-or-extension` +This standard protocol function checks whether a caller (`tx-sender`) is the DAO executor or an authorized extension, delegating the extensions check to the `executor-dao` contract. + +#### `is-paused` +A read-only function that checks the operational status of the contract. + +#### `pause` +A public function, governed through the `is-dao-or-extension`, that can change the contract's operational status. + +##### Parameters +```lisp +(new-paused bool) +``` + +#### `transfer-all-to-many` +This contract feature is designed to transfer its entire balance of a specified list of tokens to a new owner. Access to this feature is restricted by the `is-dao-or-extension` function. + +##### Parameters +```lisp +(new-owner principal) (token-traits (list 10 )) +``` + +#### `set-fee-to-address` +A public function, governed through the `is-dao-or-extension`, that sets the address to which the fee in Bridged BTC tokens will be transferred. + +##### Parameters +```lisp +(new-fee-to-address principal) +``` + +#### `set-peg-in-fee` +A public function, governed through the `is-dao-or-extension`, that establishes the fee to be deducted for the peg-in operation. + +##### Parameters +```lisp +(fee uint) +``` + +#### `set-btc-peg-out-fee` +###### _(only present in meta-peg-in-v2-06-swap)_ +A public function, governed through the `is-dao-or-extension`, that sets the percentage fee applied to BTC peg-out operations. + +##### Parameters +```lisp +(fee uint) +``` + +#### `set-btc-peg-out-min-fee` +###### _(only present in meta-peg-in-v2-06-swap)_ +A public function, governed through the `is-dao-or-extension`, that establishes the minimum fee required for BTC peg-out operations. + +##### Parameters +```lisp +(fee uint) +``` + +### Getters + +* `get-fee-to-address` +* `get-peg-in-fee` +* `get-pair-details` +* `get-pair-details-or-fail` +* `get-pair-details-many` +* `get-tick-to-pair-or-fail` +* `get-peg-in-sent-or-default` +* `get-btc-peg-out-fee` _(only present in meta-peg-in-v2-06-swap)_ +* `get-btc-peg-out-min-fee` _(only present in meta-peg-in-v2-06-swap)_ +* `get-liabtc-decimals` _(only present in meta-peg-in-endpoint-v2-04-lisa)_ + +### Relevant internal functions + +* `index-tx`: this function validates and indexes a Bitcoin transaction in the `oracle-v2-01` contract. +* `refund`: this function returns the total amount of the peg-in transaction, including the fee, to the sender in case of a failure during the operation. + +## Contract calls (interactions) + +* `executor-dao`: calls are made to verify whether a certain contract-caller is designated as an extension. +* `meta-bridge-registry-v2-03`: this interaction is used by the peg-in contract to check and set token pair information. It also facilitates liquidity operations to set balances and manage pool operations. +* `btc-peg-out-endpoint-v2-01`: the `request-peg-out-0` function of this contract is used by the peg-in contract to remove liquidity and refund BTC amounts. +* `btc-bridge-registry-v2-01`: the peg-in contract calls the `set-peg-in-sent` function of this contract to register a processed Bitcoin transaction. +* `meta-peg-out-endpoint-v2-04`: the `finalize-peg-in-remove-liquidity` feature and the internal `refund` function call this contract to request a peg-out in their respective contexts. +* `cross-router-v2-03`: the peg-in cross and peg-in cross swap operations use this contract to validate-route and route peg-ins involving other blockchains. +* `oracle-v2-01`: this contract is called to verify that a transaction was mined and to index Bitcoin transactions. +* `clarity-bitcoin-v1-07`: the peg-in contract uses this contract to obtain legacy transaction IDs from a SegWit native transaction. +* `amm-pool-v2-01`: this contract manages all liquidity operations, including adding and reducing positions, within the peg-in features. Additionally, it acts as a helper to retrieve pool information and details. +* `token-abtc`: this is the Bridged BTC token used throughout the peg-in contract to operate with native Stacks' SIP-010 token transactions involving the burn blockchain base-coin (BTC). +* Tokens (`token-trait`): during peg-in operations, this trait is used to invoke the relevant tokens to perform the necessary transfers involved in the transaction. It is a customized version of Stacks' standard definition for Fungible Tokens (`sip-010`), with support for 8-digit fixed notation. +* `bridge-common-v2-02`: this contract provides common helper functions to all xLink contracts, including order creation, transaction decoding, and cross-chain routing validations. +* `liabtc-mint-endpoint`: this contract is called to validate and register burn requests of LiaBTC during peg-in operations. It ensures that the burn process adheres to protocol requirements and updates the registry with the burn request details. +* `token-wvliabtc`: this contract manages the wrapped representation of LiaBTC tokens on the Stacks network. It is used during peg-in operations to burn wvliabtc tokens and to validate the corresponding token amounts for bridging purposes. + +## Errors + +| Error Name | Value | +| --------------------------------- | ------------- | +| `err-unauthorised` | `(err u1000)` | +| `err-paused` | `(err u1001)` | +| `err-peg-in-address-not-found` | `(err u1002)` | +| `err-invalid-amount` | `(err u1003)` | +| `err-token-mismatch` | `(err u1004)` | +| `err-invalid-tx` | `(err u1005)` | +| `err-already-sent` | `(err u1006)` | +| `err-address-mismatch` | `(err u1007)` | +| `err-request-already-revoked` | `(err u1008)` | +| `err-request-already-finalized` | `(err u1009)` | +| `err-revoke-grace-period` | `(err u1010)` | +| `err-request-already-claimed` | `(err u1011)` | +| `err-invalid-input` | `(err u1012)` | +| `err-tx-mined-before-request` | `(err u1013)` | +| `err-commit-tx-mismatch` | `(err u1014)` | +| `err-invalid-burn-height` | `(err u1003)` | +| `err-tx-mined-before-start` | `(err u1015)` | +| `err-slippage-error` | `(err u1016)` | +| `err-bitcoin-tx-not-mined` | `(err u1017)` | +| `err-invalid-request` _(only present in meta-peg-in-endpoint-v2-04-lisa)_ | `(err u1018)` | + + + diff --git a/developers/contracts/meta-peg-out-endpoint.md b/developers/contracts/meta-peg-out-endpoint.md index 90c0f66..d8fc888 100644 --- a/developers/contracts/meta-peg-out-endpoint.md +++ b/developers/contracts/meta-peg-out-endpoint.md @@ -1,6 +1,6 @@ # meta-peg-out-endpoint -- Location: `xlink/packages/contracts/bridge-stacks/contracts` +- Location: `xlink/packages/contracts/bridge-stacks/contracts/meta-peg-out-endpoint-v2-04` - [Deployed contract](https://explorer.hiro.so/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.meta-peg-out-endpoint-v2-04?chain=mainnet) This technical document provides a detailed overview of the contract responsible for facilitating the peg-out process of tokens from the Stacks network to the burn chain. The target token standard is BRC-20, a protocol on Bitcoin's metaprotocol layer that supports fungible assets, inspired by Ethereum's ERC-20 standard.