# LISA LISA is an acronym for Liquid Staking for All; Or, the Goddess of Liquid Staking. Currently, LISA offers liquid staking for users looking to earn yield on: For starters, we labeled LISA as Liquid Staking for All because our mission is to enable anyone from anywhere to easily convert their assets into safe and secure reward-generating assets. If you have assets like Bitcoin, Stacks, or even USDT, LISA allows you to earn safe and secure yields by converting them into liquid staking tokens that you can further use on external DeFi platforms; in other words, tapping into more opportunities beyond the LISA yields! We collaborate with highly trusted partners like ALEX, Ryder, Xverse, XLink, and COBO to make this possible! ### What Tokens does LISA Offers? LISA is deployed on and functioning within the Stacks blockchain network. Allowing users to free up their staked tokens by minting transferable utility tokens (known as Liquid Staking Tokens) that can be utilized in other on-chain activities. Currently, LISA offers liquid staking for users looking to earn yield on: * STX as LiSTX * ALEX as LiALEX * BTC as LiaBTC ([Coming soon](https://x.com/LisaLab_BTC/status/1846880393598747115)!) * USDT (Coming soon!) ### Why LISA? * **Flexibility Unlocked:** LISA revolutionizes staking by offering the flexibility to earn yields without immobilized assets, keeping your capital fluid. * **Dual-Token Advantage:** Users can choose between two token mechanisms: * **Rebasing:** Li-yield tokens offer a 1:1 conversion rate with your staked assets, ensuring your token count grows over time. * **Yield-Bearing Tokens:** vLi-yield tokens increase in intrinsic value as rewards accrue with each cycle, boosting your investment's growth potential—this is via the [Wrap Feature](/features-how-tos/wrapping-unwrapping). * **Maximized Efficiency:** LISA utilizes multiple staking pools, which allows for dynamic position adjustments, thereby optimizing investment efficiency. * **Collaborative Strength:** By harnessing the collective expertise of leading Stacks developers, LISA provides access to varied staking strategies and enhances collateral use cases. * **DeFi Expansion:** Through its integration with ALEX, LISA expands accessibility to DeFi services, solidifying its integral role within Bitcoin's decentralized finance ecosystem. ### Enter LISA **Imagine this:** You've entered the realm of liquid staking, where you're not just earning rewards but also seeing your assets appreciate with a competitive annual percentage yield (APY). Staking has become one of the foundational yield sources across various blockchain ecosystems, not just Bitcoin, offering a smart approach to growing your portfolio. However, there's a traditional trade-off — your assets are typically locked up, inaccessible for other financial maneuvers for a set period. As you survey the Bitcoin DeFi landscapes, rich with potential, you can't help but imagine what could be done with assets that are currently sidelined by staking commitments. **Enter LISA —** a beacon in the liquid stacking space, designed to weave flexibility and dynamism into your investment tapestry. LISA elevates stacking & staking by freeing your assets by enabling participation in lucrative farming pools or using them as collateral for stablecoin loans, all while your assets continue to earn. ### LISA’s Distinct Advantage for LiSTX LISA, a collaboration between [ALEX](https://alexlab.co/), [Ryder’s Fast Pool](https://www.ryder.id/), [XLink](https://app.xlink.network/) and [Xverse Pool](https://www.xverse.app/), leverages unparalleled engineering and operational excellence, setting a new standard within the Stacks ecosystem. Its key advantages include: * **Enhanced Pool Integration and Flexibility**: LISA integrates multiple stacking pools like Fast Pool and Xverse Pool, boosting efficiency and diversification. This setup provides stackers with flexibility, allowing direct stacking above certain minimums or delegation below them. Unlike protocols that restrict users to a single pool, LISA offers a broad network of operators, enhancing effectiveness and using STX as collateral for other protocols. * **Broadened DeFi Opportunities**: Through seamless integration with ALEX, Bitcoin’s premier finance layer, LISA significantly expands the range of DeFi services available to users, reinforcing its foundational role in Bitcoin’s DeFi landscape. * **Innovative “Rebase” Tokens**: LISA introduces “rebase” tokens to Stacks, inspired by Lido’s success. These tokens dynamically adjust their supply to mirror their underlying assets’ value, facilitating efficient yield capitalization and flexible position management with minimal slippage. This breakthrough enhances LISA’s token liquidity and market stability, proving indispensable for DeFi users at every experience level.
## Maximize Your Stacking Efficiency with LISA **Example with LiSTX;** The traditional stacking model often forces stackers to miss an entire cycle if they decide to adjust their locked STX, resulting in significant opportunity costs due to the two-week cycle. LISA solves this by pooling STX from users and collaborating with various stacking pools, enabling a more efficient and flexible management system than individual stacking allows. For stackers, this means greater freedom in managing your investments. With LISA, adjust your stacking positions without major opportunity costs, ensuring your STX is always working efficiently for you. ## Summary: A New Era of Stacking & Staking LISA redefines liquid staking beyond the Stacks ecosystem by merging the expertise of our ecosystem partners to unlock unparalleled stacking and staking flexibility and liquidity. By introducing dual tokens—both rebasing and yield-bearing—LISA enables participation in a broader DeFi landscape without sacrificing yield. LISA not only enhances efficiency and diversification but also integrates seamlessly with ALEX, thereby expanding the DeFi opportunities available to users. With LISA, stacking and staking are no longer rigid commitments but dynamic strategies, empowering stackers with the freedom to optimize their investments and navigate the evolving world of Bitcoin DeFi with confidence. # Stacks ($STX) **LiSTX** uses a rebasing mechanism for balance growth, while **vLiSTX** appreciates in value as stacking rewards accumulate. This design ensures both liquidity and adaptability, maintaining LiSTX at a 1:1 ratio with STX, whereas vLiSTX’s value diverges over time due to rewards. ## 1 LiSTX = 1 STX Locking STX grants users LiSTX, which grows in the balance to reflect stacking yields. LiSTX can be traded at any time: It can be redeemed for STX at face value or traded against STX and other assets on supporting exchanges. Both LiSTX and vLiSTX adhere to the SIP-10 standard, yet they distinguish themselves in how rewards are accumulated. LiSTX rebases to increase balance, while vLiSTX’s balance remains constant as its value grows from stacking rewards. Users can interchange LiSTX and vLiSTX via a smart contract, ensuring sharing liquidity. LiSTX’s rebasing keeps its value aligned with STX, enabling efficient trading with minimal slippage. In contrast, vLiSTX, expected to diverge in value from STX due to rewards, may experience higher slippage when traded. ### What are the differences between the STX tokens? **$STX:** * Can be used to participate in STX mining to earn BTC—e.g: via [Xverse](/ecosystem-partners/xverse). * Most CEX and DEXs use STX pairs for trading. * Does not earn yield by itself, but you can add it to a liquidity pool (LP) to earn fees on a DEX like ALEX. **$LiSTX:** * Earns up to \~10% in STX yield rewards annually. * Your LiSTX balance increases with each stacking cycle via a rebasing mechanism. * Requires you to unstake back to STX for CEX deposits. **$vLiSTX:** * Its intrinsic value increases as rewards accrue with each cycle, but your balance remains the same. * Requires you to wrap it from LiSTX; which you can also unwrap via the [Unwrap](/features-how-tos/wrapping-unwrapping) feature. * Bridgeable to other networks via XLink (Allows you to participate in different network campaigns). # How LiSTX Architecture Works?
LISA's LiSTX runs on three core components, all of which are operated by LISA DAO: * LiSTX Mint Factory * LISA Vault * Strategies Please read the subsection to understand how those mechanism works. # Mint Factory ## LiSTX Mint Factory LiSTX Mint Factory is the main smart contract LISA users interact to mint/burn LiSTX/vLiSTX. LiSTX Mint Factory implements the logic of LiSTX minting/burning process, while the relevant data is stored at LiSTX Mint Registry. Such separation of the logic and the data storage allows for future upgrades of the logic, while preserving the data layout. ### Request to mint LiSTX When a user requests to mint LiSTX, a mint request ticket (in form of NFT) is issued to the user and the relevant STX is sent to LISA Vault. In order for a user to start stacking from the next cycle, a mint request must be confirmed at least 300 blocks before the prepare stage of stacking begins for the next cycle (100 blocks before the current cycle end). Otherwise, the mint request is queued for the following cycle. ### Finalise the mint request When LiSTX is ready to be minted (which is 432 blocks after the relevant stacking cycle start), the user can finalise the mint request at which time the mint request ticket will be burnt in exchange for LiSTX. ### Revoke the mint request Subject to availability of unlocked STX at LISA Vault, a user may revoke a mint request, in which case the mint request ticket is burnt and the relevant STX sent to the user. A user may not revoke a mint request if the unlocked STX at LISA Vault were sent to Strategies for stacking, or if the unlocked STX were redeemed to meet any outstanding burn requests. ### Request to burn LiSTX When a user requests to burn LiSTX, a burn request ticket (in form of NFT) is issued to the user and the relevant LiSTX is sent to LISA Vault. While the user waits to burn LiSTX, the stacking rewards will continue to be accrued. ### Finalise the burn request Finalisation of a burn request is subject to the availability of unlocked STX at LISA Vault. When a burn request is made, LiSTX Mint Factory will try to finalise immediately (in which case the user would immediately burn the burn request ticket and receive the relevant STX). Otherwise, the burn request is queued. ### Revoke the burn request A user may revoke a burn request any time, in which case the burn request ticket will be burnt and the relevant LiSTX sent to the user. ## LiSTX and vLiSTX LiSTX may be wrapped to vLiSTX any time, and vice versa. # LISA Vault ## LISA Vault LISA Vault holds STX that are received from the LISA users and that are available for LiSTX redemption. LISA Vault permissions Strategies to pull STX from itself to be deployed to the members of the Strategies. In return, Strategies are implemented so that they can send STX only to LISA Vault. # Strategies ## Strategies Strategies are the smart contracts that implement particular stacking strategies. Each strategy may have one or more "members" which join and delegate STX to different stacking pools. They are managed by Strategy Managers, who decide the allocation of STX across the members of its strategy for each cycle. # Bitcoin ($BTC)
**LiaBTC** is a rebasing token for aBTC and vLiaBTC is a yield-bearing token for BTC. aBTC is designed to mirror Bitcoin's value, maintaining a 1:1 ratio (1 aBTC = 1 BTC). It is built on the Stacks platform, which brings smart contract functionality to Bitcoin, enhancing its utility in decentralized finance (DeFi). ## 1 LiaBTC = 1 aBTC LiaBTC employs a rebasing mechanism similar to other LISA rebasing tokens, dynamically adjusting supply based on underlying value changes. ### Staking Timeframes You can stake your BTC to LiaBTC immediately; however, to unstake, you would need to wait 1,000 Bitcoin blocks for your LiaBTC to be converted back to BTC. * **Stake In:** Instantly convert your BTC to LiaBTC. * **Stake Out:** To convert LiaBTC back to BTC, you must wait for 1,000 Bitcoin blocks. # How LiaBTC Earns Bitcoin Yield? LiaBTC generates yield by staking BTC on the Babylon platform through the COBO API. The staked BTC contributes to securing Proof of Stake (PoS) chains, supporting the network's security budget. In return, stakers receive token emissions as rewards from the network they secure. It is important to note that LiaBTC yield accrues based on Bitcoin blocks, not on cycles like LiSTX or LiALEX. **Video explanation available here:** ### Withdrawal Timeline * Babylon requires a 7-day (\~1,008 Bitcoin blocks) unbonding period after a withdrawal request. * The withdrawal process follows a mechanism similar to the LiSTX withdrawal procedure. # What is LiaBTC backed by? The underlying BTC backing aBTC is securely staked at Babylon, with COBO ensuring the finality of transactions, offering both security and irreversibility. When users stake aBTC through LISA, they receive LiaBTC at a 1:1 ratio, directly reflecting their staked aBTC. LISA then works with XLink, the designated staking manager, to handle the staking of the Bitcoin that underpins those aBTC holdings. # How LiaBTC utilizes Cobo?
XLink, in partnership with Cobo as the custodian of BTC reserves, instructs Cobo to securely stake the relevant Bitcoin on the Babylon platform. The underlying Bitcoin that backs the aBTC is staked at Babylon, with COBO serving as the finality provider to ensure security and the irreversibility of transactions. As rewards from the staking process accrue, LiaBTC balances automatically increase, ensuring a continuous stream of rewards for holders. Similar to other liquid staking products offered by LISA, LiaBTC is a rebase token, meaning its supply adjusts based on rewards, ensuring continuous compounding without manual reinvestment.
# How would ALEX V2 Upgrade Affects LiaBTC? With the ALEX V2 upgrades, XLink will integrate with LISA, allowing Bitcoin users to send BTC and receive vLiaBTC (in BRC-20) in their Bitcoin wallet (i.e., users won't need a Stacks wallet to interact with LISA). This approach will also be applied to all other liquid staking products on LISA over time (in which case it will be STX/ALEX/USDT in BRC-20 => vLiSTX/vLiALEX/vLiUSDT in BRC-20). Currently, LISA only supports staking in and out via the Stacks network, even though you can bridge the LSTs out of the Stacks network. # ALEX ($ALEX) LiALEX is a rebasing token of ALEX. LiALEX replaces the legacy manual staking system previously offered by the ALEX AMM DEX. Instead of committing to a fixed number of cycles, holding LiALEX allows you to continuously earn staking rewards without the need to repeatedly re-enter your staking position after each cycle ends. ## 1 LiALEX = 1 ALEX To fully view the current APR of holding $LiALEX, please visit here: # Staking / Stacking
\ To start earning $STX or $ALEX reward, you need to either stack/stake or buy the liquid stacking/staking tokens via the ALEX AMM. To stack, follow these instructions: 1. Enter the [LISA Stacking/Staking](https://app.lisalab.io/lisa) Page and pick the tokens you want to begin earning rewards. 2. Connect your preferred wallet. 3. To earn rewards for STX, click ‘Stack Now’ on the STX selection. 4. Enter the amount of STX you would like to stack and click ‘Stack’ 5. Approve the ‘Request-Mint’ transaction. 6. Once the transaction has completed, you will receive a Request Mint NFT, which represents the cooldown period for your Stack In process. To understand the mechanism of how the stacking works, please read '[Depositing into LISA](/rebasing-mechanism-101/depositing-withdrawing-from-lisa)'. ### Buying via AMM: You can skip both the In and Out cooldown cycle by buying or selling your LISA tokens via AMM: [ALEX](https://app.alexlab.co/swap) or [Bitflow](https://app.bitflow.finance/trade). Buying via the AMM is subject to slippages and swapping fees in exchange for the convenience of time.
# Unstaking / Unstacking
To unstake your LISA tokens, you would need to individually select which LISA tokens specifically you would like to unstake: **LiSTX:** [**https://app.lisalab.io/li/stx/redeem**](https://app.lisalab.io/li/stx/redeem) **LiALEX:** [**https://app.lisalab.io/li/alex/redeem**](https://app.lisalab.io/li/alex/redeem) **LiaBTC:** [**https://app.lisalab.io/li/abtc/redeem**](https://app.lisalab.io/li/abtc/redeem) **vLiaBTC (Bitcoin Chain):** [**https://app.lisalab.io/li/btc/redeem**](https://app.lisalab.io/li/btc/redeem) **To stack, follow these instructions:** 1. Enter the LISA Unstacking Page listed above. 2. Connect your preferred wallet. 3. Type in the amount you'd like to Unstack. 4. Click ‘Request Unstack’ after confirming the amount you will receive. (It will always be 1:1) 5. Approve the ‘Request-Burn’ transaction. 6. Once the transaction has completed, you will receive a Receive Mint NFT, which represents the cooldown period for your Stack Out process.
To understand how the Request / Redemption process works in depth, please read the Stacking/Staking on LISA section. To understand the mechanism of how the unstacking works, please read [Withdrawing from LISA](/rebasing-mechanism-101/depositing-withdrawing-from-lisa). ### **Selling via AMM:** You can skip both the In and Out cooldown cycle by buying or selling your LISA tokens via AMM: [ALEX](https://app.alexlab.co/swap) or [Bitflow](https://app.bitflow.finance/trade). Selling via the AMM is subject to slippages and swapping fees in exchange for the convenience of time.
# LISA Point System
LISA points are points earned via holding eligible LISA tokens, different tokens represent different point earning ratio. For example, 1,000 LiSTX earns you 1,000 points per day and each time you earn 2,000 points, you are rewarded with a LISA loot box. You can also earn points by sharing your referral links to others; given if the referrer uses LISA via depositing STX or ALEX into LISA. The point leaderboard shows you both Points and also Volume; Points are the combination of both Volume (Deposited tokens) and also referral points. # Wrapping / Unwrapping
#### To convert your rebasing token into a reward-bearing token, you can do this via the Wrap feature. Wrapped LISA tokens will maintain the same amount but its intrinsic value changes each passing cycle. For example, your 1,000 vLiSTX will become 1,100 LiSTX after a year assuming the reward’s APY is 10% consistently while your rebasing version would just become 1,100 LiSTX reflected in your wallet. To wrap: 1. To wrap, you would need to have LiSTX balances within your wallet. 2. To begin wrapping, click on the [Wrap section](https://app.lisalab.io/li/stx/wrapUnwrap) of LISA. 3. Type in the amount you would like to wrap. 4. Check the rate of LiSTX -> vLiSTX; this only increases through time. 5. Click ‘Wrap’ and approve the ‘Mint’ transaction.
To convert your wrapped token back to a rebasing token, you can do this via the Unwrap feature. Unwrapped LISA token balance changes each passing cycle. For example, your 1,000 LiSTX will become 1,100 LiSTX after a year assuming the reward’s APY s 10% consistently; you won’t need to click Unstack or check AMM rate to see your balance change as the LISA UI would reflect your balance change directly on the UI. **To wrap:** 1. To unwrap, you would need to have vLiSTX balances within your wallet. 2. To begin unwrapping, click on the [Wrap section](https://app.lisalab.io/li/stx/wrapUnwrap) of LISA and choose ‘Unwrap’. 3. Type in the amount you would like to unwrap. 4. Check the rate of vLiSTX -> LiSTX; you can also use this to determine how much reward you have earned thus far. 5. Click ‘Unwrap’ and approve the ‘Burn’ transaction. # My Rewards / Overviews
You can use the Rewards page to check how much you have earned every cycle; both for LiSTX and LiALEX. They must be opened separately: **LiSTX:** **LiALEX:** \ Important to note that, if you are holding the wrapped version, the reward will not reflect on this page. You would need to manually input the amount in the Unwrap page to check the latest balance of STX or ALEX. # Review to Earn Review to Earn is an easy way to Win Rewards for using LISA by providing public feedback, thoughts, or even just by saying something nice about LISA on X—it must be unbiased and honest. The review can be positive, neutral, or even negative. **Requirements:** * You must be a LISA user. * Actively holding any of these tokens ( $LiSTX / $LiALEX / $vLiSTX / $vLiALEX ) Click Review to Earn via LISA page here (Upper Right as shown below): # Send LISA Tokens
Due to the absence of a LISA rebasing mechanism, similar to Lido's, not all wallets or explorers may accurately display the correct amount of rebasing tokens in your holdings. This also results in issues that prevent you from sending LISA tokens to another Stacks address. By using the LISA Send feature, you will be able to send the correct amount of LISA tokens to another address. **To Send:** 1. Navigate to LISA Send: 2. Select the asset you wish to send. 3. Enter the amount and paste the recipient's address. 4. Click Send. Please note, the amount sent might not reflect correctly in the Explorer. Therefore, you may need to advise your recipient to wait for confirmation. Then, they can use the LISA UI to check their balance. # Checking your Balance
To check your balance, simply open any LISA page, and the balance will be displayed alongside the header section. This feature has been introduced because most explorers or even wallets lack rebasing support; hence, to accurately check your balance, you would need to do so via the LISA website." # Rebasing vs Reward-Bearing Mechanism ### **Rebasing Tokens** Assuming you have 100 LiSTX, you would have approximately 110 LiSTX after a year if the average APR is 10%, which you can then unstack to get back 110 STX. **Today :** 1 STX = 1 LiSTX **Tomorrow :** 1 STX = 1 LiSTX \ **Mechanism:** Rebasing tokens adjust their total supply to smooth out the value of each token over time. When the protocol's staking rewards increase the overall value, the rebase mechanism might increase the number of tokens in your wallet, or decrease them if the value goes down, to keep the token price relatively stable. **User Experience:** You might hold 100 tokens today, but after a rebase, you could have 110 tokens (or fewer), but ideally, each token retains roughly the same proportionate value of the total supply. The idea is that the price per token remains more consistent, but your token count changes. **Purpose:** This aims to reduce volatility by adjusting the supply dynamically. ### **Reward-bearing Tokens** Assuming you have 100 vLiSTX, you would still have 100 vLiSTX after a year, but if the average APR is 10%, you could then unstack them to receive 110 STX. **Today :** 1 STX = 1 vLiSTX **Future :** 1.1 STX = 1 vLiSTX **Mechanism:** These tokens do not change in quantity in your wallet due to rebasing. Instead, the value of the token itself increases over time as rewards from staking are accrued. The number of tokens you have remains constant, but their inherent value goes up because they represent a share in a growing pool of staked assets. **User Experience:** If you start with 100 tokens, you'll still have 100 tokens later, but each token might give you claim to a larger portion of the staked assets or the rewards accumulated. **Purpose:** To provide a straightforward staking reward mechanism where the token count is stable, but the value of each token appreciates with staking rewards. # Depositing / Withdrawing from LISA ### Depositing into LISA **Request LiSTX:** Users submit a mint request and receive an NFT ticket, transferring the specified STX to the LISA Vault. To be included in the next stacking cycle, requests must be confirmed 300 blocks before the next cycle's preparation stage starts; otherwise, they're deferred. **Finalize mint:** Minting finalizes 432 blocks after the cycle begins, exchanging the NFT ticket for LiSTX. **Cancel mint:** If conditions allow (unlocked STX are available and not committed elsewhere), users can revoke their requests, recovering their STX. Revocation is not possible if the STX is allocated for strategies or outstanding burn requests. #### Do I earn Points after Depositing into LISA? Yes, once you have deposited into LISA, you will start earning points even if you have not yet received your LISA tokens. ### Withdrawing from LISA You can use our Redeem tabs to redeem LiSTX and receive STX at a 1:1 exchange ratio. The redemption steps are as follows: * **Requesting Burns:** For burning LiSTX, users receive an NFT ticket and transfer LiSTX to the LISA Vault, with rewards continuing to accrue during the wait. * **Finalizing Burns:** Burns depend on unlocked STX availability in the Vault and may proceed immediately or be queued. * **Revoking Burns:** Users can revoke burn requests at any point, canceling the ticket and retrieving their LiSTX. #### **How Long to Wait for Withdrawal and do I still earn Points?** Under normal circumstances, redemption requests can take anywhere from 1 to 14 days until the next stacking cycle is completed, after which you can claim your STX using the Claim dashboard. If there is enough STX within the unstacking balance, you will be able to redeem your STX instantly. {% hint style="info" %} The instant redemption is funded by new STX deposited into the stacking vault. If there isn't enough newly deposited STX by the time you make a stack-out request, you need to wait for another cycle. E.g.: If cycle #N has 200,000 STX newly stacked, the same 200,000 STX can be used by anyone who wishes to stack out immediately. {% endhint %} **Easier way to put it:** * If there's sufficient STX for redemption: **Instant—but no more LISA points.** * If there's insufficient STX for redemption: **Wait for one cycle—still earn LISA points.** You can also exchange LiSTX on DEX LISA integrations (e.g., ALEX swap). # How are Rewards Paid Out? Rewards are paid out after each participated cycle ends. # How do I calculate my earnings? You can check your earning via: * My Reward Page (LiSTX and LiALEX uses a different page) * Unwrap Page (Check the difference between the initial STX balance and compare it to current; given if you have held the wrapped token through cycles) # Do I Earn Rewards if I withdraw before a Cycle Ends? No, you will not earn any rewards if you withdraw your Stack In before your cycle ends. We highly recommend that you commit to your stacking cycles! # How is APR determined? APR are calculated based on the total number of stacking/staking cycles per year \* percentage of reward earned per cycle. The $STX earnings are generated from the Stacks Chain stacking mechanism; your earnings will therefore vary from cycle to cycle. Assuming the entire year's APY stays constant at 12% and you hold 25,000 $LiSTX for a year (26 Stacking Cycles). * You started with 25,000 LiSTX * After ONE stacking cycle, you will earn: 115.3825 LiSTX. * The LiSTX balance in your wallet is then increased from 25,000 LiSTX to 25,115.3825 LiSTX * You can keep checking after every cycle to see your updated $LiSTX balance. Important to note that not all wallets or explorers support rebasing mechanism, which means that your LiSTX will not reflect accurately. For LiSTX, to see your balance accurately, check it here: For LiALEX, to see your balance accurately, check it here: # How can I check my past transactions on LISA?
The ALEX Explorer provides the most accurate representation of any amount of tokens swapped historically. This means you can see how much X you swapped for Y. You can review both your personal transaction records and global transaction records, dating back to when ALEX was launched. Currently, the ALEX Explorer supports interactions with both ALEX and LISA tokens. Most importantly, the ALEX Explorer supports the rebasing mechanism! This feature is crucial because many wallets and explorers do not support rebasing, which can lead to inaccurate amounts being displayed on third-party user interfaces. # How can I check the accurate LiSTX amount I’ve swapped via AMM? To check how much LiSTX you have received via AMM swaps: 1. Connect your wallet on either LISA or ALEX. 2. Click ‘Explorer’ on the upper right of the LISA webpage. 3. Choose ‘LISA’. 4. Click on ‘My Records only’ 5. You should be able to track back your swap history. Important to note, if you are using an external service to swap like Bitflow, it may not show up here. # Can I bridge out my LISA Tokens to other networks? Yes! Plus, for example, if you are holding vLiSTX on other networks, it will still accrue stacking rewards similar to those in the Stacks network. Additionally, you might even be eligible for bonus rewards, depending on the campaigns run by other networks. # How to Participate in LISA Merkl Campaign? To participate in the Merkl Campaign, here's what you need to do: 1. If you have Stacks ($STX), convert them into $LiSTX either by [stacking](/features-how-tos/staking-stacking) or by [buying it via the AMM](https://app.alexlab.co/swap). Please note that stacking has a cooldown period; if you need $LiSTX more quickly, it is advisable to buy them through the AMM. 2. Once you have $LiSTX, use the [Wrap](/features-how-tos/wrapping-unwrapping) feature to convert it to vLiSTX, which is a yield-bearing version of $LiSTX.

Sufficient Balance will not display Insufficient Amount

3. Then, head to [XLink](https://app.xlink.network/bridge/cross-bridge) and connect your wallet that holds the vLiSTX. 4. Once connected to XLink, select: * From: **Stacks Chain** * To: **Mode Network** 5. Enter the amount you want to bridge, scroll down in the Bridge UI, and check the approximate time and fees required for the bridge. 6. Once everything checks out, you may proceed to bridge over to the MODE Network. 7. Remember, you can always bridge back to the Stacks Network. **Note:** This example uses the MODE Network as a reference. # Point Reward Scores ### LiSTX Every 1 LiSTX = 1 LISA Points per day ### LiALEX Every 1 LiALEX = 1/20 LISA Points per day Which is equivalent to 20 LiALEX = 1 LISA Points per day. ### Wrapped Token Points You will still earn points if you are holding $vLiSTX on the Stacks network, the amount will be calculated based on the amount of $LiSTX amount from your current $vLiSTX holdings. Unfortunately, due to certain technical limitations, you will not earn points if you hold LISA-issued assets such as $LiSTX, $vLiSTX, $LiALEX, or $vLiALEX on networks other than the Stacks network. Points are only available for holding these assets on the Stacks network. ### STX-LiSTX LP Farm via ALEX You will receive LISA Points based on the amount of LiSTX you currently have in your STX-LiSTX pair. For example, if your LP pair has 1,000 STX : 1,000 LiSTX within your LP pair; even though that would be equivalent to 2,000 STX since 1 LiSTX = 1 STX, you will earn 1,000 LISA Points since there’s only 1,000 LiSTX within the LP pair. ### **LiaBTC** Point is not available yet.
# Points to Loot Box Conversion Each 2,000 LISA points will reward you ONE Loot box. Important to note that you cannot double earn a loot box on an existing 2,000 LISA Points. ### Loot Box Rarity There are three different rarity : * **Uncommon** * **Rare** * **Legendary**
In some cases, LISA may drop Unique event-based loot boxes that cannot be earned via LISA Points. Some of the Unique loot boxes are: * **WELSH** * **MODE** # Entry / Exit Cycle Cooldown FAQs ### Do I earn points during Stacking/Staking In? Yes, you will start earning points if you have stacked or staked your supported tokens on LISA! ### Do I still earn points after Stacking/Staking Out? No, you will no longer earn any LISA points once you have exited your current staking/stacking positions; this applies to both LiALEX and LiSTX. ### Do I earn points immediately after buying LISA tokens via AMM? Yes, the moment you start holding LISA tokens, you will begin earning LISA points. Important to note that, your earning comes the next day, not instantly. # LISA DAO Rule based governance for LISA ## What is a DAO? A DAO, or Decentralized Autonomous Organization, is a type of organization represented by rules encoded as a computer program that is transparent, and controlled by organization members. DAOs operate on blockchain technology, to automate and enforce rules and decisions without the need for a central authority. ## What is LISA DAO? LISA DAO manages proposals to the LISA platform which enables changes to be implemented in a rule-based way. Changes to the platform can take various forms, including modifications to parameters, minting or burning of tokens, and adding, upgrading, or deprecating system contracts. ## LISA DAO Architecture
### Main DAO Components Overview This architecture has the following main components: #### LISA-DAO Contract This is the core contract responsible for the DAO's operations and privileges. It is in charge of: * Bootstrapping the DAO * Defining new DAO features through extensions (modules) * Executing proposals * Authorizing components and extensions #### Operators Contract This contract manages the governance of the DAO and is implemented within LISA's platform as an extension. It is responsible for: * Managing and controlling the users with permission to propose and vote changes to the platform. * Establishing proposal signaling thresholds * Receive and hold presented proposals while being voted/accepted * Signaling (voting on) registered proposals * Delegating proposal execution to the DAO operation contract * Controlling the validity, resubmissions, and expirations of proposals #### Extension Contracts These individual contracts are designed to enhance the features and operations of the DAO by providing new specific implementations. These contracts usually have the same permissions as the DAO contract itself. (see is-dao-or-extension) #### Proposal Contracts Proposals are contracts that define updates to the DAO platform. They are meant to execute tasks reserved for the DAO's privileged executors (the LISA DAO contract itself, or enabled extensions). These tasks can include platform state changes, executing actions, and introducing extensions to the platform. Each proposal is approved through a voting system implemented in the operator's extension. They are executed only once with the DAO contract as the transaction sender. ### Operations Proposal **Lifecycle**
**Proposal created** A proposal is ready to be used when its contract is finally deployed. **New Proposal** Procedure to register the address of a given contract that conforms to the predefined proposal interface (trait). The operator that creates the proposal automatically signals 1 vote for it. Resubmissions (i.e. proposing again) are restricted only to non-executed expired proposals. This operation is restricted to enabled operators. **Signaling** Signaling is the process of voting for a certain registered and non-expired proposal in a boolean fashion (i.e., adding or subtracting 1 vote). Operators can only signal the same proposal twice if it has been resubmitted. The signaling procedure will trigger the execution step automatically if the proposal's signal count meets the threshold for execution. This operation is restricted to enabled operators. **Execution** As described in the signaling procedure, execution happens automatically when the signal count for the proposal meets the threshold. The procedure is delegated to the DAO operation contract, which restricts the operation to authorized extensions or the DAO contract itself. Finally, the execution invokes the proposal contract's execution method. **Expiration** Proposal expiration occurs at a certain point in time (in the underlying burn blockchain) when the block height surpasses the validity period for that proposal. The validity period is defined as the range of blocks from when the proposal was created until reaching the sum of that block plus a predefined delta (currently set to 144 blocks). **Validation Logic** Proposals have a validation status, which is accomplished if two conditions are met: * The proposal has not expired. * The proposal was created after the operator extension was set up, including any updates to operators or thresholds. This validation is used in both new proposals and signaling procedures. #### Extensions #### **New extension** Only DAO operator members (i.e. the core contract lisa-dao or previously registered and enabled extensions) can perform this step. Typically, new extensions are only registered through proposal contracts when they receive a majority of votes.\ \ **Availability** During or after the registration of a module (extension), other DAO operator members can enable or disable the extension in a boolean fashion. Although disabled extensions will remain registered in the core contract, they will not be permitted to perform future operations while in that state. As with the registration process, only DAO operator members have the authority to change the status of extensions.
**Callbacks** Extensions that conform to the predefined extension interface (trait) have access to the core contract’s "Extension Requests" special feature. This feature allows other enabled extensions to call the core contract, which in turn, can call back the initiating extension to perform a specific callback method with lisa-dao privileges. This includes the sender that triggered the call and a provided payload. ## Examples ### A proposal: lip-004.clar. The lip-004 contract is a multi-purpose proposal that modifies the DAO-platform structure by adding and removing extensions while performing a few reconfigurations. For it to be executed, it must first be accepted by the platform. The process is as follows: * The newly proposed extension contracts (lqstx-mint-endpoint-v2-01 and public-pools-strategy-manager-v2) must be created along with this proposal contract, which will contain the code for the system reconfiguration. * Once both contracts are created and deployed, the proposal is submitted to the DAO-platform through the operators (extension) contract. This contract verifies that the submission is made by a DAO-operator. * The proposal is then put to a vote by the remaining DAO-operators (it is assumed that the submitting operator votes in favor, and its vote is automatically counted with the submission). * At some point, the proposal either reaches a predefined voting threshold or it expires. If the voting threshold is reached, the operators contract invokes the executor-dao contract to run the proposal's execute() code with DAO privileges. In this way, the code in the proposal gains the necessary permissions, allowing it to invoke any required DAO-platform functionality as if it were already part of the DAO. This enables the proposal to do things like: * Include new extensions to the platform (as well as remove, stop, pause, etc.). * Reconfigure token pools. * Reconfigure blocklists. * Confirm special cases of token migrations. * Perform other necessary tasks. * After all actions by the proposal are executed, it is discarded and cannot execute its code again or regain DAO privileges. #### In this particular case As mentioned before, in this particular case, the proposal contains code to perform different reconfiguration actions: 1. Newly deployed extension contracts must be set up in the DAO-platform, while the replaced versions must be removed from the platform. 2. Contracts that are removed from the platform must be also paused. 3. One of the new extensions requires initial setup. To perform the extension replacement in the platform, a new invocation is made to the executor-dao contract, which tracks the extensions in use and allows verification of whether an invoking contract is approved. The deprecated extensions must be paused to prevent them from being operated if invoked. Finally, the public-pools-strategy-manager-v2 extension will be invoked to perform its initial setup. DAO-operator: a contract already integrated into the DAO-platform or a system user with operator privileges.
### Extension Example: Treasury Is a crucial part of the DAO’s financial management. It allows authorized transfers of both STX and SIP-010 tokens, ensuring that only the DAO or its extensions can initiate these transfers. Additionally, it provides functionality for making proxy calls to other contracts, further enhancing the DAO's capability to interact with and manage external contracts. This setup ensures secure and authorized management of the DAO’s treasury.
# LISA DAO Improvements lip contracts * lip001: Update LiSTX token meta data, introduce mint delay, whitelist users for testing, * lip002: Mint LiSTX NFTs for testers * lip003: Add auto-whitelist for FAST pool and Xverse pool members # Stacking Strategies How STX is used by LISA to earn rewards ### Public Pools Strategy v1 With the Public Pools Strategy, LISA delegates stacking to public stacking pools. Currently, the strategy uses * [FAST Pool](https://fastpool.org) by Ryder * [Xverse Pool](https://pool.xverse.app) An authorized strategy manager is allowed to transfer STX between LISA's vault and the strategy. The strategy consists of 20 contracts that act as pool members of one of the public pools. The strategy manager distributes the funds to the pool members and manages their delegation to the pools. Currently, authorized strategy managers are * 'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH * 'SP2G5X5HCJW31Q3Z71XGPV5S8FNBZMWW7PK45ZWG8 # Security Audits The smart contracts are audited by CoinFabrik: * [2024-04 DAO and Liquid Staking](https://cdn.lisalab.io/pdf/LISA_Audit_2024-04.pdf) * [2024-05 Alex's Auto Token v3](https://cdn.lisalab.io/pdf/Auto_Alex_v3_Audit_May2024.pdf) * [2024-11 XLINK Staking](https://cdn.lisalab.io/pdf/XLINK_Staking_Audit_2024_11_final.pdf) # External Analytics Signal21
Signal21 is a leading blockchain data and intelligence platform designed specifically for navigating the Bitcoin Economy. To view LISA data on Signal21, click here: # Deployed Contracts ### Extensions | Contract | Description | | --------------------------------------------------------------- | -------------------------------------------------------------------------------- | | `SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.operators` | Implments a smart contract based multisig to execute LISA Improvement Proposals. | | `SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lqstx-vault` | Holds STX of the members | | `SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lqstx-mint-endpoint` | Interacts with the members and mints / burns LiSTX. | ### Stacking Strategies | Contract | Description | | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | `SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.public-pools-strategy` | Using public stacking pools (10 pool members with FAST pool, 10 pool members with Xverse pool). | | `SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.public-pools-strategy-manager` | Endpoint used by strategy managers. | # ALEX
Launched in early 2022, [ALEX](https://www.alexlab.co) builds the future of decentralized trading, driving the evolution of Bitcoin DeFi. The ALEX DEX stands as the leading decentralized exchange on Bitcoin layers, specifically on the Stacks Chain. ### Public Information Available about ALEX **Coingecko:** **Defillama:** **𝕏 :** **Stacks:** # Ryder
[Ryder](https://www.ryder.id/) created the simplest way to take control of your crypto: Ryder One. With just two taps, you can secure your coins for a lifetime, set it up in under a minute, and back it up even faster. # Fast Pool by Ryder
The [Fast Pool](https://fastpool.org/) is the oldest and one of the largest stacking pools on the Stacks ecosystem. It’s also the only pool that distribute rewards in STX. Start doubling your STX rewards today!
# Xverse

Xverse is the leading Bitcoin wallet for everyone, providing a user-friendly gateway to the growing Bitcoin Web3 ecosystem.
# XLink
[XLink](https://www.xlink.network) is a Liquidity Layer on Bitcoin, integrating Bitcoin into the decentralized finance (DeFi) ecosystem. With XLink, vLiSTX and vLiALEX is supported on more than 13 different networks as listed in [Supported Networks](/developers/lisa-supported-network). # Cobo
Founded in 2017 by blockchain pioneers, Cobo aims to simplify digital asset security. It has positioned itself as a trusted leader in digital asset custody, providing wallet infrastructure that integrates various wallet technologies like Custodial Wallets, MPC Wallets, Smart Contract Wallets, and Exchange Wallets into one unified platform. Cobo boasts a zero-incident security track record, safeguarding billions of dollars in assets for over 500 organizations worldwide. This emphasizes their commitment to security and trust in the management of digital assets. We work with Cobo with the implementation of [LiaBTC](/supported-tokens/bitcoin-usdbtc). # List with LISA! Looking to help your community to unlock their liquidity to earn yields? LST your tokens with LISA today, read more below to find out more!
Staking is a popular strategy used by DAOs, protocols, and projects, where you hold and lock up cryptocurrency to help run, secure, earn incentives and etc. However, each project handles rewards differently based on its setup. This can make it tough for new users to figure out how to earn rewards, as it might require a lot of research and effort. Additionally, some projects set a minimum amount needed to start staking, which might exclude smaller investors from earning rewards. Enter liquid staking tokens (LSTs), which solve the issues of minimum balances and cumbersome processes. Yet, not every project can afford to create their own LSTs for their native tokens. This is where LISA comes in—LISA provides a custom LST solution for your project's tokens. **In short, LSTs:** * Are easier for anyone to participate in—usually with a simple swap. * Are accessible to smaller accounts by removing staking amount limitations and eliminating the hassle of complicated staking processes. * Enable your community to expand into more DeFi opportunities without missing out on the staking rewards of your native tokens. ### Why Launch your LST with LISA? LISA has a proven track record of launching 3 and counting numbers of LSTs with each of them designed in a bespoke manner: * **STX ->** [**LiSTX**](https://docs.lisalab.io/~/changes/nTd2kdqu4i8fnOkHTWmm/supported-tokens/stx)**:** Rewards from securing the Stacks network via the Proof-of-Exchange mechanism. * B**TC ->** [**LiaBTC**](https://docs.lisalab.io/~/changes/nTd2kdqu4i8fnOkHTWmm/supported-tokens/bitcoin-usdbtc)**:** Rewards from Babylon via the COBO API. The staked BTC is used to secure Proof of Stake (PoS) chains and generate yield. * **ALEX ->** [**LiALEX**](https://docs.lisalab.io/~/changes/nTd2kdqu4i8fnOkHTWmm/supported-tokens/alex)**:** Rewards from ALEX reward emissions for participating in the ALEX Ecosystem. * **(Incoming) aUSD -> LiaUSD:** Rewards from US Treasury yields; Real World Asset (RWA) yields. Unlike LST platforms like Sanctum from Solana, which only support one type of asset, $SOL, on a single network, LISA develops bespoke LSTs and supports a wide range of assets. Additionally, it enables you to bridge your tokens to more than 16 different networks listed in the [Supported Networks](https://docs.lisalab.io/~/changes/nTd2kdqu4i8fnOkHTWmm/developers/lisa-supported-network), powered by [XLink](https://docs.lisalab.io/~/changes/nTd2kdqu4i8fnOkHTWmm/ecosystem-partners/xlink). ### How LISA LST Works? 1. Instead of committing funds into a contract that locks up funds indefinitely for yields, LISA will use your committed funds to stake on your behalf. In exchange, you will receive LSTs as returns; LSTs are on-chain IOU tokens. 2. LISA LSTs are issued as liquid staking tokens each time a user commits funds into the LISA contract. These LSTs can be redeemed whenever a user requests to unstake them, along with the rewards generated from the amount you committed to LISA. 3. The rewards are generated each time depending on the mechanism of the tokens we support; for example, the reward structures for LiaBTC and LiSTX are not the same. However, with each reward cycle that passes, LISA will channel those rewards into your LSTs. ### Requirements to LST with LISA It's important to note that even though LISA provides bespoke solutions for LST creation, not every token can be converted into LSTs. Here are some of the requirements that must be met: * The token must currently support staking features (we support both Permissioned and Permissionless). * The token must have continuous staking with a uniform unstake delay and a short, uniform stake delay (maximum 3 days). For example, a user can stake at any time with up to a 3-day delay in the start of staking, and can unstake at any time with a delay in receiving unstaked tokens. The reward cycle duration cannot be random. * The staking reward, schedule, and structure must be clearly laid out, showing how rewards are earned and distributed to staked tokens. * Your project must obtain and pass audits from notable auditing firms to ensure that your smart contracts meet the safety requirements. * The LISA team needs to review/approve the staking contract and may require audit reports. If all of the above requirements are met, the LISA team can provide the integration and create your LST for your community! {% hint style="info" %} Interested to LST with us? Send us a message via our official 𝕏 profile here: {% endhint %} # LISA Supported Network The current supported network for LISA tokens are: * Core * B2 * BOB * Bitlayer * Lorenzo * Merlin * AILayer * MODE * X Layer * Arbitrum * Aurora * Manta * Stacks To see full list of supported networks enabled via the XLink bridge, please head here: Please make sure you chosen only the wrapped version of LISA tokens (**vLiALEX, vLiSTX**) # LISA Media Kits Here are the official LISA media kits: # Contracts Technical Design Overview LISA is deployed and functioning within the Stacks blockchain network. This document aims to serve both as an index and an overarching overview of the LISA on-chain ecosystem. ## Governance At the top of the on-chain architecture is the LISA DAO, accounting for LISA's governance in a rule-based, modular and flexible manner. Built upon Marvin Janssen's ExecutorDAO project, it operates based on the following core principles: 1. Proposals are smart contracts. 2. The core executes, the extensions give form. 3. Ownership control happens via sending context. For technical details on the ExecutorDAO, refer to the project's [README.md](https://github.com/MarvinJanssen/executor-dao#readme). To understand how the ExecutorDAO is customized and implemented within LISA, visit the dedicated [LISA DAO](https://docs.lisalab.io/governance/lisa-dao) governance page in the documentation. ## Liquid Staking ### aBTC as LiaBTC `aBTC`, or [ALEX BTC](https://medium.com/alexgobtc/abtc-from-alex-a-practical-step-towards-bitcoin-defi-ccb6ec684d87), is a Stacks SIP-010 token pegged 1:1 to Bitcoin. `LiaBTC` is a rebasing token for `aBTC`, while `vLiaBTC` is its non-rebasing, value-accruing wrapper. #### Relations Diagram {% @mermaid/diagram content="flowchart LR classDef smclass fill:#FFE4B5,stroke:#FF8C00 ``` subgraph XLink Infrastructure sm[XLink Staking Manager]:::smclass sm -.-o stake[["External BTC Staking Platform (Cobo + Babylon)"]]:::smclass end mint[LiaBTC Mint Endpoint] reg[LiaBTC Mint Registry] mint <--state update & fund management--> reg subgraph Tokens direction LR lia["LiaBTC (Rebasing)"] wrap["vLiaBTC (Non-Rebasing Wrapper)"] lia <--> wrap end mint --stake/unstake aBTC--> sm[XLink Staking Manager] mint --mint/burn--> lia" %} ``` #### LiaBTC Mint Endpoint * Contract name: `liabtc-mint-endpoint` * [Complete technical documentation](/developers/contracts/liabtc-mint-endpoint) The Mint Endpoint serves as the users' operational interface to stake and unstake `aBTC`, facilitating the minting and burning of `LiaBTC`. It relies on the XLink Staking Manager to handle the liquid staking pool management. #### LiaBTC Mint Registry * Contract name: `liabtc-mint-registry` * [Complete technical documentation](/developers/contracts/liabtc-mint-registry) The Mint Registry functions as the persistence and treasury module for the Mint Endpoint operations. #### Token LiaBTC * Contract name: `token-liabtc` * [Complete technical documentation](/developers/contracts/token-liabtc) Implementation of the `LiaBTC` rebasing token that represents staked `aBTC`. The underlying Bitcoin backing these `aBTC` tokens is staked externally utilizing the XLink on-chain and off-chain infrastructure. The lifecycle of the token invoves minting when `aBTC` is submitted for staking and burning upon unstaking. When users stake `aBTC` through the Mint Endpoint, they receive `LiaBTC` at a 1:1 ratio. #### Token vLiaBTC * Contract name: `token-vliabtc` * [Complete technical documentation](/developers/contracts/token-vliabtc) Implementation of the `vLiaBTC` value-accruing token, designed as a non-rebasing wrapper for `LiaBTC`. It is mainly used as a layer of compatibility to integrate `LiaBTC` with other DeFi protocols. Users can wrap their `LiaBTC` into `vLiaBTC` to maintain the same value in a non-rebasing format. #### XLink Staking Manager * Contract name: `xlink-staking` * [Complete technical documentation](https://docs.xlink.network/developers/contracts/xlink-staking) The XLink Staking Manager is a generic contract designed to manage liquid staking pools for multiple tokens and track staker positions within each pool. It is part of a hybrid, token-agnostic liquid staking management system, that operates alongside off-chain backend and frontend components managed by XLink. {% hint style="info" %} This contract is part of [XLink](https://docs.lisalab.io/ecosystem-partners/xlink) ecosystem and is governed by the XLink DAO. {% endhint %} ## Deployed contracts {% hint style="warning" %} Page under construction. This is not an exhaustive list. {% endhint %} ### Governance * ExecutorDAO: [`'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lisa-dao`](https://explorer.stxer.xyz/txid/SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lisa-dao) * Operators: [`'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.operators`](https://explorer.stxer.xyz/txid/SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.operators) ### aBTC Liquid Staking * LiaBTC Mint Endpoint: [`'SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.liabtc-mint-endpoint`](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.liabtc-mint-endpoint) * LiaBTC Mint Registry: [`'SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.liabtc-mint-registry`](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.liabtc-mint-registry) * LiaBTC Token: [`'SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-liabtc`](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-liabtc) * vLiaBTC Token: [`'SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-vliabtc`](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-vliabtc) * XLink Staking Manager: [`'SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.xlink-staking`](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.xlink-staking) # liabtc-mint-endpoint * Location: `xlink-dao/contracts/liabtc/liabtc-mint-endpoint.clar` * [Deployed contract](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.liabtc-mint-endpoint) Façade for [`xlink-staking`](https://docs.xlink.network/developers/contracts/xlink-staking) contract designed to handle the lifecycle of the `LiaBTC` rebasing token (mint, burn and rebase operations). The `liabtc-mint-endpoint` contract acts as single `aBTC` staker within the [`xlink-staking`](https://docs.xlink.network/developers/contracts/xlink-staking) contract. It serves as an abstraction layer, simplifying interactions between `LiaBTC` users and the liquid staking pool management provided by the [`xlink-staking`](https://docs.xlink.network/developers/contracts/xlink-staking) contract, also known as XLink Staking Manager. ## Mint The mint operation consists of two main actions: * User transfers `aBTC` to be staked in the liquid staking pool. * User receives `LiaBTC` tokens in exchange at a 1:1 ratio (1 `aBTC` = 1 `LiaBTC`). When a user mints `LiaBTC`, the underlying `aBTC` is transferred to the Staking Manager, which stores the funds, tracks the liquid staking status (including shares and stake balances) and emits an event. {% @mermaid/diagram content="flowchart LR User --aBTC--> liabtc-mint-endpoint liabtc-mint-endpoint --LiaBTC--> User liabtc-mint-endpoint --aBTC--> xlink-staking xlink-staking -.-> A\[\["Updates storage and emits event"]]" %} ## Burn The burn operation (or unstake) allows users to withdraw their `aBTC` from the liquid staking pool in exchange for burning `LiaBTC` tokens at a 1:1 ratio. These operations are managed by the [`liabtc-mint-registry`](/developers/contracts/liabtc-mint-registry) and involve a waiting period between the burn request and the final withdrawal of `aBTC`. ### Request User initiates the request to unstake a specific amount of `aBTC`. During this step: * That same amount of `LiaBTC` tokens are burned from the user wallet. * A burn request is created in the registry with a unique `request-id` and a [`PENDING`](#pending) status. * The `aBTC` are sent from the Staking Manager to the registry, which will hold the funds until the request is either finalized or revoked. ### Finalize Once the [`burn-delay`](#burn-delay) period (typically 1,000 Bitcoin blocks) has passed, the user or any other principal can finalize the request. On finalization: * The corresponding `aBTC` is transferred from the registry to the requester, completing the unstaking process. * The request status is updated to [`FINALIZED`](#finalized). ### Revoke Burn requests can be revoked by the requester at any time before it is finalized. When revoke: * The corresponding `aBTC` is returned to the user. * A [`mint`](#mint) operation is executed in the same transaction, restoring the user's original amount of `LiaBTC`. * The request status is updated to [`REVOKED`](#revoked). ## Rebase This contract manages the `LiaBTC` token reserve through the [`rebase`](#rebase) public function. Mint and burn operations perfom a rebase every time they are executed. However, `rebase` can be called permissionlessly by any principal. The rebasing mechanism is implemented via the "shares" concept. The `LiaBTC` reserve reperesents the value in `aBTC` of the staking shares held by the `liabtc-mint-endpoint`, as tracked by the XLink Staking Manager contract. The staking shares held by the `liabtc-mint-endpoint` are adjusted whenever users mint or burn `LiaBTC`. Over time, the value of these shares in `aBTC` grows as accrued staking rewards are reinvested, increasing the reserve. For a detailed overview of the `LiaBTC` liquid token, refer to the [`token-liabtc`](/developers/contracts/token-liabtc) contract documentation. ## Features ### Public #### `rebase` Updates the `LiaBTC` token reserve by recalculating its value in `aBTC` based on the staking shares held by the `liabtc-mint-endpoint` contract. #### `mint` Mints `LiaBTC` to the caller (defined as `sender` within the contract) in exchange for `aBTC` at a 1:1 ratio. The provided `aBTC` is staked in the XLink Staking Manager by the `liabtc-mint-endpoint` on behalf of the user. The `message` and `signature-packs` parameters serve as inputs to the [`xlink-staking::stake`](https://docs.xlink.network/developers/contracts/xlink-staking#stake) function. They are part of the XLink liquid staking pool's reward accrual mechanism, which operates permissionlessly and relies on validators. **Parameters** | Name | Type | | ----------------- | ------------------------------------------------------------------------------- | | `amount` | `uint` | | `message` | `{ token: principal, accrued-rewards: uint, update-block: uint }` | | `signature-packs` | `list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) }` | #### `request-burn` Initiates the burn procedure for a certain amount of `LiaBTC`. Several actions are performed: * `LiaBTC` amount is burned from the user wallet. * The same amount of `aBTC` is unstaked from the `xlink-staking` contract and transferred to the `liabtc-mint-endpoint`, which then transfers it to the [`liabtc-mint-registry`](/developers/contracts/liabtc-mint-registry), where it is held until finalization or revocation. * A request with `PENDING` status is created on the registry. As with [`mint`](#mint-1), the `message` and `signature-packs` parameters serve as inputs to the [`xlink-staking::unstake`](https://docs.xlink.network/developers/contracts/xlink-staking#unstake) function. **Parameters** | Name | Type | | ----------------- | ------------------------------------------------------------------------------- | | `amount` | `uint` | | `message` | `{ token: principal, accrued-rewards: uint, update-block: uint }` | | `signature-packs` | `list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) }` | #### `revoke-burn` Revokes a burn request. Only the requester (`requested-by` field of the request) can call this function. The registry returns the funds back to user as in `finalize-request`, with the key difference that the [`mint`](#mint-1) function is invoked (with the user as `sender`) to restake the `aBTC` and mint the `LiaBTC` back to the user. Request status is updated to `REVOKED`. **Parameters** | Name | Type | | ----------------- | ------------------------------------------------------------------------------- | | `request-id` | `uint` | | `message` | `{ token: principal, accrued-rewards: uint, update-block: uint }` | | `signature-packs` | `list 100 { signer: principal, message-hash: (buff 32), signature: (buff 65) }` | #### `finalize-burn` Finalizes a burn request by transferring the `aBTC` from the registry to the user (`requested-by` field of the request). Request is set as `FINALIZED`. This function is permissionless and can be called by any user, even those who did not initiate the burn request. **Parameters** | Name | Type | | ------------ | ------ | | `request-id` | `uint` | #### `finalize-burn-many` Finalizes requests in bulk. **Parameters** | Name | Type | | ------------- | ---------------- | | `request-ids` | `list 1000 uint` | ### Governance The following functions are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. This implies that only the LISA DAO or an enabled extension can use these features. #### `set-use-whitelist` Sets the [`use-whitelist`](#use-whitelist) variable. **Parameters** | Name | Type | | --------- | ------ | | `new-use` | `bool` | #### `set-whitelisted` Assigns the whitelist status of a user. Modifies the [`whitelisted`](#whitelisted) map. **Parameters** | Name | Type | | ----------------- | ----------- | | `user` | `principal` | | `new-whitelisted` | `bool` | #### `set-whitelisted-many` Assigns the whitelist status of users in bulk. **Parameters** | Name | Type | | ----------------- | --------------------- | | `users` | `list 1000 principal` | | `new-whitelisted` | `list 1000 bool` | #### `set-mint-paused` Sets the [`mint-paused`](#mint-paused) variable. **Parameters** | Name | Type | | ------------ | ------ | | `new-paused` | `bool` | #### `set-burn-paused` Sets the [`burn-paused`](#burn-paused) variable. **Parameters** | Name | Type | | ------------ | ------ | | `new-paused` | `bool` | #### `set-burn-delay` Sets the [`burn-delay`](#burn-delay) variable. **Parameters** | Name | Type | | ----------- | ------ | | `new-delay` | `uint` | ### Supporting features #### `is-dao-or-extension` Standard protocol function to check whether the `contract-caller` is an enabled extension within the DAO or the `tx-sender` is the DAO itself (proposal execution scenario). The enabled extension check is delegated to the LISA's `executor-dao` contract. #### `is-whitelisted-or-mint-for-all` Checks if a given `principal` is eligible for minting under the current whitelist settings. If the whitelist is active, returns `false` if the user is not whitelisted. Returns `true` in all other cases. **Parameters** | Name | Type | | ------ | ----------- | | `user` | `principal` | #### `validate-mint` `xlink-staking::validate-stake` façade for handling `aBTC` staking. Within the contract, this function is solely called by the [`mint`](#mint-1) function. Throws if mint is paused or the `sender` is not whitelisted (when applicable). **Parameters** | Name | Type | | -------- | ------ | | `amount` | `uint` | #### `validate-request-burn` `xlink-staking::validate-unstake` façade for handling `aBTC` unstaking. Within the contract, this function is solely called by the [`request-burn`](#request-burn) function. Throws if burn is paused. **Parameters** | Name | Type | | -------- | ------ | | `amount` | `uint` | #### `validate-revoke-burn` Performs revoke burn validations and returns the corresponding request details. Within the contract, this function is solely called by the [`revoke-burn`](#revoke-burn) function. Validations encompass: burn is not paused, request exists, request has `PENDING` status and `sender` matches the `requested-by` field on the burn request (only the requester can revoke). **Parameters** | Name | Type | | ------------ | ------ | | `request-id` | `uint` | #### `validate-finalize-burn` Performs finalize burn validations and returns the corresponding request details. Within the contract, this function is solely called by the [`finalize-burn`](#finalize-burn) function. Validations encompass: burn is not paused, request exists, request has `PENDING` status and the [`burn-delay`](#burn-delay) period has been completed. **Parameters** | Name | Type | | ------------ | ------ | | `request-id` | `uint` | ### Getters #### `is-mint-paused` Returns the [`mint-paused`](#mint-paused) variable. #### `is-burn-paused` Returns the [`burn-paused`](#burn-paused) variable. #### `is-not-mint-paused-or-fail` Throws with `err-paused` if mint is paused, returns `(ok true)` otherwise. #### `is-not-burn-paused-or-fail` Throws with `err-paused` if burn is paused, returns `(ok true)` otherwise. #### `get-burn-request-or-fail` Returns a burn request stored in the `liabtc-mint-registry`'s `burn-request` map. If entry doesn't exist, throws. **Parameters** | Name | Type | | ------------ | ------ | | `request-id` | `uint` | #### `get-burn-request-or-fail-many` Returns a list of burn requests stored in the `liabtc-mint-registry`. If any of the entries doesn't exist, throws. **Parameters** | Name | Type | | ------------- | ---------------- | | `request-ids` | `list 1000 uint` | #### `get-burn-delay` Returns the [`burn-delay`](#burn-delay) variable. #### `get-current-bitcoin-block` Getter for testing purposes. If mainnet, returns the `burn-block-height`. ## Storage ### `mint-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | Indicates the operational status for the mint (stake) operations. ### `burn-paused` | Data | Type | | -------- | ------ | | Variable | `bool` | Indicates the operational status for the burn (unstake) operations. ### `burn-delay` | Data | Type | | -------- | ------ | | Variable | `uint` | Indicates the waiting period for a burn request, measured in Bitcoin blocks (burn chain). It represents the time users must wait between initiating burn request and being able to finalize it. ### `use-whitelist` | Data | Type | | -------- | ------ | | Variable | `bool` | Indicates whether the whitelist mechanism is currently active. The whitelist applies to mint (stake) operations but not to burn (unstake) ones. ### `whitelisted` | Data | Type | | ---- | ---------------- | | Map | `principal bool` | Maintains a mapping of users (`principal`) to their whitelist status (`bool`). ### Relevant constants #### `PENDING` | Type | Value | | -------- | ------ | | `buff 1` | `0x00` | Burn request pending status. When created, burn requests start with this status. #### `FINALIZED` | Type | Value | | -------- | ------ | | `buff 1` | `0x01` | Burn request finalize status. #### `REVOKED` | Type | Value | | -------- | ------ | | `buff 1` | `0x02` | Burn request revoked status. ## Contract calls * [`xlink-staking`](https://docs.xlink.network/developers/contracts/xlink-staking): Interactions with the Staking Manager are present in the contract's core opertions. It is called during every mint or burn operation to handle the corresponding stake or unstake actions. Additionally, the Staking Manager is essential to perfom the `LiaBTC` rebase by retrieving the value of `aBTC` held by the `liabtc-mint-endpoint` as a staker within the protocol. * [`liabtc-mint-registry`](/developers/contracts/liabtc-mint-registry): The registry is called to manage burn requests and handle funds during the burning/unstaking process. * [`token-liabtc`](/developers/contracts/token-liabtc): This contract is called to perform three essential actions: rebase, mint and burn. * `'SP2XD7417HGPRTREMKF748VNEQPDRR0RMANB7X1NK.token-abtc`: As the underlying token that backs `LiaBTC`, this contract is called for transfers and to specify the token being staked in the Staking Manager. * `'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lisa-dao`: This contract is exclusively called by the [`is-dao-or-extension`](#is-dao-or-extension) function for authorizing governance operations. ## Errors | Error Name | Value | | ---------------------------------- | ------------- | | `err-unauthorised` | `(err u1000)` | | `err-paused` | `(err u7001)` | | `err-request-pending` | `(err u7006)` | | `err-request-finalized-or-revoked` | `(err u7007)` | | `err-not-whitelisted` | `(err u7008)` | # liabtc-mint-registry * Location: `xlink-dao/contracts/liabtc/liabtc-mint-registry.clar` * [Deployed contract](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.liabtc-mint-registry) The `liabtc-mint-registry` is the data and treasury counterpart to the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint) contract. It manages the storage of burn requests data and serves as the `aBTC` treasury during burn operations. Although it is primarly designed to be called by the `liabtc-mint-endpoint`, this registry can function as a general vault accesible to governance roles (LISA DAO or enabled extensions). What actions can this contract do? * Create new burn requests, each tracked using a unique nonce. * Update any field of a burn request, including its status. * Transfer a specified token[^1] from its balance to a designated recipient. The caller specifies the token, recipient and transfer amount. ## Features ### Governance The following functions are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. These features are resticted to the LISA DAO or enabled extensions. #### `set-burn-request` Creates or modifies burn requests in the [`burn-requests`](#burn-requests) map as specified in the `details` parameter. It is called by the functions [`request-burn`](/developers/contracts/liabtc-mint-endpoint#request-burn), [`revoke-burn`](/developers/contracts/liabtc-mint-endpoint#revoke-burn) and [`finalize-burn`](/developers/contracts/liabtc-mint-endpoint#finalize-burn) in the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint) contract. New requests are created by passing `u0` as the `request-id` parameter. On each request creation, the [`burn-request-nonce`](#burn-request-nonce) variable is incremented by one, resulting in the id of the new request. **Parameters** | Name | Type | | ------------ | --------------------------------------------------------------------------------- | | `request-id` | `uint` | | `details` | `{ requested-by: principal, amount: uint, requested-at: uint, status: (buff 1) }` | #### `transfer` Calls the `transfer` function of the `token-trait` passed with `as-contract` privilege. The caller has the ability to send tokens from the registry's balance to a designated `recipient`. **Parameters** | Name | Type | | ------------- | ----------------- | | `amount` | `uint` | | `recipient` | `principal` | | `token-trait` | `` | ### Supporting features #### `is-dao-or-extension` Standard protocol function to check whether the `contract-caller` is an enabled extension within the DAO or the `tx-sender` is the DAO itself (proposal execution scenario). The enabled extension check is delegated to the LISA's `executor-dao` contract. ### Getters #### `get-burn-request-nonce` Returns the [`burn-request-nonce`](#burn-request-nonce) variable. #### `get-burn-request-or-fail` Returns the burn request on the [`burn-requests`](#burn-requests) map at a given key. If there is no entry for the provided `request-id`, throws. #### Parameterss | Name | Type | | ------------ | ------ | | `request-id` | `uint` | ## Storage ### `burn-request-nonce` | Data | Type | | -------- | ------ | | Variable | `uint` | Indicates the `request-id` of the last burn request created. This variable can only monotonically increase. It initialized as `u0`, the key that will always have an empty value. ### `burn-requests` | Data | Type | | ---- | -------------------------------------------------------------------------------------- | | Map | `uint { requested-by: principal, amount: uint, requested-at: uint, status: (buff 1) }` | Map that stores the burn requests, typically used by the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint). ### Relevant constants #### `PENDING` | Type | Value | | -------- | ------ | | `buff 1` | `0x00` | Burn request pending status. When created, burn requests start with this status. #### `FINALIZED` | Type | Value | | -------- | ------ | | `buff 1` | `0x01` | Burn request finalize status. #### `REVOKED` | Type | Value | | -------- | ------ | | `buff 1` | `0x02` | Burn request revoked status. ## Contract calls * ``: Interaction with potentially any contract implementing the [official SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.mdsip-010-fungible-token-standard.md) occurs when the [`transfer`](#transfer) function is called. * `'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lisa-dao`: This contract is exclusively called by the [`is-dao-or-extension`](#is-dao-or-extension) function for authorizing governance operations. ## Errors | Error Name | Value | | ------------------------ | ------------- | | `err-unauthorised` | `(err u1000)` | | `err-unknown-request-id` | `(err u1008)` | [^1]: The token just needs to comply with the [official SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.mdsip-010-fungible-token-standard.md). # token-liabtc * Location: `xlink-dao/contracts/liabtc/token-liabtc.clar` * [Deployed contract](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-liabtc) ## What is LiaBTC? The `LiaBTC` token is a [SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md) compliant rebasing token that represents staked `aBTC`. The underlying Bitcoin backing these `aBTC` tokens is staked externally. This particular staking process uses the [XLink Staking Manager](https://docs.xlink.network/developers/contracts/xlink-staking) contract to track on-chain status and inform staking actions, the [Babylon](https://babylonlabs.io/) Bitcoin staking platform for execution and [Cobo](https://www.cobo.com/) as the finality provider. The lifecycle of the `LiaBTC` token invoves minting when `aBTC` is submitted for staking and burning upon unstaking. When users stake `aBTC` via LISA, they receive `LiaBTC` at a 1:1 ratio. ## Rebase mechanism The rebasing nature of `LiaBTC` is implemented via the "shares" concept. The contract tracks and stores each user's proportional share of an external reserve. By holding shares, users effectively hold a fraction of the total reserve. The reserve's value is tracked by the [`reserve`](#reserve) variable within the contract, which is updated externally, typically by the [`liabtc-mint-endpoint::rebase`](/developers/contracts/liabtc-mint-endpoint#rebase-1) function. The `LiaBTC` balance of a specific user is calculated according to the following equation. $$ \begin{equation} \textrm{User Balance} = \frac{\textrm{User Shares}}{\textrm{Total Shares}} ; \cdot : \textrm{Reserve} \end{equation} $$ Where: * **Reserve** is the current total amount of `aBTC` staked, backed by the `BTC` staked at Babylon and their corresponding staking rewards which were converted to `BTC` and restaked. * **User Shares** represent the user's portion of the total reserve. Every time a user stakes `aBTC`, the equivalent value in shares is calculated and added to the user's shares balance. Shares increase when users deposit `aBTC` and decrease when they redeem. * **Total Shares** is the sum of all shares held by all `LiaBTC` token holders. The above equation can be generalized for an arbitrary amount of shares: $$ \textrm{LiaBTC Tokens} = \frac{\textrm{Shares}}{\textrm{Total Shares}} ; \cdot : \textrm{Reserve}, $$ while the token-to-share conversion can also be deduced by the same equation: $$ \textrm{Shares} = \frac{\textrm{LiaBTC Tokens}}{\textrm{Reserve}} ; \cdot : \textrm{Total Shares}. $$ This is how [`get-shares-to-tokens`](#get-shares-to-tokens) and [`get-tokens-to-shares`](#get-tokens-to-shares) functions work. ## Balances The `LiaBTC` balance of each user, accessible via the [`get-balance`](#get-balance) function, is automatically adjusted on each rebase, without involving an explicit token transfer. In a scenario where the user do not perform any staking movements, their balance will increase over time as staking rewards are reinjected into the staking protocol. On the other hand, the shares balance, which can be obtained through the [`get-share`](#get-share) function, accounts for the portion of the total `aBTC` reserve that belongs to the user. Shares behave like a regular fungible token, meaning that balances can only changes with transfers, mints or burns. Users can freely use `LiaBTC` and its public interface just like any other token. The rebase and share mechanism is transparent from a `LiaBTC` token holder's perspective, with balance adjustments occurring automatically. ## Units Except for some specific cases, all interface functions' input and output amounts are in `LiaBTC` token units. The exceptions are the following functions: * [`get-share`](#get-share): returns an amount in shares. * [`get-shares-to-tokens`](#get-shares-to-tokens): receives shares and returns tokens. * [`get-tokens-to-shares`](#get-tokens-to-shares): receives tokens and returns shares. Both shares and tokens use the same number of decimals, defined by [`token-decimals`](#token-decimals). ## Features ### Public #### `transfer` Transfers `LiaBTC` from the `sender` to the `recipient`. For authorization, the specified `sender` must either be the `tx-sender` or the `contract-caller`. Uses the [`ft-transfer?`](https://docs.stacks.co/reference/functions#ft-transfer) Clarity function, where the actual transferred assets are shares. **Parameters** | Name | Type | | ----------- | ---------------------- | | `amount` | `uint` | | `sender` | `principal` | | `recipient` | `principal` | | `memo` | `optional (buff 2048)` | ### Token management The following functions are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. These features are resticted to the LISA DAO or enabled extensions. #### `set-reserve` Updates the [`reserve`](#reserve) variable. It is primarly called by the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint) contract. **Parameters** | Name | Type | | ------------- | ------ | | `new-reserve` | `uint` | #### `add-reserve` Increments the reserve. **Parameters** | Name | Type | | ----------- | ------ | | `increment` | `uint` | #### `remove-reserve` Decrements the reserve. **Parameters** | Name | Type | | ----------- | ------ | | `decrement` | `uint` | #### `dao-mint` Mints `LiaBTC`. This function uses the [`ft-mint?`](https://docs.stacks.co/reference/functions#ft-mint) Clarity native function. The actual minted amount is first converted to shares before minting given the rebasing nature of `LiaBTC`. It is primarly called by the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint) contract. **Parameters** | Name | Type | | ----------- | ----------- | | `amount` | `uint` | | `recipient` | `principal` | #### `dao-burn` Burns `LiaBTC`. This function uses the [`ft-burn?`](https://docs.stacks.co/reference/functions#ft-burn) Clarity native function. The actual burned amount is first converted to shares before burning given the rebasing nature of `LiaBTC`. It is primarly called by the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint) contract. **Parameters** | Name | Type | | -------- | ----------- | | `amount` | `uint` | | `sender` | `principal` | #### `burn-many` Performs bulk burning of `LiaBTC`. **Parameters** | Name | Type | | --------- | ---------------------------------------------- | | `senders` | `list 200 { amount: uint, sender: principal }` | ### Token governance The following functions are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. These features are resticted to the LISA DAO or enabled extensions. #### `dao-set-name` Updates the [`token-name`](#token-name) variable. **Parameters** | Name | Type | | ---------- | ----------------- | | `new-name` | `string-ascii 32` | #### `dao-set-symbol` Updates the [`token-symbol`](#token-symbol) variable. **Parameters** | Name | Type | | ------------ | ----------------- | | `new-symbol` | `string-ascii 10` | #### `dao-set-decimals` Updates the [`token-decimals`](#token-decimals) variable. **Parameters** | Name | Type | | -------------- | ------ | | `new-decimals` | `uint` | #### `dao-set-token-uri` Updates the [`token-uri`](#token-uri) variable. **Parameters** | Name | Type | | --------- | ----------------- | | `new-uri` | `string-utf8 256` | ### Supporting features #### `is-dao-or-extension` Standard protocol function to check whether the `contract-caller` is an enabled extension within the DAO or the `tx-sender` is the DAO itself (proposal execution scenario). The enabled extension check is delegated to the LISA's `executor-dao` contract. #### `get-tokens-to-shares` Converts a specified `LiaBTC` `amount` into its equivalent shares representation. **Parameters** | Name | Type | | -------- | ------ | | `amount` | `uint` | #### `get-shares-to-tokens` Converts a specified amount of `shares` into its equivalent value in `LiaBTC` tokens. **Parameters** | Name | Type | | -------- | ------ | | `shares` | `uint` | ### Getters #### `get-balance` Returns the `LiaBTC` balance of a specified principal (`who`). The balance is calculated by retrieving the user's shares and converting them into their equivalent value in tokens. This conversion depends on the current share supply and the total value of the reserve. **Parameters** | Name | Type | | ----- | ----------- | | `who` | `principal` | #### `get-total-supply` Returns the total supply of `LiaBTC`, which is the [`reserve`](#reserve). #### `get-share` Returns the amount of shares held by a specified principal (`who`). This function uses the [`ft-get-balance`](https://docs.stacks.co/reference/functions#ft-get-balance) Clarity function. **Parameters** | Name | Type | | ----- | ----------- | | `who` | `principal` | #### `get-total-shares` Returns the total supply of shares, which is the value returned by the [`ft-get-supply`](https://docs.stacks.co/reference/functions#ft-get-supply) Clarity function. #### `get-reserve` Returns the [`reserve`](#reserve) variable. #### `get-name` Returns the [`token-name`](#token-name) variable. #### `get-symbol` Returns the [`token-symbol`](#token-symbol) variable. #### `get-token-uri` Returns the [`token-uri`](#token-uri) variable. #### `get-decimals` Returns the [`token-decimals`](#token-decimals) variable. ## Storage ### `reserve` | Data | Type | | -------- | ------ | | Variable | `uint` | Tracks the reserve of `LiaBTC`. It represents the current total value of `aBTC` staked through the [`liabtc-mint-endpoint`](/developers/contracts/liabtc-mint-endpoint), including the restaked rewards. ### `token-name` | Data | Type | | -------- | ----------------- | | Variable | `string-ascii 32` | Intial value is `"LiaBTC"`. ### `token-symbol` | Data | Type | | -------- | ----------------- | | Variable | `string-ascii 10` | Intial value is `"LiaBTC"`. ### `token-uri` | Data | Type | | -------- | ---------------------------- | | Variable | `optional (string-utf8 256)` | Initial value is `some u"https://cdn.alexlab.co/metadata/token-liabtc.json"`. ### `token-decimals` | Data | Type | | -------- | ------ | | Variable | `uint` | Initial value is `u8`. ## Contract calls * `'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lisa-dao`: This contract is exclusively called by the [`is-dao-or-extension`](#is-dao-or-extension) function for authorizing governance operations. ## Errors | Error Name | Value | | -------------------- | ------------- | | `err-unauthorised` | `(err u3000)` | | `err-invalid-amount` | `(err u3001)` | # token-vliabtc * Location: `xlink-dao/contracts/liabtc/token-vliabtc.clar` * [Deployed contract](https://explorer.stxer.xyz/txid/SP673Z4BPB4R73359K9HE55F2X91V5BJTN5SXZ5T.token-vliabtc) ## What is vLiaBTC? The `vLiaBTC` token is a [SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md) compliant value-accruing token, designed as a non-rebasing wrapper for `LiaBTC`. This token is mainly used as a layer of compatibility to integrate `LiaBTC` with other DeFi protocols[^1] since the total supply and wallet balances remain constant over time. However, its value in terms of `LiaBTC` does change over time. Users can wrap their `LiaBTC` into `vLiaBTC` to maintain the same value in a non-rebasing format. Upon unwrapping, users receive the same amount of `LiaBTC` tokens as they would have if they had held the liquid token (`LiaBTC`) throughout. ## How it works? The `token-vliabtc` contract can be used as a trustless wrapper that accepts `LiaBTC` tokens and mints `vLiaBTC` in return. The contract locks the wrapped `LiaBTC` in its own balance. When the user unwraps, the contract burns the user's `vLiaBTC` and sends the corresponding `LiaBTC` in return. Internally, the `vLiaBTC` balance represents the user's share of the total `LiaBTC` held by the `token-vliabtc` contract (vaulted `LiaBTC`). This means that for a general user that holds `vLiaBTC`, the value in `LiaBTC` is given by the following equation: $$ \textrm{LiaBTC value} = \frac{\textrm{vLiaBTC Balance}}{\textrm{vLiaBTC Total Supply}} ; \cdot ; \textrm{Vaulted LiaBTC} $$ Unlike some other DeFi protocols, the amount of `vLiaBTC` minted when wrapping does not directly correspond to the `LiaBTC` shares exchanged. However, both approaches are equivalent and achieve the same functional outcome. For a detailed explanation of this equivalence, see the [Appendix](#appendix). ## Features ### Public #### `transfer` Transfers `LiaBTC` from the `sender` to the `recipient`. For authorization, the specified `sender` must either be the `tx-sender` or the `contract-caller`. Uses the [`ft-transfer?`](https://docs.stacks.co/reference/functions#ft-transfer) Clarity function, where the actual transferred assets are shares. **Parameters** | Name | Type | | ----------- | ---------------------- | | `amount` | `uint` | | `sender` | `principal` | | `recipient` | `principal` | | `memo` | `optional (buff 2048)` | ### Token management The following functions are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. These features are resticted to the LISA DAO or enabled extensions. #### `mint` Mints `vLiaBTC` for the specified `recipient`. The `recipient` must be either the `tx-sender` or the `contract-caller`. The amount of `vLiaBTC` minted is calculated by applying [`get-tokens-to-share`](#get-tokens-to-shares) to the provided `amount` before transferring the `LiaBTC` from the user to the contract. **Parameters** | Name | Type | | ----------- | ----------- | | `amount` | `uint` | | `recipient` | `principal` | #### `burn` Burns `vLiaBTC` for the specified `sender`. The `sender` must be either the `tx-sender` or the `contract-caller`. The amount of `LiaBTC` to be transferred back to the user is calculated via the `get-shares-to-tokens` function before performing the burn. **Parameters** | Name | Type | | -------- | ----------- | | `amount` | `uint` | | `sender` | `principal` | ### Token governance The following functions are guarded by the [`is-dao-or-extension`](#is-dao-or-extension) function. These features are resticted to the LISA DAO or enabled extensions. #### `set-name` Updates the [`token-name`](#token-name) variable. **Parameters** | Name | Type | | ---------- | ----------------- | | `new-name` | `string-ascii 32` | #### `set-symbol` Updates the [`token-symbol`](#token-symbol) variable. **Parameters** | Name | Type | | ------------ | ----------------- | | `new-symbol` | `string-ascii 10` | #### `set-decimals` Updates the [`token-decimals`](#token-decimals) variable. **Parameters** | Name | Type | | -------------- | ------ | | `new-decimals` | `uint` | #### `set-token-uri` Updates the [`token-uri`](#token-uri) variable. **Parameters** | Name | Type | | --------- | ----------------- | | `new-uri` | `string-utf8 256` | ### Supporting features #### `is-dao-or-extension` Standard protocol function to check whether the `contract-caller` is an enabled extension within the DAO or the `tx-sender` is the DAO itself (proposal execution scenario). The enabled extension check is delegated to the LISA's `executor-dao` contract. #### `get-tokens-to-shares` Converts a specified `LiaBTC` `amount` into its equivalent value in `vLiaBTC`. The term shares is utilized because `vLiaBTC` amounts represent a share of the total vaulted `LiaBTC`. **Parameters** | Name | Type | | -------- | ------ | | `amount` | `uint` | #### `get-shares-to-tokens` Converts a specified amount of `vLiaBTC` (referred to as the `shares` parameter) into its equivalent value in `LiaBTC`. This function is called within the [`burn`](#burn) function to determine the amount of `LiaBTC` to transfer to the user. The term shares is utilized because `vLiaBTC` amounts represent a share of the total vaulted `LiaBTC`. **Parameters** | Name | Type | | -------- | ------ | | `shares` | `uint` | ### Getters #### `get-balance` Returns the `vLiaBTC` balance of a specified principal (`who`) using the [`ft-get-balance`](https://docs.stacks.co/reference/functions#ft-get-balance) Clarity function. **Parameters** | Name | Type | | ----- | ----------- | | `who` | `principal` | #### `get-total-supply` Returns the total supply of `vLiaBTC` using the [`ft-get-supply`](https://docs.stacks.co/reference/functions#ft-get-supply) Clarity function. #### `get-share` Returns the value in `LiaBTC` of a user's total balance of `vLiaBTC`. It is calculated by retrieveing the `LiaBTC` amount and converting it to tokens with the [`get-shares-to-tokens`](#get-shares-to-tokens). **Parameters** | Name | Type | | ----- | ----------- | | `who` | `principal` | #### `get-total-shares` Returns the vaulted `LiaBTC` balance. This is the `LiaBTC` held by the `token-vliabtc` contract, which are the tokens from the users that currently hold the wrapped token. #### `get-name` Returns the [`token-name`](#token-name) variable. #### `get-symbol` Returns the [`token-symbol`](#token-symbol) variable. #### `get-token-uri` Returns the [`token-uri`](#token-uri) variable. #### `get-decimals` Returns the [`token-decimals`](#token-decimals) variable. ## Storage ### `token-name` | Data | Type | | -------- | ----------------- | | Variable | `string-ascii 32` | Intial value is `"vLiaBTC"`. ### `token-symbol` | Data | Type | | -------- | ----------------- | | Variable | `string-ascii 10` | Intial value is `"vLiaBTC"`. ### `token-uri` | Data | Type | | -------- | ---------------------------- | | Variable | `optional (string-utf8 256)` | Initial value is `some u"https://cdn.alexlab.co/metadata/vtoken-liabtc.json"`. ### `token-decimals` | Data | Type | | -------- | ------ | | Variable | `uint` | Initial value is `u8`. ## Contract calls * [`token-liabtc`](/developers/contracts/token-liabtc): Core external calls are made to perform `LiaBTC` transfers when wrapping/unwrapping and to retrieve the balance of `LiaBTC` held by the `token-vliabtc` contract (vaulted `LiaBTC`). * `'SM26NBC8SFHNW4P1Y4DFH27974P56WN86C92HPEHH.lisa-dao`: This contract is exclusively called by the [`is-dao-or-extension`](#is-dao-or-extension) function for authorizing governance operations. ## Errors | Error Name | Value | | ------------------ | ------------- | | `err-unauthorised` | `(err u3000)` | ## Appendix The amount of `vLiaBTC` minted during wrapping does not directly correspond to the `LiaBTC` shares exchanged. In some other DeFi protocols, these two values are exactly the same. Why are these different approaches to wrapping equivalent? To understand this, let's revisit the equation from the [How it works?](#how-it-works) section, pasted down here to facilitate the explanation: $$ \begin{equation} \textrm{LiaBTC value} = \frac{\textrm{vLiaBTC Balance}}{\textrm{vLiaBTC Total Supply}} ; \cdot ; \textrm{Vaulted LiaBTC}. \end{equation} $$ This equation shows the **LiaBTC value** for a general user holding a specific **vLiaBTC Balance**. Now, consider the relationship between `LiaBTC` shares and tokens, given by [equation (1)](/developers/contracts/token-liabtc#rebase-mechanism) of the `token-liabtc` document. Using that equation, the **Vaulted LiaBTC** can be expressed as: $$ \textrm{Vaulted LiaBTC} = \frac{\textrm{Vaulted Shares}}{\textrm{Total Shares}} ; \cdot : \textrm{Reserve}, $$ where the **Vaulted Shares** are the `LiaBTC` shares representation of the vaulted `LiaBTC`. Similarly, we can think of the **LiaBTC value** expressed as a fraction of the **Reserve** using a hypothetical shares term: $$ \textrm{LiaBTC value} = \frac{\textrm{Shares}\_h}{\textrm{Total Shares}} ; \cdot : \textrm{Reserve}. $$ Assuming the **LiaBTC value** remain unchanged since the user wrapped their tokens, the hypothetical shares *are* the shares representation of the `LiaBTC` amount that the user wrapped. So, from now on, we will refer them as **User Shares**, the `LiaBTC` shares that the user exchanged during the wrap operation. Replacing the expressions for **Vaulted LiaBTC** and **LiaBTC value** into equation (1) and cancelling the **Reserve** factor from both sides, we get: $$ \frac{\textrm{User Shares}}{\textrm{Total Shares}} = \frac{\textrm{vLiaBTC Balance}}{\textrm{vLiaBTC Total Supply}} ; \cdot ; \frac{\textrm{Vaulted Shares}}{\textrm{Total Shares}}. $$ After cancelling **Total Shares** on both sides, we obtain $$ \begin{equation} \textrm{User Shares} = \frac{\textrm{vLiaBTC Balance}}{\textrm{vLiaBTC Total Supply}} ; \cdot ; \textrm{Vaulted Shares} \end{equation} $$ as the general equation that relates the `LiaBTC` shares (representing the `LiaBTC` amount that the user initially wrapped) and the corresponding `vLiaBTC` balance. In many DeFi protocols, the amount of wrapped tokens minted equals the rebasing token's shares exchanged. In such cases, the **Vaulted Shares** equal the total circulating supply of the wrapped token (**vLiaBTC Total Supply**), simplifying the equation to: $$ \textrm{User Shares} = \textrm{vLiaBTC Balance}. $$ This scenario is a specific case of equation (2), showing that both approaches are functionally equivalent. [^1]: Note that [`get-balance`](#get-balance) and [`get-total-supply`](#get-total-supply) functions are implemented like standard Clarity fungible tokens.