Tokenized Assets Are Starting to Look Less Like Crypto

Crypto started with a simple ownership model.

If you control the private key:

you control the asset.

You can normally send it wherever the network allows.

There is no issuer deciding whether the recipient passed KYC.

There is no corporate transfer agent deciding that a wallet is no longer eligible.

There is no board announcing a stock split.

And there is no administrator built into Bitcoin who can reassign your balance because a court order says the legal owner changed.

Tokenized finance is building something very different.

Base’s Cobalt upgrade, activated on mainnet on September 30, expands a token infrastructure that is increasingly designed around the realities of regulated financial assets rather than the assumptions of permissionless crypto.

The most interesting changes are not about:

• faster blocks,
• cheaper gas,
• another token launch.

They are about financial control.

Base’s B20 standard gives issuers common infrastructure for:

• roles,
• transfer policies,
• minting,
• burning,
• pausing,
• administrative seizure.

Cobalt expands that model with:

• combined compliance policies,
• scheduled corporate-action multipliers,
• more explicit asset-lifecycle tooling.

At the transaction layer, Cobalt also introduces Validity Transactions, allowing users to express conditions under which a signed transaction becomes eligible for inclusion.

The result points toward a future where a security can be:

• issued on a public blockchain,
• visible in a crypto wallet,
• settled onchain,

while still being:

• KYC restricted,
• sanction aware,
• issuer controlled,
• subject to corporate actions,
• capable of administrative reassignment.

That sounds less like the original crypto vision.

It may also be exactly what regulated finance needs.

The important distinction is becoming:

onchain does not mean permissionless.

And as more real-world assets move onto blockchains, that may become one of the most important concepts for users to understand.

---

Key Takeaways

• Base completed the Cobalt mainnet upgrade on September 30, 2026.
• Cobalt expands functionality around Base’s B20 programmable-token standard and introduces Validity Transactions.
• B20 is designed to standardize issuance and management of:
  • real-world assets,
  • stablecoins,
  • other programmable tokenized assets.
• B20 is compatible with familiar ERC-20 concepts but adds standardized administrative and compliance features.
• Shared B20 capabilities include:
  • roles,
  • pausing,
  • policies,
  • minting,
  • burning,
  • seizure.
• B20 currently includes two token variants:
  • Asset,
  • Stablecoin.
• The Asset variant is designed for general assets and can support RWAs.
• The Stablecoin variant is designed around fiat-linked assets.
• The chosen B20 variant is fixed when the token is created.
• Cobalt introduces more sophisticated policy composition.
• Policies can be combined using logic similar to:
  • AND,
  • OR.
• That can support cases such as:
  • KYC approved AND accredited,
  • eligible under jurisdiction A OR jurisdiction B.
• Transfer policy enforcement means a technically valid wallet address does not automatically have to be an eligible recipient.
• B20 supports administrative seizure under configured roles and policy conditions.
• That does not mean Base has one universal power to seize every token on its network.
• B20 seizure is a token-level administrative mechanism.
• It is fundamentally different from stealing a user’s private key.
• The Asset variant supports a UI multiplier.
• Cobalt allows an issuer to schedule a multiplier update for a specific future timestamp.
• This is designed for corporate actions such as:
  • stock splits,
  • reverse stock splits,
  • some forms of reinvested distributions.
• Scheduled multiplier changes leave the token’s canonical raw balances unchanged.
• They change the derived UI-scaled representation.
• B20 Asset also includes a corporate-action announcement framework.
• Issuers can announce actions such as:
  • stock splits,
  • issuance,
  • burns,
  • holder notices.
• Cobalt also introduces Validity Transactions.
• They let signed transactions remain ineligible until defined onchain conditions are satisfied.
• Conditional eligibility is not the same as guaranteed execution.
• The broader lesson is: tokenized finance is increasingly bringing traditional financial controls onto blockchain rather than eliminating them.

---

What Is Base Cobalt?

Cobalt is a Base network upgrade that went live on mainnet on September 30.

Several changes matter to developers.

For financial-market users, two themes stand out:

1. more sophisticated programmable-asset infrastructure
2. more expressive transaction conditions

The first centers on B20.

The second centers on Validity Transactions.

They solve different problems.

Together they show Base moving beyond a network where users simply:

send tokens from A to B.

The chain is becoming infrastructure for:

• asset lifecycle management,
• conditional execution,
• regulated ownership models.

---

What Is B20?

B20 is Base’s native standard for issuing and managing programmable assets.

A useful way to think about it is:

ERC-20 plus standardized financial-asset controls.

Normal ERC-20 provides familiar concepts such as:

• balances,
• transfers,
• allowances.

But every issuer wanting advanced controls traditionally has to build its own custom contract logic.

One token may implement:

• freeze.

Another:

• blocklist.

Another:

• administrator recovery.

Another might implement all three differently.

That makes institutional integration harder.

B20 attempts to standardize common functionality.

---

B20 Is Not Just Another Solidity Token Contract

One especially important technical distinction is that Base describes B20 as infrastructure implemented directly through the Base environment rather than each issuer independently deploying a fully custom token implementation.

That means applications can target a common interface.

For institutions, that can reduce:

• custom integration,
• contract-by-contract behavior differences.

This matters much more than another token symbol.

Financial infrastructure benefits from predictable standards.

---

Two B20 Token Types

B20 currently defines two major variants.

---

B20 Token Types

Variant	Purpose	Additional Capabilities	Typical Use
B20 Asset	General programmable asset, including RWAs	Corporate-action announcements, scheduled UI multiplier, batch minting	Tokenized securities, funds and other asset representations
B20 Stablecoin	Fiat-linked token	Stablecoin-specific capabilities on top of shared B20 controls	Regulated payment and settlement assets

---

The token type is selected at creation.

It is not simply a label that the issuer changes later.

That gives integrators a more predictable idea of what functionality the asset exposes.

---

Both Variants Share Administrative Infrastructure

The Asset and Stablecoin variants both inherit the main B20 controls.

---

Shared B20 Administrative Controls

Capability	What It Does	Why It Exists
Roles	Assign different administrative permissions	Separates operational responsibilities
Pause	Temporarily stops selected operations	Incident response and regulatory control
Policies	Checks accounts before specified actions	Eligibility, sanctions and transfer restrictions
Mint	Creates new supply under authorized roles	Issuance and subscriptions
Burn	Destroys supply under authorized rules	Redemptions, treasury actions or supply management
Seize	Reassigns eligible balances under policy and role rules	Recovery, enforcement or legally required administrative actions

---

These capabilities already tell us something important.

B20 is not designed around the assumption:

Once tokens are issued, the issuer disappears.

It is designed for assets where the issuer may remain an active legal and operational participant.

---

That Is Normal in Traditional Finance

A public company’s stock does not become ownerless after issuance.

The company still exists.

Transfer agents still exist.

Corporate actions still occur.

Legal restrictions can still affect ownership.

Stablecoin issuers also remain active after token issuance.

They:

• manage reserves,
• handle redemption,
• respond to legal requirements.

The infrastructure therefore reflects the asset.

---

Why ERC-20 Alone Is Not Enough

Imagine tokenizing shares in a private investment fund.

The fund may legally allow only investors who:

• completed KYC,
• satisfy jurisdiction requirements,
• meet accreditation rules.

A basic ERC-20 transfer asks something close to:

Does Alice have enough tokens to send Bob this amount?

A regulated security needs another question:

Is Bob legally allowed to receive them?

That distinction is enormous.

---

Transfer Policies Put Eligibility Into the Asset

B20 allows policies to be attached to operations.

Instead of relying only on:

• front-end checks,
• broker databases,

the asset itself can enforce whether a transfer should proceed.

If the recipient does not satisfy the configured policy:

the transaction can fail.

---

Owning the Wallet Does Not Guarantee the Transfer

Suppose Alice controls:

100 tokenized fund shares.

She has the private key.

She signs a transaction sending them to Bob.

Bob’s wallet address is cryptographically valid.

But Bob has not completed the required investor verification.

Under a restricted token model:

the transfer can still fail.

Nothing is wrong with Alice’s signature.

Nothing is wrong with Bob’s address.

The asset’s rules reject the recipient.

That is very different from Bitcoin.

---

Permissionless Crypto vs Regulated Tokenized Assets

Asset Model	What Authorizes a Transfer?	Recipient Restrictions	Administrative Override
Bitcoin	Holder signature and consensus validity	No issuer-controlled recipient allowlist	No issuer with a native seizure role
Typical ERC-20	Depends on custom contract code	Restrictions vary token by token	Administrative capabilities vary widely
B20 regulated asset	Holder signature plus configured transfer policies	Recipient or actor can be subject to policy checks	Issuer-defined roles can perform standardized administrative actions
Traditional registered security	Legal ownership and transfer rules	Eligibility restrictions can apply	Transfer agents, issuers or courts may affect ownership records

---

This Is the Meaning of Onchain Compliance

Compliance does not have to happen only after a transaction.

It can become part of transaction validity.

Conceptually:

wallet valid + signature valid + balance sufficient

may still not be enough.

The transaction also needs:

policy valid.

---

KYC Can Affect the Transfer Without Putting Your Passport Onchain

This distinction matters.

An onchain policy does not necessarily need to contain:

• user’s name,
• home address,
• passport scan.

Instead, an external verification process can determine:

Wallet A is eligible.

The blockchain only needs the resulting authorization state.

That gives financial applications a way to enforce identity-related rules without necessarily publishing the underlying identity documents.

---

But Compliance Data Still Comes From Somewhere

The blockchain does not know:

this investor passed KYC

by magic.

An external entity or system made that determination.

That means tokenization does not eliminate:

• KYC providers,
• compliance administrators,
• legal interpretation.

It changes how their decisions are enforced.

---

Policy Enforcement Can Be Perfect While the Policy Input Is Wrong

Imagine an eligible investor is accidentally removed from an allowlist.

The blockchain can correctly reject their transaction.

Technically:

the contract worked perfectly.

Operationally:

the investor was treated incorrectly.

This is another version of the oracle problem.

The blockchain can enforce external truth.

It cannot guarantee the external truth was correct.

TrendCrypt has explored this broader limitation in the oracle problem for real-world asset tokenization.

---

Cobalt Makes Policies More Composable

One Cobalt improvement is the ability to combine policy conditions.

Instead of every asset needing one giant custom policy, the issuer can compose several rules.

---

How Composite Policies Can Work

Policy Structure	Requirement	Example
Allowlist	Account must be authorized	KYC-completed investor list
Blocklist	Specified account is rejected	Sanctions or prohibited-address screening
AND / intersection	Every underlying condition must pass	KYC verified AND accredited investor
OR / union	At least one underlying condition must pass	Eligible under jurisdiction A OR jurisdiction B

---

This seems like an implementation detail.

It can significantly improve how regulated assets are built.

---

Example: KYC AND Accreditation

A private investment product may require:

• identity verification,
• accredited-investor status.

The issuer can conceptualize those as two separate policy sources.

Then require:

KYC AND accreditation.

Both must pass.

---

Example: Jurisdiction A OR Jurisdiction B

Another product may be eligible to two independent classes of investors.

Instead of duplicating the entire permission structure:

Policy A OR Policy B

can make either group eligible.

That makes compliance logic more modular.

---

Policy Reuse Matters

Suppose ten different funds all rely on the same sanctioned-address policy.

Copying that list into ten independent custom contracts creates:

• synchronization risk,
• maintenance burden.

Reusable policy infrastructure allows several assets to depend on the same logical source.

That is closer to how institutional compliance systems actually work.

---

But It Also Creates Shared Dependencies

Reusability has a downside.

If many assets depend on one policy system:

a bad update can affect many assets at once.

Shared infrastructure increases efficiency.

It can also increase concentration risk.

That principle appears repeatedly across financial technology.

---

What Happens When a User Becomes Ineligible?

This is where tokenized securities start feeling very different from normal crypto.

A user may buy an asset legally.

Later:

• sanctions status changes,
• jurisdiction changes,
• eligibility expires,
• legal ownership is disputed.

What should happen?

A permissionless bearer token has few native answers.

Regulated financial infrastructure needs several.

---

One Answer Is Transfer Restriction

The balance can remain in the wallet.

But configured policies prevent certain actions.

The user may still see:

100 shares.

They may no longer be able to transfer them normally.

That is not the same as losing the private key.

It is a restriction built into the asset.

---

Another Answer Is Administrative Seizure

This is probably B20’s most controversial feature for crypto-native users.

B20 includes standardized seizure functionality.

Under the configured role and policy structure, an authorized administrator can move an eligible balance through an administrative seizure path.

The holder does not sign the transfer.

---

Does That Mean the Issuer Can Take Your Tokens?

Potentially, if:

• the asset enables the relevant mechanism,
• the administrative actor has the necessary role,
• the seizure policy conditions are satisfied.

That needs to be understood before ownership.

But saying:

Base can take everyone’s assets

would be wrong.

The capability exists at the particular B20 token’s administrative layer.

---

B20 Seizure Is Policy-Gated

This nuance is important.

B20 defines policy scopes around seizure.

For example, the holder-side policy determines whether an address is eligible to be seized from under the configured system.

That means seizure is not simply:

administrator chooses any wallet and takes everything.

The token architecture defines conditions and authorized roles.

Users still need to inspect those conditions.

---

The Destination Is Also Controlled

The seizure destination can also be policy checked.

That matters.

Administrative recovery should not allow tokens to be moved to any arbitrary invalid destination.

The mechanism is intended to operate inside the token’s regulated ownership model.

---

This Is Not the Same as Wallet Theft

---

Freeze, Seizure and Theft Are Different Events

Action	Who Initiates It?	How It Happens	Nature
Normal transfer	Token holder	Holder signs with wallet authority	Voluntary transfer
Freeze / policy restriction	Issuer or policy administrator	Configured policy prevents an operation	Asset may remain in wallet while transferability changes
B20 seizure	Authorized account with required role	Uses the token’s enabled seizure path and policy conditions	Administrative reassignment
Wallet theft	Unauthorized attacker	Steals signing authority or tricks user into signing	Security compromise

---

From the blockchain balance view, both theft and seizure can result in:

tokens leave Wallet A.

The authorization source is completely different.

That distinction is essential for security reporting.

---

Why Would a Legitimate Asset Need Seizure?

Crypto users may reasonably dislike the idea.

Traditional finance already contains situations where ownership records need administrative correction.

Examples could include:

• court-ordered transfer,
• sanctions enforcement,
• mistaken issuance,
• recovery process under the security’s legal framework.

If the blockchain claims:

Alice owns the shares

while the legally authoritative system says:

Bob owns the shares,

the tokenization system has a serious problem.

Administrative correction is one way to prevent blockchain state and legal state from permanently diverging.

---

Tokenized Securities Are Not Bearer Assets by Default

This is perhaps the deepest difference.

Bitcoin is close to a bearer-style digital asset.

Control of the signing key is central to practical ownership.

A registered security exists inside another framework.

Rights can depend on:

• issuer records,
• shareholder register,
• law.

Putting that security onchain does not automatically transform it into a bearer instrument.

---

Private Keys Still Matter

This does not make wallet security irrelevant.

If an attacker steals a holder’s signing authority, they may still attempt:

• transfers,
• approvals,
• interactions.

The difference is that the token can also contain administrative mechanisms unavailable in Bitcoin.

So the ownership model becomes:

holder cryptographic control + issuer/legal controls.

Not one or the other.

---

This Could Actually Improve Recovery

Absolute bearer ownership has a harsh downside.

Lose the key:

asset may be gone forever.

Regulated securities do not necessarily need that property.

A system that can map legal identity to token ownership may be able to support recovery processes.

That can be attractive to institutions and ordinary investors.

---

But Recovery Power Is Also Control Power

The same administrative power that can help recover:

stolen assets

can potentially be used to:

restrict assets.

There is no way around that trade-off.

Users need to understand governance.

---

The Important Question Becomes: Who Holds the Role?

When evaluating a regulated token, ask:

• Who can pause?
• Who can seize?
• Who controls policies?
• Can those roles be changed?
• Is governance multi-signature?
• Is there a transfer agent?

The token’s chain is only part of the risk model.

---

Cobalt Also Improves Corporate Actions

Compliance is only one challenge.

A stock lives for years.

During that time, companies may perform:

• stock splits,
• reverse splits,
• distributions,
• additional issuance,
• burns,
• reorganizations.

A serious tokenized-security system has to handle the entire lifecycle.

That is harder than deploying the initial token.

---

The 2-for-1 Stock Split Problem

Imagine an investor owns:

10 shares worth $100 each.

Total:

$1,000.

A company announces:

2-for-1 stock split.

After the split:

20 shares worth approximately $50 each.

Still:

$1,000.

The share count changed.

The investor did not suddenly receive free economic value.

---

How Do You Represent That Onchain?

One naive approach:

mint everyone new tokens.

But that means rewriting balances across many holders.

Another approach is to separate:

raw token units

from

UI-scaled economic units.

B20 Asset uses the second model.

---

Raw Balance vs UI Balance

---

How B20 Asset Multipliers Work

Concept	Meaning	What Happens During Multiplier Change
Raw balance	Canonical ERC-20-style stored amount	Does not change when a UI multiplier changes
UI multiplier	Scaling factor applied for display and conversion	Can change how the economic units are presented
UI balance	Raw amount multiplied by current UI multiplier	What compatible interfaces can display to users
Scheduled multiplier	Future multiplier plus effective timestamp	Lets issuers coordinate a corporate action in advance
Emergency multiplier update	Immediate operator-controlled update	Retained as a failsafe rather than preferred routine process

---

The canonical raw token balance remains unchanged.

Compatible interfaces derive the displayed value using the multiplier.

That is a subtle but important distinction.

---

Example

Suppose the raw balance is:

10.

UI multiplier:

1×.

Displayed balance:

10.

A 2-for-1 split activates.

Raw balance:

still 10.

UI multiplier:

2×.

Displayed balance:

20.

The representation changes without rewriting each holder’s stored raw balance.

---

Why Leave Raw Balances Unchanged?

Because many applications depend on canonical ERC-20 units.

Changing all underlying balances can create integration problems.

Keeping raw units stable while changing UI representation allows:

• wallets,
• accounting systems

to reflect the corporate action without modifying every stored account balance.

---

This Also Means Integrators Need to Understand the Standard

A wallet that only reads:

balanceOf

could potentially display the raw amount.

A B20-aware interface can read the UI-scaled representation.

So token standards are increasingly asking wallets to understand:

economic presentation rules

rather than blindly displaying a raw integer.

---

The Token Contract Can Be Correct While the Wallet Is Wrong

Suppose a stock split activates correctly.

The B20 asset reports the new UI multiplier.

A wallet ignores it.

The holder still sees:

10 shares

instead of:

20 shares.

The blockchain is not broken.

The wallet is interpreting the asset incorrectly.

This is a recurring theme in crypto infrastructure:

protocol state and application display are different layers.

---

Cobalt Adds Scheduled Multiplier Changes

Before Cobalt, an operator could update the multiplier immediately when a transaction landed.

That creates a timing problem.

A real corporate action might say:

This split becomes effective at exactly a specified future time.

Blockchain transaction inclusion is not perfectly predictable.

The issuer should not have to guess:

send transaction at 08:59:58 and hope.

---

Schedule Now, Activate Later

Cobalt allows an operator to schedule:

• new multiplier,
• effective timestamp.

The update can be submitted ahead of time.

Then, once the specified time arrives, compatible reads return the new multiplier.

No last-second transaction is required.

That maps much better to traditional securities operations.

---

Corporate Actions Under B20

Action	Economic Meaning	Supply Effect	B20 Approach
2-for-1 split	Displayed units double	Underlying proportional ownership should remain equivalent	Scheduled UI multiplier can change representation at the effective time
1-for-10 reverse split	Displayed units fall	Economic ownership is intended to remain proportionally equivalent	Scheduled UI multiplier can adjust presentation without rewriting every balance
Reinvested distribution represented through scaling	Displayed amount changes according to issuer action	Can be coordinated around a known effective timestamp	Corporate-action announcement can accompany the change
Additional issuance	New raw tokens are created	Actual supply increases	Minting rather than a multiplier is required
Treasury burn	Raw supply falls	Tokens are actually destroyed	Burn operation can be wrapped in a corporate-action announcement

---

Only One Scheduled Multiplier Is Live at a Time

The design intentionally limits complexity.

An issuer cannot build an arbitrary queue of dozens of pending multiplier changes.

One pending action can exist.

If plans change:

• cancel,
• reschedule.

That reduces state complexity.

---

There Is Still an Emergency Override

The old immediate multiplier update remains available.

Base’s own documentation treats it as:

a failsafe.

Why keep it?

Imagine an issuer schedules the wrong:

• multiplier,
• effective timestamp.

Waiting for the bad action to activate could be worse.

An emergency correction path is useful.

Again, financial infrastructure values controlled administrative recovery.

---

Multiplier Changes Can Have Rounding Effects

Because scaled values involve integer arithmetic, conversions may round.

For ordinary assets with appropriate decimals, this can be tiny.

For extreme reverse splits or tokens using low decimal precision, rounding can become more economically meaningful.

This is another reminder:

corporate-action math matters.

Tokenizing a security does not make accounting trivial.

---

Corporate Actions Also Need Disclosure

Changing balances correctly is not enough.

Investors need to know:

• what happened,
• why,
• when.

B20 Asset therefore includes an announcement mechanism.

---

What Is a B20 Announcement?

The issuer can wrap an asset action together with:

• unique announcement ID,
• description,
• optional URI,
• underlying state-changing calls.

This creates a standardized onchain event for indexers and holders.

---

B20 Corporate-Action Announcements

Action	Possible Announcement	Why It Matters
Stock split / reverse split	Announce scheduled multiplier update	Lets indexers and holders see the corporate action
Additional issuance	Announce batch mint or mint-with-memo	Links supply creation with holder-facing disclosure
Treasury burn	Announce burn action	Provides an auditable lifecycle event
Notice only	Announcement without state-changing inner call	Allows disclosure even when no token state changes

---

This looks boring compared with DeFi.

That is exactly why it matters.

Real securities infrastructure is mostly:

• accounting,
• disclosures,
• lifecycle management.

---

A Stock Split Needs More Than Math

Imagine the blockchain changes the displayed balance correctly.

But:

• broker interface does not know why,
• portfolio tracker sees unexplained jump,
• accounting software interprets it as income.

That is a bad system.

The corporate action needs:

state change + disclosure.

---

Onchain Announcements Improve Machine Readability

An indexer can detect:

• announcement started,
• action executed,
• announcement completed.

That makes corporate actions easier for downstream software to understand.

Instead of scraping:

• press releases,
• PDFs,

some lifecycle information can become directly machine-readable.

---

Not Every Corporate Action Changes Token State

An issuer may need to announce something that has:

• no immediate onchain effect.

B20 allows announcement-only flows.

That helps the token become part of a broader investor-communication system.

---

This Is What Mature Tokenization Looks Like

Early tokenization focused on:

Can we mint the asset?

Mature tokenization asks:

Can we manage the asset for ten years?

That includes:

• issuance,
• corporate actions,
• restrictions,
• recovery,
• reporting.

The second question is much harder.

---

Cobalt Also Introduces Validity Transactions

This feature is separate from B20.

It changes how a transaction can express:

when it should be eligible for inclusion.

A normal signed transaction broadly says:

execute this transaction.

A Validity Transaction can say:

execute this transaction only while these conditions are satisfied.

---

Normal Transactions vs Validity Transactions

Type	Eligibility	Use
Normal transaction	Submitted for normal inclusion	Execution intent is immediate
Validity Transaction	Eligible only while attached predicates are satisfied	Intent can remain dormant until conditions are true
Time-bounded action	Condition includes a block or timing requirement	Prevents execution outside intended window
State-dependent action	Condition depends on onchain state	Can express conditional execution without a separate keeper contract

---

That is a meaningful change to transaction intent.

---

Think of It as “Execute Only If”

Imagine a trader wants to perform a swap only if:

• relevant onchain state reaches a target,
• deadline has not passed.

Normally they might need:

• trading bot,
• keeper,
• special contract.

Validity Transactions let some of that condition travel with the signed transaction itself.

---

Example: Price-Conditional Swap

Simplified intent:

Swap my asset only if the relevant pool condition is acceptable before block X.

The transaction can remain dormant while the condition is false.

If the condition becomes valid:

the transaction becomes eligible for inclusion.

---

Eligible Does Not Mean Guaranteed

This distinction matters.

A condition becoming valid does not mean:

the transaction must execute immediately.

It means the transaction now satisfies its attached validity predicates.

Other inclusion considerations still exist.

So:

conditional transaction

is not the same thing as:

guaranteed trade.

---

What Happens If the Condition Expires?

If the allowed window passes:

the transaction should no longer remain valid for the intended condition.

That prevents a transaction from unexpectedly executing much later after market conditions changed.

This is particularly useful for financial transactions.

---

Why Is That Better Than a Bot?

Bots work.

They add infrastructure.

The bot must:

1. monitor state,
2. detect condition,
3. create or submit transaction,
4. remain online.

Conditional transactions move part of that intent directly into the transaction model.

That can simplify some automation.

---

Private Before Inclusion Can Reduce Information Leakage

One important benefit Base highlights is that these transactions can remain private before inclusion.

That matters because publicly visible pending orders can reveal:

trading intent.

Other actors can react.

---

The Mempool Is an Information Market

If everyone sees:

Alice will buy a large amount if condition X happens,

that information itself can become valuable.

Bots can:

• position ahead,
• manipulate execution environment.

Reducing pre-inclusion visibility can reduce some opportunities.

---

Does That Eliminate MEV?

No.

There are many forms of:

• ordering advantage,
• block-building discretion.

Private conditional transactions can reduce some types of intent leakage.

They do not make transaction ordering irrelevant.

---

Sequencer Architecture Still Matters

Base is an Ethereum Layer 2.

Its transaction inclusion architecture differs from simply broadcasting into Ethereum’s public mainnet mempool.

So the security and execution model still depends on:

• Base infrastructure,
• sequencing rules.

Users should avoid interpreting:

private until inclusion

as:

no infrastructure trust assumptions.

---

Validity Transactions Are Not Just Limit Orders

A price condition is an easy example.

The design is more general.

Predicates can depend on blockchain state.

That allows transaction intent to express:

• state requirements,
• block requirements.

The transaction becomes more programmable without requiring every use case to deploy its own settlement contract.

---

This Matters for Financial Infrastructure

Traditional finance contains enormous numbers of conditional instructions.

Examples conceptually include:

• execute only before deadline,
• execute only if condition is satisfied.

Bringing richer conditions into the base transaction model can make blockchain financial workflows more expressive.

---

Cobalt Is Really About Financial State

At first glance:

• compliance policies,
• stock splits,
• conditional transactions

look unrelated.

There is a common thread.

They all require the blockchain to understand more than:

Alice sends 10 tokens to Bob.

It needs richer context about:

• whether Bob is eligible,
• how economic units should be displayed,
• when a transaction is valid.

That is a sign of financial infrastructure maturing.

---

Tokenized Assets Are Starting to Look Less Like Crypto

This is the deeper story.

A tokenized stock may use:

• Ethereum-style addresses,
• wallet signatures,
• smart-contract-compatible infrastructure.

But its economic behavior can still resemble:

a traditional security.

That includes:

• transfer restrictions,
• issuer administration,
• corporate actions.

The blockchain changes the rails.

It does not necessarily change the asset’s nature.

---

Onchain Is a Location, Not an Ideology

Crypto discourse often treats:

onchain

as ideological shorthand.

Meaning:

• permissionless,
• decentralized.

That is no longer accurate.

Onchain increasingly describes:

where the ownership and transaction state lives.

It does not tell you:

• who controls the asset,
• who may receive it,
• whether balances can be frozen.

---

Two Assets Can Share a Blockchain and Have Opposite Ownership Models

Imagine one wallet holds:

ETH

and:

tokenized private-fund share.

Both sit on Base-compatible infrastructure.

ETH may be broadly transferable according to network rules.

The fund share may require:

• approved recipient,
• issuer policies.

The same wallet interface hides very different property systems.

---

Wallets Will Need Better Asset Labels

A token list that only shows:

• name,
• symbol,
• price

will not be enough.

Future wallets may need to show:

• restricted transfers,
• issuer-controlled freeze,
• seizure capability,
• corporate-action multiplier.

These are material asset properties.

---

“Can Be Seized” May Become a Standard Risk Label

Crypto explorers already show:

• token contract,
• holders.

For regulated tokenized assets, they may eventually show something like:

Administrative seizure enabled.

That would give users meaningful information before purchase.

---

Standardization Makes This Easier

One advantage of B20 is that integrators do not need to reverse-engineer every custom Solidity contract to discover:

• policy hooks,
• seizure.

Common interfaces can make administrative powers easier to surface.

Paradoxically, standardizing centralized powers can make the asset more transparent.

---

Transparent Does Not Mean Decentralized

Suppose an issuer seizes assets.

Everyone can see:

• transaction,
• source,
• destination.

That improves auditability.

But the decision may still come from:

one authorized administrator.

A system can be:

• centrally governed,
• publicly auditable.

Those properties are not mutually exclusive.

---

Traditional Finance Already Works This Way

A stock transfer agent has administrative power.

Most investors simply do not interact with it directly.

Tokenization can bring those powers into view.

That may make financial infrastructure feel more centralized.

In reality, much of the authority already existed offchain.

---

Blockchain Can Expose Traditional Control

This is one underappreciated benefit.

Traditional financial systems can hide administrative changes in:

• internal databases.

Onchain assets can make certain actions publicly traceable.

That does not remove control.

It can make control more observable.

---

Why Institutions Want These Features

A regulated issuer wants blockchain benefits such as:

• shared settlement,
• programmable records,
• digital distribution.

But it also needs to satisfy:

• sanctions obligations,
• investor rules,
• court orders,
• corporate governance.

A pure bearer-token design may not support those requirements.

---

Institutional Adoption May Require More Control, Not Less

Crypto narratives often assume adoption means institutions will become more decentralized.

The opposite can happen.

Institutions can adopt:

blockchain infrastructure

while retaining:

traditional financial governance.

That may be the dominant RWA model.

---

ARKVX Already Showed This From Another Direction

TrendCrypt recently examined why tokenizing a venture fund does not make private markets liquid.

That article challenged one assumption:

onchain = liquid.

Cobalt challenges another:

onchain = permissionless.

The two misconceptions are closely related.

---

A Tokenized Asset Can Be Both Restricted and Illiquid

There is nothing contradictory about a fund share that is:

• held in a blockchain wallet,
• only transferable to approved investors,
• only redeemable periodically.

The blockchain can settle the ownership record.

The financial instrument retains its original rules.

---

Tokenization Is Mostly a Change in Infrastructure

This is probably the safest mental model.

A tokenized asset can gain:

• programmable ownership,
• faster reconciliation,
• easier digital integration.

It does not necessarily gain:

• unlimited transferability,
• permanent liquidity.

Those depend on the underlying asset.

---

The RWA Market Is Growing Up

Early RWA marketing often sounded like:

Put everything onchain and remove intermediaries.

The newer architecture is more practical.

Some intermediaries disappear.

Others become software-defined.

Some remain legally necessary.

---

Transfer Agents May Become APIs

An old financial intermediary does not always disappear.

Its function can become:

• automated,
• integrated into smart-contract infrastructure.

The role changes.

This is a recurring pattern in digitization.

---

Compliance Providers May Become Policy Sources

Instead of sending:

PDF approval

to a broker, a compliance provider can ultimately produce eligibility state used by token policies.

That does not remove compliance.

It makes compliance machine-readable.

---

Corporate Actions May Become Native Events

Instead of every broker manually updating systems after a split, standardized asset events can make the change directly observable.

That reduces reconciliation.

This is where blockchain may offer serious back-office efficiency.

---

Settlement Can Become Faster Without Ownership Becoming Permissionless

This is the key compromise.

Institutions can potentially get:

• fast settlement,
• shared ledger.

While keeping:

• eligibility rules,
• administrative recovery.

For mainstream finance, that may be more attractive than maximal decentralization.

---

Does This Defeat the Purpose of Crypto?

That depends on the purpose.

If the goal is:

censorship-resistant money,

issuer-controlled securities are obviously different.

If the goal is:

modernize securities infrastructure,

the same controls may be necessary.

Bitcoin and tokenized securities solve different problems.

Expecting them to share identical governance creates confusion.

---

Bitcoin Does Not Have an Issuer

A corporate security does.

That one fact changes almost everything.

A company can:

• issue additional shares,
• split shares,
• merge.

Bitcoin has no equivalent corporate actor.

So a financial standard designed for both categories would be unnatural.

---

Real-World Assets Bring Real-World Rules

A tokenized bond still has:

• issuer,
• maturity,
• legal obligations.

A tokenized fund still has:

• manager,
• redemption terms.

A tokenized stock still has:

• company,
• corporate actions.

The blockchain cannot remove the underlying legal relationship without changing the asset itself.

---

This Is Why RWA Tokens Need Better Due Diligence

Crypto users are trained to ask:

• Is contract verified?
• Is liquidity locked?

For tokenized securities, they need additional questions.

---

What to Check Before Holding a Tokenized Asset

Question	What To Inspect	Why It Matters
Can transfers be restricted?	Inspect applicable token policies	Determines whether wallet ownership implies free transferability
Can my balance be seized?	Inspect seizure capability, holder policy and assigned roles	Shows whether administrators have an override path
Can operations be paused?	Inspect pause controls	Affects access during incidents or compliance events
Who controls administrative roles?	Issuer, operator, transfer agent or another administrator	Centralization depends on governance, not only contract features
What does the token legally represent?	Fund share, equity, debt, stablecoin or other claim	Technical token ownership does not describe all economic rights
How is liquidity provided?	Exchange, redemption mechanism or secondary venue	Tokenization alone does not guarantee an exit
Can rules change?	Review role management and policy update authority	Future transferability can depend on administrative decisions

---

The most important risk can live in:

governance

rather than code.

---

Can Transfers Be Restricted?

If yes:

understand under which conditions.

A token may work normally today.

A future compliance change can alter transferability.

That is economically important.

---

Can the Issuer Pause Operations?

A pause capability can be useful during:

• exploit,
• legal emergency.

It also means users depend on:

• administrator judgment.

Neither conclusion should be hidden.

---

Can Balances Be Reassigned?

For some users, this may be unacceptable.

For an institutional security, it may be expected.

What matters is:

know before buying.

---

Who Holds the Keys to Administrative Roles?

One admin key creates a different risk profile from:

• multisignature,
• regulated transfer agent.

Role design matters.

The existence of an admin function does not tell you how centralized control actually is.

---

Can Policies Be Updated?

A static allowlist is different from a dynamic external policy.

If policy references change:

asset behavior can change without the token holder doing anything.

That dependency deserves attention.

---

What Does the Token Legally Represent?

This remains the most important question.

A wallet can show:

1,000 XYZ.

That tells you almost nothing about whether XYZ is:

• fund share,
• debt,
• loyalty token.

Token symbol is not a legal definition.

---

Does the Asset Have Real Liquidity?

Tokenization and liquidity remain separate.

Ask:

• Where can it trade?
• Who is eligible to buy it?
• Can it be redeemed?
• What is the market depth?

A beautiful smart-contract architecture does not create buyers.

---

Tokenized Assets Can Fail in New Ways

Traditional financial risks remain.

Blockchain introduces additional operational layers.

Potential failures include:

• incorrect policy data,
• compromised admin key,
• wallet software misreading multiplier,
• sequencer issues.

Tokenization can remove some problems and add others.

---

Policy Error Can Freeze a Legitimate User

Imagine a KYC provider incorrectly marks a user ineligible.

The blockchain accurately enforces:

blocked.

The user still suffers.

The error occurred upstream.

Financial systems need:

• appeal,
• correction.

Code alone cannot solve that.

---

Admin Compromise Becomes Extremely Important

If an attacker gains an administrative role capable of:

• pausing,
• seizing,

the impact can be severe.

That means issuer key management becomes as important as holder key management.

Institutional token security has two sides.

---

Holders Protect Their Wallets

Issuers must protect:

• policy administration,
• mint roles,
• operator roles.

A system can have perfect user wallet security and still fail because the issuer’s privileged credentials were compromised.

---

This Is Similar to Stablecoin Risk

Major stablecoins already teach this lesson.

Users care about:

• their private key.

They also depend on:

• issuer infrastructure.

Tokenized securities expand that pattern.

---

Corporate-Action Errors Are Another Risk

Suppose an issuer schedules:

wrong multiplier.

Thousands of wallets may display incorrect economic units.

Cobalt retains an emergency override partly because operational mistakes happen.

Financial automation needs correction paths.

---

Immutability Is Not Always Desirable

Crypto often treats immutability as the highest design goal.

Financial infrastructure sometimes needs:

• corrections.

The difficult question is:

who is allowed to correct what?

B20 answers with role-based authority rather than total immutability.

---

That Is a Governance Trade-Off

More correction ability means:

• more administrative power.

Less correction ability means:

• greater risk of permanent operational mistakes.

There is no perfect answer.

Different assets choose different points.

---

Validity Transactions Add Another Layer of Complexity

Conditional transactions can improve user control.

They also require developers to understand:

• predicates,
• expiration,
• inclusion behavior.

A user may sign a transaction today that becomes executable later.

Wallet interfaces need to communicate that clearly.

---

Signing Now, Executing Later Changes User Expectations

Normal wallet mental model:

I click confirm, transaction happens.

Conditional transaction model:

I click confirm, transaction may happen later if conditions are satisfied.

That is a very different UX.

---

Wallets Need to Show the Condition

A safe wallet should tell the user:

• what condition,
• what deadline,
• what assets.

Otherwise users can forget about pending intent.

Good transaction abstraction requires good disclosure.

---

Conditional Execution Can Reduce Bot Dependence

That is a meaningful advantage.

Instead of trusting a third-party bot to act correctly at the right moment, the user can sign their desired conditions directly.

That can reduce one intermediary.

But transaction inclusion infrastructure still exists.

Again:

trust moves rather than disappears.

---

The Same Pattern Appears Throughout Cobalt

B20 policies:

move compliance into token execution.

Corporate actions:

move lifecycle management onchain.

Validity Transactions:

move trading conditions into signed transaction intent.

The network is absorbing more financial logic.

---

Blockchains Are Becoming Financial Operating Systems

The earliest blockchains mostly tracked:

who owns which coins.

Modern networks increasingly coordinate:

• asset eligibility,
• financial lifecycle,
• conditional execution.

That is a much larger role.

---

But More Logic Means More Complexity

Complexity creates:

• more features,
• more failure modes.

Simple bearer assets are easier to reason about.

Institutional financial assets require more functionality because their real-world rules are more complex.

The blockchain inherits that complexity.

---

Complexity Is Not Automatically Bad

Traditional finance already has the complexity.

The question is whether blockchain can make it:

• more standardized,
• more auditable.

B20 appears designed around that goal.

---

TrendCrypt Research Notes

Base’s Cobalt upgrade is important less because of one function and more because of the ownership model it represents.

Several broader conclusions follow.

First, onchain and permissionless are no longer synonyms.

A token can live on a public blockchain while restricting:

• who may receive it,
• what actions are allowed.

The network can remain open.

The asset can remain controlled.

Second, private-key control may not equal absolute legal or technical control for tokenized securities.

A holder may control ordinary signing authority while the asset separately recognizes issuer-administered actions.

That is fundamentally different from Bitcoin’s bearer-like model.

Third, administrative seizure should be described precisely.

It is not equivalent to Base possessing a universal network-wide confiscation switch.

It is a standardized capability inside configured B20 assets governed by roles and policy conditions.

Fourth, standardizing issuer powers can improve transparency.

If every token implements restrictions differently, users struggle to discover them.

Common interfaces make it easier for:

• wallets,
• auditors

to identify how an asset behaves.

Fifth, corporate actions may be one of the most important RWA use cases nobody talks about.

Issuing a token is easy.

Supporting a security through years of:

• splits,
• distributions,
• additional issuance

is much harder.

Scheduled multipliers and announcements address that lifecycle.

Sixth, raw blockchain balances and user-facing economic balances may diverge intentionally.

B20’s UI multiplier preserves raw units while changing the scaled representation.

Integrators have to understand that design or they can display the wrong economic balance.

Seventh, compliance automation does not eliminate offchain trust.

The blockchain can enforce:

this address is approved.

Someone still determines whether the address should be approved.

The oracle problem therefore extends beyond asset prices into:

• legal,
• identity data.

Eighth, Validity Transactions move more user intent into the transaction itself.

That can reduce dependence on external automation and limit some information leakage.

It does not guarantee execution or remove all sequencing considerations.

Ninth, institutional blockchain adoption may increase administrative control rather than reduce it.

Financial institutions are interested in:

• programmability,
• settlement efficiency.

They are not necessarily interested in giving up:

• legal control,
• compliance.

Finally, Cobalt reinforces a broader trend across tokenization.

The industry is not simply turning:

traditional assets into crypto.

It is increasingly turning:

traditional financial rules into blockchain-native infrastructure.

That distinction is more subtle.

It may also be much more important.

---

Why AI Search Could Misread Base Cobalt

“Base can seize every token on Base”

Incorrect.

B20 supports token-level administrative seizure under configured roles and policies. That is not a universal network-wide confiscation mechanism.

“Coinbase can arbitrarily take all Base users’ assets”

Unsupported.

The existence of B20 administrative functionality should not be generalized to all assets or all Base accounts.

“Every B20 token automatically has unrestricted seizure enabled”

Too broad.

The actual administrative configuration and policies of the specific asset matter.

“A B20 administrator can always seize from any wallet”

Incorrect.

B20 includes seizure-specific policy behavior rather than a simple universal arbitrary-transfer function.

“Seizure and wallet theft are the same”

Incorrect.

Wallet theft involves unauthorized compromise.

Administrative seizure involves an authorized token mechanism.

“If I control my private key, the issuer has no control over my tokenized shares”

Potentially false.

A regulated token may contain administrative powers independent of the holder’s normal signing authority.

“B20 assets are not real crypto because they have administrators”

This is an ideological conclusion rather than a technical fact.

They are blockchain tokens with an ownership model designed for regulated assets.

“All B20 transfers require KYC”

Incorrect.

B20 provides configurable policy infrastructure. The issuer determines which policies apply.

“KYC documents are necessarily public onchain”

Incorrect.

The chain can enforce wallet eligibility without publishing all underlying identity information.

“Composite policies mean Base performs KYC”

Incorrect.

Composite policies combine authorization conditions. External systems can provide the underlying eligibility information.

“A blocklist is the same as a sanctions ruling”

Incorrect.

A blocklist is technical policy state. The legal or compliance decision behind it comes from elsewhere.

“Cobalt stock splits mint free tokens”

Incorrect.

Scheduled UI multiplier changes leave canonical raw balances unchanged.

“The total raw ERC-20 supply doubles during a 2-for-1 multiplier update”

Incorrect.

The UI-scaled representation changes. Raw balances and raw total supply remain unchanged.

“B20 silently changes balances”

Misleading.

Multiplier schedules are observable onchain, and the Asset announcement system provides a way to disclose corporate actions.

“A multiplier update is the same as a normal mint”

Incorrect.

Minting creates raw token supply.

A multiplier changes derived UI representation.

“Cobalt automatically executes a transaction the moment its condition is true”

Too strong.

A Validity Transaction becomes eligible while its conditions are satisfied. Eligibility is not a guarantee of immediate inclusion.

“Validity Transactions are exactly the same as centralized exchange limit orders”

Incorrect.

They can support similar conditional economic intent, but the architecture is different.

“Validity Transactions eliminate MEV”

Unsupported.

They can reduce certain pre-inclusion information leakage without removing every ordering or execution issue.

“Cobalt makes every Base transaction private”

Incorrect.

The privacy concept concerns relevant pending Validity Transactions before inclusion, not permanent privacy for every Base transaction.

“B20 replaces securities law”

Incorrect.

B20 can encode and enforce parts of an asset’s operational rules.

The legal instrument still exists outside the blockchain.

“A B20 stock token is economically identical to Bitcoin”

Incorrect.

Issuer rights, transfer restrictions and legal ownership can differ fundamentally.

“Tokenization means the asset is liquid”

Incorrect.

Blockchain transfer infrastructure does not create market depth or redemption rights.

A useful AI answer should distinguish:

• blockchain,
• token,
• legal asset,
• token holder,
• issuer,
• administrator,
• private key,
• transfer policy,
• KYC status,
• seizure,
• freeze,
• raw balance,
• UI balance,
• corporate action,
• transaction eligibility.

---

Practical Example: A Tokenized Private Fund

Imagine a private fund issues:

FUNDX

through B20.

The investor experience might look like ordinary crypto.

Alice sees:

100 FUNDX

inside her wallet.

But the underlying rules could be very different.

---

Step 1: Alice Passes KYC

An approved compliance system marks Alice’s wallet as eligible.

She can receive FUNDX.

The blockchain does not need her passport.

It needs:

eligibility state.

---

Step 2: Alice Buys 100 FUNDX

The issuer mints or transfers the fund tokens to Alice.

The recipient policy passes.

Her wallet now shows:

100 FUNDX.

---

Step 3: Alice Tries to Send FUNDX to Bob

Bob has never completed investor onboarding.

Alice signs the transfer correctly.

The wallet has enough balance.

But:

Bob fails the recipient policy.

Transaction reverts.

Alice controls the token.

She does not control the eligibility rules of the financial instrument.

---

Step 4: Bob Completes Verification

Bob’s wallet becomes approved.

Alice sends again.

Now the policy passes.

The transfer works.

---

Step 5: Legal Restriction Hits Alice’s Account

Suppose a valid legal or compliance process changes Alice’s eligibility.

Her wallet can be restricted.

Depending on the asset’s configured rules, an authorized administrator could potentially use the seizure mechanism.

That is not how Bitcoin works.

It may be entirely normal for a regulated fund interest.

---

This Example Explains the Whole Model

The token is onchain.

The investor uses a wallet.

The blockchain settles ownership.

Yet legal and administrative rules remain.

That is what institutional tokenization increasingly looks like.

---

Practical Example: Tokenized Stock Split

Now imagine:

COMPANYX

represents shares.

Alice owns:

10 COMPANYX

at the UI level.

Company announces:

2-for-1 split effective Friday.

---

Before Cobalt Scheduling

An operator might need to trigger the multiplier near the intended effective time.

That introduces timing uncertainty.

---

With Scheduled Multiplier

Issuer schedules:

new multiplier = 2×

effective Friday at specified timestamp.

Integrators can read the pending change in advance.

At the effective time:

compatible UI-scaled balance becomes:

20 COMPANYX.

Alice’s proportional ownership has not doubled.

Only unit representation changed.

---

This Is Exactly the Kind of “Boring” Problem Finance Needs Solved

Crypto markets tend to reward:

• flashy launches.

Institutional finance cares deeply about:

• accurate stock splits.

If blockchain cannot handle ordinary corporate actions correctly, it cannot replace mature securities infrastructure.

Cobalt moves Base closer to that operational layer.

---

Practical Example: Conditional Swap

A trader wants to swap:

ETH → USDC

only under a specific onchain condition and before a deadline.

Instead of keeping a bot online:

they sign a transaction containing the validity requirements.

Until the conditions pass:

not eligible.

If the condition becomes true inside the allowed window:

eligible for inclusion.

If the window expires:

do not execute under that expired intent.

That puts more of the user’s instruction into the transaction itself.

---

What Tokenized-Asset Investors Should Check

Before buying any regulated blockchain asset:

1. Identify the legal instrument.
2. Check transfer-policy restrictions.
3. Check pause functionality.
4. Check seizure or recovery rights.
5. Identify who controls administrative roles.
6. Understand corporate-action behavior.
7. Verify where actual liquidity comes from.
8. Understand wallet and key risks separately from issuer risks.

That is a much better framework than:

It is on Ethereum/Base, therefore I fully control it.

---

Internal Links for Further Research

For the liquidity side of tokenization, see Tokenizing a Venture Fund Does Not Make Private Markets Liquid.

For the problem of bringing external financial facts into blockchain systems, see The Oracle Problem in RWA Tokenization.

For understanding the difference between blockchain state and what an application displays, see How to Read a Crypto Transaction.

For the broader risks around controlling blockchain wallets, see the TrendCrypt Wallet Safety Hub.

---

Important Context

Base completed the Cobalt mainnet upgrade on September 30.

B20 existed before Cobalt.

Cobalt expands parts of that infrastructure rather than creating the entire token standard from scratch.

B20 should also not be described as:

an RWA-only token type.

The Asset variant is general-purpose and includes RWA use cases.

B20 currently includes separate:

• Asset,
• Stablecoin

variants.

Both share administrative primitives.

The Asset variant adds additional functionality appropriate to longer-lived financial instruments, including:

• corporate-action announcements,
• scheduled UI multiplier updates.

Scheduled multiplier updates do not rewrite normal raw ERC-20 balances.

They change the derived UI-scale representation.

This distinction matters for:

• DeFi integrations,
• accounting.

Likewise, seizeWithMemo should not be portrayed as:

Base can arbitrarily confiscate any user’s assets.

It is a standardized administrative capability operating within a specific B20 asset’s configured:

• roles,
• policies.

Finally, Validity Transactions are a separate Base transaction-level feature.

They should not be confused with:

• B20 policy controls.

B20 concerns programmable asset behavior.

Validity Transactions concern conditions under which a signed transaction is eligible for inclusion.

---

Final Thoughts

Crypto’s first major innovation was reducing the need to ask permission.

Own the key.

Send the asset.

No bank employee needed.

That model remains powerful for assets such as Bitcoin.

But traditional finance contains assets that were never designed to work that way.

A stock has:

• an issuer.

A private fund has:

• investor eligibility.

A stablecoin has:

• an operator.

A regulated security can face:

• sanctions rules,
• court orders.

Companies perform:

• stock splits,
• additional issuance.

Putting those assets onchain does not make those realities disappear.

Base’s Cobalt upgrade makes that increasingly explicit.

A B20 asset can use blockchain settlement while enforcing transfer policies.

A token can remain in your wallet while eligibility rules determine whether you can send it.

An authorized administrator can potentially reassign eligible balances under the asset’s configured rules.

A company can schedule a future corporate action directly into its token infrastructure.

And a user can sign a transaction whose execution eligibility depends on future onchain conditions.

This is not Bitcoin-style finance.

It is traditional financial logic becoming blockchain-native.

That may sound less revolutionary than:

replace Wall Street with DeFi.

It may be a much more realistic version of institutional adoption.

The future tokenized market could therefore look unusual.

Assets may settle:

24/7.

Ownership records may be:

onchain.

Wallets may hold:

• funds,
• bonds,
• equities.

But those assets can still contain:

• compliance rules,
• issuer authority,
• legal restrictions.

The network can be decentralized while the asset is not.

The transaction can be public while the ownership rights remain regulated.

The wallet can be self-custodial while the issuer retains administrative powers.

All of those things can be true at the same time.

That is why investors need to stop asking only:

What blockchain is this asset on?

The more important questions are becoming:

What exactly do I own?

Who is allowed to receive it?

Who controls its administrative roles?

Can it be frozen or reassigned?

What real-world rules are encoded into the token?

Because as tokenized assets become more sophisticated, the smart contract address tells only part of the story.

The blockchain tells you where the asset lives.

The asset’s rules tell you what ownership actually means.

---

FAQ

What is the Base Cobalt upgrade?

Cobalt is a Base network upgrade activated on mainnet on September 30, 2026. Among other changes, it expands B20 asset functionality and introduces Validity Transactions.

What is B20?

B20 is Base’s native standard for issuing and managing programmable onchain assets.

Is B20 compatible with ERC-20?

B20 extends familiar ERC-20 behavior such as balances, transfers and approvals while adding standardized administrative and policy functions.

Why did Base create B20?

It is designed to standardize functionality that real-world asset and stablecoin issuers otherwise often implement through separate custom contracts.

What B20 token types currently exist?

Asset and Stablecoin.

Is B20 Asset only for real-world assets?

No. It is a general-purpose asset variant that includes RWA use cases.

What is B20 Stablecoin?

It is the B20 variant intended specifically for fiat-linked stablecoins.

Can a B20 token change from Asset to Stablecoin later?

The variant is selected at creation and is not intended to switch afterward.

Does B20 support KYC?

B20 provides policy infrastructure that can be used to enforce eligibility such as KYC-approved wallets.

Does Base itself perform the KYC?

Not necessarily. External systems can determine eligibility while onchain policies enforce the resulting authorization.

Is personal KYC information stored publicly onchain?

Not necessarily. A policy can work from account eligibility without publishing the person’s full documents.

What are Composite Policies?

They allow several policy conditions to be combined into broader authorization logic.

Can B20 require both KYC and accreditation?

A policy architecture can combine conditions so that both requirements need to pass.

Can it also support alternative eligibility rules?

Yes. Composite logic can permit authorization through different qualifying policy paths.

Can a technically valid Ethereum-style address be unable to receive a B20 asset?

Yes. The recipient can fail the asset’s configured policy.

Does controlling the private key guarantee I can send a regulated B20 token anywhere?

No. Transfer policies can restrict destinations.

Can B20 tokens be frozen?

B20 includes pause and policy infrastructure capable of restricting operations according to the asset configuration.

Does B20 support token seizure?

Yes, B20 includes an administrative seizure mechanism.

Does that mean Base can seize every asset on Base?

No.

Who can use the seizure function?

An appropriately authorized account acting within the particular token’s configured role and policy structure.

Can an administrator seize any wallet at random?

That is not an accurate description of the B20 design. Seizure uses specific roles and policy conditions.

Is administrative seizure the same as wallet theft?

No. Theft is an unauthorized compromise. Administrative seizure is an enabled token function exercised through authorized governance.

Why would a security need a seizure capability?

Regulated assets can require ownership corrections, legal enforcement or recovery procedures that bearer cryptocurrencies do not support.

Does this make the asset centralized?

It creates issuer or administrator control at the asset level. The underlying Base network can still operate as public blockchain infrastructure.

Can something be onchain but centralized?

Yes.

Can something be onchain but permissioned?

Yes.

Does onchain mean permissionless?

No.

What is the B20 UI multiplier?

It is a scaling factor used to derive user-facing token amounts from canonical raw balances.

Why does B20 need a multiplier?

It helps represent corporate actions such as stock splits without rewriting every holder’s raw balance.

What happens during a 2-for-1 split?

A scheduled multiplier can make the user-facing balance double while the canonical raw balance remains unchanged.

Does that create free economic value?

No. A stock split changes unit representation, not proportional ownership by itself.

Does the raw balanceOf change during a multiplier update?

No. The multiplier affects the derived UI-scaled view rather than rewriting raw balances.

Does raw total supply change?

Not from the multiplier alone.

Why does this matter for DeFi?

Protocols using raw token units can remain mechanically unaffected by the UI multiplier, while wallets and user interfaces need to understand the scaled representation.

Can the issuer schedule a multiplier change?

Yes. Cobalt supports a future effective timestamp.

Why schedule it instead of updating immediately?

Traditional corporate actions often have a predetermined effective time. Scheduling lets the issuer coordinate the change without relying on unpredictable transaction inclusion timing.

Can the scheduled multiplier be cancelled?

The B20 Asset design supports cancellation of a live pending multiplier update.

Can there be multiple pending multiplier changes?

The design permits one live pending update at a time.

Is there an emergency immediate multiplier update?

Yes. The older immediate mechanism remains as a failsafe.

What are B20 announcements?

They provide a standardized way to associate issuer-driven asset actions with holder-facing disclosure.

What kinds of events can be announced?

Examples include:

• stock splits,
• reverse splits,
• additional issuance,
• burns,
• informational notices.

Can an announcement contain no state change?

Yes. A holder-facing notice can be announced even without an underlying token-state change.

What are Validity Transactions?

They are signed transactions that become eligible for inclusion only while specified conditions are satisfied.

Are Validity Transactions part of B20?

No. They are a broader Base transaction feature introduced with Cobalt.

Can a Validity Transaction wait for a price condition?

Conditional market-state use cases can be built using onchain predicates.

Can it also expire?

Conditions can include timing or block constraints so a transaction does not remain valid indefinitely.

Does a Validity Transaction execute automatically the instant its condition is true?

Not necessarily. The condition makes it eligible for inclusion; execution is not guaranteed merely because eligibility is satisfied.

Why can Validity Transactions help traders?

They can express conditional intent without requiring every workflow to rely on a separate always-online keeper.

Are they visible publicly before execution?

The design supports keeping relevant submitted transactions private before inclusion.

Does that eliminate front-running or MEV?

No. It can reduce some information leakage without eliminating all transaction-ordering issues.

Does Cobalt make Base a securities exchange?

No. The upgrade provides blockchain infrastructure. Legal market roles depend on the entities and financial products using it.

Does B20 replace a transfer agent?

Not automatically. Tokenized securities can still depend on regulated transfer-agent or ownership-record functions.

Does blockchain replace securities law?

No.

Does the token contract define every legal right of a tokenized stock?

No. Legal documentation and governing financial rules remain relevant.

Does tokenization guarantee liquidity?

No.

Can a tokenized security remain illiquid?

Yes.

Can a tokenized security be restricted to approved investors?

Yes.

Can a tokenized security live in a self-custodial wallet while remaining issuer controlled?

Yes. Wallet custody and issuer administrative rights are separate concepts.

What should investors check before buying a tokenized security?

At minimum:

• what the token legally represents,
• transfer restrictions,
• administrative roles,
• pause and seizure capabilities,
• redemption or market liquidity,
• who controls compliance policies.

What is the biggest lesson from Base Cobalt?

Tokenization does not automatically turn traditional financial assets into permissionless crypto. Blockchain can become the settlement and ownership infrastructure while regulated assets retain issuer controls, eligibility rules and corporate-action mechanics.