V2 is almost ready. Development took a while, and we’re doing the final checks now. If everything looks good, we’ll roll it out.

Same price for everyone during the sale. No bonding curve.We’re testing this as a new launch option. Would you launch a token this way?

If you’ve launched a token on alkanes.fun and have a real community behind it, DM me to get a verification badge.

I think we should add voting for MAGA holders so the community can help decide which features we ship next🙌

As promised, we’ve permanently renounced our ability to pause trading in our existing pools. All platform credential units are now sealed in the Trustee. Fee collection remains available for buybacks, without giving us control over trading. Code, transactions, and verification instructions：github.com/alkanes-fun/contr… Don’t trust, verify.

The official Alkanes.fun Telegram group is now open. Join us for project updates, community discussions, and feedback:t.me/Alkanesfungroup

All reported issues with buying through OKX Wallet have been fixed. I’m now putting my full focus into V2, with more launch options coming soon. We’re also talking with Gabe about integrating Subfrost AMM. I don’t think it’ll be a long wait. I love Alkanes and want more people to discover it. #BTC #Alkanes

Our first MAGA burn is complete: 1.11% of the supply has been burned. More flexible token launches are now live. Creators can choose a graduation target of just 0.1 BTC.The default funding window is 24 hours. After that, anyone can manually trigger graduation, even if the funding target hasn’t been reached. We’re also working on support for other pool assets, including FIRE and DIESEL.

Looks like it’s time to have a proper discussion about PSBT. We published the source for our core contracts almost as soon as we announced the project. Making our implementation available for independent scrutiny was part of our approach from the beginning. For everyone following the discussion, our position is straightforward: Transparency: We published our core contract source early and provide tools to verify it against the deployed contracts. Transactions: Both buyers and sellers can inspect what they authorize through the PSBT, wallet signing flow, front-end logic, and relevant asset state. Identity: A public identity can add accountability. Verifiable code establishes what the system actually allows. Consistency: The community should expect comparable transparency from every platform handling users’ assets. We welcome specific technical scrutiny. A fair assessment should recognize the evidence already available, identify the remaining trust assumptions, and apply the same standard across projects. One concern raised in the community is that PSBT marketplaces are not open source “because they live offchain.” Being off-chain does not prevent software from being open source. It describes where a component operates; it does not determine whether its implementation can be published. Our complete PSBT marketplace backend has not yet been publicly released. For other well-known Alkanes marketplaces, including UniSat and iDclub, we have likewise not located publicly available source for their complete production marketplace backends. Wallet code, SDKs, API documentation, and marketplace backends are separate components. A fair comparison needs to examine the same component across platforms. That context does not remove our responsibility to improve transparency. It does mean the discussion should distinguish an unpublished backend from an unverifiable transaction. The transaction presented for signing can still be inspected. Using UniSat’s signing window, the actual PSBT, our front-end transaction logic, and the relevant Alkanes asset state, users and independent reviewers can examine what is being authorized: When selling: Which asset UTXO is being offered, the payment amount, and the receiving address. In our implementation, the seller’s listing signature binds the asset input to a specified payment output. When buying: Which assets are being acquired, where the transfer instructions direct them, how much BTC is being paid, and the transaction’s fees. The buyer signs the settlement transaction, including its outputs and asset-transfer instructions. These are concrete transaction details and signature commitments, available for inspection before authorization. UniSat itself instructs users to review transaction inputs and outputs before signing. UniSat’s transaction-review guidance A wallet window alone is not a complete audit of an Alkanes transaction. Asset state and signature scope matter, and signing a listing does not mean it has already settled. Those distinctions are why the discussion should focus on what users authorize and what the system enforces. Remaining backend dependencies are legitimate subjects for scrutiny. Identifying a specific dependency and its consequences allows the community to evaluate the actual risk. We also intend to publish our UTXO/PSBT marketplace infrastructure. We are considering AO on Arweave for decentralized order-book and coordination services, while keeping settlement on Bitcoin. These are future plans, distinct from the verification users can perform today. Another concern raised in the discussion is whether a team handling significant financial activity should publicly disclose its identity. We understand why people value accountability. But a public identity does not change a contract’s permissions. Knowing someone’s legal name does not disable an administrator key. A public profile does not prevent a contract upgrade. A recognizable face does not enforce a withdrawal restriction. Those protections must exist in the implementation. That is why we place greater weight on verifiable code and enforceable constraints when evaluating technical security. Our Registry, Launch, and Pool contract source is public. We also provide reproducible build instructions and verification tools that allow reviewers to compare the resulting bytecode with the contracts deployed on Bitcoin. Our contract source and verification tools Anyone can inspect the implementation, examine its permissions, and check that correspondence. We made the core source available almost immediately when the project was announced. That timing matters. Independent verification was part of how we introduced the project. This early disclosure should be part of any fair assessment of our transparency and the trust our system requires. Our security argument rests on what the deployed implementation permits and prevents. If a power exists, reviewers should be able to identify it. If a restriction exists, reviewers should be able to verify how it is enforced. That is what these principles mean to us: Don’t trust, verify. Give people the information and tools to check the claims independently. Code is law. Examine the rules and permissions that the deployed implementation actually enforces. Publishing source does not automatically prove that every part of a system is safe. It makes meaningful scrutiny possible. Matching that source to deployed code makes the scrutiny relevant to the system users actually interact with. We welcome anyone identifying a concrete issue in our permissions, transaction construction, or remaining backend dependencies. Those concerns deserve technical answers. At the same time, an assessment based on anonymity should account for the technical evidence already available. Identity and reputation cannot establish the same facts as inspecting the implementation and verifying its deployment. These standards should apply consistently across the Alkanes ecosystem. As one relevant comparison, pizza.fun’s CHEESE/SLICE system already accepts users’ staked assets. The corresponding transparency questions concern the implementation governing those deposits, withdrawals, rewards, redemptions, and upgrades. In our review, we identified these core deployed implementations: CheeseVault · CheeseTreasury · CheeseAdmin · CheeseInvites We have not located their public implementation source together with reproducible instructions for matching that source to those deployments. If those materials are available, links would help the community verify them. Pizza.fun’s documentation describes a root key that controls upgrades to the vault, treasury, admin, and referral contracts. It also describes a pre-TGE emergency power to withdraw staked liquidity, intended for a DAO decision to leave the Alkanes ecosystem. Official CHEESE documentation Those are material permissions. The community should be able to inspect the implementation and verify their limits. Relevant questions include how the stated DAO decision is enforced, what conditions govern the emergency withdrawal, and what an upgrade can change. Public implementation source and deployment-verification instructions would allow independent reviewers to examine those questions. For Curvestack, the documentation says that the exact mechanisms and full documentation are reserved for the platform’s launch. We have not located a complete public implementation that would allow independent examination of the full system. Official Curvestack description An indexer, a mathematical curve library, or a generic token template does not by itself establish how the complete system handles users’ assets. The relevant evidence is the implementation governing those assets and the powers exercised over them. The more assets a system handles, and the more authority its administrators retain, the stronger the case for making that implementation publicly verifiable. That principle applies to pizza.fun, to our project, and to every other platform in the ecosystem. The purpose of this comparison is to establish a consistent standard. Our responsibility to improve transparency remains, regardless of what any other project publishes. The same responsibility applies elsewhere. We published our core contract source almost as soon as we announced the project. We provide a path to verify it against deployed code. We explain what users can inspect in their PSBTs and acknowledge the infrastructure we still intend to publish. The community should expect that same level of specificity when evaluating any project: what is public, what is deployed, what users authorize, and what powers remain with the operators. Scrutiny is healthy. It becomes more useful when it is specific, evidence-based, and consistent. Don’t trust, verify. Code is law. Those principles apply to every project—including ours.

Token images and descriptions now display properly. You can also add a custom image when creating a token.

The issue preventing buys on mobile is fixed. If you’re still having trouble buying, please send me a screenshot of the error.

alkanes.fun is back online. alkanes.trade will remain available too. Thanks to @gabe_subfrost and @Huaguibtc for their help with the domain issue. I was pleasantly surprised that you took the time to help an independent project like ours. Let’s Make Alkanes Great Again.

The long wait when buying with an OKX wallet has been fixed.

MAGA buys with frBTC are live. Check “Use frBTC first” and the site will automatically check your wallet’s UTXOs. If your frBTC balance doesn’t cover the buy, it’ll use BTC for the rest. You can use frBTC and BTC together, so there’s no need to make two separate purchases. If trading runs smoothly, we’ll renounce our trading pause permissions in the next update.

A lot of you have reported spending BTC but not receiving MAGA. These buys failed because the slippage tolerance was too low, and the funds were returned as frBTC. Some wallets don’t display Alkanes assets, so you may not see the returned frBTC. You can now connect your wallet on our site and check your frBTC balance in the top-right corner. We’re still working on the buyback plan. We want every trade to include an automatic burn, and we’re already testing that mechanism. Once it passes testing, we’ll add the buyback and burn plan to our roadmap.

I’ve seen the FUD around our launchpad, especially over the ability to pause trading. Let me clear that up. The pause function is an emergency measure intended only for extreme situations where users’ funds could be at risk. It’s there to help protect those funds while we address the issue, not for my personal benefit. It’s fair to question that permission. The code is open source. Check the repo, and let’s talk specifics. From what I’ve seen, much of this FUD seems to come from the same circle of people with shared interests. I don’t have time for drama. We’ve got plenty of site updates to ship today. I just want to Make Alkanes Great Again. #Alkanes #Bitcoin

MAGA has graduated. AMM trading is now live. The chart needs a little more time to catch up, but you can already trade. We’ll add our buyback and burn plans to the roadmap in a future update.

Platform token MAGA is live. Launch: app.alkanes.trade/token/2:98… During the curve phase, buys are capped at 0.05 BTC per transaction. At 1 BTC raised, liquidity is added and pool trading opens automatically. Our contracts are now open source:github.com/alkanes-fun/contr…

Since alkanes.fun was registered, our website has faced repeated attacks. The domain was locked on September 27, and we are appealing the decision. Until access is restored, please use alkanes.trade as our temporary website.

MAGA feels like the right ticker. MAGA = Make Alkanes Great Again. We see all the “wen” replies. We have put a lot into this launchpad, so we are waiting for the audit to finish. We want to get this launch right. #Alkanes #Bitcoin