Google is preparing to expand its crypto security operations with a new Multi-Party Computation (MPC) service targeting institutional digital asset custody. The move comes as a fresh vulnerability in Fireblocks’ MPC library highlights the risks buried inside crypto key-management systems.
Google MPC is reportedly in private preview, with major financial institutions testing the service. The technology is also being used to secure digital assets on Ethereum and Solana, with commercial availability expected in early 2027.
The timing puts institutional crypto security under renewed scrutiny. On October 26, CERT/CC disclosed a vulnerability in Fireblocks’ MPC library that could weaken protections separating cryptographic key shares.
CERT/CC’s Oct 26 advisory describes a hardened-derivation flaw in Fireblocks’ mpc-lib, CVE-2026-90975. A compromised descendant signer share plus its chain code can expose that party’s ancestor shares. This does not independently recover a full spendable key; MPC threshold…
— Venkata Satish Guttula(@snakeyesV1) October 27, 2026
Discover: The Crypto Presales This Q4 2026
MPC allows multiple parties to participate in transaction signing without assembling a complete private key in one place. Instead, each participant holds a separate key share, and the parties collaborate to authorize transactions.
This design reduces the risk associated with a single compromised device or insider. However, MPC does not eliminate vulnerabilities in the software handling those shares.
Google Cloud has previously supported institutional MPC deployments through Confidential Space, which uses confidential computing and hardware-backed attestation. These safeguards help verify sensitive workloads and restrict access to protected data, including during blockchain transaction signing.
The reported Google MPC service would take the company further into dedicated institutional crypto security. Its appeal could lie in combining cloud infrastructure with cryptographic controls designed for organizations managing substantial digital asset holdings.
Now, institutions will still need to assess implementation details, transaction approval policies, and recovery procedures. MPC itself is a cryptographic technique, not a guarantee that every component of a custody system is secure.
CERT/CC published vulnerability VU#701544 on October 26, identifying a flaw in Fireblocks’ mpc-lib library. The issue affects its implementation of BIP32 hardened key derivation when a required private parent key is missing.
According to the advisory, the library can substitute a zero-filled buffer instead of rejecting the operation. If an attacker also obtains a compromised descendant signer share and its associated chain code, the attacker may recover ancestor shares within that party’s key hierarchy.
The flaw does not expose a complete, spendable private key. Instead, it weakens an additional protection designed to limit how far a compromised share can expose related key material.
CERT/CC said no vendor fix was available when its advisory was published. It recommended keeping chain codes confidential and avoiding reliance on hardened derivation to isolate signer shares until the implementation is corrected.
The incident illustrates why Google MPC security will need to be evaluated at the implementation level. Distributing private keys is one layer of protection, but derivation logic, access controls, and transaction approval mechanisms also matter.
Discover: The Best Token Presales
The post Google MPC Could Reshape Crypto Custody: Fireblocks Security Flaw Draws Attention appeared first on Cryptonews.
Tokenizing $100 million in assets is a technical milestone. Making the infrastructure commercially viable is an entirely different challenge.
Imagine an investment firm preparing to tokenize $100 million in real estate, private credit, or other financial assets.
The business case looks promising. Blockchain-based ownership records could simplify transfers, fractional ownership could expand investor participation, and automated processes could reduce administrative work.
But the firm faces a question that rarely appears in tokenization market forecasts:
How much money must the business spend before its first token generates meaningful revenue?
The answer extends far beyond smart contract development.
Legal structuring, asset verification, investor onboarding, custody arrangements, compliance systems, and ongoing administration all contribute to the economics of tokenization.
And these costs do not necessarily decline simply because assets are represented digitally.
According to McKinsey’s research on tokenized financial assets, the market could reach approximately $2 trillion by 2030, excluding cryptocurrencies and stablecoins. Its optimistic scenario approaches $4 trillion.
Yet the same research highlights an important obstacle: implementing tokenization infrastructure can require substantial investment before the anticipated efficiencies become commercially meaningful.
For businesses entering this market, the central question is no longer whether assets can be tokenized.
It is whether the financial benefits justify the infrastructure required to tokenize them.
One of the most important distinctions in tokenization economics is the difference between asset value and business income.
Consider a platform that successfully issues digital tokens representing $100 million in underlying assets.
That figure might represent assets issued, assets administered, or assets currently held through the platform.
It does not represent revenue earned by the platform operator.
Revenue depends on the commercial arrangement.
A platform might charge asset issuers for token creation, collect recurring administration fees, license infrastructure to institutions, or earn transaction fees where legally permitted.
For example, a hypothetical 0.50% annual administration fee on $100 million in fee-bearing assets would generate $500,000 in gross annual revenue.
That sounds attractive until the operating costs enter the calculation.
The platform may still need to pay for regulatory compliance, custody services, infrastructure maintenance, security assessments, investor support, and asset servicing.
Moreover, a platform might tokenize $100 million over several years without ever maintaining $100 million in active fee-bearing assets.
Tokenized asset value measures the scale of assets represented. Revenue measures the commercial value the platform captures.
Confusing the two can lead businesses to overestimate their potential returns before development begins.
To understand the economics, consider a hypothetical financial services company launching a custom platform to support $100 million in tokenized assets.
Assume the company already has access to suitable assets and intends to serve professional or otherwise eligible investors.
The following model illustrates one possible initial budget.
The important observation is not the $500,000 total.
It is how the money is distributed.
A production-ready tokenization platform requires more than a mechanism for creating blockchain tokens.
Depending on the business model, it may need investor dashboards, asset issuance workflows, ownership records, subscription management, payment integrations, reporting tools, and administrative controls.
For companies evaluating Asset Tokenization Platform Development, the critical budgeting decision is determining which capabilities must be developed internally and which can be integrated through existing infrastructure providers.
Custom development offers greater control over workflows and future functionality, but it also creates ongoing maintenance responsibilities.
A lower initial software budget is not necessarily cheaper if the platform later requires expensive architectural changes.
Representing an asset on a blockchain does not automatically establish legally enforceable ownership.
The business must determine what the token represents.
Does it convey direct ownership, an interest in a legal entity, a debt claim, or contractual rights against an issuer?
Each structure can introduce different legal, disclosure, investor eligibility, and transfer requirements.
Depending on the jurisdiction and offering structure, businesses may need legal opinions, offering documentation, regulatory advice, entity formation, and agreements with regulated intermediaries.
Some structures may also require licenses or authorization before operations begin.
These obligations cannot be eliminated through software automation.
Smart contracts can automate token issuance, transfers, restrictions, and selected asset-related operations.
But automation introduces another category of financial risk.
A poorly designed contract could allow unauthorized transfers, incorrectly enforce ownership restrictions, or create vulnerabilities affecting investor assets.
Security testing and independent audits therefore deserve their own budget.
Audit costs also depend on the number of contracts, their complexity, the maturity of the underlying code, and the extent of remediation required.
Importantly, a completed audit does not guarantee that a system is free from vulnerabilities.
Before tokenization, the underlying asset must be verified.
For real estate, this may involve ownership documentation, title review, valuation, and property-related due diligence.
Private credit assets may require loan documentation, borrower information, collateral assessment, and servicing arrangements.
Tokenization does not remove the need to establish that an asset exists, belongs to the relevant party, and supports the rights being offered.
The blockchain records the digital representation.
It does not independently verify every claim made about the underlying asset.
Businesses must decide how digital assets and signing credentials will be controlled.
Possible arrangements include institutional custody providers, multisignature authorization systems, and multiparty computation infrastructure.
The appropriate approach depends on legal obligations, the operating model, and the parties responsible for safeguarding assets.
Integrating custody also introduces expenses related to access controls, transaction approvals, key recovery procedures, and operational monitoring.
A tokenization platform can function successfully in a demonstration environment while remaining unprepared for real investors.
Production testing should examine investor onboarding, transaction failures, restricted transfers, corporate actions, reconciliation, reporting, and recovery procedures.
These workflows become especially important when blockchain records must remain consistent with legally authoritative off-chain records.
Launching the software is only one part of launching the business.
Initial development expenditure receives considerable attention.
Recurring operational expenditure deserves just as much.
Consider an illustrative annual operating budget for the same platform.
Under these assumptions, the business would commit approximately $750,000 across its initial investment and first year of operations.
This excludes financing costs, taxes, asset acquisition costs, major unforeseen expenses, and other items that may apply to a particular business.
The first-year cash requirement could therefore be materially higher.
A company focusing exclusively on development costs may underestimate the capital needed to reach sustainable operations.
This problem is particularly significant when a platform must maintain both blockchain-based and conventional financial records.
In its analysis of tokenization adoption, McKinsey identifies the expense of operating traditional and digital processes simultaneously as a barrier to achieving near-term economic benefits.
Tokenization can create efficiency.
But during implementation, it can also temporarily increase operational complexity.
Now consider the commercial consequences of the financial model.
The platform has:
Its annual gross revenue would be:
$100 million × 0.50% = $500,000
After deducting $250,000 in annual operating expenses, the business would retain $250,000 before taxes, financing costs, and other excluded expenses.
If the full $100 million remains fee-bearing, all revenue is collected, and annual expenses remain constant, recovering the $500,000 initial investment would take approximately two years.
But consider what happens when the assumptions change.
Under this simplified model, the platform needs approximately $50 million in fee-bearing assets merely to cover its assumed annual operating expenses.
It must generate additional surplus to recover development costs.
And that calculation assumes every dollar of the relevant asset base generates the same fee.
In reality, fee discounts, onboarding delays, client departures, and changing asset values could materially affect revenue.
The financial viability of a tokenization platform depends less on how many tokens it can issue than on how consistently it can generate revenue from the assets and services it supports.
Tokenization is frequently associated with lower transaction costs and faster settlement.
Those benefits are possible, but they are not automatic.
The Bank for International Settlements’ 2025 Annual Economic Report explains how programmable financial infrastructure could combine activities such as messaging, reconciliation, and settlement.
The potential economic advantage comes from reducing duplicated processes and coordinating transactions more efficiently.
For businesses, three areas deserve particular attention.
Administrative automation: Automated ownership updates, distribution calculations, and transfer restrictions may reduce manual processing requirements.
Reconciliation efficiency: Shared transaction records may reduce the need for separate parties to repeatedly compare inconsistent information.
Settlement coordination: Where appropriate payment and asset infrastructure exists, programmable settlement arrangements may reduce delays and counterparty exposure.
However, businesses should measure these benefits against their existing processes.
If a company already operates an efficient, low-cost administrative system, replacing it with blockchain infrastructure may not immediately generate meaningful savings.
Likewise, faster on-chain transfers do not automatically resolve legal settlement requirements or eliminate traditional asset-servicing responsibilities.
The relevant metric is not the theoretical speed of the blockchain.
It is the reduction in the total cost of completing a legally valid financial transaction.
Once the economic model is established, businesses face another decision.
Should they develop their own tokenization infrastructure, license an existing platform, or outsource selected operations?
Each approach changes the relationship between upfront expenditure, recurring costs, and operational control.
A company planning a limited issuance may find that custom infrastructure creates unnecessary financial exposure.
An institution expecting repeated issuances across several asset classes may place greater value on controlling its own technology and integrations.
For organizations evaluating an RWA Asset Tokenization Platform Development Company, the more useful comparison is therefore not simply development cost versus licensing cost.
It is the total cost of ownership over three to five years, including integration, compliance, maintenance, vendor charges, and the financial consequences of changing providers.
That calculation can reveal whether an initially inexpensive solution remains economical as the business expands.
The tokenized asset market is growing, but aggregate market figures require careful interpretation.
As of October 11, 2026, RWA.xyz’s platform dashboard reported approximately $39.22 billion in distributed asset value and $357.50 billion in represented asset value.
These figures describe different categories of asset representation and should not be combined as though they measure the same thing.
They also do not reveal how much revenue tokenization infrastructure providers earn.
Nor do they establish that every tokenized asset has an active secondary market.
A tokenization platform can administer substantial asset value while generating relatively little transaction activity.
That matters because some business models depend on recurring administration fees, while others rely more heavily on issuance volume or trading-related revenue.
The same $100 million asset portfolio could therefore produce very different financial outcomes depending on how the platform earns money.
Businesses should evaluate market growth alongside customer demand, asset turnover, fee structures, and operating expenses.
Market size can demonstrate opportunity.
It cannot establish the profitability of an individual business.
The financial analysis leads to five questions that deserve answers before a tokenization project receives its development budget.
1. What specific cost or market limitation will tokenization solve?
A credible business case should identify measurable improvements rather than relying on blockchain adoption as an objective.
2. How much of the underlying asset value will actually generate revenue?
Total issued asset value and fee-bearing assets may differ substantially.
3. Which operational responsibilities will remain outside the blockchain?
Legal administration, custody, reporting, investor verification, and asset servicing may continue to require specialized providers.
4. What happens if adoption reaches only 25% of the original forecast?
A viable financial model should survive slower onboarding, lower issuance volumes, and higher operating expenses.
5. At what scale does the platform become economically sustainable?
This requires calculating the minimum revenue needed to cover recurring costs and eventually recover the initial investment.
These questions do not guarantee commercial success.
They help prevent a technically successful project from becoming an economically unsustainable one.
Bringing $100 million in assets on-chain can be an important technological achievement.
But it does not automatically create a profitable platform, eliminate traditional financial obligations, or produce liquid markets.
The financial outcome depends on how effectively the business converts its infrastructure investment into recurring revenue, operational savings, or measurable strategic advantages.
Under the illustrative model explored here, a $500,000 initial investment and $250,000 in annual operating expenses create a meaningful financial commitment before the platform achieves scale.
Different assumptions could produce dramatically different results.
That is precisely why tokenization projects should begin with financial modeling rather than technology selection.
The businesses most likely to benefit from tokenization will not necessarily be those that issue the greatest number of tokens. They will be those that understand the economics of issuing, managing, and servicing those tokens over time.
The most important question is not simply what it costs to put $100 million on-chain.
It is what the business must earn — or save — to make that investment worthwhile.
Understanding the economics of asset tokenization is only the first step. Translating those financial assumptions into a secure, scalable platform requires an architecture that supports the business model from issuance through ongoing asset administration.
Softean develops custom RWA asset tokenization platforms for businesses, asset managers, and financial institutions seeking to digitize real-world and financial assets. Our development capabilities span token issuance, investor onboarding, smart contract integration, compliance-enabled workflows, ownership management, custody connectivity, and asset administration.
Rather than approaching tokenization as a standalone blockchain implementation, we focus on building infrastructure around each client’s asset structure, operational requirements, and long-term platform objectives.
Whether a business is preparing its first tokenized offering or planning a multi-asset tokenization ecosystem, Softean helps translate its requirements into a practical development roadmap.
Planning an asset tokenization platform? Explore Softean’s development capabilities and discuss the infrastructure your business needs to bring tokenized assets to market.
Hidden Economics of Asset Tokenization: What It Actually Costs to Bring $100 Million in Assets… was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
A six-step method that starts at the contract, not the dashboard.
Pick a large stablecoin. Open three data sites. You will get three different circulating supply numbers.
None of them is lying. They are answering three different questions.
And the gap is not cosmetic. In June 2026, one widely used aggregator reported roughly $371 million more USDS than the Ethereum mainnet contract did. No hack. No stealth mint. Escrowed supply counted twice.
If you hold a stablecoin, lend against one, or carry one on a balance sheet, you need a figure you can defend in a risk meeting. Here is the six-step method.
Three structural reasons, and not one of them involves anybody being dishonest.
Same dollar. Three honest answers.
Circulating supply is not a fact you look up. It is a definition you choose, then measure.
Step 1. Read the contract before you read the dashboard
Every real audit starts with one call: totalSupply() on the issuing contract, at a named block.
Not a screenshot. A block height.
Yearn’s risk team did exactly that to USDS on 9 September 2026 at block 25939320. Mainnet totalSupply() came back at 6,645,559,216, down 15% from their previous reading.
They also pulled the protocol’s own internal debt figure, so the token number could be checked against the issuer’s books rather than against another website. The full working is public.
That is the standard worth copying. Two independent reads, same block, both published.
Step 2. Subtract the supply that is not actually circulating
Raw total supply overstates circulation almost every time. Four buckets come out:
The bridge bucket is where most errors live. In that same September reassessment, native-escrow USDS fell from about $448M to $102M, escrowed sUSDS from about $812M to $343M, and LayerZero-locked USDS from roughly $48.7M to $6.67M. Miss those and a cross-chain total quietly counts real money twice.
Step 3. Do not count the yield-bearing wrapper twice
This one catches careful people.
sUSDS is not extra supply. It is a claim on USDS that has been supplied to the Sky Savings Rate module. One dollar of USDS wrapped into sUSDS is still one dollar of stablecoin liability, not two.
Scale is why this matters. Roughly half of USDS supply sits in sUSDS, and the Ethereum sUSDS pool showed $4.85B on 26 October 2026. That is a lot of float to misclassify.
A yield-bearing wrapper is a claim on supply. It is never new supply.
Step 4. Check what backs the supply, not just how big it is
Supply tells you the size of the liability. It tells you nothing about whether that liability is covered.
So pull the collateral figure next, from the same issuer, on the same day.
On 27 October 2026, Sky Ecosystem published $14.15B in Total Collateral against $11.48B in stablecoin supply.
That is roughly $1.23 of collateral behind every dollar of supply, which is the entire point of an overcollateralized design.
Two surfaces let you check it yourself instead of taking it on trust:
Credit agencies have started running the same exercise. Moody’s assigned Sky Protocol a B3 issuer rating with a stable outlook on 7 October 2026, the first rating it has given any stablecoin protocol, after S&P Global affirmed B- on 1 October.
Both flagged reserve depth as the constraint. That is what an outside read of the collateral side looks like, and it is worth more than a logo on a trust page.
Step 5. Ask whether that supply can actually leave at a dollar
A supply number is only as good as the exit. Three questions:
Sky Protocol runs Peg Stability Modules, smart contracts that convert supported stablecoins into USDS and back at 1:1 directly with the protocol rather than against another trader, under governance-set caps. Moving between USDS and sUSDS carries no lockup in either direction.
Redemption depth is the part of a supply audit most people skip, and the part every stress event tests.
Step 6. Date the number, or bin it
Stablecoin supply moves daily. A figure without a timestamp is a rumour with decimal places.
Write the audit line in four fields: source, metric, value, block or date.
This is about to stop being a matter of taste. On 21 October 2026 the OCC finalised its GENIUS Act rule.
From 18 January 2027, permitted issuers must publish the monthly composition of their reserves on their own websites by noon on the last day of each month, and file weekly confidential reserve reports.
As Forbes noted, an accurate weekly reserve figure demands daily reconciliation between tokens outstanding onchain and reserves held at the custodian.
Monthly PDFs are becoming weekly reconciliation. Protocols that already publish live will barely feel it.
Six lines, dated 26 to 27 October 2026, each checkable in under ten minutes:
A defensible number, with the working shown.
Here is the part most supply write-ups leave out.
Supply that pays nothing is a static liability. Supply that pays has to be funded, and that funding has to come from somewhere real.
The Sky Savings Rate is a variable rate set by Sky Governance and accessed by holding sUSDS.
It is funded from revenue Sky Protocol accrues as the Sky Agent Network, independent allocators including Spark, Grove, Osero, Keel and Obex, draws USDS liquidity under governance-set risk parameters and deploys it.
So when you audit the supply, audit the engine behind it:
Galaxy appears to have run some version of that test. On 23 September 2026 it added $100 million of sUSDS to its corporate treasury and approved sUSDS as eligible collateral across its institutional trading business.
Audit the supply. Then audit whatever pays it.
Run this before you quote any stablecoin supply figure:
Six steps. One figure you can put in front of a risk committee.
The stablecoin market sat near $308B in August 2026, below its May peak of $322.4B. That is a lot of dollars measured by methods most holders have never read.
Which leaves the question I actually want argued in the comments.
Does circulating supply mean tokens that exist, tokens that can move, or tokens someone can redeem at par today?
Pick one. Then run the six steps on whatever stablecoin you hold and post the number with its date underneath. I will check mine against yours.
How to Audit a Stablecoin’s Real Circulating Supply was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
The most delegated contract in my EIP-7702 sample ends in these 12 bytes: a164736f6c6343000822000a. Most Solidity contracts built with default settings end in 53. The longer tail is a small CBOR map the compiler appends to the bytecode: an IPFS hash of the contract’s metadata file, the compiler version, and two bytes giving the map’s length. This one has the version and no hash.
On 8 September I pulled every EIP-7702 authorization from a 200-block window on Ethereum mainnet, 1,178 of them, and read the bytecode of the 59 contracts they delegated to. Nine of those authorizations pointed at the zero address, which is how an account undelegates, so 1,169 went to real code. When I went back over the 59 on 11 October, ten had the short tail. I left a note beside them: no metadata hash, so maybe nobody meant the source to be found.
Read as CBOR, a1 opens a map with one entry, 64 says a four-byte string follows (solc), and 43 says a three-byte value follows: 00 08 22, which is version 0.8.34. The last two bytes, 00 0a, give the length of everything before them, ten. So the compiler version survives. What’s gone is the hash that would let anyone fetch the exact metadata file, the one that lists every source file’s own hash and the compiler settings. In solc that’s a single setting, metadata.bytecodeHash set to none, and Foundry exposes it as bytecode_hash.
Today I asked Blockscout’s API whether each of the 59 has verified source, and asked Sourcify the same. Nine of the ten stripped contracts are verified on Blockscout. Of the 46 that kept the full hash, 21 are. The other three have no CBOR tail at all, and one of those is verified.
Counting authorizations instead of contracts widens the gap. In that September window, 369 of the 371 authorizations to stripped delegates went to a contract with published source. For the full-hash contracts it was 324 of 774, about 42%.
The one stripped contract with no source, 0xbaa66503..., drew two authorizations. The second most delegated contract in the whole sample, 0x67b743f3... with 144, carries a full IPFS hash and has no verified source on either service. Neither does 0x912518c2... with 96. Three unverified contracts of 2,140 bytes each carry the same IPFS hash, so they’re one build deployed three times.
The nine verified ones carry six contract names: Uniswap’s CaliburEntry at three addresses, Alchemy’s SemiModularAccount7702 at two, two TokenPocket delegators, UniversalGaslessDelegate, and the most delegated contract of all, with 308 of the window’s authorizations, whose verified source names it Poisoner.
Calibur’s foundry.toml and the one in Alchemy’s modular-account repository both set bytecode_hash = "none" as the project default. Neither file says why. Five of the ten addresses look mined: two start with eight zeros, one with 0x0000fb7702, one with 0x69007702, and one starts 0x77021100 and ends 0000. The metadata hash changes whenever a comment or a file path changes, even when the compiled code doesn’t, and an address found by searching CREATE2 salts depends on the exact bytecode. Dropping the hash ties the bytecode to the code alone. That’s my reading of the reason, not something either project says.
Sourcify answered for eight of the stripped contracts, and all eight came back as match, none as exact_match. Of the full-hash contracts it has, 13 of 17 are exact. Sourcify’s docs say an exact match rests on the metadata hash in the deployed code agreeing with the recompiled one, which is how it proves the source files are byte for byte the ones the author compiled. With no hash in the bytecode there’s nothing for that check to hold on to, so I’d expect every stripped contract to stop at match, whoever wrote it.
The authorization counts come from one 200-block window in September, so they say which delegates were busy then. Verified means Blockscout’s flag and Sourcify’s record as I read them on 27 October. I didn’t check Etherscan, which wants an API key, and a contract could be verified there and nowhere else. I also tried two public IPFS gateways for the hashes on the unverified contracts and both refused the requests, so I can’t say whether any of those metadata files exist somewhere.
Ten EIP-7702 delegates strip their metadata hash. Nine of them publish their source was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Dear old wallet, I rushed into minting a shiny NFT because FOMO hit harder than common sense and minutes later I got drained! Lost money…
Blockchain security depends on a fundamental assumption: knowing a public key should not make it computationally feasible to derive its private key. Quantum computing could eventually challenge this assumption, forcing blockchain networks to reconsider how transactions are authenticated, how ownership is verified, and how existing accounts migrate to safer cryptography.
For B2B founders and developers, this is not simply an algorithm upgrade. It is a protocol compatibility, asset recovery, infrastructure, and governance challenge. A successful transition must strengthen cryptographic security without breaking wallets, smart contracts, transaction verification, or access to existing assets.
Many blockchain networks rely on elliptic-curve cryptography. Ethereum uses the Elliptic Curve Digital Signature Algorithm (ECDSA) over the secp256k1 curve for externally owned accounts (EOAs), while other networks use different signature schemes.
These systems remain secure against known classical attacks when implemented correctly. However, a sufficiently capable, fault-tolerant quantum computer could use Shor’s algorithm to solve the mathematical problem underlying elliptic-curve cryptography.
In conventional cryptography, deriving a private key from its public key is computationally impractical. Shor’s algorithm could change that by efficiently solving the elliptic-curve discrete logarithm problem on a sufficiently powerful quantum computer.
On Ethereum, an EOA’s address is derived from its public key. Although the public key is not directly displayed in the address, a valid transaction signature allows it to be recovered. Consequently, accounts that have transacted may already have exposed their public keys through transaction history.
This does not mean blockchain wallets can be compromised by quantum computers today. No currently demonstrated quantum computer can break these signatures at the required scale. However, blockchain infrastructure takes considerable time to upgrade, making early preparation important.
Another concern is harvest now, decrypt later. This primarily affects encrypted information rather than ordinary public blockchain transactions, which are already transparent. Nevertheless, organizations using blockchain alongside confidential business data should consider whether long-lived encrypted records could become vulnerable to future quantum attacks.
Post-quantum cryptography (PQC) uses mathematical problems believed to resist attacks from both classical and quantum computers. The National Institute of Standards and Technology (NIST) finalized two digital-signature standards in August 2024:
Lattice-based schemes rely on the difficulty of solving particular mathematical problems involving structured lattices. Hash-based signatures derive their security from cryptographic hash functions and carefully constructed signing processes.
These standards provide alternatives to vulnerable elliptic-curve signatures, but adoption requires careful engineering.
Traditional elliptic-curve signatures are relatively compact. Post-quantum signatures can be substantially larger, depending on the algorithm and parameter set. This creates several blockchain-specific challenges:
A migration that strengthens cryptography but makes transactions prohibitively expensive is not a successful production migration.
The most practical starting point is cryptographic agility: the ability to change authentication algorithms without redesigning an entire application or network.
Applications should avoid embedding assumptions about one signature algorithm throughout their business logic. For example, a transaction authorization layer can define the intended operation, account, chain identifier, nonce, expiry, and execution parameters independently of the cryptographic verification mechanism.
A verifier then checks the signature against the account’s authorized authentication policy. The architecture can be represented as:
Transaction intent → Authentication policy → Signature verification → Execution
On smart-account systems, developers may implement multiple verification methods within the account’s authorization logic. On networks with fixed EOA verification rules, protocol-level changes or new account mechanisms may be necessary.
This separation reduces the number of components that must change during migration. However, it does not make a protocol quantum-resistant by itself: the underlying authorization mechanism must also reject vulnerable authentication paths when required.
A wallet or smart account can use an explicit, versioned policy to identify its supported signature scheme. Such a policy might define:
The signed message should bind authorization to the intended chain, account, operation, and nonce. This helps prevent cross-chain replay and reuse of a signature for a different operation.
Algorithm identifiers alone are insufficient. The verifier must enforce valid parameters, canonical encoding, and unambiguous message serialization. Otherwise, inconsistent interpretation between implementations can create security vulnerabilities.
One possible transition strategy is hybrid authentication, in which an operation requires both a conventional signature and a post-quantum signature. For example, a smart account might require both signatures during a migration period before eventually switching to post-quantum-only verification.
This approach can provide defense in depth, but its security depends on the exact verification policy. If the account accepts either signature, an attacker who can break the legacy scheme may still have a path to authorization. If both are mandatory, the system must correctly verify both and handle the failure of either verification process.
Hybrid authentication also increases signature size, execution costs, implementation complexity, and wallet integration requirements. It should therefore be introduced through a clearly defined threat model and rigorous testing rather than treated as an automatic upgrade.
Replacing a signature scheme changes more than cryptography. It affects every component that creates, transports, verifies, or stores signatures.
If a transaction format assumes a fixed signature length or a specific elliptic-curve encoding, larger post-quantum signatures may require new transaction types or protocol rules.
Developers should benchmark transaction serialization, signature verification, block propagation, and worst-case execution costs. They should also test denial-of-service scenarios in which malformed transactions attempt to trigger disproportionately expensive verification.
On public blockchains, increased signature size can also raise transaction fees or put pressure on block limits. These costs must be measured under realistic network conditions, not estimated from cryptographic benchmarks alone.
Smart contracts may contain ECDSA-specific verification logic. Bridges, exchanges, relayers, custodians, and institutional wallets may independently assume a particular signature format. Upgrading a wallet therefore does not automatically make every connected application quantum-resistant.
Engineering teams should inventory these dependencies and determine whether each requires a contract upgrade, a new verification path, or a protocol-level change. They should also verify that external systems agree on the algorithm, signature encoding, and message format.
Migration requires control of the account or an explicitly authorized recovery mechanism. Lost keys, abandoned wallets, inaccessible hardware devices, and outdated multisignature policies can leave assets difficult or impossible to migrate.
Protocols must decide how to handle accounts that never migrate. Freezing legacy accounts, forcing transfers, or introducing recovery mechanisms creates security, governance, and ownership implications.
There is no universal solution for dormant accounts. Migration plans must account for users who cannot upgrade immediately without introducing arbitrary asset seizure or weakening account authorization.
Founders and engineering leads should treat post-quantum readiness as a phased engineering program.
1. Inventory cryptographic dependencies. Identify ECDSA, EdDSA, BLS signatures, elliptic-curve commitments, signature-verification contracts, wallet libraries, bridges, and custody systems. Not every cryptographic primitive has the same quantum risk, so classify each dependency individually.
2. Prioritize high-risk components. Focus on high-value keys, long-lived assets, critical infrastructure, and systems that cannot be upgraded easily. Document the assumptions each component makes about keys and signatures.
3. Build a replaceable authentication layer. Separate business authorization from algorithm-specific verification wherever the protocol permits. Define versioned formats and strict verification rules.
4. Prototype standardized algorithms. Evaluate ML-DSA and SLH-DSA using vetted implementations. Measure signature size, verification latency, memory consumption, throughput, and interoperability across supported platforms.
5. Test migration and recovery. Simulate legacy transactions, mixed-version clients, interrupted upgrades, failed key rotation, and account-recovery scenarios. Include malformed signatures, replay attempts, and resource-exhaustion tests.
6. Deploy through controlled stages. Use test networks, security reviews, and formal verification where appropriate. Establish explicit activation criteria, monitoring, emergency procedures, and a documented migration path before production rollout.
For Ethereum-based projects, monitor the Ethereum Foundation’s post-quantum research and the Ethereum quantum-resistance roadmap. These resources describe ongoing research and evolving plans, not guarantees that every proposed feature will be available by a particular date.
Post-quantum blockchain security is not achieved simply by selecting a quantum-resistant signature algorithm. It requires compatibility across wallets, contracts, validators, transaction formats, custody systems, and recovery processes.
The strongest preparation starts with cryptographic agility, dependency mapping, measurable performance testing, and a migration strategy that protects users who cannot upgrade immediately.
Quantum-resistant cryptography is becoming an important engineering consideration, but rushed implementations can introduce vulnerabilities of their own. Blockchain teams should begin by understanding their cryptographic dependencies, testing standardized alternatives, and designing migration mechanisms that preserve authorization and asset access.
For B2B founders, the strategic question is not only whether a protocol can adopt new signatures. It is whether the entire ecosystem can adopt them without compromising asset ownership, network performance, or trust.
Preparing Blockchain Authentication for the Post-Quantum Era: Signature Migration and Compatibility… was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Tokenization put real-world assets onchain. DeFi is what makes them actually move. Here is where stablecoin yield, sUSDS and the Sky Savings Rate fit in.
Here is the part almost nobody says out loud about tokenization: putting a real-world asset onchain is the easy bit now.
About $39 billion of tokenized real-world assets sit onchain today, excluding stablecoins, per RWA.xyz in mid-October 2026.
The underlying assets those tokens point to run into the hundreds of billions. Issuance is basically a solved problem, and the pipeline keeps filling.
Boston Consulting Group has projected tokenized assets could reach into the trillions of dollars by 2030.
But a token that just sits there is a receipt. Not a working financial instrument.
The hard part is distribution. Making that token useful. Lending it, borrowing against it, composing it into something productive. And more and more, that job belongs to DeFi.
So here is the thesis, plainly: DeFi is becoming the distribution layer for tokenized assets. Not all of them. Mostly the ones built to move freely.
Everything below is dated analysis, not financial advice, so check the live numbers before you act.
“Tokenization issues the asset. DeFi distributes its utility.”
There are two separate jobs in bringing real-world assets onchain.
The first is issuance. Wrapping a Treasury bill, a credit position, or a dollar into a token.
Tokenization has largely cracked this. Onchain RWA value, excluding stablecoins, more than tripled in a year, past $39 billion by October 2026.
Tokenized US Treasuries alone are worth roughly $14.7 billion, with private credit and tokenized gold making up much of the rest.
The second job is distribution. Taking that token and making it productive. This one is harder, and it is where DeFi comes in.
DeFi protocols are composable. Drop a tokenized asset into them and it can be lent, pooled, borrowed against, and stacked into strategies without asking permission. A static record becomes a living building block.
Tokenization mints the asset. DeFi distributes its utility.
Once an asset can move freely, “distribution” stops being abstract. In practice it means a handful of concrete uses:
Each of these turns a passive holding into something that earns or frees up liquidity. That is what “RWA in DeFi” really describes.
RWA deposits into DeFi lending and yield protocols climbed sharply through 2026, into the several billions. A handful of names carry most of the flow.
Across these venues, RWA deposits roughly tripled in the year to mid-2026, climbing from a couple of billion dollars into the several billions.
One detail worth sitting with: credit tokens and tokenized gold currently make up most RWA collateral, more than Treasuries. These rankings shift fast, so treat them as a snapshot.
Now the honest part, because the headline numbers hide it.
For all the momentum, most tokenized real-world assets are doing nothing in DeFi.
By one 2026 analysis, more than half of reported RWA value sits idle. Issued, held, parked. Not circulating.
Why? Design.
A lot of tokenized assets, especially the institutional ones, are permissioned.
They need KYC, allowlisting, or jurisdiction checks, and they carry transfer restrictions. You cannot just drop them into an open protocol.
A token you cannot move without permission cannot be distributed by a permissionless system.
So the thesis needs a sharper edge. DeFi is not distributing all of RWA. It is becoming the distribution layer for the assets that were built to be distributed.
“A token you can’t move without permission can’t be distributed by a permissionless system.”
The assets that actually move through DeFi share a profile. Freely transferable. Built in standard token formats. Composable by default.
Yield-bearing stablecoins fit that mould almost perfectly. So do some freely transferable Treasury tokens. Heavily gated institutional tokens, however large, mostly do not.
The lesson for anyone issuing a tokenized asset is blunt. Composability is not a feature you bolt on later. If you want distribution, you design for it at issuance.
Sky is a clean example of the permissionless side of this story. One example among several, not the whole trend.
Start with USDS, Sky Protocol’s stablecoin and the entry point to everything else.
USDS is over-collateralized, backed by a diversified mix that includes tokenized real-world assets like short-duration US Treasuries.
As of late October 2026, Sky.money’s homepage showed about $16.24 billion of collateral backing roughly $10.02 billion of USDS supply. That is close to $1.62 of collateral for every dollar.
Now the yield part. Supply USDS and you receive sUSDS, the world’s largest yield-bearing stablecoin, with supply near $4.83 billion on Sky.money in late October 2026.
sUSDS accrues the Sky Savings Rate (SSR) automatically, and you can redeem it for USDS plus accrued yield at any time.
The Sky Savings Rate is a variable, governance-set rate funded from aggregate Sky Protocol surplus, shown at 3.80% on Sky.money in late October 2026. It can change, and Sky.money does not set, control, or guarantee it.
Here is why it matters for this story:
That dual role, issuer and distributor, is the exact pattern this piece describes.
It runs on infrastructure that has worked on stablecoin systems since 2017. sUSDS still carries smart-contract and peg risk, and the rate is variable.
None of this is a sure thing. If you want the mechanics, here is a plain-English explainer of what sUSDS is and how it works.
Distribution is not free. Plugging real-world assets into DeFi imports new risks:
None of this kills the thesis. It just means distribution is a trade-off, not a free lunch.
The direction is clear. As more value gets tokenized, DeFi is becoming the layer that makes it useful. The place a token turns into collateral, yield, and a building block.
But it is early and uneven. Most tokenized assets still are not active onchain.
The winners are the ones designed to compose. And the yield comes with real risk.
The clearest sign it is real: institutions now post composable RWA tokens as collateral and keep earning on them, rather than letting the tokens sit.
If you hold stablecoins, the practical takeaway is simple. You do not have to issue anything to benefit from this shift.
A composable, RWA-backed yield-bearing stablecoin like sUSDS already plugs into it, letting your dollars earn the Sky Savings Rate instead of sitting still.
Put your stablecoins to work, check the live numbers, size your own risk, and treat this as a map, not advice.
Q. What does “DeFi is the distribution layer for RWA” mean?
A. Tokenization creates real-world-asset tokens. DeFi is where they become useful, as collateral, vault inputs, and composable building blocks, instead of sitting idle.
Q. Why is most tokenized RWA not used in DeFi?
A. Many tokenized assets are permissioned and gated, so they cannot compose freely. Only a minority is actively used today.
Q. How does sUSDS relate?
A. sUSDS is a permissionless, composable, RWA-backed yield-bearing stablecoin that accrues the Sky Savings Rate and circulates through DeFi. The rate is variable and governance-set.
DeFi Is Becoming the Distribution Layer for Tokenized Assets was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Beijing just ordered a national blockchain network, eight months after banning Bitcoin, Ether and stablecoins.
South Africa is taking an important step towards answering a question that has hung over its crypto market for years:
How should crypto assets be treated under the country’s rules on moving money across its borders?
The problem is not new.
South Africa has long run an exchange-control system to manage capital flowing in and out of the country. The National Treasury and the South African Reserve Bank (SARB), through its Financial Surveillance Department (FinSurv), administer it under the Exchange Control Regulations of 1961.
The problem is that crypto does not fit neatly into a system built around banks, foreign currencies and conventional payment channels.
That raises a legal question:
Is crypto “capital” for the purposes of exchange control?
Two High Court decisions show the uncertainty.
In Standard Bank of South Africa Ltd v South African Reserve Bank, SARB had forfeited funds linked to cryptocurrency transactions involving Leo Cash and Carry (Pty) Ltd.
Standard Bank challenged the forfeiture, arguing that cryptocurrency was not “capital” under Regulation 10(1)(c). The court agreed, finding that cryptocurrencies fell outside the definitions of “money” and “capital” in the Regulations, and set the forfeiture aside.
In Mangundhla & Dangaiso, the court went the other way. The case involved roughly 1,680 Bitcoin, bought in South Africa and valued at under R182 million, which were sent to wallets reachable through exchanges outside the country. SARB forfeited certain Bitcoin and funds held in the applicants’ Standard Bank and Luno accounts.
This time the court held that Bitcoin could constitute capital, based on the ordinary meaning, context and purpose of the legislation.
This result is the real gap.
If crypto is capital, its cross-border movement can fall under exchange control. If it is not, applying the old framework becomes very difficult. The position is also still unsettled, because the Standard Bank decision is subject to appeal. The courts exposed the problem, but they did not solve it.
That is the background to the Draft Capital Flow Management Regulations, 2026, published for public comment on 17 April 2026. On 15 May 2026, the National Treasury and SARB followed with a joint statement covering, among other things, how crypto assets are treated, held and traded, and how they move across borders.
The draft regulations are broader than crypto. They are meant to replace the 1961 regulations and modernise how South Africa manages international capital flows, moving towards a risk-based, surveillance-oriented model. Instead of relying mainly on prior approvals, the aim is to let legitimate transactions flow while strengthening reporting, monitoring and intervention for high-risk activity.
For crypto, the key point is that the draft does not build a separate system. It places crypto assets inside the existing framework, alongside foreign currency, securities and gold.
Buying and selling
Purchases, sales, borrowing and lending of crypto above a set threshold would generally have to go through an Authorised Crypto Asset Service Provider (CASP), or otherwise meet permission requirements. A CASP could only carry out the activities it is authorised for, and the National Treasury could add conditions or bar it from dealing with particular people, assets or transactions.
Moving crypto abroad
This is arguably the most significant part. Taking or sending crypto out of South Africa, delivering it for removal, and certain payments involving people outside the country would generally need permission from the National Treasury or an authorised body.
Declaring foreign crypto
A person in South Africa who gains control or possession of a foreign asset or crypto asset may have to declare it within a set period. The declaration would cover when and how it was acquired, where it is held and whether it is linked to a foreign liability. Once declared, later sales or transfers could be restricted.
Seizure, blocking and forfeiture
If there are reasonable grounds to believe crypto is connected to a contravention, authorities could seize it or block dealings with it in an account, and it could eventually be forfeited to the State.
The draft even deals with the practicalities of crypto: after forfeiture, the previous holder may be required to hand over the passwords, PINs or codes needed to access the assets.
The proposed draft contains safeguards. Forfeiture decisions must comply with the Promotion of Administrative Justice Act, and affected people can challenge attachment, blocking, and forfeiture through judicial review.
The Draft Crypto Asset Manual for Cross-Border Activities supplies the operational detail. Its main job is to say when a crypto transaction becomes a cross-border one for exchange-control purposes.
These flows are intended to be identifiable and reportable to FinSurv.
With a non-custodial wallet, the user holds the private keys and there is no intermediary holding the assets. Even so, the framework treats a transfer from a domestic CASP to such a wallet as an outward movement of value.
It also takes a stricter line on certain inward transfers from non-custodial wallets, treating them as non-permissible. The focus is not on whether an asset sits on a blockchain, but on where the value comes from, where it goes and whether it crosses the border.
For now, the Manual is narrow on who can send crypto offshore. Individuals can do so through authorised CASPs using their existing foreign-exchange allowances, such as the Single Discretionary Allowance (SDA) or Foreign Capital Allowance (FCA), subject to the applicable requirements. That is not a general permission for every person or business to move crypto abroad, and other categories will depend on the final rules.
Taken together, the draft is not trying to prohibit cross-border crypto activity. It is trying to make crypto movements visible to the capital-flow system. Exchange control was designed for a world of identifiable institutions and bank accounts, and crypto can move value across borders without passing through any of them. The trigger-point approach gives regulators a way to see when that movement matters.
It is also activity-based.
At this stage it does not distinguish between types of crypto asset, and it does not treat crypto as official currency or legal tender.
So the framework is less about whether Bitcoin or a stablecoin is “money,” and more about whether an activity amounts to a movement of value that should be subject to capital controls.
This will sit on top of existing oversight.
The Financial Sector Conduct Authority (FSCA), the Financial Intelligence Centre (FIC) and the South African Revenue Service (SARS) already play roles in regulating crypto activity. A crypto business may therefore need to ask two separate things:
Am I authorised to provide this service, and does this particular transaction create an exchange-control or reporting obligation?
The draft regulations supply the legal architecture for bringing crypto into South Africa’s capital-flow regime, and the Manual supplies the practical test for when a transaction is caught.
What I find most telling is where the rules choose to focus. They do not try to settle what crypto is. They regulate what crypto does when it crosses a border.
That is a pragmatic response to the court split, because it sidesteps the “is it capital?” debate by looking at the movement of value instead.
For businesses and users, three questions will matter most:
For regulators, the goals are clear: better visibility over cross-border crypto flows, fewer chances for regulatory arbitrage and stronger detection of illicit finance, without choking off legitimate digital-asset use.
The open question is how well that balance survives the final text. Rules on non-custodial wallets, in particular, will test whether visibility can be achieved without making ordinary self-custody impractical.
The proposals are still subject to consultation and may change. But the direction is clear. Crypto may be borderless, but its movement across South Africa’s borders will increasingly come with rules on permission, reporting and oversight.
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.
Moving Crypto Out of South Africa? What the Draft Capital Flow Rules Mean for Your Business was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
The US finalised its stablecoin yield rule on 21 October. The real border is not where you think, and the UK proves it.
On 21 October 2026, the US Office of the Comptroller of the Currency finalised its rules under the GENIUS Act.
One line did most of the work: a permitted payment stablecoin issuer cannot pay a holder interest or yield simply for holding, using or storing the coin.
Most outlets filed that under American news.
It is not. It quietly redrew the map for everyone else.
Because “non-US investor” is not a category. It is roughly 190 different answers wearing one label.
If you are planning around a US border, you are planning around a line that has already moved.
Yes. In most jurisdictions, and often through fewer gates than a US retail investor now faces.
Onchain yield is produced by smart contracts on public blockchains. Those contracts do not read your passport. That is the design, not a loophole.
But three things sit between “the contract will accept you” and “you should proceed”:
Two routes exist in practice.
The first is permissionless DeFi yield, reachable with a wallet and nothing else.
The second is tokenized real-world-asset products built specifically for non-US investors under securities exemptions.
Those are aimed at you and still gated, usually with KYC, wallet allowlisting, minimums and lockups.
So the honest picture is split. One route is open. The other was designed for you and still asks for papers.
Permissionless at the protocol layer does not mean permitted at the personal layer.
Hold that, because the rest of this depends on it.
Here is what the “escape the US” takes keep missing.
The EU got there first. Under MiCA, interest on e-money tokens and asset-referenced tokens is already prohibited.
The US arrived at the same place with the GENIUS Act in July 2025, and this week’s final rule confirmed it.
Two of the world’s largest regulatory blocs now agree: the issuer of a payment stablecoin does not pay you for holding it.
So the interesting question is no longer whether you sit inside or outside America.
It is this: where does the yield actually come from, and who is paying it?
A rate funded by a protocol’s own surplus and set by token holder vote is a structurally different object from an issuer passing along reserve interest. That distinction now does real work.
Some scale for context. The total stablecoin market sat near $301 billion on 21 October 2026.
Most of those dollars are idle. Not because people chose idleness, but because the route to anything else was unclear.
This part surprises people.
The protocol layer is permissionless. Open-source smart contracts, deployed on Ethereum and other public chains. No gatekeeper. Reachable directly, or through any independent front end.
The interface layer is not. A front end is operated by a legal entity, and that entity geo-restricts.
Take a real example instead of a hypothetical. Sky.money publishes its prohibited jurisdiction list in its Terms of Use, version 2.0, updated 1 September 2026.
Thirty-five countries and regions are named. China, Hong Kong, Russia, Iran, Venezuela.
It also names the United Kingdom.
It does not name the United States.
Read that again. Meanwhile the UK’s Financial Conduct Authority published fresh DeFi consultation papers on 21 October 2026, with its full cryptoasset regime due in force from October 2027.
The border is not America versus the world. It is drawn country by country, by lawyers, and it moves.
So much for “non-US access.”
Tokens move freely. Trust does not.
An allocator in Singapore, a founder in Lagos and a saver in Sao Paulo share no vocabulary for “is this safe.” That gap is the real barrier to global onchain yield. Not geography.
Which is why two announcements this year matter more than they look.
On 7 October 2026, Moody’s assigned Sky Protocol a B3 counterparty risk rating with a stable outlook.
It was the first rating Moody’s has issued on any stablecoin protocol. S&P Global had already assigned a B- in August 2025, the first credit rating ever given to a DeFi protocol, and affirmed it this year.
Sky Protocol is currently the only stablecoin protocol formally rated by both.
Neither rating is investment grade. Nobody is pretending otherwise, and both agencies published what would need to improve. That is the point of a scale. A rating is not a compliment.
A credit rating is the one document that reads the same in Singapore, Sao Paulo and Lagos.
Then the backing, which anyone can check without asking permission:
That is roughly $1.62 of collateral value behind every $1 of USDS obligation, visible in real time rather than attested once a quarter.
If you want the mechanics, Sky.money has a plain-English explainer on what actually backs a stablecoin.
The protocol underneath is not running on fumes either. Sky Protocol generated $107.35 million in gross revenue in Q2 2026, its second consecutive quarter above $100 million and its fifth straight quarter of surplus.
Trailing twelve-month net protocol revenue stood at $159.63 million, and protocol collateral climbed 45.5% year over year.
Those are numbers a rating agency can audit. Which is exactly why one did.
In September 2026, Galaxy Digital put $100 million of sUSDS on its corporate balance sheet and approved it as collateral across its institutional trading business. Institutions do not do that on vibes.
The mechanics are deliberately boring.
What separates the Sky Savings Rate from most stablecoin yield:
The rate is variable and can change. Check it live on the sUSDS page rather than trusting a number in an article.
For anyone who wants something other than the baseline, there is Fixed Yield, where the rate is fixed only if you hold to maturity, Vaults curated on Morpho, stUSDS for advanced risk capital, and Sky Ecosystem Rewards. Different risks, different reasons. sUSDS stays the baseline.
Run this first:
Non-US investors can access onchain yield. Many have more routes open than US retail does right now.
But the useful question was never “am I non-US.”
It is: is my specific jurisdiction served, by this specific interface, for this specific product, today?
The protocol does not care where you live. The front end does. Your tax authority definitely does.
What makes any of this work at global scale is not permissionlessness on its own. It is measurement. Published collateral. Rates voted onchain.
Two independent credit ratings on the same scale a pension fund already uses. A shared language for capital that reads the same whatever the jurisdiction or currency.
That is the part that actually crosses borders.
This is informational only. Not legal, tax or financial advice. Yields are variable and not guaranteed.
Now tell me where you are reading this from. Which jurisdiction are you in, and has an interface ever geo-blocked you out of something you were perfectly entitled to hold? I want to see how wide the gap really is. Comments are open.
Onchain Yield for Non-US Investors: The Map Is Wrong was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
In the competitive Web3 industry, having a better product does not always guarantee better results. A blockchain startup may have advanced technology, secure smart contracts, and useful features, yet struggle to attract users. Meanwhile, a competitor with similar capabilities may gain attention through stronger communication, consistent content, and a well-planned crypto marketing strategy.
This is where crypto marketing becomes essential. It helps blockchain businesses communicate their value, reach relevant audiences, and build trust in a crowded market. Without a clear strategy, even innovative projects can remain unnoticed while competitors establish stronger brand recognition.
A successful Crypto Marketing Agency does more than promote a project on social media. It identifies the target audience, studies competitors, develops meaningful content, and selects channels that support measurable business objectives. Effective Crypto Marketing Services also help businesses explain complex blockchain products in ways that potential users can understand.
Consider two decentralized finance projects offering similar features. One publishes occasional technical updates, while the other shares educational articles, product demonstrations, and community insights. The second project may attract more attention because its audience has a clearer understanding of what it offers.
This does not automatically mean that the competitor has a better product. It means the competitor may be communicating its value more effectively.
Before increasing promotional spending, Web3 founders should consider these priorities:
The goal is not to copy another project’s promotional activities. It is to understand how better positioning, relevant Crypto Marketing Solutions, and consistent execution can help a strong product receive the attention it deserves.
Product quality is important, but people cannot evaluate a product they have never discovered. In Web3, projects compete across social media, search engines, developer communities, industry publications, and online forums.
A competitor may have a simpler product but communicate its benefits more clearly. Another may publish useful tutorials, respond quickly to questions, and explain its development progress regularly. These activities give potential users more opportunities to understand the product.
A Crypto Marketing Company can help identify these communication gaps and build a strategy around the project’s actual strengths.
Imagine a blockchain analytics platform that provides reliable on-chain data but uses highly technical language throughout its website. Potential customers may struggle to understand how the platform helps them.
Its competitor, however, explains how its tools help research teams monitor wallet activity and investigate token movements. Even if the underlying capabilities are comparable, the clearer explanation can make the competitor more appealing.
Effective crypto marketing connects technical features with practical benefits. It helps audiences understand why a product matters instead of expecting them to interpret complex technical information independently.
Marketing is rarely effective when it happens only during a product launch. Regular educational content, product updates, and community discussions help projects remain visible while giving audiences multiple opportunities to learn.
The objective is not to publish content every day without a purpose. It is to establish a consistent communication process that supports awareness, understanding, and adoption.
Before investing in additional campaigns, founders should examine how competing projects attract and retain attention. The objective is to discover opportunities rather than copy another brand’s approach.
A competitive review should cover messaging, content quality, audience engagement, distribution channels, and transparency.
Review how competing projects describe their products. Do they explain their target audience and primary benefits clearly? Are their claims supported by evidence? Do they address the questions potential users are likely to ask?
For example, a decentralized application might describe itself as a platform powered by smart contracts. A stronger explanation could describe the specific process it automates, the problem it solves, and the limitations users should understand.
This type of analysis can guide the development of more relevant Crypto Marketing Solutions.
Look at the educational articles, technical demonstrations, newsletters, and community discussions competitors publish. Determine which subjects generate meaningful questions and which formats help users understand the product.
Also examine how competitors respond to feedback. A project that answers questions transparently may build more credibility than one that publishes frequent promotional announcements but avoids difficult discussions.
The most useful competitive insights often come from identifying information that competitors overlook.
Your project may be able to provide clearer documentation, more detailed product demonstrations, practical tutorials, or better explanations of token utility. These improvements can create a distinctive position without requiring the business to imitate another project’s identity.
Once the competitive gaps are clear, the next step is to develop a crypto marketing strategy that connects the project’s capabilities with the needs of its audience.
Start by defining three things: who the product serves, what problem it solves, and what evidence demonstrates its value.
Blockchain products often involve smart contracts, decentralized governance, token standards, and complex infrastructure. However, different audiences need different explanations.
Developers may want integration documentation, while business customers may prioritize operational benefits. Everyday users may care more about usability, transaction fees, and security.
A cryptocurrency marketing agency should understand these differences when planning content and campaigns.
For example, rather than simply stating that a platform uses smart contract automation, explain which tasks it automates, how the process works, and what users need to know before relying on it.
Your website, social media accounts, articles, and community channels should communicate a consistent value proposition.
Consistency does not mean repeating identical sentences. It means ensuring that each communication reinforces the project’s actual purpose.
A clear message also helps a crypto token marketing agency or internal marketing team develop campaigns that remain aligned with the product rather than following every emerging market trend.
Avoid relying on unsupported claims about guaranteed returns, explosive growth, or future token prices. Instead, use product demonstrations, technical documentation, verified milestones, and authentic customer feedback.
This approach makes the project’s communication more credible and gives potential users better information for evaluating its value.
Being present on every platform is not always an effective marketing strategy. Projects should prioritize channels that reach their intended audiences and support their specific objectives.
SEO can help blockchain businesses reach people who are actively researching solutions. Educational articles, technical guides, and product comparisons can answer relevant questions while introducing the project’s capabilities.
For example, a smart contract security provider might publish practical content about common vulnerabilities, audit preparation, and testing methods. Such resources can attract developers who need these services.
Social platforms help projects communicate updates, explain features, and participate in industry conversations. Community channels also provide opportunities to answer questions and gather feedback.
The emphasis should remain on relevant interactions rather than follower counts alone.
Creators, industry publications, and strategic partnerships can introduce projects to new audiences. However, campaign selection should be based on audience relevance, credibility, and transparent communication.
A smaller creator with an engaged developer audience may be more useful to an infrastructure project than a larger creator whose audience has little interest in the product.
Managing content, community engagement, competitor research, and campaign measurement requires time and specialized knowledge. Crypto Marketing Services can help businesses coordinate these activities under a unified strategy.
The value of external support depends on the provider’s expertise, the agreed deliverables, and the project’s objectives.
A suitable Crypto Marketing Company may support several areas.
When evaluating crypto marketing agencies, founders should ask how each activity supports business goals. They should also distinguish measurable deliverables from outcomes that no provider can guarantee.
Token projects face an additional challenge: explaining the token’s purpose while attracting attention in a crowded market.
Token marketing should clarify how the token fits into the ecosystem, how its supply is structured, and what users can realistically expect from its functionality.
A practical token launch marketing strategy should cover three stages.
Token launch marketing services should be evaluated according to the quality of these activities, the audiences reached, and the accuracy of the information provided.
Token sales marketing may involve explaining distribution terms, vesting schedules, token allocation, and participation requirements. These details should be consistent across public communications.
A token marketing campaign should not rely on guaranteed-return claims or artificial urgency. Legal and promotional requirements must also be assessed for the relevant jurisdictions.
A qualified crypto token marketing agency can help coordinate campaign messaging and audience education, but founders remain responsible for ensuring that token offerings and public claims comply with applicable requirements.
Strong visibility does not automatically translate into product adoption. Founders should measure whether marketing activities attract relevant users and help them progress toward meaningful actions.
Useful indicators may include:
For example, a campaign that attracts thousands of visitors but produces very few active users may be less valuable than a smaller campaign that reaches people with a genuine need for the product.
A good marketing team combines analytics with direct feedback to identify where users lose interest and which improvements could increase adoption.
A competitor with stronger marketing may gain attention even when its technology is not significantly better. However, Web3 businesses can close that gap by communicating their strengths clearly, choosing relevant channels, and building credibility through consistent execution.
The priorities are straightforward:
Ultimately, effective crypto marketing is not about making a weaker product appear superior. It is about ensuring that the right audience understands your project’s genuine value and has a compelling reason to explore it.
What If Your Biggest Web3 Competitor Isn’t Better, Just Better Marketed? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
UNDP and the Blockchain for Good Alliance announced a two-year cybersecurity programme on October 19. The initiative brings a practical question into blockchain adoption by public institutions: whether the people operating a service can prevent failures, respond to them and restore access.
TL;DRThe programme announcement describes training and advisory support for public institutions, including work on digital payments and data protection.
Consider a hypothetical public grant system that records payments on a blockchain. The ledger can faithfully record a transfer even if an attacker changed the beneficiary’s details before an authorized employee approved it. Consensus over the final transaction cannot determine whether the original administrative instruction was legitimate.
That makes the surrounding workflow part of the security boundary. A beneficiary change, a payment approval and the act of signing a transaction may need different permissions. Combining all three under one account can make a single compromise more damaging.
NIST’s Cybersecurity Framework provides a wider reference for organizations managing cyber risk. Its relevance here is that security is an organizational responsibility, not merely a property of one technology purchased by an institution.
The distinction is visible in payment screening before settlement. Checks performed before money moves address a different problem from verifying that the network processed the payment correctly.
A public service can remain technically online while failing the people who depend on it. Lost credentials, unavailable staff or an unresolved account dispute can prevent a legitimate recipient from accessing funds even when the underlying blockchain continues producing blocks.
A useful exercise would therefore follow a realistic incident from first warning to restored service. Which official can pause a payment instruction? Who confirms a new beneficiary account? Which records establish what happened? How does a person obtain help if the normal digital channel is unavailable?
These are operational questions that can be tested. A training programme becomes more valuable when staff practice the decisions, rather than simply learn the vocabulary of blockchain security.
Custody and key-control arrangements provide one financial example of assigning responsibilities in advance. The software-maintenance process in Bitcoin Core’s disclosure update provides another: knowing about a repair is different from deploying it in the systems that people use.
The programme’s eventual impact will be easier to assess through completed exercises, clearer approval rules and demonstrably recoverable services than through attendance totals alone. For institutions considering digital payments, that is a useful way to judge whether capacity-building has changed day-to-day practice.
Written by the News Desk and edited by Samuel Rae.
Login