Congrats to the winners of the Best Use of Meteora DBC track at @solana's STOCKLANA hackathon. Builders used Meteora's Dynamic Bonding Curve to experiment with tokenized stocks. Projects were judged on work shipped during the hackathon, 11 to 25 September. First prize: $2,000 🥇 @BubbleStocksSol by @unchartedTTy Second prize: $1,500 🥈 @gabox_fun by @Amir0X1 Third prize: $500 each 🥉 juno-app-chi.vercel.app 🥉 @plintoxyz by @_0xrk 🥉 usecontinuity.xyz @DefiPreacherr Honorable Mention: $300 each 🏆 equinox.ansht.workers.dev by @soltyagi 🏆 teserra.world Prizes are paid once projects deploy on mainnet. Thanks to everyone who entered and shipped with @MeteoraAG. Meet the winners below 👇

Legacy DAMM v1 Update (Release 0.5.6) We’ve completed an improvement to the legacy DAMM v1 pool accounting design, following a collaborative review with security firms and independent white-hat researchers. This update strengthens how LP (liquidity provider) ownership is tracked on DAMM v1 and reinforces an important best practice: users are encouraged to always use the official Meteora product features and documentation when managing your positions. What we learned During recent protocol monitoring efforts, security researchers identified a design limitation related to legacy DAMM v1 pools in edge cases where the LP tokens were transferred to the System Program (11111111111111111111111111111111) or Incinerator address (1nc1nerator11111111111111111111111111111111) by the position owner, without using Meteora’s UI. To do so, the position owner would have had to independently transfer tokens to the System Program or Incinerator address, thereby giving up full control over their position. This was likely an attempt to lock their liquidity permanently. However, these transfers do not provide the same functionality and safeguards as Meteora’s official permanent LP Lock feature on the UI, which utilizes a lock escrow account mechanism. Under Solana’s SPL token program rules, tokens held in accounts owned by or associated with the System Program or Incinerator address may still be burnable by anyone to reclaim rent etc. In the original DAMM v1 design, LP ownership was calculated using the total LP token supply. This means burning LP tokens in the System Program or Incinerator address will shrink lp_mint.supply and inflate the share or ownership ratio of the remaining LP tokens in the pool. Recent Case Review The review found that a third party wallet made use of this design behaviour in seven legacy DAMM v1 pools that had low amounts of liquidity from eight LPs. Apart from SOL, these pools contained unverified and illiquid tokens that had multiple safety warnings and an organic score of 0. By first depositing assets to these pools, then burning the LP tokens previously sent to the System Program or Incinerator address, the wallet increased its own share of liquidity in these pools to approximately $12,644 worth of assets. Once notified, our team temporarily paused all DAMM v1 pools while collaborating with the security firms and researchers to review and improve the pool accounting design. This is completed, so apart from the seven pools that will continue to be disabled for deposits and swaps, DAMM v1 pools are now operating as usual. This case highlights why transferring tokens to a System Program or Incinerator address on Solana should not be treated as equivalent to using a protocol’s dedicated locking mechanism. Note: This only involved legacy DAMM v1 pools and no pools from other Meteora programs. DAMM v1 was also phased out of the main Meteora UI earlier this year and in the process of being fully deprecated. Improving the DAMM v1 design Although the plan is for DAMM v1 to be eventually deprecated, we’ve updated the pool LP accounting design with two key improvements for existing users and integrators. 1. Pool-level LP supply tracking Each DAMM v1 pool now tracks and maintains its own record of total LP supply, pricing LP shares with pool.lp_mint_supply. This record changes only when the program itself mints or burns LP tokens as part of pool deposits and withdrawals. LP ownership is calculated using this pool-maintained record, so burning LP tokens outside the pool and program no longer changes the ownership share of other LP holders. Previously: LP ownership share = LP tokens held ÷ total LP token supply Now: LP ownership share = LP tokens held ÷ total LP supply recorded by the pool 2. LP owner signature required for withdrawals Withdrawals now also require an on-chain signature from the owner of the LP tokens, and removing liquidity through a delegate is not possible. This provides an additional ownership verification step to further protect users. A simple example: Consider a DAMM v1 pool with $100 in liquidity and 100 LP tokens. If 90 LP tokens are transferred to the System Program, and a subsequent depositor adds $100 and receives 100 LP tokens, under the original design, burning those 90 transferred LP tokens could increase the depositor’s calculated share to approximately $181.82. With the updated design, the pool continues to record a total supply of 200 LP tokens, even if those 90 LP tokens are burned externally. The depositor’s 100 LP tokens therefore continue to represent 50% of the pool, worth $100 based on the example’s $200 liquidity balance. The result: external token burns no longer alter LP ownership calculations. Key takeaway for users When interacting with Meteora or other DeFi protocols, users are encouraged to always use the official product UI, documentation, and its intended features for actions such as locking LP tokens, managing positions, and withdrawing liquidity, because dedicated product features are designed to apply important safeguards. Next steps For integrators, you can follow the instructions in Release 0.5.6 (t.me/meteora_dev/164) If you believe you are an LP or token holder from any of the seven disabled DAMM v1 pools mentioned earlier, please open a ticket in the Meteora Discord. Our team will provide further guidance and assistance wherever possible. We sincerely appreciate the efforts of @SIRN_org, @blockaid_, @asymmetric_re, @zeroshadow_io and all the other independent researchers who helped us identify this case and enhance the DAMM v1 design. The seven disabled DAMM v1 pools can be found below.