아크 8 캐치업: 토큰 속 미들웨어

출처: Dev.to

Arc 8 of 100 Days of Solana was about Token‑2022.
That might sound odd at first, because Token‑2022 had already shown up in the previous arcs.
Arc 6 used token extensions to explore fees, interest, frozen accounts, and revocable credentials. Arc 7 used Token Extensions to build NFTs from the same token primitives.
Arc 8 made the model explicit.

The whole arc hangs off one idea:
Token extensions are like middleware that lives inside the asset.
For Web2 developers, that is the shift worth noticing.

In a normal app, rules usually sit around the asset. You write backend code. You add middleware. You call a payment processor. You run a cron job. You trust every integration to go through the right path.

With Token‑2022, some of those rules can live on the mint itself.
That changes the shape of the system.

A token is no longer just a balance that moves between accounts. It can be a balance with transfer fees, interest display, transfer restrictions, or other behavior attached.

The middleware is not next to the token.
It is part of the token.

Most Web2 developers have built systems where rules sit outside the thing being moved.
A marketplace might charge a platform fee.
A fintech app might show yield.
A loyalty system might prevent points from being transferred.
A membership product might issue a badge that cannot be sold.

Usually, the rule lives somewhere in your application.
You might write:

calculateFee()
applyInterest()
rejectTransfer()
checkMembershipStatus()

That works as long as every relevant path uses the same logic.
But that is the weak point.
One backend service might apply the fee. Another script might forget it. An integration partner might call the wrong endpoint. An admin tool might bypass the normal flow. A scheduled job might fail. A frontend might display one thing while the ledger stores another.

Token‑2022 takes a different approach.
When the extension is configured on the mint, the Token‑2022 program enforces the behavior consistently. Every wallet, CLI, dApp, and program that interacts with the token has to deal with the same rule.

That is why the middleware analogy is useful, but only if you take it one step further.
This is not middleware sitting in your app stack.
It is middleware baked into the asset.

Arc 8 started with a fee‑bearing token.
The exercise was simple: create a mint under the Token‑2022 program, add a transfer fee configuration, mint some supply, and inspect the result.

The important part was not the percentage.
It was where the rule lived.

The transfer fee was not a line of backend code. It was not a webhook. It was not a checkout rule. It was not a convention that wallets were expected to follow voluntarily.

The fee configuration lived on the mint.
That means the token itself carried the rule:
When this token moves, apply this fee.

For Web2 developers, the contrast is familiar.
If you charge a fee through Stripe, you usually build fee logic around the payment flow. You decide how much to collect, when to collect it, how to reconcile it, and which integrations are allowed to move value.

With Token‑2022, the fee rule is part of the asset’s behavior. The transfer goes through the token program, and the token program applies the rule.

That is a meaningful difference.
You are not trusting every app to remember the fee. You are configuring a token that cannot move without the fee logic being considered.

That is the first big Arc 8 lesson:
The rule travels with the token.

Creating a fee‑bearing mint is only the first part.

Arc 8 then put the token in motion and followed the fee lifecycle end to end:
transfer → withhold → withdraw

That lifecycle matters because transfer fees do not behave like a normal payment processor settlement flow.

When a fee‑bearing token is transferred, the recipient does not simply receive the full amount and then send a fee somewhere else.
Instead, the fee is withheld in the recipient’s token account.

For example, with a 1% transfer fee, a transfer of 1,000 tokens gives the recipient 990 spendable tokens. The remaining 10 are recorded as withheld tokens on the recipient’s token account.

Those withheld tokens are not spendable by the recipient. They sit there until the withdraw authority collects them.

That is a very different mental model from a Web2 marketplace fee.

In a normal app, you might have a payment ledger, a treasury balance, a settlement job, a reconciliation process, and a dashboard showing fees owed.

Here, the withheld amount is visible in the token account itself. The fee authority can later withdraw it using the Token‑2022 program.

The important thing is what you did not build.
No custom program.
No payment processor flow.
No webhook.
No cron job.
No separate fee table.

The protocol enforced the fee and stored the withheld amount.

That is the kind of concrete behavior that makes Token‑2022 easier to understand. It is not an abstract extension system. It is a rule you can observe on devnet.

Arc 8 then combined transfer fees with interest‑bearing behavior.
This is where the middleware analogy becomes more powerful.

A token can have more than one rule.
The mint can say:

• Charge a fee when tokens move.
• Display balances with interest over time.

Those behaviors are different, but they can coexist on the same mint.

That matters because Web2 developers often expect separate systems for separate behaviors.

A fee might belong to a payments service.
Interest might belong to a financial calculation service.
Metadata might belong to an asset database.
Restrictions might belong to an access control system.

Token‑2022 lets those behaviors be configured as extensions on one mint.

The technical reason is that extensions are stored as structured data on the account. The mint has enough space allocated for the extensions, and the Token‑2022 program knows how to read and enforce them.

But the product lesson is simpler:
A token can be configured with multiple behaviors at once.

The fee and interest example also made an important distinction clear.

The transfer fee works on the raw token amount. It moves real token units and withholds part of the transfer.

Interest‑bearing behavior affects the displayed amount. It does not continuously mint new tokens in the background. The raw balance does not change every second. The UI amount is computed from the stored amount, rate, and elapsed time.

That is why the two features can coexist cleanly.

The fee changes what happens during transfer.
The interest extension changes how the balance is interpreted when read.

Those are different layers of behavior on the same asset.

The interest‑bearing extension is one of the easiest places for Web2 instincts to mislead you.

In a conventional app, if a balance grows, you usually assume something wrote a new value somewhere.
A scheduled job updated the balance.
A database row changed.
A ledger entry was added.
A batch process applied interest overnight.

Token‑2022 does not need to work that way.

With the interest‑bearing extension, the raw token amount stays the same unless an actual token instruction changes it. What changes is the displayed amount.

The program can calculate the UI amount based on the interest rate and time elapsed.

That is why Arc 8 deliberately used a high rate on devnet. At realistic rates, the change over a short challenge window would be too small to notice. A dramatic rate makes the model visible.

The lesson is not “high yield tokens are good.” The lesson is:
Display can be computed from state without constantly rewriting state.

For Web2 developers, that is a useful mental shift.

Arc 8 forced that distinction into the open.

One of the most useful Arc 8 exercises wa