Track market-moving stories before they get noisy

Norway’s National Criminal Investigation Service, known as Kripos, announced the arrest of 28 men across seven countries following an operation conducted in early June 2026. The suspects allegedly used Monero to pay for access to child sexual abuse material on multiple dark web forums. Three children were safeguarded, and over 460 items were seized, including electronic devices, crypto wallets, and illegal drugs.

The arrests spanned Norway, Sweden, Switzerland, Canada, the Czech Republic, Poland, and Germany. Europol supported the operation, underscoring the kind of multi-jurisdictional coordination that has become increasingly common in dark web takedowns.

How Monero became the payment method of choice, and how that’s changing Monero sits in a specific corner of the crypto market: privacy coins, designed to obscure sender, receiver, and transaction amount by default. Bitcoin leaves a public trail. Monero, in theory, does not. That’s why it became the preferred currency for illicit dark web transactions.

Advertisement

Kripos developed new methods for tracing Monero transactions in 2025. The agency has not disclosed exactly how those methods work, which is deliberate. But the operational result speaks for itself: 28 arrests across seven countries tied to payments made in a coin that many assumed was beyond reach.

More arrests are expected as the investigation continues, according to Kripos.

One suspect was also reported to have used artificial intelligence extensively to generate illegal material. Some victims were identified as family members of the suspects.

What this means for privacy coins and the investors who hold them Major exchanges, including Kraken and Binance, delisted Monero in various markets between 2021 and 2023 under regulatory pressure. The Financial Action Task Force has repeatedly flagged privacy coins as high-risk assets for money laundering and illicit finance.

This operation fits into a broader pattern. The Kidflix takedown and Operation Grayskull in 2025 collectively led to hundreds of arrests globally and relied heavily on forensic crypto analysis.

Disclosure: This article was edited by Editorial Team. For more information on how we create and review content, see our Editorial Policy.

THORChain Podcast #198: Live Monero Demo ft. jpthor & KentonC137 | May 14, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DRJP ran a live Monero demo on a 7-node THORChain chainnet with real funds, executing the first end-to-end decentralized $RUNE to $XMR swap with full vault auditability across signing and non-signing nodes.The implementation uses a deterministic view key (SHA-512 of "thorchain view key") plus on-chain key images and per-transaction signing keys to make every Monero inbound, outbound, and vault balance publicly auditable.Monero runs as a Rust sidecar alongside Bifrost, built on Luke Parker's Serai signing stack and the Monero Oxide wallet library, plumbed into THORChain by Boone.JP and Chad disagree on running multiple Asgard vaults versus a single vault for Monero, a question to be resolved before the mainnet rollout.The code is functional today, but mainnet is gated on more stress testing. When it ships, expect a guarded launch with small pools.Where things stand (June 2026): This recap revisits JP's live demo from May 14. In the weeks since, Chad Barraford confirmed on THORSday #209 that Monero now works end-to-end on the chainnet test environment, with real $XMR swaps, liquidity adds and removes, and churns all confirmed. A live $XMR launch is targeted for roughly a month after THORChain's trading restart, barring a bug that forces a v3.20 change, with Zcash ($ZEC) one to two weeks behind. Mainnet is not live yet.

IntroductionThis was not a typical podcast episode. JP joined Kenton and ran a fully live Monero implementation on a real-fund chainnet: seven nodes churning, two Asgard vaults, key gens, key signings, the works. By the end of the call, JP had executed the first end-to-end decentralized $RUNE to $XMR swap, audited the transaction with a key image and a signing key, and confirmed his receiving wallet got paid. This was THORChain producing the proof that years of Monero integration work actually delivers.

What follows is a recap of the architecture, the audit primitives, the live result, and the open questions still on the table before mainnet.

1. The Live Demo: Seven Nodes, Real Funds, Real SwapJP began by tearing down his existing chainnet and redeploying it from scratch. The deploy spooled up seven THORChain nodes and one genesis vault, then churned into a six-active-node, two-Asgard-vault configuration. He added 0.5 $XMR and 500 $RUNE to each active vault, waited for confirmations, then fired off a 100 $RUNE to $XMR swap back to his own Monero wallet.

It worked. The signing nodes generated the transaction, produced a key image and a transaction signing key, propagated those to the non-signing nodes for verification, then settled the outbound. JP pasted his recipient address and the transaction key into a Monero block explorer's proof-of-payment tool and confirmed receipt.

"Real money, real funds. I love it when a plan comes together." (JP)Across all seven nodes, signing, non-signing, and standby, the reported $XMR balance converged. The on-chain vault state matched the actual Monero wallet state, and gas accounting was correct. After the swap, the protocol began an unhalted churn, generating two new Asgard vaults and migrating funds in multiple rounds without breaking auditability.

2. How THORChain Audits Monero Without a Privacy BackdoorThe core challenge with Monero on a transparent chain is making the vault state verifiable, since Monero hides addresses and amounts by default. JP's solution rests on three primitives.

Deterministic view key. Every THORChain Monero vault uses the same private view key, derived from SHA-512("thorchain view key"). It is global and public, so anyone can see inbounds to any THORChain Monero vault and confirm the amounts. Standard Monero wallets never expose their view key. THORChain's vaults do, by design.

Key images. A view key alone does not reveal when outputs are spent. For every inbound, THORChain kicks off a key image ceremony, essentially a 2/3 threshold ceremony similar to a key signing ceremony. The resulting key image is stored on-chain. When that key image later appears as spent on the Monero blockchain, anyone can audit the vault's debits.

Transaction signing keys. For every outbound a signing subset produces, they also generate a transaction signing key and propagate it to the non-signing nodes. Plug the transaction key plus the recipient address into a Monero proof tool, and the destination and amount are verifiable. This is how the rest of the network confirms the signers did what they were supposed to, and did not reroute funds.

Put together, these three primitives let anyone audit every Monero inbound, every spent output, and every outbound on every THORChain vault, in real time. As Kenton summarized it on the call:

"THORChain doesn't become more private by adding Monero. THORChain is actually bringing more publicity to the Monero transactions that occur on THORChain. Anything private has to happen on the Monero chain itself." (Kenton)JP agreed:

"THORChain actually honestly doesn't know that Monero is a privacy chain. THORChain thinks Monero is just literally Bitcoin." (JP)The audit model is what makes the integration possible. Without it, JP noted, the nodes could just steal.

3. Architecture: A Rust Sidecar Built on Serai and Monero OxideMonero is the first chain client where THORChain runs a dedicated sidecar process alongside the Go-based Bifrost. The sidecar is written in Rust because it needs to host the FROST signing engine for Monero, and because the entire Rust Monero stack is more mature than any Go equivalent. Bifrost orchestrates: it tells the sidecar when to key gen, when to key sign, with what amount and to what address. The sidecar executes.

The foundation is Luke Parker's work. Luke, the lead developer of Serai, built both the modular FROST stack THORChain depends on for threshold key generation and signing, and Monero Oxide, the Rust-based Monero wallet library THORChain uses for everything from view key derivation to vault address generation to transaction construction, decoy selection, and fee computation.

"All the Monero stuff is based on Luke's work. We just kind of plumbed it into THORChain's semantics." (JP)Boone did the plumbing. JP credited Boone explicitly for taking Luke's libraries and adapting them to THORChain's Bifrost architecture.

THORChain also runs a fork of the Monero TS wallet library, published on the THORChain GitHub, which adds 255-byte TX extras. That is the change that lets THORChain memos ride alongside Monero transactions. Any wallet integrating Monero with THORChain needs roughly three lines of code to adopt the same pattern, and 255-byte memos are already valid on the Monero base layer, JP noted, which most integrators do not realize.

4. Handling Monero's QuirksMonero behaves differently from Bitcoin in ways the implementation has to absorb.

10-block lock per UTXO. Every Monero output is locked for 10 blocks after receipt, roughly 20 minutes. The signers track lock state per UTXO and refuse to sign until the spendable balance is available. THORChain does not see the lock directly; it just schedules the outbound and the signers say "talk to me in nine blocks." If one vault is fully locked, THORChain reschedules the transaction to the other active vault. Streaming swaps are not affected, JP confirmed, because Chad recently shipped a feature that begins the streaming swap clock as soon as the deposit kicks off confirmation counting.

Gas budget. Monero gas accounting is hard, so THORChain hardcodes a 120,000-unit budget per outbound, about 42 cents at current prices. Real transactions usually come in closer to 4 cents, so there is a roughly 10x buffer. Simple, predictable, slightly overpaid.

Zero-output change. Every Monero transaction must have two outputs (the real destination plus a dummy from a decoy ring). When THORChain does not actually need a change output, it produces a zero-amount second output and ignores it on the receiving side. This applies to consolidations, migrations, and any one-recipient outbound.

Consolidation strategy. JP proposes consolidating 10 UTXOs down to 5 at a time rather than larger batches. Gas scales linearly with UTXOs, and so does signing time. Keeping consolidations bounded keeps both manageable.

Birthday-based scanning. Each Monero vault saves its creation block height on-chain. Sidecars scan from that birthday forward rather than from Monero genesis. A rescan mode lets any node rebuild its sidecar inventory from scratch by pulling addresses, birthdays, key images, and the view key from THORChain itself. JP says he has tested it ad nauseam.

Old vault refunds. If someone sends Monero to a retired vault, THORChain cannot auto-refund because it cannot identify the sender address. The funds flow to the latest active vault instead, available for a manual treasury refund if the sender produces their transaction private key to prove ownership.

5. Single Vault or Multiple? An Open DebateThe most consequential open question from the episode: should THORChain run one Monero vault or many?

JP's position is to run multiple Asgard vaults, the same way Bitcoin and Ethereum work today. Multiple vaults give the network redundancy when 10-block UTXO locks tie up one vault's spendable balance, and they limit the impact of any single signer set going offline. The trade-off is more key gens, more key image ceremonies, and unproven scalability of FROST Monero across all 100 nodes simultaneously.

Chad's position is to run a single vault. With one vault, every node is a signer, which lets the implementation skip the multi-vault key image generation overhead and simplify the protocol surface area.

Kenton pushed back on the disconnect directly, telling JP that he and Chad clearly need to sort this out: Chad is saying one vault, JP is saying multiple. JP indicated multiple is more aligned with how the other chain clients already work, and that moving to a DKLS-based ECDSA TSS library could eventually make single-vault designs viable. He will continue the conversation with Chad before mainnet, and Kenton suggested running both configurations on mainnet for a few weeks each to observe behavior. The decision is open.

6. AI-Assisted Development, and the "Vibe Coded" QuestionJP addressed criticism that the Monero implementation is "vibe coded" head-on. His view: AI tooling (Claude, Codex, GPT 5.5) lets him work an order of magnitude faster than five years ago, when the team spent a year building the original Bitcoin Bifrost. Tasks that used to require hand-grepping logs across 100 nodes now take minutes when AI can crawl them.

But the workflow is not hands-off. JP described it as juggling, with constant supervision required: one slip and the whole thing crashes down. He uses separate AI conversations per stack component and trains each with project-specific skills.

"The code only works if it's correct. If it didn't work, then you would not see these correct numbers. Gas accounting would be wrong, the balances wouldn't match." (JP)Kenton's framing: it does not matter whether the code starts as vibe-coded or hand-written. What matters is whether it gets reviewed, tested, and verified to work. By that test, the Monero implementation is human-approved code regardless of how the first draft was produced.

7. Future-Proofing for FCMP++ and CarrotAn audience question raised the upcoming Monero hardfork, which introduces FCMP++ (Full-Chain Membership Proofs Plus Plus) and the Carrot addressing protocol. Carrot adds outgoing view keys, forward secrecy, and other privacy and usability features while maintaining backward compatibility with existing Monero addresses.

JP's expectation is that the upgrade should be plug-and-play for THORChain. Luke Parker's Serai and Monero Oxide stacks will absorb the changes upstream. When the hardfork ships, THORChain will pause Monero trading, upgrade its sidecar dependencies, and unpause, with no expected protocol-level rework on THORChain's side and no expected long downtime.

What to WatchMore stress testing on chainnet. JP planned to run automated scripts that throw every edge case at the implementation: bad memos, wrong gas, old vault refunds, mismatched routing. If solvency holds after sustained abuse, the path to mainnet is clear.JP and Chad converging on vault architecture. Single vault or multiple is unresolved and material. Watch for a follow-up between them.Chainnet to stagenet to mainnet rollout. The chainnet code is the mainnet code, and the deploy pattern is identical. Mainnet is a confidence question, not a code question.A guarded launch when live. Expect small pools and small trades at first. JP and Kenton both flagged that Monero could need several months on mainnet before it is fully battle-tested.FCMP++ and Carrot hardfork handling. Monero's hardfork is on the near-term horizon. The plan is a brief THORChain pause for sidecar upgrades, then resume."We could launch this on mainnet tomorrow. It just depends on how confident we are that we're not going to hit a bug." (JP)More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.

THORSday Community Podcast #211 ft. CBarraford, KentonC137 & Patriotsounds | June 25, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DRTHORChain trading is back after roughly a month offline. The team framed the recovery as one of the harder classes of incidents to debug, but the network is live again and the roadmap can move.$XMR moved closer. v3.19.2 includes the Solana churn fix and embeds Monero code, with Chad saying $XMR could land closer to two weeks after trading resumed than the month previously discussed.The security path is becoming clearer: publish the TSS library around v3.20, keep reviewing the GG20 patch surface with Huginn and Soda Labs, then move chain by chain toward DKLS and FROST.Growth work did not stop during the pause. Morpheus, Keplr Wallet, affiliate onboarding, KOL campaigns, x402 payments and MCP tooling all came up as ways to make THORChain more reachable.POL became the biggest governance topic. The debate is now about how aggressively THORChain should route income into protocol-owned liquidity, especially if Monero needs deep pools quickly.1. Trading Is Back, and the Roadmap Can Breathe AgainDenny opened the first post-restart THORSday like a man who had been waiting a month to press the party button. Confetti fired, the desk-pop jokes landed, and the simple message was the one everyone wanted to hear: THORChain is back online and swapping again.

Under the celebration, Chad Barraford kept the explanation grounded. This was not a normal bug hunt where a developer can read logs, isolate a bad branch and patch the issue within hours. The exploit lived in peer-to-peer validator communication and key-share behavior, which meant the team had to infer the attack path from limited evidence and then make sure the thing they found was the thing that mattered.

"This kind of attack is one of the hardest to recover from." (Chad)That is why the restart took as long as it did. The network had to recover from a sophisticated cryptography attack, deal with verification and node issues along the way, and then get back into a state where the team could safely resume trading. Now that it has, Chad's posture was simple: the team can get back to the roadmap.

For users, the practical message is equally simple. Swaps are back through THORChain Swap, and the ecosystem has breathing room again. For the dev side, the next release is already queued.

2. Monero Moves From "Later" to "Soon"The biggest roadmap update was Monero. Chad said v3.19.2 is being cut with two important pieces: a fix for a Solana churn issue, and the Monero integration embedded in the release. The $XMR code still needs more internal testing and node readiness, but the tone changed from "roughly a month after restart" to "closer to two weeks."

The caveat matters. Nodes still need to build and sync Monero infrastructure, which Chad estimated around two to three days depending on resources. He also said there is a chance Zcash and Monero could launch together, but he did not frame that as a promise.

Denny tied the moment back to the privacy thesis. For the first time, Monero holders would get permissionless layer 1 to layer 1 access without bridges, wrapped assets, accounts or KYC. He also made sure nobody mistook that excitement for a guarantee of a perfect launch.

"The pools will be shallow. Do not attempt big swaps at first." (Denny)That warning should be repeated. Mainnet is different from testnet. New chain clients have always had their own quirks, and Monero is the most complex chain THORChain has added. The likely launch path is small swaps first, close monitoring and a willingness to pause if something behaves badly.

The shout-outs were important too. Boone started the Monero chain-client process, and Luke Parker's work through Serai gave THORChain an open-source FROST TSS base that helped make the integration possible. Testing never fully stopped during the trading pause. The work just moved in the background until the network could breathe again.

3. Security: Open Source, Huginn, DKLS and FROSTSecurity dominated the technical section. The current TSS library is not public yet, but Chad expects it to be open sourced around v3.20, likely after a deeper Soda Labs review. Soda Labs is still spending time with the codebase before the team opens it again, and Chad framed that delay as a tradeoff in favor of better review.

The review surface is not small. Chad said Huginn, his AI audit and triage agent, has opened close to 200 issues against the private TSS library alone, with varying severity. The team is reviewing and prioritizing them, but not every issue necessarily deserves a patch if the long-term plan is to leave GG20.

"Everybody wants to get off of GG20 and move to DKLS." (Chad)That does not mean pressing a panic button. Chad emphasized that changing cryptography is inherently dangerous, especially when live funds have to migrate between schemes. The likely path is slower and more controlled: move chain by chain, start with smaller-value chains if possible, observe keygen and signing behavior, then expand.

The direction is now a dual track. Use FROST where THORChain can, especially EVM chains and Bitcoin through Taproot. Use DKLS where FROST is not available, such as Litecoin and Dogecoin. Monero already uses FROST, but Chad clarified that it is a different variant and cannot simply be reused for EVMs or Bitcoin.

Chainflip came up as one possible FROST implementation to study because it has been in production, but Chad made no commitment. THORChain still needs to evaluate whether any candidate library supports the accountability features the protocol needs, including identifying and slashing participants who hold up keygen or signing.

The team is also exploring bigger vault architecture ideas: hot and cold vaults, less frequent signing for most funds, and possibly two-of-two schemes later. The security team has a deeper meeting next Wednesday. Chad suggested next THORSday may have a clearer readout.

4. The Growth Stack: Wallets, KOLs and AI AgentsThe pause did not freeze business development. Kenton ran through a stack of smaller but important growth items now that trading is live again.

First, Morpheus. THORChain had a call with Morpheus, the decentralized AI project, and the immediate next step is simple: whitelist the ERC20 contract so a liquidity pool can be created. David from Morpheus is expected on the podcast in August. Kenton also floated the broader idea of reaching out to more ERC20 communities that want access to Bitcoin liquidity without asking nodes to support a whole new chain.

Second, wallets and affiliates. Keplr Wallet support on THORChain Swap is expected to start with EVM chains, then UTXO chains. The affiliate page is also being cleaned up so partners can get API keys, set fees, choose payout assets and likely create a THORName up front as part of the onboarding flow.

Third, marketing. Eric from Moca introduced Kenton to Creatorverse, the campaign platform from SCAL3. The pitch is a contest model for KOLs: creators compete on a leaderboard, with payouts tied to performance instead of a flat fee per post. Kenton liked the game theory, while Chad immediately asked the right question: how do they keep bots from gaming likes and retweets?

The AI-agent section was the most forward-looking. After the Morpheus call, Chad listed action items around x402 payments, Ethereum agent standards and an MCP for THORChain. He has built an MCP before and said he may open source it. Andy from Liquify has also been working on MCP tooling.

Kenton had already started checking THORChain's web properties with Agents First, trying to make thorchain.org and THORChain Swap easier for AI systems to read and interact with.

"THORChain has to be easily accessible by AI." (Kenton)The thesis is straightforward: if agents become a major share of blockchain transactions, THORChain cannot be invisible to them.

5. POL Takes Center StageThe biggest governance conversation was protocol-owned liquidity. With trading back and Monero close, Kenton wanted to know when the community should start debating what percentage of system income should go to POL.

The first issue is mechanics. Chad believed the POL percentage had been moved to an operational Mimir, where nodes can vote different percentages and the leading value wins. Boone joined to say his dashboard still shows it as an economic Mimir, with 12 votes trying to set it to 1%. Chad linked the commit he remembered making and said he would need to check whether something had been reverted.

The second issue is economics. Kenton corrected his own math from a previous discussion: if the system moved from 75% of fees going to nodes to 50% going to nodes and 25% going to POL, node operators would need to raise operator fees by 50% to get back to even. His view was that bond providers and operators need to have that conversation honestly, especially in a lower-fee, lower-$RUNE environment.

Boone's argument was urgency. After the exploit, asking third-party LPs to trust the pools immediately is a hard sell. Monero could become one of THORChain's most important pools, but without POL, the liquidity has to come from somewhere else.

"Getting liquidity back into the pools is a really really huge priority." (Boone)That is why the POL debate feels bigger than a simple fee split. Under normal LP incentives, THORChain rents liquidity from third parties and keeps paying for it. Under POL, the protocol slowly owns more of the pools, earns fees on its own liquidity and can target liquidity into strategic pools like $XMR.

"It's renting versus owning." (Boone)Kenton floated 25% POL while keeping the 5% $RUNE burn, or 29% POL with the burn reduced to 1%. Denny preferred going as aggressive as possible, while keeping at least a 1% burn for the deflationary narrative. The hosts also noted that the attack aftermath already left several million $RUNE to burn, far more than the fee-burn mechanism had destroyed so far, though they were careful with the exact number.

The sales pitch for new chains may be even stronger. Instead of paying a centralized exchange listing fee and handing supply to a market maker that sells, a project can seed a THORChain pool, keep custody of its LP position, accept impermanent loss as the real cost, and let POL keep buying and holding its token if the pool earns its way there. That turns THORChain from a listing venue into a long-term liquidity partner.

What to Watchv3.19.2 adoption. Watch for the Solana churn fix, Monero code adoption and node readiness after the release reaches operators.$XMR mainnet. The target moved closer, but shallow liquidity and possible early pauses should be expected. Small swaps first.The security meeting. Next Wednesday's discussion may clarify hot/cold vaults, two-of-two ideas and the first DKLS or FROST migration path.v3.20. Chad expects the public TSS library around v3.20, with $TAO and free stable swaps also discussed for that release path, gated by Mimir where needed.POL governance. The Mimir type needs clarity, then the community has to converge on a percentage. The practical question is how fast THORChain should own liquidity again.AI accessibility. x402, MCP tooling and agent-readable THORChain sites are now explicit action items, not abstract future talk.Upcoming guest. Saturday's episode is expected to feature Amir Taaki for the Monero and cypherpunk crowd.More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.

Binance, the world’s leading crypto exchange, has announced the delisting of four digital currencies, including Monero (XMR), Multichain (MULTI), Vai (VAI), and Aragon (ANT). The decision to remove these tokens from the platform comes as part of Binance’s periodic review process.

According to the latest announcement, the delisting process is scheduled to take effect on February 20, 2024, at 03:00 a.m. UTC. Following this, all trading pairs associated with these tokens, including ANT/BTC, ANT/USDT, MULTI/USDT, USDT/VAI, XMR/BNB, XMR/BTC, XMR/ETH, and XMR/USDT, will cease to be available for trading. Additionally, deposits of these tokens will not be credited to user accounts after February 21, 2024. Moreover, withdrawals for these tokens will be not supported after May 20, 2024.

Why Did Binance Decide To Delist Monero, Multichain, Vai & Aragon? Binance’s decision to delist these tokens is guided by a comprehensive assessment of various factors. These include the commitment of the project teams, development activity, trading volume, network stability, public communication, responsiveness to due diligence requests, and contribution to a healthy crypto ecosystem. Any evidence of unethical conduct or negligence also weighs into the decision-making process.

Monero, known for its privacy features, has faced scrutiny from regulatory bodies due to its potential use in illicit activities. While it offers anonymity to users, this very feature has raised concerns among authorities regarding its susceptibility to use in money laundering and other illegal transactions.

Multichain, Vai, and Aragon, while not as widely recognized as Monero, have also failed to meet Binance’s standards in terms of development activity, trading volume, and network stability. The delisting of these tokens underscores the crypto exchange’s commitment to maintaining a trustworthy trading environment for its users.

Also Read: Binance Tops CME In Bitcoin Futures, Is Bitcoin ETF Demand Over?

Implications Of Delisting In addition to the delisting of Monero, Multichain, Vai, and Aragon trading pairs from the spot market, Binance will also remove these pairs from its margin trading platform, futures trading, and various other services. This includes Binance Margin, Binance Futures, Binance Simple Earn, Binance Auto-Invest, Binance Loans, Binance Convert, Binance Gift Card, Binance Pay, and Trading Bots.

Despite the delisting, the CEX ensures that users’ funds are safeguarded. Any remaining balances in delisted tokens will be automatically converted into stablecoins on behalf of users. However, it’s important to note that the conversion is not guaranteed, and users will be notified before the process begins. The stablecoins will then be credited to user accounts after the conversion.

In response to the delisting announcement, users are advised to close any open positions and withdraw their assets in the above-mentioned trading pairs. In addition, they are advised to manage any associated products such as Simple Earn, Auto-Invest, Loans, Margin, Futures, Convert, Gift Cards, Pay, and Trading Bots before the stipulated deadlines to avoid any potential losses.

Also Read: Binance Co-founder Announces $5 Million Reward for Reporting Insider Trading