In 2001, PayPal’s single biggest revenue line was not fees. It was the yield on money that was just sitting there. AI agents are about to recreate that problem at machine speed.
Read PayPal’s S-1 filing from 2001 and you find something strange.
Its single biggest revenue line at the time was not transaction fees. It was the blended yield, roughly 3.8%, that PayPal earned on customer balances sitting inside the system. Money nobody was spending paid the bills.
Every financial intermediary since has rediscovered the same lesson. Idle money is a business.
Hold that thought, because the AI agent economy is about to produce a very large pile of idle money, and almost nobody is budgeting for it.
The “will AI agents use crypto” debate ended quietly, in production, sometime last year.
Look at what is running today:
That last figure is the whole story. A 26 cent payment cannot survive card rails, where interchange alone often exceeds 20 cents per swipe.
The math simply does not work. So the traffic went somewhere the math does work.
The last hundred days turned that into standard infrastructure. Mastercard launched Agent Pay for Machines in June 2026 with more than thirty partners.
Cloudflare shipped Wallets on 1 August, giving agents a stablecoin balance and a human-readable name.
AWS took Bedrock AgentCore Payments to general availability on 18 August, built with Coinbase and Stripe.
Agents spending stablecoins is a solved problem. Agents holding stablecoins is not. Those are two different questions with two different answers.
Here is the part that never makes the headlines.
An agent cannot pay from an empty wallet. Settlement clears in milliseconds. A funding approval does not. So every production agent runs with a pre-funded buffer sitting underneath it.
Three reasons that buffer can never be zero:
And here is the uncomfortable arithmetic. Float does not scale with revenue. It scales with agent count.
At a modest $250 buffer per wallet, a 2,000-agent fleet is sitting on half a million dollars doing nothing at any given moment.
Now scale the flow. Gartner expects AI agents to intermediate around $15 trillion in B2B purchases by 2028.
McKinsey QuantumBlack puts global agentic commerce at $3 trillion to $5 trillion by 2030.
You do not need to believe either forecast precisely. You only need to accept the direction, because float is a roughly fixed percentage of flow.
For context on what that pool is worth to whoever captures it: Circle reported $653 million in reserve income in Q1 2026 on around $77 billion of USDC in circulation. Idle balances are not a rounding error. They are a revenue line.
So yes, agents will hold stablecoins. Not because it is elegant. Because they have no alternative.
Now the half that should make you pause.
Spending exposes one transaction. Holding exposes the balance. Those are completely different risk shapes, and 2026 has been rough on the second one.
The structural flaw is not exotic. A language model cannot reliably separate an instruction from content it is reading. A spending cap written into a system prompt is a suggestion, not a control.
Security researchers now push what some call the outside-the-model standard: enforce limits at the wallet or custody layer, never inside the prompt.
Which is a polite way of saying the industry assumes the agent will eventually be tricked, and designs around that assumption.
Follow that logic and you get thin agent wallets by default, with the real balance parked somewhere the agent’s reasoning cannot reach.
Here is the rule most agentic payment write-ups skip entirely.
Under the GENIUS Act, US payment stablecoin issuers are barred from paying interest directly to holders. Section 4(a)(11) closes that door.
The practical consequence is blunt. An agent’s idle float, held in a mainstream payment stablecoin, earns exactly nothing.
Every dollar of buffer is a drag on margin, and that drag grows with every agent you deploy.
Which reframes the question. It is no longer “which stablecoin should an agent hold.” It is “which structure can compensate a holder at all.”
Sky Protocol is built differently, and the difference is mechanical rather than cosmetic:
How regulators treat each structure over time is genuinely unsettled, and anyone telling you otherwise is selling something.
But the plumbing is not the same, and that is worth understanding before the agent fleet doubles.
Sky Agents are not AI agents.
Spark, Grove, Keel, Obex and Osero are independent businesses that borrow USDS and deploy it into yield strategies. They are run by people. They compete under risk parameters set by governance and published onchain.
The word collision is unfortunate. The distinction matters, because the interesting thing about the Sky Agent Network is not that it is autonomous. It is that the rules governing it are already machine-readable.
Strip away the narrative and a holding asset has to clear four tests before software will touch it:
Most yield products fail test two or test three. Anything with a lock-up is useless to an agent that might need the balance in four seconds.
Rates funded by token emissions do not survive contact with a treasury policy. So it is fair to ask what funds this one.
For Q2 2026, Sky Frontier Foundation reported Gross Protocol Revenue of $107.35M, up 10.5% year over year and the second straight quarter above $100M. Net Protocol Revenue reached $40.09M at a 37.3% net margin.
Protocol Collateral stood at $12.32B, up 45.5%. sUSDS supply hit $5.52B, up 149%.
Net Protocol Surplus came in at $33.29M, the fifth consecutive positive quarter, with cumulative Sky Savings Rate distributions past $250M since inception.
Live figures sit on the public dashboard. Check them rather than trusting a paragraph.
Partially. And the split will be functional, not ideological.
The genuinely interesting shift is not that software can spend money. It already does, 160 million times over.
Software is about to become a category of holder. And holders ask questions spenders never bother with. What backs this. Who sets the rate. Can I leave.
Those are the questions this ecosystem has been answering onchain for almost a decade. The audience just changed.
Your turn. If you were architecting a 500-agent fleet tomorrow, where would you park the float? Thin wallets with frequent refills, or a pooled treasury sitting in a readable rate? And be honest: would you let an agent hold a five-figure balance today? Comments are open.
Will AI Agents Hold Stablecoins? The Case For and Against was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
On September 3, 2026, roughly $1.73M in DAI and USDC left Notional Finance’s V1 Escrow contract in a single transaction. There was no flash loan, no price oracle manipulation, and no compromised key. The attacker minted a fabricated fCash claim equal to Escrow’s entire live balance and withdrew it as real tokens, using a raw type-narrowing cast in Notional’s collateral valuation code that let a maximally insolvent account report zero debt.
Notional Finance V1 represents fixed-rate lending positions as ERC1155 tokens called fCash. Every position is one half of a payer and receiver pair, the payer owes cash at maturity, the receiver is entitled to collect it. Transferring one of these ERC1155 tokens does not move an existing balance. It calls Portfolios.mintfCashPair(), which mints a brand new offsetting pair on the spot, a design built for OTC block trades. That function's only safeguard is a free collateral check on the payer, computed in Portfolios._freeCollateral() and converted into an ETH value by Escrow.convertBalancesToETH(). The entire system's solvency rests on that one conversion being correct.
An attacker-controlled helper contract deployed four disposable contracts.
The helper contract then called safeTransferFrom on Notional's ERC1155 fCash token, which routed into Portfolios.mintfCashPair(). That function creates a new payer and receiver position in a single call and checks free collateral on the payer only, an assumption written directly into the code that the receiver's position always increases and therefore needs no check of its own.
The same account acted as payer twice in a row, first for a notional of 1, then for a notional of 340282366920938463463374607431768211455, the maximum value a uint128 can hold. Combined, the two debts summed to exactly 2¹²⁸, a boundary value chosen with precision rather than brute force.
That combined debt reached Escrow.convertBalancesToETH(), which calls ExchangeRate._convertToETH() to price the payer's balance in ETH for the solvency check. Inside that function, uint128 absBalance = uint128(balance.abs()) casts the debt with a raw, unchecked cast rather than SafeCast.toUint128(). A value of exactly 2^128 truncates cleanly to 0 in that cast, so the largest debt mathematically possible was read as owing nothing.
The second disposable contract, 0x84A060Ed81316E6741Af216A099cFea8bCDd3489, the one holding that fabricated 2¹²⁸-1 claim, passed its own free collateral check on the strength of it, even after Notional’s standard haircut, a claim that size dwarfs any real-world debt. It called safeTransferFrom twice more, once with a notional of 69,257,372,677,950,923,155,658 sent to a third contract, 0x265ccfF3673bCAb03867988081cd51bFd919C03C, once with a notional of 1,658,524,864,122 sent to a fourth contract, 0x4a3508C5aC0677325932f3bC786Ae7A1C3e9CAfF.
Both calls routed through mintfCashPair() again, so the third contract came away holding a receiver claim exactly equal to Escrow's real DAI balance, and the contract came away holding a receiver claim exactly equal to Escrow's real USDC balance.
In a second transaction, Portfolios.settleMaturedAssets() converted the third contract fabricated claim into a real, internally tracked Escrow cash balance, and Escrow.withdraw() checked that balance, found no offsetting debt, and paid out 69,257.372677950923155658 DAI from Escrow to 0x265ccfF3673bCAb03867988081cd51bFd919C03C, which forwarded the full amount to the attacker's main address, 0xDaCC235a494750193695A111D715c2ca12b5Ce38, in the same transaction.
The same transaction repeated the process for the fourth contract, settling its fabricated claim into an Escrow cash balance and paying out 1,658,524.864122 USDC from Escrow to 0x4a3508C5aC0677325932f3bC786Ae7A1C3e9CAfF, which likewise forwarded the full amount to 0xDaCC235a494750193695A111D715c2ca12b5Ce38.
The root cause is an unchecked, raw uint128() cast on a debt balance inside ExchangeRate._convertToETH(), in place of the reverting SafeCast.toUint128() used elsewhere in the same file.
Two things made that cast reachable in the first place. Portfolios.mintfCashPair() checks solvency on the payer only, so a fabricated debt on one account is never caught by a check on the account that actually benefits from it.
RiskFramework.sol itself computes the debt correctly, using safe, reverting arithmetic throughout, which meant the attacker had to engineer one exact value rather than exploit sloppy math earlier in the chain. Each factor on its own would have limited the damage, together they turned a single missing bounds check into a full drain.
Type-boundary fuzzing on every narrowing cast. Fuzzing _convertToETH() and every other raw uint128() or uint256() cast with boundary values, 0, 2^128 minus 1, and 2^128 itself, would have surfaced the exact wrap that zeroed out the payer's debt.
Two-sided solvency checks on any function that mints offsetting positions. A review of mintfCashPair() against the principle that both sides of a newly created payer and receiver pair need verification, not just the side assumed to be taking on risk, would have flagged the one-sided freeCollateral(payer) check as a design gap on its own, independent of the cast bug.
A project-wide ban on raw narrowing casts in solvency-critical paths. A lint rule or manual pass flagging every uint128(x) or uint256(x) cast on a value that can carry adversarial input, requiring SafeCast or an explicit bounds check instead, would have caught this specific line even without the fuzzing pass above.
The DAI and USDC withdrawn from Escrow were moved through intermediary wallets and consolidated into a single address.
That address swapped the combined DAI and USDC for approximately 689.2 ETH.
The ETH was then deposited into Tornado Cash.
At the time of writing, Notional Finance has not published a tweet, statement, or post-mortem addressing this incident, and has not disclosed an official loss figure or confirmed root cause. This section will be updated once the protocol responds.
Attacker EOAs
Vulnerable Contracts
Attacker Contracts
Key Transactions
This was not a flash loan attack and not a price manipulation. It was a single unchecked cast, uint128(balance.abs()), sitting inside a function that turns a debt balance into an ETH-denominated solvency check. Because Notional's fCash minting function trusted that check completely and only applied it to one side of every new position, an attacker who could engineer one specific number, 2^128, could make the largest possible debt look exactly like zero. Roughly $1.73M in DAI and USDC left Notional's V1 Escrow contract as a result, swapped to ETH and moved into Tornado Cash. In a system built entirely on solvency checks, the check itself has to be the most carefully verified line in the codebase, because everything downstream believes whatever number it returns.
Original Posted at QuillAudits
Notional Finance $1.73M Free Collateral Integer Overflow Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
On August 18, 2026, an attacker chained six bugs in MAYAChain’s trade account and outbound-handling logic to drain the Asgard reserve. No key was stolen, and this wasn’t a flash-loan drain: a single batched deposit triggered a false theft alert, and an uncapped slash subsidy turned that into 48.87M forged CACAO in one thin pool. The attacker cashed out through it, extracting roughly $1.7M.
MAYAChain settles cross-chain swaps through its Asgard vaults, with every observed transaction tracked against a shared ObservedTxVoter record. A single MsgDeposit can batch multiple actions together, including trade-account swaps and a DONATE action, all reported against that same voter. When an outbound transaction appears to go missing, the chain treats it as theft and slashes a subsidy into the affected pool to make it whole, a safety mechanism this exploit turned into the attack itself.
MAYAChain’s protection against a receipt being processed twice lives in a shared ObservedTxVoter record, one per native transaction ID. Inside the handler for a batched MsgDeposit, every message in the batch creates its own fresh voter and overwrites whatever was there before via SetObservedTxInVoter(). A transaction with enough messages can let its last message quietly erase what every earlier message had recorded.
The attacker used exactly that. A single MsgDeposit carrying 23 messages ran 20 trade-account swaps into ARB.ETH, two more into ARB.LINK, and closed with a one-unit DONATE:ARB.LINK message. That final message overwrote the voter the earlier trade withdrawals had set, resetting OutboundHeight to 0 and marking the whole transaction done.
Check here in rwa data: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7
With OutboundHeight zeroed, the outbound matcher fell back to FinalisedHeight and scanned forward in fixed increments, but it never checked the one block where the LINK outbounds had actually landed. Finding no record there, the chain concluded the outbound had gone missing and triggered its theft-detection slash.
That slash path converts the supposedly stolen amount into CACAO at the pool’s own exchange rate, with nothing capping the result against how much asset the pool actually holds. The ARB.LINK pool had only about 0.11 LINK in it, so running the stolen amount through that rate produced a number completely detached from reality: roughly 49.45 million CACAO, booked straight into the pool.
The code writes that inflated pool balance to state before it actually tries to fund it from the reserve. The reserve only held about 168,000 CACAO, so the funding transfer failed, but the pool’s new balance had already been saved. The handler that caught the failure just logged it and marked the transaction done anyway, with no rollback, leaving the inflated pool sitting in state as if it were real.
With a pool now showing tens of millions of CACAO against almost no LINK, the attacker added a small amount of liquidity to it. The pool-unit math treated the deposit as founding a fresh pool, handing over 99.93% ownership, and an immediate withdrawal at 9,900 basis points paid out 48.87 million CACAO from the Asgard module. The attacker moved straight into swapping it for BTC, ETH, RUNE, and stablecoins across every Maya pool.
It was six separate weaknesses lining up in one transaction. The root failure is that a shared observed-transaction voter could be silently overwritten by a later message in the same batched deposit, and everything downstream, theft detection, the slash subsidy, and the funding transfer, trusted that voter’s state without re-checking or bounding it against reality.
Once the final DONATE message reset the voter, the outbound matcher's fallback logic never checked the right block, the slash subsidy calculation never capped itself against the pool's real balance, and the code that wrote the inflated pool to state ran before the code meant to fund it, with the resulting failure just logged and swallowed instead of rolled back. Any one of those checks alone would have stopped the drain, bind the voter to something a later message can't clobber, cap the subsidy to what the pool can actually hold, or roll back state when a downstream transfer fails.
Voter integrity across batched messages. Any check whose entire security model rests on a shared record needs a guarantee that record can’t be overwritten by an unrelated message later in the same batch. A review tracing every writer of ObservedTxVoter would have caught SetObservedTxInVoter clobbering per-message state in handler_deposit.go.
Bound every subsidy calculation to the pool’s actual balance. The AssetValueInRune call behind the slash subsidy had no ceiling tied to pool.BalanceAsset, so a thin pool could be told it held tens of millions of CACAO it never had. Any function that credits a balance from a computed value needs an explicit sanity cap against the resource it's crediting.
Never commit state ahead of the transfer meant to back it. SetPool ran before SendFromModuleToModule in helpers.go, so when the transfer failed, the inflated state had already been saved. Persisted state should follow a successful funding transfer, not precede it, and a failed downstream call should roll back what came before it rather than just log and continue.
The attacker immediately began swapping the drained CACAO into BTC, ETH, RUNE, and stablecoins across every Maya pool.
20.82 BTC, worth about $1,343,367, moved to bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646. As of now they are still in attacker wallet
Meanwhile on ethereum attacker has deposited some eth in tornado cash.
Maya founder posts an initial public message calling it sad news and saying it will work to fix the issue and recover in full.
Maya confirms the exploit to its community, roughly 20 BTC and $300k in other assets, says it has done a global halt to contain the damage, and shares the attacker’s Bitcoin address in case they’re open to a bug bounty.
Maya commits $200,000 of the team’s own funds into the pools as a first step in the recovery process.
Maya says it will accelerate the launch of its Aztec Chain platform and direct a share of the funds it raises back into the pools to help recover from the exploit.
Maya sends the attacker a message through a Bitcoin OP_RETURN transaction, asking them to return the funds and offering a bug bounty in exchange.
Attacker Wallet
Affected Pool
Key Transactions
No key was stolen, and no single bug did this on its own. A shared voter that a later message could silently overwrite was trusted by every check downstream of it, theft detection, the slash subsidy, and the transfer that was supposed to back it, and none of them verified what the others had already gotten wrong. A pool with barely any liquidity ended up crediting tens of millions of CACAO to itself, and the attacker just had to show up and withdraw it. Six checks failed in sequence; one working boundary anywhere in that chain would have stopped it.
Original Posted at QuillAuidts
MAYAChain $1.7M Slash Subsidy Pool Inflation Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Launching a crypto exchange can look straightforward from the outside.
You choose the trading model, add a few cryptocurrencies, connect wallets, build a trading interface, and prepare for launch.
But founders who have worked on real exchange projects know that the difficult part usually starts after the basic platform is in place.
A trading engine that slows down during high-volume periods. A wallet architecture that creates unnecessary security risks. Liquidity that looks sufficient during testing but disappears when real users arrive. Compliance requirements that were considered too late. These issues can turn an exciting launch into an expensive rebuild.
That is why a proper crypto exchange checklist matters before development begins.
Here are the areas founders should evaluate before committing resources to an exchange project.
Not every crypto exchange should be built the same way. Your first decision should be the type of exchange you want to operate.
Common models include:
Each model affects the technology architecture, liquidity strategy, custody approach, security requirements, trading functionality, and regulatory considerations.
For example, a centralized exchange generally requires components such as user accounts, custodial wallets, an order book, matching engine, admin controls, and liquidity integrations.
A decentralized exchange has a very different architecture because trading logic can rely heavily on smart contracts and blockchain infrastructure.
Choosing the model after development has already started can create unnecessary changes to the entire platform.
A beautiful exchange with poor liquidity will struggle to retain traders.
Users expect orders to execute at competitive prices without excessive slippage. If the order book is thin, traders may move to another platform even if your interface and features are excellent.
Before development, decide how liquidity will be sourced.
Possible approaches include:
The right approach depends on the exchange model and target market.
Liquidity should be considered part of the initial business and technical strategy, not something added immediately before launch.
The matching engine is one of the most important components of a centralized exchange.
It determines how buy and sell orders are processed and matched.
Founders should ask:
A platform can have an impressive frontend while still delivering a poor trading experience if the backend cannot handle real market activity.
Performance testing should therefore happen before launch, not after users start complaining about delays.
Security shouldn’t be a final development phase.
An exchange handles valuable assets, sensitive user information, authentication credentials, transaction data, and trading activity. A weakness in any of these areas can have serious consequences.
A security checklist may include:
Cold and hot wallet management also deserves careful planning, particularly for custodial exchanges.
The goal isn’t simply to add security features. The architecture itself should be designed to reduce unnecessary attack surfaces.
Wallet functionality is another area founders sometimes underestimate.
If the exchange supports multiple cryptocurrencies and blockchain networks, wallet infrastructure can become increasingly complex.
You may need to manage:
Supporting an asset isn’t just a matter of displaying its symbol on the trading screen.
The backend needs to correctly handle blockchain transactions and maintain accurate balances across the platform.
Compliance requirements can influence the architecture of an exchange.
Depending on the target market and operating model, founders may need to consider areas such as KYC, AML, transaction monitoring, user verification, data protection, licensing, and reporting requirements.
This is where a common mistake happens.
A founder builds the platform first and starts thinking about compliance later.
That can force major changes to onboarding flows, transaction monitoring, user management, reporting systems, and administrative controls.
Compliance requirements should therefore be mapped against the product architecture from the beginning.
A competitor may have 200 trading pairs, advanced charts, copy trading, staking, bots, margin trading, and multiple payment options.
That doesn’t mean your first release needs all of them. Start by identifying the features that directly support your target users.
For example, an initial exchange may prioritize:
Additional features can be introduced as the user base and trading activity grow.
A focused platform is often easier to test, secure, and operate than an overloaded first release.
This decision can affect almost every other item on the checklist.
Don’t evaluate a development company only by its portfolio screenshots or quoted development cost.
Ask about its experience with:
It is also useful to understand whether the team has experience building the specific exchange model you are planning.
If you’re comparing development teams, reviewing a company’s cryptocurrency exchange development services can give you a better idea of the technologies, exchange models, and functionality that can be included in a platform.
The important point is to evaluate technical capability, not just marketing claims.
A platform working correctly with ten test users doesn’t prove much. Before launch, test scenarios that resemble real activity.
For example:
Load testing and failure testing can reveal problems that aren’t visible during normal development.
The earlier these issues are found, the cheaper they usually are to fix.
Scalability doesn’t mean building the biggest possible infrastructure from day one.
It means creating an architecture that can grow without forcing a complete rebuild.
Think about future requirements such as:
A modular architecture makes it easier to introduce these capabilities over time.
Founders often focus heavily on the trader interface and overlook the administration system.
But exchange operators need strong internal tools to manage the platform.
An effective admin dashboard may include:
The admin panel is effectively the control center of the exchange. It needs the same level of planning as the user-facing application.
Before moving toward launch, ask yourself:
Exchange model: Is the platform architecture appropriate for the trading model?
Liquidity: Do we have a realistic strategy for maintaining liquidity?
Performance: Can the matching and trading infrastructure handle growth?
Security: Have wallet, API, authentication, and transaction risks been addressed?
Compliance: Have applicable requirements been considered from the beginning?
Wallets: Can the infrastructure safely support the assets and networks we plan to offer?
Scalability: Can the platform handle more users and trading activity without a major rebuild?
Admin tools: Can the operations team actually manage the exchange efficiently?
Testing: Has the platform been tested under realistic traffic and failure conditions?
Development partner: Does the technical team have relevant exchange development experience?
The biggest mistake isn’t forgetting one feature.
It’s starting development before understanding how all the important components fit together.
A crypto exchange is more than a trading interface. It is a combination of trading infrastructure, wallet systems, blockchain connectivity, liquidity, security, compliance, administration, and scalability.
If these areas are planned independently, problems tend to appear later when they are more expensive to solve.
A good checklist forces founders to think beyond the launch screen.
Before asking how quickly an exchange can be built, ask a more important question:
Will the architecture still work when real users, real transactions, and real trading volume arrive?
That question can save months of development time and prevent costly decisions from becoming permanent problems.
The Crypto Exchange Checklist Most Founders Skip — And Regret Later was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Inside the false positives, bias, and liability gaps AI creates in crypto compliance
The expansion of financial activities related to digital assets has created a difficult compliance problem.
Virtual asset service providers (VASPs) process large volumes of transactions across wallets, exchanges, blockchains, and jurisdictions – simultaneously, regulators expect them to verify customers, monitor transactions, detect suspicious activity, screen for sanctions, and keep detailed records.
Traditional compliance systems weren’t built for that kind of speed and volume.
Artificial intelligence offers a possible solution.
It can process large datasets, identify transaction patterns, assess risk, and automate parts of compliance. For crypto businesses, this creates an opportunity to make compliance faster and more responsive.
However it also creates a legal problem.
If a VASP relies on an AI system to make or support compliance decisions, who remains responsible when the system gets it wrong?
That question is becoming increasingly important as AI moves from assisting compliance teams to influencing decisions that can directly affect customers and transactions.
Compliance in crypto markets presents some characteristics that are different from traditional financial services.
Blockchain transactions run 24/7, across borders, often between wallet addresses that don’t obviously reveal who’s actually behind them. A VASP may therefore need to assess not only its customer but also the transaction history associated with a wallet and a single customer may interact with multiple wallets, decentralised protocols, exchanges, and other services.
That’s an enormous amount of information for a human team to review by hand – which is exactly the kind of problem AI is good at.
AI can support several stages of the compliance process.
AI can assist with customer onboarding by automating parts of identity verification.
The systems can analyse identification documents, compare information across databases, detect inconsistencies and, where appropriate, support biometric or liveness verification. This can reduce the amount of manual work involved in onboarding customers but automation does not eliminate the need for proper customer due diligence.
A system can verify the authenticity of a document without confirming the identity of the presenter. Thus, the quality of the data and the design of the verification process are crucial.
This may be one of the most significant applications of AI in crypto compliance.
Instead of reviewing transactions one at a time, AI can scan for patterns across thousands of wallets at once – rapid movement between addresses, connections to high-risk wallets, behavior that looks designed to dodge reporting thresholds, or links between addresses that seem unrelated on the surface.
The system can then assign a risk score or generate an alert for further investigation.
An AI-generated alert doesn’t confirm money laundering or fraud; it just indicates a pattern that may need human investigation.
AI can assist crypto businesses with sanctions and risk screening. A compliance system may compare wallet addresses, transaction histories, and customer information against relevant sanctions lists and other risk databases.
It can also help identify relationships that are not immediately apparent from a simple name or address search. This can be particularly useful in a market where transactions may involve pseudonymous blockchain addresses rather than conventional bank-account identifiers but the reliability of the outcome depends heavily on the information being used.
An incomplete database misses real risks, and an oversensitive model buries compliance teams in false alarms.
AI can also assist with the process that follows transaction monitoring.
Where a system identifies potentially suspicious activity, it can help compliance teams organise the relevant information, prepare internal case files and support regulatory reporting.
Natural language processing can also assist in reviewing regulatory guidance and identifying changes in compliance requirements.
Automated reporting comes with its own risks. A suspicious transaction report is more than a technical output; it can carry regulatory and legal implications. A VASP must therefore understand how the automated system makes decisions and ensure proper oversight of the reporting process.
A VASP can use AI for compliance tasks, but the AI does not become the regulated entity; the business still holds the regulatory responsibility.
If an AI system fails to identify suspicious transactions, incorrectly classifies customers as low-risk, or produces defective reports, the VASP may still have to answer to its regulator.
Using someone else’s AI tool doesn’t transfer your compliance obligations to them.
This follows a fundamental principle in financial regulation that outsourcing or automating a function does not equate to relinquishing accountability for that function.
In practice, that means a crypto business needs to actually understand its own AI system – what it does, what data it uses, how it was tested, and where a human needs to step in.
AI systems can sometimes miss detecting suspicious activity or misidentify legitimate actions as potentially harmful.
Imagine a customer who regularly transfers digital assets between several wallets because they use different wallets for different purposes. An AI model may interpret the pattern as suspicious because it resembles behaviour associated with layering or asset movement.
The customer’s account may then be restricted or subjected to additional review. If this happens repeatedly, legitimate customers get fed up with unnecessary friction, and the compliance team drowns in false alarms.
The objective therefore is to create a system capable of distinguishing between unusual activity and genuinely meaningful risk.
AI systems learn from data.
If the data used to train or configure a system is incomplete, inaccurate or biased, the resulting compliance decisions may also be problematic.
For example, a risk model may disproportionately classify certain transaction patterns as high risk because of the way its historical data was constructed.
How then does a VASP know that its AI compliance system is producing fair and reliable results?
The answer requires more than purchasing an AI compliance tool. Businesses may need appropriate testing, validation, monitoring and periodic review of the system.
A human compliance officer can generally explain why a customer was flagged for review.
An AI system may produce a risk score without providing an explanation that a human reviewer can easily understand.
That’s a real problem when the AI’s decision affects someone’s account or blocks their transaction. If a business restricts a customer because a model called them high-risk, someone inside that business needs to be able to explain why – in plain terms, to the customer and potentially to a regulator.
This means that the business should have sufficient understanding and documentation to explain and defend the compliance process.
AI-powered compliance systems may process significant amounts of personal and financial information.
This can include: identity documents, biometric information, transaction histories, wallet addresses, device information, IP addresses, behavioural patterns and information about counterparties.
When these datasets are combined, a VASP may be able to create a detailed picture of a customer’s financial behaviour.
That creates data-protection and privacy concerns.
The fact that blockchain transactions may be publicly visible does not mean that every piece of information derived from those transactions can be processed without restriction.
A VASP using AI therefore has to consider not only whether the system is effective but also whether the data is collected, processed, stored and shared lawfully.
Picture three failures: the AI misses genuine fraud, wrongly tags a legitimate customer as high-risk, or blocks a real transaction on a false positive.
In each case, the technology may have failed.
However, the legal responsibility does not necessarily stop there.
The VASP chose the system.
The VASP integrated it into its compliance process.
The VASP relied on its output.
The VASP remains subject to the regulatory obligations applicable to its business.
This does not mean an AI provider can never be liable. Where the provider’s system fails to perform as contractually promised, contains a material defect, or the provider’s own conduct contributes to the compliance failure, liability may arise under the applicable law.
However, the VASP remains responsible for its regulatory obligations because it chose to use an AI system.
The most workable model right now is AI and humans working together, not AI replacing the team outright.
Let AI do what it’s good at: collect, analyze, detect, score, flag. Human compliance professionals can then investigate, assess context, and make decisions where human judgment is necessary.
Human involvement is crucial for high-impact decisions, and the required level varies based on the function being automated.
The key is to ensure that automation does not become a substitute for accountability.
If AI is becoming part of the compliance infrastructure of a VASP, then AI governance itself should become part of the compliance framework.
Any business using these tools should be able to answer some basic questions:
What compliance function does the AI perform? What data does it rely on? How was the system tested? How accurate is it? How are false positives handled? Who reviews its decisions? How are errors corrected? How is the system monitored after deployment? What happens when the model changes?
These questions are critical because AI systems can significantly accelerate and expand the scale of compliance decision-making.
Regulators aren’t against AI in compliance – used well, it can make AML systems faster and more effective at catching real risk. However, regulators also need assurance that businesses are not using AI as a black box.
A VASP should not be able to say:
“The algorithm made the decision.”
That defense may be insufficient where the business remains responsible for the underlying compliance function.
Regulatory attention will continue to shift toward governance, accountability, data quality, testing, explainability, and audit trails, not just whether a company has “AI-powered compliance” on its website.
The use of AI in crypto compliance is not necessarily a choice between humans and machines.
AI is genuinely well-suited to problems involving huge volumes of data and constant monitoring. Human judgment still matters wherever context, discretion, and real consequences are on the line.
The real challenge is deciding where the boundary should be. AI can make crypto compliance faster, broader, and sharper.
What it can’t do is absorb the responsibility that comes with getting it wrong. The real test for crypto companies is whether they can use it without turning it into a gap where accountability quietly disappears.
If you enjoy analytical commentary on digital asset regulation, crypto markets, and emerging financial technologies, consider subscribing to my newsletter where I share additional research, commentary, and industry insights.
https://samuel-ayodeji.kit.com/profile
Also, if your company, startup, or publication needs clear, well-researched content on blockchain, digital assets, fintech, or emerging technology law, my inbox is always open.
Can Crypto Companies Outsource Compliance to AI? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Ethereum looks unusually calm.
After climbing more than 30% in August, ETH has spent the first part of September moving in a narrow range, repeatedly testing the $2,500 mark without finding enough momentum to break higher.
But beneath that quiet price action, the Ethereum market is anything but still.
Treasury companies are continuing to accumulate ETH. Exchange balances are falling. ETF demand has cooled but remains positive overall. At the same time, developers are preparing major changes to Ethereum’s infrastructure, with Glamsterdam approaching and the longer-term Hegotá roadmap beginning to take shape.
So while ETH is moving sideways, several important pieces are falling into place.
ETH has spent much of the recent period between $2,480 and $2,520.
The repeated attempts to reclaim $2,500 show that buyers are still defending the psychological level, but resistance around $2,525–$2,535 has kept the upside contained. Beyond that, $2,550 remains the more important barrier.
A decisive move above $2,550 could put $2,600 back on the radar and potentially open a path toward the $3,000 area if momentum returns.
The downside is equally clear.
The first support zone sits around $2,475–$2,485. A break below it could expose $2,430–$2,445.
Some technical charts have also produced a golden cross, generally viewed as a longer-term bullish signal. But technical indicators alone cannot overcome weak market participation.
That is particularly important now, with investors watching the Federal Reserve meeting scheduled for September 15–16.
For the longer-term picture, current ethereum price prediction scenarios are likely to depend heavily on whether ETH can turn this consolidation into a sustained breakout rather than another temporary rally.
One of the clearest differences in the current market is happening between different groups of ETH holders.
Wallets holding between 100 and 10,000 ETH reportedly sold around 307,000 ETH last week.
Whales, meanwhile, bought roughly 82,000 ETH.
That does not necessarily mean the market is turning bearish. It may simply indicate that some investors are taking profits after August’s rally while larger players are building longer-term positions.
BitMine Immersion Technologies is perhaps the clearest example.
The company bought another roughly 28,086 ETH, worth around $69–70 million, bringing its reported holdings to approximately 5.93 million ETH.
That represents close to 4.9% of Ethereum’s total supply.
The scale is difficult to ignore. BitMine has continued buying even while its holdings remain below the average purchase price on paper, with a large portion of its ETH also being staked.
This is a very different approach from short-term trading.
Abraxas Capital has also been active.
The firm reportedly purchased around 13,000 ETH, worth roughly $32 million, in the spot market.
But the reason is particularly interesting: part of the purchase was reportedly used to hedge a much larger short position of around 141,000 ETH on Hyperliquid.
In other words, not every large ETH purchase represents a straightforward bullish bet.
Elsewhere, an early Ethereum holder reportedly sold around 11,023 ETH through Wintermute, while Justin Sun continued moving ETH after withdrawing additional funds from Lido.
The takeaway is simple: whale activity is increasing, but it is not pointing in one clear direction.
Some large holders are selling. Others are accumulating. Some are hedging.
The spot Ethereum ETF market tells a similar story.
Weekly inflows reportedly fell to around $218 million, down sharply from approximately $824 million the previous week. Some individual trading sessions also saw net outflows.
That is a noticeable slowdown.
Still, it would be premature to interpret weaker ETF flows as disappearing institutional interest.
Another part of the supply picture is moving in the opposite direction.
More than 116,000 ETH reportedly left exchanges within a 48-hour period at one point. Fewer ETH sitting on exchanges can mean less immediate selling pressure, although it does not guarantee that prices will rise.
Institutional infrastructure is also expanding. Standard Chartered has reportedly increased access to deliverable ETH spot trading for institutional clients in the UAE.
The market, therefore, is seeing slower demand in one area while institutional participation continues to develop elsewhere.
If the price chart looks boring, Ethereum’s development roadmap certainly does not.
The Ethereum Foundation’s Protocol Cluster recently released its first unified ranking of 62 proposed EIPs for the planned Hegotá upgrade.
Two proposals were placed among the highest-priority changes.
EIP-7805, or FOCIL, is aimed at strengthening censorship resistance by helping enforce transaction inclusion.
EIP-8141, known as Frame Transactions, could address one of Ethereum’s long-standing user-experience problems: needing ETH simply to pay transaction fees.
The proposal could eventually allow users to pay gas with stablecoins such as USDC or USDT while also supporting native account abstraction and new authentication approaches.
That could make interacting with Ethereum feel considerably simpler for ordinary users.
There is also a much longer-term objective behind the roadmap: quantum resistance for Ethereum’s Layer 1, with December 2029 currently highlighted as an important target.
Hegotá is still further down the road.
Before that comes Glamsterdam, Ethereum’s next major upgrade, currently targeted for Q4 2026.
The upgrade is focused heavily on improving Layer-1 performance.
Developers are working on enshrined proposer-builder separation, block-level access lists, gas repricing and higher gas limits.
One of the targets is a gas-limit floor of around 200 million, which could significantly increase Ethereum’s capacity if implemented successfully.
The Sepolia testnet fork is expected around September 28 or early October.
That makes the coming weeks important for more than just ETH traders. They will also provide another look at how Ethereum’s technical roadmap is progressing toward mainnet.
Ethereum’s broader ecosystem is changing alongside the core network.
Lido has launched the testnet for its 0x02 Community Staking Module, designed to support compounding validators with balances of up to 2,048 ETH.
If approved for mainnet, the change could improve capital efficiency for staking operators.
Scroll, meanwhile, is taking a very different path.
The Ethereum Layer-2 project has announced plans to gradually transition from a general-purpose public chain toward a more application-specific network built around its Compass AI ecosystem.
The transition is expected to take roughly nine months. Scroll also plans to move the SCR token to Ethereum mainnet without changing its existing supply or tokenomics.
Elsewhere, Trezor has added Clear Signing support through ERC-7730, another effort aimed at making blockchain transactions easier to understand before users approve them.
Ethereum does not currently have one giant catalyst capable of deciding its next move.
Instead, several smaller forces are pulling the market in different directions.
Retail holders are selling.
Treasury companies are accumulating.
ETF inflows have slowed.
Exchange balances have declined.
ETH is sitting near $2,500.
And Ethereum’s developers are preparing some of the network’s most important changes in years.
That leaves traders with a fairly simple near-term map.
A sustained move above $2,550 would strengthen the bullish case, while a break below $2,475 could shift attention toward $2,430–$2,445.
Until one of those areas gives way, Ethereum may continue to consolidate.
But the lack of dramatic price movement should not be confused with a lack of activity.
The market may be quiet on the surface, but underneath it, Ethereum is going through a period of accumulation, repositioning and infrastructure development.
The next major move in ETH may ultimately depend not on one headline, but on which of these trends gains the upper hand.
Ethereum Is Quiet at $2,500. But the Bigger Story Is Happening Underneath was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
A valid signature confirms that a wallet approved a message. Proving that the wallet belongs to a project requires more evidence.
A valid wallet signature proves a narrow fact: a specific wallet approved a specific message. It does not, by itself, prove that the wallet belongs to a crypto project, that the signer is authorized to represent the team, or that the statement is true. Verifying an official project wallet requires both cryptographic proof and a reliable link between the wallet and the project.
Editorial note: This article was developed with AI assistance and reviewed against primary technical standards.
Imagine that a new crypto project publishes a wallet address on its website. Next to the address, you see a signed message saying, “This is our official wallet.”
The signature verifies correctly. It feels like strong evidence, and it is. But it answers only one part of the question.
It shows that the wallet approved the message. It does not establish who operates the website, whether the signer represents the project, or whether the wallet still has the same role today.
A wallet signature connects three elements:
When the signature is verified, it shows that the signing authority associated with the wallet approved that message.
For a standard wallet controlled by a private key, this usually means that someone with access to the key signed it. Multisignature accounts and smart-contract wallets may use different verification methods, so the network and account type still matter.
A valid signature also protects the integrity of the message. If someone changes a word, address, or date after it was signed, the original signature should no longer verify against the modified message.
The NIST Digital Signature Standard makes an important distinction here. Verifying a signature and confirming the identity associated with a public key are separate tasks. The cryptography can validate the signature, but it cannot create the real-world identity link on its own.
A valid signature does not automatically prove that:
This last point is easy to overlook. A wallet can sign a false or exaggerated statement. The signature proves that the wallet approved the words. It does not prove that the words are true.
Think of a signature as an answer to one precise question:
Did this wallet approve this exact message?
If the real question is “Does this wallet officially represent the project?”, another layer of evidence is needed.
A signature has meaning only when you can read what was signed.
A request that simply says “Sign this message” provides very little context. It does not explain which project is involved, what the signature authorizes, or how long the claim should remain valid.
A useful signed message should identify the wallet, the requesting domain, the network, and the purpose of the signature. When appropriate, it should also include a unique nonce, an issue time, and an expiration time. These details make the claim clearer and reduce the risk of an old signature being reused in a different context.
The Sign In With Solana specification provides a structured format for wallet authentication. A Sign In With Solana message can include the domain, wallet address, statement, network, nonce, issue time, expiration time, request identifier, and related resources. The verifier receives the account, the signed message, and the signature.
Sign-In with Ethereum, ERC-4361, follows a similar approach for Ethereum accounts. Its message format includes the domain, address, URI, chain ID, nonce, and issue time. The verifier is expected to check those fields as well as the signature.
These standards focus on authentication, but they illustrate a broader rule: the wording of the message defines the limits of the proof.
A signature authorizing a login does not prove that the wallet controls a project treasury. A message confirming one website does not automatically verify every social account using the same project name. A signature created several months ago may no longer describe the wallet’s current role.
Suppose you discover an unfamiliar website claiming to represent a crypto project.
The website lists a wallet as official. That wallet then signs a message saying the website is official.
The signature may be completely valid, but the evidence is circular. The website identifies the wallet, and the wallet validates the website. If the same unknown person controls both, nothing outside that circle confirms the project’s identity.
A stronger verification starts from a source whose relationship to the project is already established. This might be a previously known domain, maintained documentation, or an official channel with a verifiable history.
That source identifies the wallet and explains its role. The wallet can then sign a fresh message that refers to the same project, domain, and purpose.
The two pieces of evidence support different parts of the claim:
Neither should be expected to do both jobs alone.
You can review an official wallet claim without connecting your own wallet or sending a transaction.
Start by asking what the wallet is supposed to represent.
Is it a treasury wallet, a contract deployer, a token authority, a profile administrator, or simply a public contact address?
The label “official wallet” is too broad if no role is given. A wallet may be official for one purpose without being authorized for every project activity.
Look for the complete wallet address on a project website, in maintained documentation, or through another channel whose history you can verify.
Do not rely only on a search result, private message, screenshot, or token name displayed inside a wallet. Those sources may help you discover the address, but they do not establish its identity.
Compare the complete address. Shortened forms are useful for display, but not for final verification.
Check exactly what the wallet approved.
The message should make the project, domain, network, wallet address, and purpose clear. If the signature is intended to confirm a current relationship, look for an issue time and a reasonable expiration time.
Do not verify a wallet signature from a screenshot alone. The original message and signature data are necessary because a screenshot can hide missing fields or remove important context.
Use a verifier that supports the relevant blockchain and account type.
Confirm that it checks the exact message you read and the exact wallet address being claimed. If a structured standard such as Sign In With Solana or Sign-In with Ethereum is being used, the expected fields should also be checked.
A “valid” label is only meaningful if you understand what the verifier actually tested.
If the project describes the wallet as a deployer, treasury, token authority, or another on-chain role, inspect the relevant blockchain records separately.
The signed message shows what the wallet claims. The blockchain can show what the wallet or related account has done.
For example, signing a message that says “We deployed this contract” does not replace checking the deployment transaction. Claiming to manage a token authority does not replace inspecting the authority recorded on-chain.
Wallet roles can change.
A project may rotate its treasury wallet, revoke an authority, replace a team member, or move to a multisignature setup. A signature that was accurate when created may become outdated later.
Save the full address, signed message, signature, source, stated role, and verification date. This turns an isolated badge into evidence that can be reviewed again.
Yes. A signature can be cryptographically valid while the conclusion drawn from it is wrong.
This may happen when the message is vague, the wrong domain or network is named, an old signature is presented as current, or the website and wallet only validate each other.
It can also happen when the signature is interpreted too broadly. A wallet may confirm control of one profile without controlling the project treasury. A founder may sign a message personally without proving that the wider team authorized the statement.
The signature remains valid. The interpretation is the part that fails.
No. Identity and safety are separate questions.
Even a well-documented project wallet can interact with risky contracts, retain powerful token permissions, manage concentrated funds, or become compromised later.
A wallet signature does not audit a smart contract. It does not explain token liquidity, holder concentration, mint permissions, or future behavior.
It should be treated as one useful piece of evidence, not as a final verdict about the project.
Before accepting an official project wallet claim, ask:
If one answer is missing, leave it marked as unknown. Do not let a verification badge answer a question the available evidence does not cover.
A valid wallet signature proves that a wallet approved a specific message. It does not independently prove that the wallet officially represents a crypto project.
To verify the broader claim, connect the wallet to an established project source, read the complete message, check its purpose and date, verify the signature correctly, and inspect any claimed on-chain role separately.
Wallet signatures are valuable because they provide precise evidence. The mistake is asking them to prove more than they can.
Save the address, message, signature, source, role, and verification date before relying on an official wallet claim.
Does a Wallet Signature Prove a Crypto Project Is Official? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
A token most traders had never heard of a week ago just ripped 250% in 24 hours and briefly touched an all-time high. No celebrity endorsement. No exchange listing. No viral tweet from a billionaire. Just a plumbing upgrade.
That’s the story of STONK, the native token of Solana launchpad StonkFun, and it’s one of the more interesting case studies in crypto market structure this year — because the rally wasn’t really about STONK at all. It was about what happens when a fast-growing app plugs directly into the dominant liquidity layer of an entire blockchain.
If you trade Solana tokens, watch DeFi, or just want to understand how integrations move markets in 2026, this one is worth unpacking in detail.
On Saturday, September 6, 2026, StonkFun announced it was integrating with Raydium’s LaunchLab, the token-launch infrastructure built by Solana’s largest decentralized exchange. The next day, the numbers told the story:
Three tokens across three different projects all moved together, in the same direction, on the same news. That’s not a coincidence. It’s how integrations work when they touch the core of a network’s liquidity.
StonkFun is a Solana-based token launchpad, but with a twist that separates it from the thousands of meme-coin factories that have come and gone: it lets users create tokens paired against real-world financial assets — tokenized stocks, ETFs, commodities, and currencies — rather than just pairing new tokens against SOL or stablecoins.
The flagship example is STONK itself, which trades against SPYx, a tokenized product from Backed Finance designed to track the S&P 500 through the SPDR S&P 500 ETF. Other pairs on the platform link tokens to assets like ZCash, Hyperliquid, and Bittensor.
It’s important to be precise about what this actually means for holders: pairing a token against a tokenized stock or ETF does not grant ownership of the underlying shares, dividends, or shareholder rights. The token’s dollar price simply reflects the value of the paired asset and the exchange rate between the two — more like a synthetic trading pair than an equity investment. That distinction matters for anyone evaluating the token, and it’s a detail worth remembering before assuming “stock-paired” means “backed by stock.”
StonkFun also runs a buyback-and-burn program, funneling a share of trading fees from its newer liquidity pools into purchasing and burning its ten largest tokens by market cap, weighted by size and executed every few minutes. As of the integration announcement, tokens paired with ZEC, HYPE, and TAO occupied the top three buyback slots, and the platform reports 78 different tokens have gone through the burn mechanism to date.
Raydium is the largest decentralized exchange (DEX) on Solana by volume, and LaunchLab is its permissionless token-launch infrastructure — a system that lets any project deploy tokens with a bonding-curve trading model that “graduates” into a full Raydium liquidity pool once it hits a volume threshold.
Before the integration, StonkFun ran its own launch mechanism. That created two problems the team had publicly acknowledged just days earlier, in a September 2 announcement:
By routing new token deployments through Raydium’s LaunchLab instead of a proprietary system, StonkFun effectively outsourced its liquidity and trust problem to the most established DEX infrastructure on Solana. New tokens launched on StonkFun now settle directly into Raydium’s order flow and, eventually, Jupiter’s aggregated routing — which explains why all three tokens moved in tandem.
Solana’s own official account publicly signaled support for the move, responding to a StonkFun post with a simple statement of backing for “Stonk Tokens” — a small detail, but one that added a layer of ecosystem-level credibility to a project that, just days earlier, was fielding user complaints.
This is the part that’s genuinely useful to understand, beyond the STONK headline number.
When a launchpad integrates directly with a major DEX’s infrastructure, it creates a flywheel effect across the stack:
In other words, a single infrastructure decision created three separate, simultaneous demand shocks — one for narrative attention, one for protocol revenue, and one for trading volume. That’s a pattern worth recognizing any time you see a launchpad-to-DEX integration announcement: check not just the launchpad’s token, but the underlying DEX and aggregator tokens too.
This is the question every trader should be asking, and it’s fair to say the honest answer is: nobody knows yet, and the early data is already showing the limits of the move.
A few signals worth watching:
For traders and researchers, the metrics worth tracking going forward are straightforward: daily trading volume on StonkFun, the pace of new token launches through LaunchLab, Raydium’s daily protocol revenue, and whether STONK’s price finds a stable range above pre-announcement levels or fully retraces.
Beyond the immediate price action, this integration is a useful data point in a broader trend: the merging of tokenized real-world assets (RWAs) with Solana’s meme-coin and launchpad culture.
StonkFun’s core pitch — pairing speculative tokens against tokenized stocks, ETFs, and commodities instead of just SOL — sits at the intersection of two of crypto’s biggest 2025–2026 narratives: real-world asset tokenization and permissionless token launches. Whether that combination produces durable products or just a faster way to speculate on volatility remains an open question, and it’s one worth watching regardless of which side of that debate you land on.
What’s clear is that infrastructure integrations are becoming one of the most reliable short-term catalysts in Solana DeFi. When a launchpad plugs into a major DEX’s liquidity engine, the resulting demand doesn’t stay contained to one token — it ripples across the stack. Anyone tracking Solana DeFi should be watching for the next version of this pattern, not just this one.
Ready to trade without watching the charts all day?
Subscribe to Hyperlyx AI and put your trading strategies on automation — built for traders who want to stay in the game through every twist of a rally like this one, without letting emotion drive the decision.
STONK is the native token associated with StonkFun, a Solana-based launchpad that lets users create tokens paired against tokenized stocks, ETFs, commodities, and other assets, most notably SPYx, a token tracking the S&P 500.
STONK surged after StonkFun announced an integration with Raydium’s LaunchLab on September 6, 2026, which lowered deployment costs, reduced sniping risk, and routed new token launches directly into Raydium’s liquidity infrastructure.
No. Pairing a token against a tokenized asset like SPYx means its price reflects that asset’s value and exchange rate — it does not grant ownership, dividends, or shareholder rights tied to the underlying stocks.
Because new StonkFun token launches now settle through Raydium’s LaunchLab and route through Jupiter’s aggregation layer, increased activity on StonkFun directly generates trading fees and volume for both platforms.
That depends on whether trading volume and new launches on StonkFun stay elevated after the initial news cycle. Early data already shows some pullback from the token’s all-time high, so sustained interest — not just the announcement itself — will determine whether gains hold.
This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency markets are highly volatile, and tokens like STONK, RAY, and JUP can experience rapid, significant price swings. Always do your own research before making investment decisions.
STONK Surges 250%: Inside the Raydium x StonkFun Integration was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Governments are stockpiling it. Wall Street is finally buying it. And the technology behind it just got a major upgrade. So why are some…
The crypto market has experienced multiple cycles.
From Bitcoin’s early adoption to DeFi expansion, NFT growth, and the rise of institutional participation, each cycle has introduced new opportunities.
Today, digital assets are becoming more connected with the broader financial ecosystem.
More users are entering the market.
More institutions are exploring blockchain technology.
More assets are moving on-chain.
But as adoption grows, one question becomes increasingly important:
Can digital assets be managed securely at a larger scale?
The future growth of crypto will not only depend on adoption.
It will depend on trust.
And trust starts with security.
When crypto was mainly used by early adopters, asset management was relatively simple.
Users controlled their own wallets.
Private keys were stored individually.
Security responsibility was mostly personal.
But the market has changed.
Today, digital assets involve:
The amount of value stored on blockchain networks continues to increase.
This creates new security challenges:
As the value of digital assets grows, traditional security approaches face greater pressure.
Private keys are the foundation of blockchain ownership.
Whoever controls the private key controls the assets.
This creates a fundamental challenge:
Security depends on protecting a single critical piece of information.
Traditional wallet models often rely on:
While this model provides direct ownership, it also creates risks.
If the private key is:
Recovery can become extremely difficult.
For individual users, this can be devastating.
For institutions managing large assets, it can become a major operational risk.
One technology attracting increasing attention is:
MPC changes how private keys are managed.
Instead of storing one complete private key in a single location, MPC divides key management responsibilities across multiple parties.
The goal:
Reduce single-point-of-failure risks.
With MPC technology:
This approach is becoming increasingly relevant as more professional users enter the crypto market.
The crypto industry is gradually changing its understanding of ownership.
Early crypto philosophy emphasized:
“Not your keys, not your coins.”
This principle highlighted the importance of self-custody.
However, as the ecosystem matures, the question becomes more complex:
How can users maintain ownership while improving security?
The future may not be a choice between:
Self-custody
or
Third-party management
Instead, it may involve advanced security models that combine:
Institutions operate differently from individual users.
They need:
Multiple team members may require different access levels.
Large transactions require additional verification.
Organizations need clear processes and audit capabilities.
Digital assets require security standards similar to traditional financial systems.
Without strong security infrastructure, large-scale adoption becomes difficult.
Artificial intelligence is influencing both sides of the security landscape.
On one side:
AI can improve security by helping detect:
On the other side:
Attackers can also use advanced technologies to create more sophisticated attacks.
This creates a continuous security race.
Future digital asset security will likely require:
In the early crypto market, users often prioritized:
But as the industry matures, priorities are changing.
Users increasingly care about:
Security is no longer just a technical requirement.
It is becoming a major factor influencing user trust.
The first phase of crypto focused on creating decentralized financial possibilities.
The next phase will focus on making those possibilities usable at scale.
That requires solving critical challenges:
Technology adoption happens when people trust the systems behind it.
Crypto is growing beyond speculation.
Digital assets are becoming part of a broader financial transformation.
But growth requires more than innovation.
It requires confidence.
The next generation of crypto users will not only ask:
“How much can this asset grow?”
They will also ask:
“How safely can this asset be managed?”
The companies and technologies that solve digital asset security challenges will play a critical role in shaping the future of blockchain.
Because the next crypto era will not only be about owning digital assets.
It will be about protecting them.
🌐 Build secure and scalable Web3 platforms with SoonTech.
Explore our solutions for White Label Crypto Exchanges, Prediction Markets, MPC Wallets, Matching Engines, Liquidity Integration, and Compliance.
The Crypto Industry Is Entering a New Stage was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Institutions say they want onchain exposure. Three words in every risk memo say otherwise. Here is what each one really means, and what it would take to clear it.
Ask a treasury team why they have not allocated onchain yet, and you will rarely hear “we think it goes down.”
You will hear three words. Custody. Compliance. Counterparties.
The same three, in roughly that order, across almost every risk memo and almost every jurisdiction. They are not price objections. They are plumbing objections.
That difference matters. Price objections resolve themselves when the market moves. Plumbing objections only resolve when somebody rebuilds the plumbing.
And the appetite is already there. In EY’s 2026 institutional digital asset survey, 73% of institutions said they plan to increase allocations this year. Stablecoin market capitalisation crossed $322 billion in June 2026.
Tokenized Treasuries climbed from roughly $8.9 billion at the start of the year to somewhere between $12 billion and $15 billion by mid-year.
The money is not undecided. It is blocked.
Here is what makes that expensive. By most estimates, around 80% of stablecoin supply sits in no yield-generating position at all. That is not caution. That is capital paying a tax to wait.
Custody is the first gate because it is the easiest one to lose your job on.
Around 75% of institutional investors flag custodial risk as a top-tier concern. The response has been revealing. 61% now run a multi-custodian model. Only 36% use a single custodian.
Read that again. Institutions are not solving custody risk. They are diversifying their exposure to it.
Splitting balances across three providers shrinks the size of any single failure. It does not remove the failure mode. The dependency does not disappear. It just gets divided by three.
Institutions are not solving custody risk. They are diversifying their exposure to it.
EY framed the shift well. The question has moved from who can custody to who can custody under scrutiny, meaning scrutiny from regulators, auditors, clients and internal risk committees at the same time.
The scar tissue is earned. FTX wiped out roughly $8 billion in customer funds in 2022 and caught Tiger Global, Sequoia and the Ontario Teachers’ Pension Plan off guard simultaneously.
Credit agencies still do not rate digital asset counterparties the way they rate a clearing house, so risk committees end up working from reputation and regulatory status.
There is a third option that most institutional crypto conversations skip past. Architecture where no third party can reach the collateral at all.
Sky Protocol is non-custodial by construction. No third party can move balances, override liquidation logic, or reach collateral directly.
Sky Governance sets parameters through onchain Executive Votes, and every sensitive change carries a mandatory time delay before it takes effect.
That is not a service commitment. It is a property of the contracts.
Regulatory uncertainty is the most-cited blocker in the market. 66% of institutions name it as their primary concern. 67% call it the single biggest barrier to allocating into tokenized products.
2026 moved the line. GENIUS Act implementing rules landed on the one-year mark. MiCA’s transition window for legacy issuers closed on 1 July. Hong Kong granted its first stablecoin issuer licences in April.
But clarity in the statute is not the same as clarity in the diligence file.
What a compliance team actually needs is evidence, produced on a schedule they control. That is where most of the market still fails them.
Traditional financial reporting runs on quarterly cycles, so by the time a report is published, the position it describes is months old.
Sky Protocol inverts that. The balance sheet, Gross Protocol Revenue, Net Protocol Revenue, Protocol Surplus and Sky Reserves are published live.
Closed-period detail sits in the quarterly reports published by the Sky Frontier Foundation.
Two more signals worth putting in a diligence file:
Operational entry matters too. The Peg Stability Module converts major stablecoins into USDS at a strict 1:1 ratio with no fees and no slippage, so a large allocation does not pay a spread simply to arrive.
Verifiable beats permitted.
A diligence analyst can check every claim in this section in about four minutes, without an NDA and without a sales call.
This is the quiet one, and the largest.
79% of institutional traders name counterparty risk as their single greatest concern in OTC markets.
48% reported settlement delays in 2025 caused by counterparty creditworthiness. 42% have capped exposure to smaller venues outright.
In most yield-bearing dollar products, counterparty risk is concentrated and invisible at the same time.
One issuer. One balance sheet. One attestation cycle. If it breaks, you are a creditor in a queue.
Sky Ecosystem is built the other way around. The Sky Agent Network is a set of independent capital allocators that access USDS liquidity under governance-set risk parameters and deploy it across diversified strategies.
Spark runs lending markets. Grove handles institutional tokenized credit. Obex incubates new allocators. They are separate businesses, not subsidiaries.
Better, the NASDAQ-listed mortgage lender, runs a $500M mortgage credit facility and is the first publicly listed US company deploying capital as a Sky Agent.
In April 2026, Coinbase completed the migration of DAI to USDS, the largest stablecoin migration recorded to date.
Here is the part most people get backwards.
An sUSDS holder accesses the Sky Savings Rate. They are not a claimant on any specific collateral pool, borrower, Agent or strategy. If an Agent’s book takes losses, those losses hit a fixed, pre-published order.
That waterfall is not a marketing diagram. It has been tested. The protocol carried zero exposure to the UST collapse and zero to the FTX bankruptcy, because governance had never approved either as eligible collateral.
It held through Black Thursday in March 2020, and through the March 2023 depeg pressure that reached the Peg Stability Module. Across seven years of operations, the core protocol has recorded zero exploits.
This is where the argument either holds up or falls over.
That last line is the interesting one. Institutions are not all waiting outside the door. Some are already inside, deploying through the network.
Any honest piece on institutional crypto barriers needs this section.
Anyone selling certainty on those four points is selling something.
Custody stops being the question when there is no third party to trust with it.
Compliance stops being the question when the balance sheet is public and continuous instead of quarterly and curated.
Counterparty risk stops being the question when exposure sits across independent allocators with a published loss waterfall behind them.
That is the thesis, and none of it requires taking anyone’s word for it. Every figure above is on a public dashboard right now at skyeco.com.
Custody stops being the question when there is no third party to trust with it.
Now the part I actually want to hear about.
Which of the three is the real blocker inside your organisation? Custody, compliance, or counterparties? And if your risk committee approved an onchain allocation tomorrow, which one would have been the last to sign off?
Tell me in the comments. I read all of them.
Custody, Compliance, Counterparties: The Three Things Blocking Institutional Capital was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
A genuine report can still cover the wrong contract. Here’s how to verify the evidence before you connect a wallet or invest.
An audit can be real and still tell you nothing about the contract you are about to use.
Suppose a project advertises an audit from a familiar security company. You find the original report on the auditor’s website. The project name matches.
Then you check the details. The report covers a different contract.
The document is authentic. Its relevance is still unproven.
That mismatch does not establish fraud. It means one important claim remains unverified.
Spotting a crypto scam takes more than recognizing fake documents. Sometimes the harder task is deciding whether genuine evidence supports the claim attached to it.
Start with the audit. Then apply the same check to the people, partnerships, and token behind the pitch. Each check should leave you with a specific finding you can explain.
For this article, I tested the same verification method on a platform I work with. On September 9, 2026, I reviewed Forvest’s public Toncoin analysis and found two different readings on the same page.
The live weekly module displayed a Trust Score of 41.9 and labeled it Weak. Farther down the page, an analysis last updated on November 6, 2025 described TON with an overall score of 78 and labeled it Strong.
Both figures referred to TON, but they did not describe the same observation. One was a live weekly signal; the other was an older editorial snapshot based on dated inputs and a separate set of stated dimensions. Quoting 78 as TON’s current Trust Score would therefore fail two checks: time and scope.
This did not show that TON was fraudulent, and it did not prove that either figure had been fabricated. It showed that the older analysis could not support a claim about the current score.
That changed the next step in the review. I recorded the asset, score, label, timeframe, page date, and access date separately. I treated 41.9 as the current interface reading and kept 78 only as historical context. The comparison also revealed a presentation issue: live and historical values need clearer version labels.
The lesson was uncomfortable but useful: verification has to apply to our own platform, too. A score without a matched date and methodology can create the same false confidence as an audit badge without a matched contract.
For the hypothetical project above, “the report exists” answers only the first question. You also need to establish what it covers.
Open the auditor’s official site independently and locate the original report. Compare the project name, network, contract address where provided, code version, scope, and date. If the report identifies source code rather than a deployed address, you still need evidence connecting that reviewed code to the contract in use.
CertiK’s explanation of verified contracts describes why this matters: teams can change code after an audit. CertiK has also documented phishing sites and exit scams falsely claiming its audits.
If the details do not match, ask a specific question:
“Where can I verify that the contract currently in use is covered by this audit?”
An explanation may resolve the mismatch. Until then, record the coverage as unverified.
Even a confirmed match has limits. An audit does not establish that the team is honest or that the token will hold its value.
A confirmed audit cannot confirm a partnership. A confirmed founder cannot confirm a token’s value.
For each claim, follow the same sequence:
These checks belong within a broader crypto investment risk assessment that also considers market, liquidity, operational, and portfolio risks.
A project announces a partnership. Three websites repeat it. A social account posts the same news.
Before treating those mentions as separate confirmations, trace their sources. If all four rely on the project’s announcement, the supposed partner has still confirmed nothing.
Find the other organization’s official channels independently. Look for confirmation naming the same project and describing the same relationship. Save the source and date.
Apply that approach to team identities, too. Find a professional presence or contact channel independently of the project’s materials, and check whether it confirms the person’s current role.
A convincing video alone cannot settle the question. In its July 2026 warning, the FBI described scammers impersonating FBI personnel through AI-generated videos and spoofed IC3 websites, including schemes targeting previous fraud victims.
An appearance of authority is a reason to check the source.
A familiar token name is not a unique identifier.
Locate the project’s official documentation independently. Compare the stated network and complete contract address with the token or contract you are being asked to use. Check that address on a reputable explorer for the same network.
Record the result narrowly: “This address matches the project’s documentation.”
That finding identifies the token. It does not establish future value, honest management, or coverage by an audit.
Use three labels to keep your findings precise:
A missing page, an outdated report, or a changed address may have an explanation. Record the gap and seek evidence for that explanation before relying on the claim.
You do not need to prove fraud to pause a transaction.
“Unable to verify” is a useful finding. It tells you which assumption would otherwise carry your decision.
A score is useful when you can understand what contributed to it.
If two tools disagree, compare their inputs, update times, definitions, and weighting. Understanding the factors behind a crypto project’s Trust Score helps you see what a number measures and which questions remain open.
Treat a high score as the start of a more specific question: “Which findings support this result, and are they relevant to the decision I am making?”
Choose the claim doing the most work in the pitch: the audit, the founder, the partnership, or the official token.
Before relying on it, write down:
Then complete this sentence:
“I verified _____ using _____. I still have not verified _____.”
If the second blank contains only another project-controlled page, trace the claim further. If the third contains something essential to your decision, keep that uncertainty visible.
A risk score can organize the signals you have already verified. It cannot turn an unverified claim into evidence.
Return to the audit at the start of this article. Finding the genuine report was useful. Checking what it covered was the step that changed the conclusion.
Before your next crypto decision, ask:
What, exactly, have I verified?
Author disclosure: I work with Forvest, where my work focuses on research-driven crypto analytics and risk-aware decision support. This article is educational and is not financial advice.
Sources
How to Spot a Crypto Scam Even When the Audit Is Real was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
The SEC is rewriting the custody rulebook right now. The answer decides more than where your stablecoins sit — it decides who keeps the yield they generate.
On 25 August 2026, the SEC sent a crypto custody proposal to the White House Office of Management and Budget. The text is sealed. No public comment yet.
One phrase inside it matters more than the rest: qualified custodian.
How the agency defines those two words will decide who is legally allowed to hold digital assets in the United States, and under what conditions. Congress has stalled. The regulator is filling the vacuum.
Meanwhile most people still can’t answer a simpler question. When your stablecoins sit somewhere and quietly accrue a return — who actually holds the keys?
That is not a technicality. It decides what happens in a bankruptcy. It decides whether a balance can be frozen. And since July 2025, it decides something almost nobody talks about: who keeps the yield.
Custody stopped being a storage question. It became a market-structure question — and then a yield question.
“Not your keys, not your coins” started as a slogan. It is now written into law on two continents.
The direction of travel is clear enough. Custodians are being professionalised. Self-custody is being protected. Both are being defined — and definitions have consequences.
Strip the vocabulary away and one thing separates the two models. The private key.
Self-custody (non-custodial):
Custodial:
Chainalysis logged $3.4 billion stolen in 2025. Centralised services took the largest single hits — the Bybit breach alone was roughly $1.5 billion.
Private key compromise, not exotic smart-contract bugs, remains the dominant attack vector.
A “qualified custodian” is a legal designation, not a security guarantee.
Under Rule 206(4)-2, US registered investment advisers must generally hold client funds with one: a bank, a broker-dealer, a futures commission merchant, or certain trust companies.
In September 2025, SEC staff issued no-action relief letting advisers treat state-chartered trust companies as banks for crypto custody purposes.
What qualified custody buys you:
What it does not buy you:
That distinction is the whole article. Regulated custody manages how counterparty risk is handled. Non-custodial architecture removes that specific risk entirely.
Here is the uncomfortable data. A survey of more than 3,000 US crypto users found:
Globally, roughly 59% of wallet users say they prefer self-custodial wallets. Behaviour disagrees with belief by a wide margin.
The gap is not ignorance. It is friction. Self-custody has historically meant a seed phrase you guard forever, no support line, and no way to put idle dollars to work without becoming a part-time DeFi analyst.
Remove the friction and the gap closes. That is why MetaMask shipped a self-custodial Money Account in June 2026 bundling stablecoin yield, payments and trading. The market is chasing the same insight.
Now the part that should change how you think about all of this.
The GENIUS Act, signed 18 July 2025, prohibits permitted payment stablecoin issuers from paying holders any interest or yield simply for holding the token. The reserves still earn. The issuer keeps it.
That is the original stablecoin bargain, now written into statute. You hand over dollars. They hand you a token. They put the reserves in Treasuries. The return stays on their balance sheet.
The fight over the edges is loud:
Strip the politics and one fact survives. In a custodial model, the return your dollars produce belongs to whoever holds them. Custody and yield are the same decision wearing two hats.
Sky Protocol runs the opposite premise.
USDS is the fully backed unit of account of Sky Ecosystem — the stablecoin independent capital allocators draw against governance-approved collateral. It converts 1:1 with major stablecoins through the Peg Stability Module, with no fees and no slippage.
Convert USDS to sUSDS and you hold the world’s largest yield-generating stablecoin. sUSDS accrues the Sky Savings Rate programmatically, inside your own wallet.
Four mechanics matter here:
The demand is measurable. In Q1 2026, sUSDS attracted more than $2.5 billion in new capital — more than the next four yield-generating stablecoins combined.
Non-custodial does not mean risk-free. It means the risks are visible.
At the time of writing, Sky Protocol shows $14.15B in Total Protocol Collateral against $11.48B in stablecoin supply.
Overcollateralised, and auditable line by line at financial.skyeco.com — not attested quarterly by a firm you have never met.
Losses absorb in a fixed, published order:
sUSDS holders access the rate. They are not claimants on any single Agent, borrower or strategy. That distinction is structural — and most people get it backwards.
The record is checkable too. Seven years of operations with zero exploits at the core protocol. Solvent through Black Thursday.
Zero exposure to UST or FTX, because governance never approved either as eligible collateral.
S&P Global assigned a B- rating in 2024, the first structured finance credit rating given to an onchain protocol.
And the Sky Frontier Foundation reported Gross Protocol Revenue of $123.79M in Q1 2026, the highest in protocol history.
If you want the full architecture, start here.
Self-custody has a bill too, and it is worth naming honestly.
Chainalysis recorded $58 million stolen in violent “wrench attacks” in 2025 — the highest annual total on record — with more than $30 million already taken in the first half of 2026.
Home invasions rose to 37% of incidents. A lost seed phrase has no support line and no appeals process.
So the honest answer depends on you, not on a universal ranking:
But treat this as two questions, not one. Who holds the keys and who keeps the return used to be separate concerns. Since the GENIUS Act, they are the same concern.
Self-custody used to mean choosing control over yield. The non-custodial savings model exists so you don’t have to choose.
If you can’t name who holds the key, you already know the answer.
Over to you. Where do your stablecoins actually live right now — an exchange, a self-custody wallet, or split between both? And if the SEC’s definition of qualified custodian lands narrow, does that change your answer?
Drop it in the comments. Curious how many people are in the 88%.
Self-Custody vs Qualified Custody: Who Actually Holds Your Keys? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
One chain won the volume. The other still holds the balance. The dollar you move and the dollar you park may not belong on the same chain.
In January 2026, Solana passed both Ethereum and Tron in adjusted monthly stablecoin transaction volume.
By June 2026, Ethereum still held roughly $154 billion in stablecoin supply. About 49% of everything issued. Solana held around $15 billion. About 5%.
Both facts are true. Same year. Same asset class.
That gap is the entire Ethereum vs Solana argument, and most versions of it online miss the point.
Money does two jobs. It moves, and it sits. Solana got very good at the first one. Ethereum still holds the second.
Picking a winner only makes sense once you say which job you mean.
Payment speed is not a single metric. It is three, and people mix them up constantly.
Finality is where the two chains genuinely diverge.
Same digits, different units. It is a useful way to remember the scale.
Fees split along the same line. Solana transfers sit well under a tenth of a cent. Ethereum mainnet is priced like a settlement venue, because that is what it has become.
Ethereum has not stood still either. The Fusaka upgrade shipped in December 2025 and raised blob capacity for rollups across two follow-on increases.
Glamsterdam, the next fork, has been in testnet hardening through 2026. Fidelity Digital Assets read Fusaka as a shift toward economic sustainability rather than raw throughput.
Single-slot finality, which would collapse that 12.8 minute window toward 12 seconds, remains research rather than a shipping date.
Solana processed roughly $650 billion in stablecoin transactions in February 2026, close to triple its January figure.
The reasons are unglamorous and real:
Now the part most comparison posts leave out.
Roughly 88% of stablecoin transfer volume is exchange activity, bots and arbitrage routing. Not real-economy payments.
Teams that filter the noise land on a few hundred billion dollars a year in genuine payment flow, not the trillions in the headlines.
So Solana did win something real. It is just not “most of the world’s money now moves on Solana.”
There is also a third chain nobody puts in the headline. Tron still carries the majority of real remittance flow, with roughly $90 billion in stablecoin supply and median transfer fees near nine cents.
If your framing is strictly “best blockchain for payments,” Tron has an uncomfortable claim that the Ethereum vs Solana framing keeps out of frame.
Volume leadership and where value actually sits are two different races.
That last line is the one large allocators price. Ethereum finality is slow measured in seconds and expensive measured in dollars. On a $50 million transfer, 12.8 minutes is not a delay. It is the product.
Sky Protocol made the same call. Its core smart contracts are deployed on Ethereum, chosen for the security and transparency that back billions in Total Protocol Collateral.
As of this writing that figure sits at roughly $14.15 billion, against a stablecoin supply near $11.48 billion.
Here is the question the chain debate never touches.
A payment takes one second, or twelve minutes. A dollar sits still for weeks.
Neither Solana’s 400 millisecond blocks nor Ethereum’s economic finality does anything about the idle balance in between.
Chain choice is a transport decision. Yield is a separate decision, and it is usually the larger one.
That is where USDS and sUSDS sit.
The funding source matters more than any headline rate. The Sky Savings Rate is sourced from revenue accrued by Sky Protocol through institutional-grade collateral and deployment strategies, not from token emissions.
Independent allocators including Spark, Grove and Osero draw USDS liquidity under governance-set risk parameters and pay for that access.
Sky Frontier Foundation’s Q2 2026 report, for the quarter ended June 30:
You do not actually have to choose. USDS already lives on Ethereum and Solana, plus Base, Arbitrum and Avalanche.
The mechanism matters here, because most multichain stablecoins are wrapped IOUs with a bridge operator hiding inside them.
There is also an incentive layer. The Pioneer Prime program rewards independent agents for growing USDS on a specific chain. Keel holds the Solana designation.
Grove pioneered the Avalanche route in April 2026, starting under a $5 million daily cap that governance raised over the following weeks.
One detail from that November migration says more about the operating culture than any tagline.
Sky Governance published the full timeline in advance: a 31-hour expected downtime window, the exact contract addresses before and after, what happened to pending transfers, and three separate scenarios for how long the checks might run.
>> PULL QUOTE >> Bridge operators do not usually pre-announce their worst case. It is a small thing that tells you which risk model you are buying into.
Skip the tribalism. Answer these instead.
Solana is winning the movement layer. Ethereum is holding the settlement layer. That is not a contradiction.
It is specialization, and it rhymes with how clearing and depository functions split roles in the system stablecoins are quietly rebuilding.
Sky Protocol was designed for that world on purpose. Collateral and settlement logic on Ethereum.
Native distribution to Solana and other chains through SkyLink. One dollar in USDS, with a yield-generating version in sUSDS for the balance that is not moving today.
Check the numbers yourself rather than taking them from a post. Protocol financials are public, and so is the onchain state.
Now the argument I want to have in the comments.
If Alpenglow ships at 150 millisecond finality, does Ethereum’s economic finality still justify a twelve-minute wait on institutional-size transfers? Or does the settlement layer start losing ground too?
Pick a side and tell me why.
Disclaimer to append at the end of the post
This content is published for information purposes only. It does not constitute financial, legal or tax guidance.
Ethereum vs Solana for Actually Moving Money was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Mastering the core architecture of blockchains and crypto-economics — without getting lost in tech jargon.
Let’s be real.
Most people talking about crypto today fall into two camps: those reciting Wikipedia definitions they don’t understand, or those who think Web3 is just about buying memecoins and waiting for a 100x return.
You don’t have to belong to either.
There are 5 fundamental concepts that dictate how modern decentralized networks actually function. If you truly grasp the logic behind them, you’ll understand the future of digital finance better than almost anyone else in the room.
The core idea: how thousands of strangers globally agree on the truth without a central authority or bank.
In traditional finance, a central ledger keeper (like a bank) validates transactions. In crypto, a public ledger is mirrored across tens of thousands of independent computers (nodes). To add new transactions, the network must reach a consensus.
Proof-of-Work (PoW): nodes expend computational energy to solve math puzzles and earn the right to validate a block (Bitcoin).
Proof-of-Stake (PoS): validators lock up capital (staking) as collateral. Misbehavior results in their collateral being slashed (Ethereum, Solana).
Takeaway: Consensus is an engineering solution to the problem of trust between untrusted parties.
The core idea: self-executing code that eliminates intermediaries and contract lawyers.
A traditional contract is a paper agreement enforced by courts. A smart contract is programmable logic operating on an If/Then basis.
Think of a vending machine: you insert $2 (If), and it automatically dispenses a drink (Then). It doesn’t need a cashier or an escrow agent. Smart contracts apply this same deterministic automation to complex financial agreements — from collateralized loans to automated revenue splits.
Takeaway: smart contracts replace human discretion and middlemen with mathematical certainty.
The core idea: computing costs and the “bypass roads” built to prevent network congestion.
Every action on a blockchain costs computational resources. Gas is the fee paid to validators for processing your transaction.
When demand spikes on a base blockchain (Layer 1, like Ethereum), blockspace runs out and gas fees surge. Layer 2 (L2) networks (such as Arbitrum, Optimism, or Base) solve this by processing thousands of transactions off-chain, bundling them into a single compressed proof, and submitting it back to Layer 1.
Takeaway: Layer 1 prioritizes maximum security and decentralization, while Layer 2 provides speed and affordability for daily operations.
The core idea: the dark side of public transparency and the battle for transaction order.
Before a transaction is finalized on-chain, it sits in the mempool — a public waiting room.
Arbitrage bots continuously scan the mempool. If they spot a large trade, they can pay a higher gas fee to validators to insert their own trade ahead of yours (front-running), or sandwich your order to extract value. This is known as Maximal Extractable Value (MEV). Modern networks increasingly use private mempools and Trusted Execution Environments (TEEs) to protect users from predatory bots.
Takeaway: the mempool is a transparent queue, and MEV is the financial game played inside that queue.
The core idea: the shift toward “Invisible Web3” that hides technical complexity from end users.
Early Web3 forced users to handle raw cryptographic complexity: 12-word seed phrases, hexadecimal addresses (0x71C...), and manual gas management.
Takeaway: This is the transition from early-stage infrastructure to mainstream usability — bringing blockchain benefits under the hood without the friction.
Web3 infrastructure has matured far beyond simple peer-to-peer transfers. It is a fundamental redesign of trust, value exchange, and financial automation. Understanding Consensus, Smart Contracts, L2s, MEV, and Intents gives you a clear lens into where digital market structure is heading next.
If You Understand These 5 Web3 Terms, You’re Ahead of 80% of People was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Login