An important update on Solflare Card. Our card issuing partner Kulipa is winding down due to solvency issues and can no longer support Solflare Card, so cards stopped working abruptly today. If your card declined on you at a checkout today, I'm sorry, that's a lousy way to find out. I know many of you spend with this card every day. One thing matters above everything else: your funds are safe and there's nothing you need to do. Solflare Card was built the hard way, on purpose. It's self-custodial end to end, so there's no deposit, no top up, and no balance parked with the card provider. The card spends straight from your wallet at the moment of purchase. Not one cent of user money was ever held by them. With a typical card program the issuer holds your balance, and when that issuer fails your money gets frozen behind a bankruptcy estate while you wait in line as a creditor for your own funds. On Solflare you open your wallet and your USDC is sitting exactly where it always was. You can move it or spend it right now, same as any other day. This is how we handle every integration we ship, not only the card. We assume any third party API can fail tomorrow, then build the observability and safeguards so that when one does, user funds are never on the line. Our partners know how high that bar is; sometimes we're a pain in the ass about it. It's also the reason your money is untouched today. Some of you will ask why we picked Kulipa in the first place. Fair. Our requirement was the best possible user experience: native look and feel, with your funds staying self-custodial the whole way through. Back then the standard offer was an iframe on top of a deposit account, your money handed to someone else, and we refused that. Kulipa was the underdog willing and able to build the truly self-custodial stack with us, so we bet on them. We pushed hard to keep the program alive: we tried to help find Kulipa an appropriate buyer, we looked at every option for continuity, and throughout that process we were reassured the program would carry on. It didn't. The debt was too deep and the company essentially collapsed. We would have liked to give you far more notice, but the final stop caught us off guard too. Now the part I've actually been excited about. The issuing ecosystem has matured a lot since that first bet, and the next version of Solflare Card has been in the works for a while, built on infrastructure ready for where Solflare is today. The plan was to keep it quiet and announce it properly once it was ready. With cards stopping today, there's no reason to keep it quiet anymore. The new program has all of your feedback incorporated: Apple Pay and Google Pay from day one, higher limits, cashback, and the rest of what you've asked us for. Self-custodial, obviously, working with the same accounts you already have in your Solflare wallet. It's a serious upgrade for every current cardholder and for everyone who's been waiting to get one, and it lands in a few weeks. Self-custody was built for exactly this. The card is paused, not gone. More details soon. HOLD STRONG

we refactored our push notification system to make it the fastest on the market. tested it before pushing to prod, only to realize it's so fast that if you have a few wallets installed, ours lands first and then gets buried by every slower wallet's notification on top of it. strongest engineering proposal so far: sleep() chat, what should we do?

SOLFLARE GUARDS Did you know that what you see in a transaction simulation is not the guaranteed outcome of that transaction? It's something that happens every day and almost nobody talks about it. A simulation is a snapshot. It shows what your transaction would do against the state of the chain at that exact moment. But Solana produces a new block roughly every 400 milliseconds, and a lot can change between the moment you sign and the moment your transaction actually lands. A simple example of how this gets abused: a malicious dapp asks you to sign a transaction with a program that reads a number stored in an account the attacker controls, then transfers that amount out of your wallet. When you sign, that account holds 10, so the simulation shows -10 USDC. Looks harmless. The moment you approve, the attacker changes the number to 1,000. Your transaction lands, the program reads 1,000, and 1,000 leaves your wallet. The simulation didn't lie. The state changed underneath it. This is what Solflare Guards were built for. Every transaction you sign goes through three steps: 1. Simulate: we run the transaction and record the outcome you approved, balance changes and other significant state 2. Guard: we append assertion instructions to the transaction itself, on-chain checks like "this wallet's balance cannot decrease by more than 10 USDC" 3. Relay: we send the guarded transaction to the network If reality no longer matches what you approved, the assertions fail and the whole transaction fails with them. Nothing leaves your wallet. Keep safe.