Khánh Trang1510

A buyer once sent me more than the agreed amount on a Binance P2P trade and asked me to refund the difference directly to a different bank account than the one the payment came from. It looked like an honest mistake at first. It was not.

This is a known pattern worth naming clearly since it catches experienced traders too, not just beginners. The overpayment itself is designed to create urgency and confusion, hoping the seller refunds the extra amount quickly before realizing the original payment might get reversed or disputed afterward, leaving the seller having sent both crypto and a cash refund for one payment that never actually settles. Binance P2P protects sellers here through its escrow system, which holds the crypto asset separately from any side conversation about refunds, and through the requirement that everything related to the trade stays inside the platform and its official channels. The moment someone asks for a refund to a different account than the original sender, that is a clear break from normal trade behavior and a red flag worth stopping on immediately.

My rule since that trade is straightforward. I never refund anything outside the original order. If a payment amount looks wrong, I do not act on my own judgment, I cancel or contact Binance support and let them review the discrepancy before I touch the crypto asset at all. I always confirm the sender name on any payment matches the verified counterparty on the order, since a mismatched name is its own warning sign. I keep a screenshot of the exact amount received in my own account, not the amount claimed in chat. Any request to move money outside the platform, refund or otherwise, gets reported rather than quietly completed.

Trusting the process over trusting a stranger's story has never once cost me anything.

@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI

Three letters saved me from a bad trade. The buyer's verified name on Binance P2P read Nguyen Van Minh, and the transfer that landed in my account came from an account labeled Nguyen Van Anh. Close enough to miss if you are skimming, different enough to matter completely.

Binance P2P ties every account to a verified identity through KYC, and that identity is supposed to match the payment account used during a trade. When I confirm payment now, I do not just check the amount. I check the sender name character by character against the name shown on the buyer's verified profile. This single habit exists because escrow only protects you if you actually use the information it gives you access to.

I paused the trade and asked about the mismatch directly in the official Binance P2P chat, which keeps a full record in case the situation needed escalating later. His explanation involved a family member's account, which happens sometimes, but Binance P2P's own transaction rules treat third party payments and name mismatches as violations regardless of the reason behind them. I did not release the crypto. I opened an appeal instead, explained the discrepancy clearly, and attached both the payment record and the profile screenshot showing the name difference.

Support reviewed it and the order was unwound, with the buyer's payment refunded rather than the trade completing. No loss on my end, and no funds released against a payment I could not fully verify.

I understand now why Binance P2P enforces this rule so strictly instead of leaving it as a suggestion. Third party payments make it nearly impossible to know who actually sent the money, which breaks the entire chain of accountability that KYC verification is supposed to guarantee in the first place. Treating a mismatch as minor undoes the protection the whole system was built around.

Reading names carefully takes ten extra seconds. Skipping that one step is how careful, experienced sellers still end up losing crypto to trades that looked completely normal at first glance.

@Binance Vietnam #BinanceP2PAnToan
$ACE

I protect a Binance P2P purchase before I press Send. Buyers often focus on receiving crypto, yet the fiat transfer is the part I control and may be difficult to reverse. One wrong beneficiary, third-party account, or off-platform instruction can turn a protected order into an unsupported payment.

My first check happens on the ad. I inspect the seller's profile, visible trading record, completion signals, limits, payment method, and terms. A slightly better price does not compensate for unclear instructions. Once I open the order, escrow reserves the seller's crypto, KYC identifies the users, order chat records the conversation, and Appeal offers a route to Binance Support. I keep every step connected to that order.

Before paying, I compare 4 items: the live order number, exact fiat amount, listed beneficiary details, and payment deadline. I send from an account in my verified name. If the seller supplies a different account in chat, asks for payment to a friend, or wants several transfers to unrelated names, I stop. I never continue through a private channel or send after the order has expired.

After I make the transfer, I verify the transaction in my payment app, keep its ID, and mark paid only when the money has genuinely left under the correct order. I tell the seller in order chat, then wait for release. I do not cancel a paid order just because the seller asks, and I do not pay twice to "unlock" the escrowed crypto. Those requests create a gap between payment and platform evidence.

If the seller does not release or disputes receipt, I save the order screen, transaction record, beneficiary, amount, timestamp, and chat. I use Appeal or official Binance Support and respond with the evidence requested. Escrow is designed to hold the crypto during review, so panic is unnecessary and a second side deal is dangerous.

My buyer's rule is precise: one active order, one verified payer, one listed recipient, one exact payment. I let the Binance P2P process connect fiat proof to escrowed crypto from start to finish.

@Binance Vietnam #BinanceP2PAnToan
$BLESS

Academic blockchain research has a reputation problem: brilliant papers, elegant proofs, and then nothing a normal user ever touches. Ask anyone who has sat through a cryptography conference and they will tell you most of what gets published stays published.

Babylon looks like an easy target for that assumption on paper. Co-founder David Tse spent 18 years teaching at UC Berkeley before more than a decade at Stanford, where he still runs a research lab, and Babylon doesn't even have a CEO, Tse serves as research scientist while co-founder Fisher Yu runs engineering as CTO. That is an academic org chart, not a typical startup one.

The timeline says otherwise. BABE, Tse's Groth16 proof verification protocol for Bitcoin, reached Babylon's alpha testnet in February 2026, claiming close to a 1,000x reduction in the setup and storage cost of verifying zero knowledge proofs on Bitcoin. By June 2, roughly four months later, that same research underpinned Trustless Bitcoin Vaults' public Aave v4 testnet integration, involving a16z crypto, Ledger, and GoMining all at once.

Babylon isn't a research lab that happens to have a token, it's evidence that a lab structure can still ship on a startup's clock when the incentives line up. Whether BABE's cost savings hold once adversarial users start probing TBV on mainnet is the part research alone can never answer.

@BabylonLabs_io $BABY #baby
$BLESS

Most lending protocols pool collateral because pooling is efficient. Aave and Compound mix thousands of users' deposits into shared markets, which deepens liquidity and tightens pricing, and that pooled model is exactly what most DeFi capital efficiency is built on. Babylon looked at that model while designing Trustless Bitcoin Vaults and picked the opposite structure on purpose.

Every TBV vault holds one user's bitcoin, tied through pre-signed transactions to that specific position and that specific external smart contract state. Nothing gets commingled. Babylon and outside analysts covering the launch have described this segregation as aimed squarely at institutional and regulatory comfort, since a vault's bitcoin stays traceable to its own deposit rather than blending into an anonymous shared pool the way a bank's fractional reserve would. It is notable that Babylon is choosing to plug this segregated design into Aave, the very kind of pooled protocol it declined to imitate, through the Aave v4 integration expected around mid-2026, rather than building its own pooled lending market from scratch. The trade-off shows up immediately: segregated vaults cannot match the depth or tight spreads a shared pool generates, and each one carries its own setup and monitoring overhead under BitVM3.

Babylon is not optimizing TBV for maximum capital efficiency, it is optimizing for auditability and per-position traceability, a bet that institutional bitcoin holders will pay a liquidity premium for cleaner accounting.

@BabylonLabs_io $BABY #baby
$WMTX

Wrapped Bitcoin did something genuinely important for this industry: it let Bitcoin's liquidity show up inside Ethereum DeFi years before anything like Trustless Bitcoin Vaults existed. Babylon's pitch does not work if you skip past giving wrapped BTC that credit first.

But wrapped BTC's design carries a permanent structural cost. A custodian holds real Bitcoin and mints a synthetic token 1:1 against it, and every unit of that synthetic asset is only as trustworthy as the custodian's solvency and honesty. Even at meaningful scale, wrapped BTC still represents well under 1 percent of Bitcoin's total supply, roughly 150,000 BTC out of just under 20 million, which tells me most Bitcoin holders have simply declined to take that custodial trade in the first place.

Babylon's answer is to remove the custodian from the picture entirely. Native BTC locks in a Taproot UTXO on Bitcoin itself, and Aave v4 lends against that locked position directly, so the coin backing your loan is never minted as an IOU somewhere else. Depositors post real Bitcoin collateral and borrow supported assets like USDC or USDT on Ethereum without that collateral ever changing form.

The honest complication is that this is currently public testnet, unproven at mainnet scale, while wrapped BTC has years of production history behind it, mistakes included. Babylon is proposing a structurally safer model for a problem wrapped BTC already solved practically, just imperfectly. Whether structurally safer wins against years of working infrastructure is the actual contest here.

@BabylonLabs_io $BABY #baby
$GIGGLE

Here's a detail I think most quick summaries of Babylon's Trustless Bitcoin Vaults skip entirely, and it's worth sitting with because it complicates the clean "no wrapping, ever" narrative. On Aave v4, if a native Bitcoin-collateralized position gets liquidated, the BTC Vault Swap Spoke allows liquidators to swap that seized BTC position into WBTC so settlement can happen quickly, with the actual native Bitcoin redeemed on the Bitcoin network afterward through Babylon's proof system.

So wrapped Bitcoin does show up here, just not where users typically expect it. Depositors post genuinely native BTC as collateral, and that part of the claim holds completely, your Bitcoin stays on the Bitcoin network the entire time you're borrowing against it. But the backend liquidation plumbing uses a wrapped representation specifically to solve a real timing mismatch, Bitcoin settles slower than Ethereum, and liquidators need to act fast when a position turns unhealthy.

I don't read this as a contradiction so much as an honest engineering trade-off that marketing language tends to smooth over. Babylon is bringing native Bitcoin liquidity to Ethereum through this design, and using a wrapped asset for a few fast-moving liquidation seconds is a very different thing than requiring users to wrap their Bitcoin just to participate at all.

Still, I'd rather people understand this nuance going into the public testnet than discover it later and feel misled. "Trustless" describes the custody and collateral verification layer here. It doesn't mean wrapped Bitcoin has disappeared from the system entirely, it's just been pushed to a narrower, faster-moving corner of it.

@BabylonLabs_io $BABY #baby
$COTI

Mention Bitcoin-backed lending to anyone who was paying attention in 2022 and you'll probably get the same reaction: that's how people lost everything. Celsius, BlockFi, Genesis, and Hodlnaut all froze withdrawals and filed for bankruptcy within about six months of each other, and the sector lost more than 10 billion dollars in customer assets in that single year. That history is real, not exaggerated, and it's a completely reasonable stereotype to carry into any new BTC lending product.

The stereotype holds up because the failure pattern stayed consistent across all of them. Investigations afterward pointed to rehypothecation, platforms quietly reusing customer collateral for their own trades and bets, plus maturity mismatches and concentrated exposure to a handful of counterparties that all blew up around the same time. Customers had no real way to see any of that happening from the outside until it was too late.

Trustless Bitcoin Vaults are built to make that specific failure mode structurally impossible rather than just promising better behavior this time. There's no custodian holding customer BTC to rehypothecate in the first place, no signer consortium making discretionary calls, and each vault's coins stay locked to one specific, isolated smart contract relationship instead of pooled into a general balance sheet a company can quietly lend out.

Babylon isn't a better-run version of Celsius, it's a structurally different animal. The 2022 collapses happened because customer coins sat in accounts companies could touch. In TBV, there's no account and no company standing between the vault and the code governing it.

@BabylonLabs_io $BABY #baby
$BANK

Đỉnh mới ko mọi ng ơi 😙😙 alpha ss rồi 🙃🙃🙃
$BTW

Trustless Bitcoin Vaults were never designed to do only one thing. Babylon's own roadmap material describes the same vault primitive powering BTC collateralized perpetuals trading and dollar pegged stablecoin issuance backed strictly by native Bitcoin, alongside lending. Three plausible first products, one piece of underlying tech.

Babylon picked lending, and picked Aave specifically, to go first. That's a decision with real logic behind it. Perps need deep, fast moving derivatives liquidity and market makers willing to quote against a brand new collateral type. Stablecoin issuance needs its own credibility campaign for yet another dollar token in a market already crowded with them. Lending against the largest DeFi protocol by liquidity sidesteps both problems, Aave already has borrowers, depositors, and a liquidation infrastructure that has run for years, so the vault tech gets a proven distribution channel instead of having to build demand from zero.

The tradeoff is that lending is also the most contested, closely watched category to launch into, competing directly against every other form of BTC collateral Aave already lists. Babylon chose the hardest room to walk into first because it was also the one already built and full of liquidity.

Babylon isn't picking lending because it's the easiest application of TBV, perps and stablecoin issuance sit on the same roadmap. Babylon is picking lending because Aave already supplies liquidity and users that a brand new perps or stablecoin venue would have had to build from zero.

@BabylonLabs_io $BABY #baby
$DEXE $BANK

Buried in Babylon's staking script is a small cryptographic choice that says a lot about the team's priorities. The unbonding output on every staked UTXO is a Taproot output, and Taproot outputs normally support two ways to spend: a fast key path or a slower script path with explicit conditions written in. Babylon disables the key path entirely, using what is called a NUMS point, nothing up my sleeve, as the internal key, a value constructed so nobody can hold a private key for it even in theory.

That single choice forces every unbonding transaction through the script path, the one requiring a quorum of covenant committee signatures defined by a specific threshold set in the chain's parameters. A key path shortcut would have been simpler to implement and cheaper to spend from. It also would have created an unauditable exit that bypassed the entire slashing and unbonding logic the protocol is built around. Babylon picked the slower, fully constrained route on purpose.

Babylon is not choosing convenience here, it is choosing provable constraint, closing a shortcut most users would never notice. That single script decision reveals a habit: when efficiency and auditability conflict at the base layer, this team picks auditability. It only shows up when you read the script, not the pitch deck.

@BabylonLabs_io $BABY #baby
$LAB

Con quỷ này ăn giống gì mà tăng dữ vậy ???
$AKE

Ein Auftragnehmer sagte mir einmal, der schnellste Weg, ein Renovierungsbudget in die Luft zu jagen, bestehe darin, den Betrag gleichermaßen in das zu stecken, was Menschen sehen, und in das, was sie nicht sehen. Klare Renovierer setzen ihr Geld dort ein, wo es sichtbar ist, und akzeptieren die verborgene Komplexität hinter den Wänden. Babylons Ingenieure haben eine ähnliche Rechnung mit BitVM3 angestellt.

Die BitVM3-Forschung hinter Babylons Tresoren berichtet von einer groben 1000-fachen Reduktion der On-Chain-Streitkosten im Vergleich zum früheren BitVM2-Design: Eine Assert-Transaktion läuft dabei etwa für 5 US-Dollar, eine Disprove-Transaktion für unter 0,20 US-Dollar. Das ist der sichtbare Gewinn: günstig, nutzbar, On-Chain-Ökonomie für etwas, das früher kaum bezahlbar zu bestreiten war.

Der Kompromiss liegt hinter den Wänden. Um diese Kostensenkung zu erreichen, wird die Hauptlast der Berechnung vollständig von Bitcoin weg verlagert—hin zu verschlüsselten Schaltkreisen (garbled circuits). Ein Herausforderer bewertet sie off-chain, statt sie stückweise auf der Blockchain zu veröffentlichen. Unabhängige technische Reviews halten fest, dass diese Schaltkreise dutzende Gigabyte groß sind und auf gewöhnliche Serverinfrastruktur angewiesen sind, um Daten zu speichern und zu übertragen—Infrastruktur, die vollständig außerhalb der Sicherheitsgarantien von Bitcoins liegt. Ein Fakt, der selten in der Schlagzeile auftaucht.

Das Design hat die Komplexität also nicht beseitigt, sondern lediglich von einer teuren On-Chain-Form in eine günstige, aber Off-Chain-Form verlagert. Das ist ein vertretbarer Engineering-Kompromiss für eine Basisschicht, die so stark eingeschränkt ist wie Bitcoin: Teure On-Chain-Berechnung hätte sich ohnehin nie auf echtes DeFi-Volumen skalieren lassen—egal, wie die Gebühren strukturiert waren. Diese eine Zahl—fünf Dollar statt eines Bruchteils eines Cents—leistet dabei enorm viel Arbeit, um das gesamte Tresormodell kommerziell im Bitcoin-Maßstab tragfähig zu machen.

Das Team von Babylon hat sich für Erschwinglichkeit entschieden, statt die Off-Chain-Trust-Fläche zu minimieren, und angesichts der Scripting-Limits von Bitcoin sieht das nach dem einzigen Trade aus, der Tresoren zu nutzbaren Kosten zum Funktionieren verhilft.

@BabylonLabs_io $BABY #baby
$DEXE

Ein Mitschüler kam über ein Legacy-Admission in eine Spitzenuniversität, und alle gingen davon aus, dass der Abschluss allein schon die Karriere sichern würde. Drei Jahre nach dem Abschluss hatte er jedoch immer noch damit zu tun, auf eigenen Beinen zu stehen – genauso wie der Rest von uns. Der Brief bewies Zugang, nicht Ergebnis.

Die Backer-Liste von Babylon liest sich wie eine Checkliste für erstklassige Krypto-Venture-Fonds: Eine Seed-Runde über 8 Millionen US-Dollar im Januar 2022, angeführt von IDG Capital und Breyer Capital, eine Series-A-Runde über 18 Millionen US-Dollar im Dezember 2023 von Polychain Capital, Hack VC, Castle Island Ventures und Symbolic Capital sowie eine Runde über 70 Millionen US-Dollar im Mai 2024, angeführt von Paradigm mit Hashkey Capital und Polychain im Rücklauf. Insgesamt wurden rund 96 Millionen US-Dollar von Investoren eingesammelt, zu denen auch Binance Labs, Galaxy Digital und Amber Group gehören. Dieses Kapital und der Ruf senkten die Vertriebshürden tatsächlich spürbar; Babylon ließ sich deutlich früher als viele konkurrierende BTCFi-Projekte in Bitget Wallet, OKX Wallet und Binance Earn integrieren, und die Ankündigungen der Finanzierungsrunde selbst erzeugten bei jedem Schritt echte Marktaufmerksamkeit. Aber Kapital und Integrationen sind Inputfaktoren, keine Ergebnisse. Die Offenlegung einer Verwundbarkeit bei einer Verlängerung per BLS-Votum im Januar 2026 geschah bei einem Unternehmen, das von allen oben genannten Unterstützern finanziert wurde. Tokenomics-Bedenken hinsichtlich einer Konzentration von etwa 66% bei Insidern tauchten aus der Community auf – trotz, nicht wegen der Investorenzusammensetzung. Starkes VC-Backing sagt viel verlässlicher eine längere Laufzeit und einen besseren Zugang zur Distribution voraus, als dass es fehlerfreie Umsetzung vorhersagt. Und Babylons eigenes Jahr an Betriebshistorie zeigt sowohl Stärken als auch Stolperer, die unter demselben Funding-Dach stattfanden.

Die Investor:innenliste von Babylon ist keine Garantie für technische oder tokenökonomische Ergebnisse. Sie hat Laufzeit, Glaubwürdigkeit und Distribution gekauft – keines davon konnte jedoch die Schwachstellen oder die Konzentrationsbedenken verhindern, die ohnehin auftraten.

@BabylonLabs_io $BABY #baby
$DEXE

A budget airline near me launched with billboards reading "we fly everywhere." The actual route map at launch covered six cities, no international routes, half the domestic map labeled coming soon. I still think about how confidently "everywhere" got printed before the schedule backed it up.

GRVT's mobile app launch ran on similar language. When the Android app hit the Google Play Store on May 29, 2025, the press release described it as bringing "the full power of GRVT's trading platform to users worldwide at their fingertips," and the CEO's quote talked about making GRVT "the ultimate onchain financial marketplace, one where everyone can easily access powerful tools." The actual rollout at that moment was Android only, available in 50 specific countries named in the announcement, places like Argentina, Japan, South Korea, and Vietnam among others, not a global blanket release. The iOS version wasn't part of that launch at all, the release noted it would arrive "in due course" with no committed date attached. Anyone reading "worldwide" and "everyone" on launch day and then checking the App Store for iPhone would have found nothing to download. Both platforms are live now, roughly a year later, and the 50-country list has likely grown since, but the gap on launch day itself was real, a "worldwide, everyone" headline sitting on top of a single-platform release with a fixed country list and an unscheduled sibling app. That's not unusual for a startup shipping in stages, most companies phase a rollout while marketing the destination rather than the current step. The mismatch matters because "worldwide" and "everyone" are absolute words, and absolute words invite someone to check them against the actual list, the way I checked that airline's map against its billboard.

GRVT's "worldwide, everyone" mobile launch language did not match its day-one footprint, an Android-only release across 50 named countries with iOS unscheduled, a gap worth noting on any launch claim.

@grvt_io #grvt
$LAB $VELVET

I once downloaded the mobile version of a trading app I already used on desktop, expecting the exact same toolkit in my pocket. Half the order types I relied on daily were simply missing from the phone screen, and I had to keep switching back to a laptop for anything beyond a basic market order.

GRVT launched its Android and iOS apps funded in part by the $14.3 million the company had raised by January 2025, a round that included a $5 million strategic check from Further Ventures, a firm backed by Abu Dhabi's sovereign wealth fund ADQ. At launch the mobile apps supported more than 40 perpetual trading pairs, a meaningful slice of the roughly 168 markets available through the full platform but far from the complete catalog. The gap between "GRVT is a full self-custodial trading platform" and "GRVT's mobile app covers a subset of what the platform actually lists" matters for anyone who assumes app store parity with the desktop experience by default. A trader managing positions on niche pairs outside that initial 40 may find themselves needing a browser anyway, even after downloading the app specifically to trade on the move. Mobile coverage has likely expanded since that initial count given how quickly the overall market list has grown platform wide, but the founding gap between marketed completeness and shipped completeness is worth noticing before assuming any given feature exists on every surface the brand touches. The same funding round that paid for the apps also backed core infrastructure work, meaning mobile development competed for resources against the exchange's back end rather than running as its own fully staffed track from day one.

GRVT's mobile apps are not simply a smaller window onto the same complete platform, they shipped narrower than the desktop experience, worth checking before relying on a phone for anything beyond the most common pairs.

@grvt_io #grvt
$LAB

The office building I used to work in had a normal process for any renovation: submit a request, wait for a review committee, get a permit, then wait out a mandatory notice period before crews could touch anything load bearing. There was exactly one override to that whole process, a fire safety panel that a handful of senior staff could trigger immediately during an active emergency, no waiting period, no committee, action within minutes.

ZKsync's governance structure, which GRVT's chain sits inside, has a similar override built into it. Ordinary protocol upgrades carry a mandatory delay of roughly 4 days 3 hours up to 8 days 3 hours before they can execute, giving the community time to notice and react to anything suspicious in a proposed code change. But there is one path around that entire waiting period: the Emergency Upgrade Board, formed by the Security Council, the Guardians, and the ZK Foundation Multisig acting together, can push an upgrade through immediately with no delay at all. That mechanism exists for a real reason, a critical vulnerability discovered mid attack cannot wait 4 days for a community review window before it gets patched. But the same fast path that lets the team stop an active exploit in minutes is also, by design, a way for a small coordinated group to push through a contract change with zero public notice if they ever choose to. Nothing about the mechanism itself tells outside observers which scenario is actually happening in any given moment it fires.

Whether the Emergency Upgrade Board is a necessary safety valve or a centralization risk depends entirely on the situation it gets used in, and GRVT's users have no way to distinguish an emergency patch from a rushed one until after the fact. Neither reading is fully wrong, and the honest position is that the tradeoff has not been resolved, only accepted as the cost of moving fast when it matters.

@grvt_io #grvt
$LAB

GRVT markets itself around self custody, funds never held by a third party, control resting with the trader. Its insurance fund quietly complicates that pitch. When a liquidated position gets closed at a price worse than its bankruptcy price, the shortfall has to come from somewhere, and on GRVT, as on nearly every leveraged exchange, that somewhere is a shared pool capitalized by liquidation fees collected from all traders on the platform.

That pool is, functionally, pooled counterparty risk. If the insurance fund runs dry during an extreme event, the backstop shifts to auto deleveraging, where profitable traders can have their winning positions forcibly closed to cover someone else's shortfall. Neither mechanism has anything to do with who holds the private keys to your collateral. Self custody protects your assets from GRVT the company; it does nothing to protect your open PnL from the mathematical reality that leveraged derivatives require some form of loss socialization when a position goes bankrupt faster than it can be closed.

This is not a flaw unique to GRVT, every serious perpetuals venue works this way. But it does mean the self custodial pitch and the insurance fund pitch are answering two different questions. One is about custody of your capital. The other is about who absorbs the loss when the market moves faster than the liquidation engine can react, and self custody was never going to answer that second question by itself. I think about this every time a project markets itself purely on the self custody angle without mentioning the insurance fund in the same breath, because the two mechanisms are answering completely different risk questions and conflating them leaves a trader with a false sense of how protected their unrealized profits actually are during a genuine tail event on any leveraged venue, GRVT included.

@grvt_io #grvt
$LAB

Về lòng đất thật rồi 🙃🙃🙃
$LAB

Lại cắm đầu nữa rồi 🙃🙃 $BTC