Primary Keyword: mary era Secondary Keywords: cardano mary, mary hard fork, native tokens cardano, multi-asset cardano
What Is the Mary Era?
The Mary era was Cardano's fourth era, activated on March 1, 2021 (epoch 251), and it made Cardano a multi-asset ledger: users could finally create, send, and hold their own native tokens directly on the blockchain — no smart contracts, no sidechains, no token standards. In one upgrade, ADA was joined by a whole marketplace of custom assets, and the Cardano mary era is remembered as the moment the network learned to carry everything.
Continuing the house analogy from our earlier articles: Shelley built the house (decentralization), Allegra installed the plumbing and wiring (timelocks and script safety), and Mary moved in the furniture — the native tokens. You can add a chair to a room without re-plumbing the house; Mary proved you can add a whole new asset class to a ledger without rebuilding it.
Quick Reference: The Mary Era in One Glance
| Attribute | Mary Era |
|---|---|
| Activation | March 1, 2021 (epoch 251) |
| Protocol version | 4.0 |
| Headline capability | Native multi-asset tokens |
| Smart contracts? | No (that was Alonzo, Sep 2021) |
| User-facing? | Yes — create and send custom tokens |
| Upgrade mechanism | Hard Fork Combinator |
The Cardano Mary Hard Fork: What Actually Happened
The mary hard fork was applied to the mainnet on March 1, 2021 at 21:44:51 UTC via a managed Hard Fork Combinator event. It had originally been targeted for the end of February 2021 (the testnet had already been forked on February 3), and when it landed on mainnet it was genuinely historic: Cardano became a multi-asset ledger overnight.
Why "Multi-Asset Ledger" Matters
Before Mary, every blockchain essentially had one asset. On Bitcoin, you had BTC. On early Ethereum, you had ETH — and if you wanted a second asset (like a token), you had to write a smart contract to simulate one.
Mary removed that requirement. The ledger itself learned to carry arbitrary assets:
- Native tokens are first-class citizens of the ledger, exactly like ADA
- They are identified and validated at the protocol level, not by contract code
- Sending them costs standard transaction fees — no per-transfer contract execution, no extra gas
- They work immediately in any wallet, exchange, or dApp that understands the ledger
Figure 1: The Cardano eras — Mary made the ledger multi-asset
Native Tokens on Cardano: The Core Capability
A native token is a custom asset created and managed directly on the Cardano blockchain using its built-in token functionality — without requiring smart contracts. This is the single most important fact of the mary era.
What You Could Do After Mary (That You Couldn't Before)
| Capability | Before Mary | After Mary |
|---|---|---|
| Create a custom token | ✗ (impossible) | ✓ Mint it in one transaction |
| Send custom tokens | ✗ | ✓ Standard fees, no contracts |
| Hold tokens in a wallet | ✗ | ✓ Any ledger-compatible wallet |
| Burn tokens | ✗ | ✓ Negative mint quantity |
| Bundle many token types | ✗ | ✓ One transaction, many assets |
The magic is in where the asset lives. On Ethereum, a token lives inside a smart contract's storage (the ERC-20 "accounting book"). On Cardano, a token lives in the UTXO itself — the same structure that holds ADA. That is what "native" means: no middleman contract, no third-party accounting book.
How Native Tokens Are Identified: Policy ID + Asset Name
Every native token on Cardano has a two-part identity — think of it as a last name + first name:
Policy ID (the "Last Name")
- The Policy ID is a 28-byte (56 hexadecimal character) hash of the minting policy script
- It identifies which rules created this token family
- A single Policy ID can cover many different asset names
Asset Name (the "First Name")
- The Asset Name is up to 32 bytes of data
- It distinguishes individual assets within a policy
- Together, (Policy ID, Asset Name) forms a globally unique Asset ID
One Policy, Many Tokens
This design is elegant: a project creates one minting policy, and from it can issue an entire collection. For example:
- One policy for a football club → thousands of player cards (different asset names)
- One policy for a stablecoin → a single "USD" asset name
- One policy for a game → every sword, shield, and potion as a distinct asset name
VN analogy: the Policy ID is like the sổ đỏ (land-use certificate) number — it identifies the exact rules that govern that asset — and the Asset Name is the specific piece of land recorded under it. Change the certificate rules and you get a different certificate number entirely.
Figure 2: How a native token is identified — Policy ID (last name) + Asset Name (first name)
Minting Policies: The "Constitution" of a Token
A minting policy is a script that defines who may create or destroy tokens, and under what conditions. Its hash becomes the token's Policy ID — so the rules are permanently baked into the token's identity.
This is the insight most people miss: the Policy ID is not a key — it's a constitution.
Permission Models You Could Use on Mary (No Plutus Needed)
| Policy Type | Rule | Typical Use |
|---|---|---|
| Unlocked | Anyone can mint | Rare; permissionless test tokens |
| Signature-locked | Only specific keys may mint | Team tokens, company coins |
| Time-locked | Minting allowed only within a window | Event tokens, time-limited drops |
| Combined | Signatures + time windows | Vesting with authorized signers |
Because minting policies could be written as native scripts (signatures and timelocks — primitives Allegra had already shipped!), projects could mint professional tokens from Mary day one, months before smart contracts arrived in Alonzo.
Minting and Burning in the Ledger
Minting happens inside a transaction via the mint field:
- Positive quantity → tokens are created
- Negative quantity → tokens are destroyed (burned)
- Validation → the transaction must satisfy the policy script
Crucially, the same transaction can mint and transfer tokens in one atomic action — there is no separate "deploy a contract, then call it" dance.
Figure 3: Mint, transfer, and burn in one atomic transaction — no smart contract needed
Token Bundles: One Output, Many Assets
Here is the most visually surprising part of the mary era: a single UTXO (unspent transaction output) can hold ADA plus many different token types at once. Cardano calls this a token bundle.
``` One transaction output (token bundle): ├── 10 ADA ├── Policy A ("Club FC") → 5 player cards + 1 "Fan" asset └── Policy B ("Game") → 3 swords, 2 potions ```Why Bundles Matter
- Atomic transfers: send a basket of assets in one transaction — all arrive together or not at all
- No contract routing: wallets and exchanges natively understand bundles
- Cheaper than ERC-20: no per-asset contract calls, no separate gas per transfer
- Same security as ADA: every token rides the same settlement guarantees as the base currency
The min-ADA Rule
Because the ledger is built on UTXOs, an output holding tokens must also carry a minimum amount of ADA (calculated from the output's size). You can think of it like a minimum balance requirement: to hold tokens, you always keep a little ADA in the same "pocket." This guarantees every output is always spendable by its owner.
The Only Two Differences Between ADA and Native Tokens
The Cardano team summarized Mary's ledger rule change almost brutally simply: there are only two differences between ADA and any native token.
| Difference | Detail |
|---|---|
| 1. Tokens can be destroyed | Minting policies can burn them (ADA can never be burned) |
| 2. Only ADA pays the bills | Fees, rewards, and deposits are always paid in ADA |
Everything else — security, finality, settlement — is identical. ADA remains special in exactly one practical way: it is the asset that powers the network (fees, delegation rewards, protocol deposits). Native tokens are passengers on the same train, with the same safety guarantees, but ADA is the one that pays the conductor.
This is why the multi-asset cardano design is so efficient: the network didn't grow a second, weaker settlement system for tokens. It made tokens equal citizens.
Mary vs ERC-20: Same Idea, Different Machine
People often ask whether Mary tokens are "Cardano's ERC-20." The honest answer is no — and that's the point.
| Attribute | Cardano Native Token (Mary) | Ethereum ERC-20 Token |
|---|---|---|
| Where it lives | In the ledger (UTXO) itself | In a smart contract's storage |
| Needs a contract to exist | No | Yes (the ERC-20 contract) |
| Transfer cost | Standard tx fee (no execution) | Contract execution + gas |
| Wallet support | Native, automatic | Requires contract-aware wallet |
| Can enforce transfer rules | Limited (no protocol-level blacklist) | Fully programmable |
| Security model | Inherits ledger consensus | Inherits contract + ledger |
The trade-off: Cardano's native tokens are simpler, cheaper, and safer for the common cases (transfer, hold, bundle, burn) — but they can't run arbitrary business logic on every transfer (e.g., a fee-on-transfer tax or a blacklist) the way a custom ERC-20 contract can. Ethereum's approach is more flexible per-token; Cardano's approach is more robust per-ledger.
Figure 4: Mary native tokens vs ERC-20 — same idea, different machine
Why the Mary Era Mattered (and Still Does)
The mary era wasn't just about one upgrade — it unlocked a content explosion that Cardano is still living on:
- NFT boom: Cardano NFTs (CNFTs) — profile pictures, gaming items, digital art — all became possible because a single policy could mint a whole collection as native tokens
- Token projects before Alonzo: teams launched their tokens with native scripts and upgraded to Plutus contracts later
- DeFi building blocks: when Alonzo added smart contracts five months later, DeFi apps could reference native tokens — a stablecoin, a governance token, an LP token — as first-class ledger assets from day one
- The proof of the roadmap: Mary proved Cardano's "one logical layer per era" approach could ship a user-facing revolution cleanly, via the Hard Fork Combinator
For Vietnamese builders, this is the era that explains the assets you actually trade today: every CNFT you see, every community token, every game item on Cardano is a descendant of the mary era's ledger change.
One-Sentence Takeaway
> The Mary era taught Cardano to carry everything — by making custom tokens first-class citizens of the ledger itself, with rules permanently baked into each asset's identity, so any token rides the same security, the same settlement, and the same simplicity as ADA.
FAQ
Q: When exactly was the Cardano Mary hard fork?
A: The mary hard fork activated on the mainnet on March 1, 2021 (epoch 251) at 21:44:51 UTC, via the Hard Fork Combinator. It was originally targeted for the end of February 2021; the testnet fork happened on February 3.Q: Does the Mary era support smart contracts?
A: No. Native tokens required no smart contracts, but programmable smart contracts (Plutus) arrived five months later with the Alonzo era (September 2021).Q: What is the difference between a native token and an ERC-20 token?
A: A native token lives directly in the Cardano ledger (like ADA), so it needs no contract, costs a standard transaction fee, and works in any wallet. An ERC-20 token lives inside a smart contract on Ethereum and needs contract execution (gas) for every transfer.Q: How are native tokens identified on Cardano?
A: Each token has a (Policy ID, Asset Name) pair. The Policy ID (a 28-byte hash of the minting policy script) is like a "last name," and the Asset Name (up to 32 bytes) is the "first name" — together they form a unique Asset ID.Q: Can native tokens be burned?
A: Yes — one of only two differences between a native token and ADA. A transaction with a negativemint quantity destroys tokens, subject to the minting policy's rules.