Arc 8 Catch-Up: Middleware Inside the Token

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.

Token rules should not depend on every app remembering them

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.

Transfer fees are enforced by the mint

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.

The fee lifecycle is transfer, withhold, withdraw

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.

Composability means extensions share the same mint

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.

Interest is a view, not a background job

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.

The token account stores raw units. The extension changes how those units are displayed. If you assume “displayed balance increased” means “new tokens were minted,” you will misunderstand what the program is doing.

Arc 8 forced that distinction into the open.

Reading mint configuration is part of building

One of the most useful Arc 8 exercises was not creating another mint.

It was auditing the mints already created.

That matters because Token-2022 configuration is public state. You can inspect a mint and see which extensions it uses. You can read the fee configuration. You can see whether interest-bearing behavior exists. You can check whether a token is non-transferable.

That is the Solana version of inspecting a production schema.

In Web2, the rules of a system are often scattered across:

• application code
• database migrations
• environment variables
• payment processor settings
• admin dashboards
• scheduled jobs
• private documentation

On Solana, much of the token’s behavior is visible in the mint account.

That does not mean the whole application is transparent. But it does mean the token’s configuration can be read by anyone.

That is part of the Token-2022 pitch.

The behavior is public.

The configuration is verifiable.

The rules cannot be silently swapped inside a private backend.

That is also why auditing matters.

You should not just create a mint and trust that you typed the command correctly. You should read it back. Check the extensions. Check the authorities. Check the raw configuration. Explain what each extension does in plain English.

That last part is important.

If you cannot describe the behavior without looking it up, you probably do not understand the asset yet.

Non-transferable tokens are useful because they fail

Arc 8 ended the build sequence with a token that refuses to move.

That might sound strange because tokens usually imply transferability. Money moves. Points move. Assets move.

But not every token-like thing should be transferable.

A course certificate should not be sellable.

A membership badge might need to stay with the person who earned it.

A compliance credential might need to remain attached to one wallet.

A proof-of-attendance token might lose meaning if it can be traded.

The non-transferable extension lets the mint encode that rule.

The challenge deliberately tried to break it. Create the token. Mint it. Create a recipient account. Attempt a transfer.

The transfer fails.

That failure is the feature.

In a Web2 app, you might prevent transferability through an API check:

if token.non_transferable:
    reject transfer

But that depends on every path using the same API.

With Token-2022, the token program itself rejects the transfer. The rule is part of the mint’s behavior, and any client interacting with the program has to respect it.

That makes non-transferable tokens different from fees and interest.

Fees and interest are still money-like features. They affect value movement and balance display.

Non-transferability changes the category of the asset. The token starts to look less like currency and more like identity, membership, status, or proof.

Same mint model. Same token accounts. Same CLI.

Different product meaning.

That is why the failed transfer matters so much. It proves the extension is not just descriptive metadata. It changes what the token can do.

Token-2022 is configuration, but not casual configuration

A tempting takeaway from Arc 8 would be:

Token-2022 lets you add features with flags.

That is true, but incomplete.

The better takeaway is:

Token-2022 lets you design token behavior through mint configuration.

That distinction matters.

Extensions feel easy because they can be created from the CLI. But they are not throwaway settings. They shape what the asset is, who can use it, and how every integration will experience it.

A fee-bearing token is different from a normal token.

An interest-bearing token is different from a normal token.

A non-transferable token is very different from a normal token.

Once those behaviors are on the mint, they are part of the asset’s design.

That brings Arc 8 back to the product questions underneath the technical work:

Should every transfer charge a fee?
Who can withdraw withheld fees?
Should balances display with interest?
Should this asset be transferable at all?
Which authorities control the rules?
Will wallets and integrations understand these extensions?

Those are not just CLI questions.

They are product, governance, and integration questions.

Token-2022 gives you reusable building blocks, but you still have to choose the right ones.

Writing turns extensions into patterns

Arc 8 ended by turning the week into a public post and social thread.

That fits the arc well because Token-2022 is easy to explain badly.

You can list extensions all day:

• transfer fees
• interest-bearing
• non-transferable
• default account state
• permanent delegate
• confidential transfers
• memo transfer

But a list is not a mental model.

A useful post needs to show the pattern.

For Arc 8, the pattern was a trilogy:

A token that charges a fee.
A token that charges a fee and displays interest.
A token that refuses to move.

That is much more memorable than “I tried some Token-2022 extensions.”

It shows the range of what extensions can do.

One changes transfer economics.

One composes transfer economics with display behavior.

One changes whether transfer is allowed at all.

That is the story.

The best write-up would include what actually happened on devnet: the fee being withheld, the interest-adjusted UI amount changing without a transaction, and the failed transfer error from the non-transferable token.

Those details matter because they prove the learning.

Not:

“I learned Token-2022.”

More like:

“I created a token that charged a transfer fee, watched the fee sit as a withheld amount on the recipient account, stacked interest on the same mint, then built a token that refused to transfer at all.”

That is useful developer storytelling.

What Arc 8 sets up

Strip Arc 8 back to its core and the main ideas are clear:

Token-2022 lets token behavior live on the mint. Transfer fees are enforced by the token program. Fees follow a visible lifecycle: transfer, withhold, withdraw. Interest-bearing behavior changes displayed amounts without constantly rewriting raw balances. Extensions can compose on the same mint. Mint configuration is public and inspectable. Non-transferable tokens show that extensions are not only about money; they can turn tokens into identity, credential, or membership objects.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

Arc 7 showed that NFTs are built from the same token primitives.

Arc 8 pulled the model together: Token-2022 is the extension system that makes many of those behaviors possible without custom on-chain programs.

From here, the question becomes more practical:

How do you choose the right token behavior for the product you are building?

That is the mindset to carry forward.

Use this post as the map, revisit the Arc 8 challenges when you want the hands-on version, and remember the central lesson: with Token-2022, the rule does not sit beside the asset. The rule can live inside the asset.