Arc 6 Catch-Up: Designing Tokens That Enforce Rules

Arc 6 of 100 Days of Solana was about designing tokens that enforce rules. Arc 5 introduced the basics: mints, token accounts, metadata, transfer fees, and non-transferable tokens. Arc 6 pushed that further by asking a more interesting question: What if the token could carry more of the product logic itself? That was the real theme of the week. Using Token-2022 on devnet, we explored interest-bearing tokens, multi-extension mints, frozen accounts, revocable credentials, and the trade-offs that come with adding more behavior to an asset. The whole arc hangs off one idea: Token extensions let you compose asset behavior without writing your own on-chain program. For Web2 developers, that is the shift worth noticing. In a normal app, rules like interest, fees, access control, and revocation usually live in backend services, database jobs, middleware, or admin tooling. With Token-2022, some of those rules can live in the token itself. Extensions are asset features, not app features Most Web2 products have some kind of internal value system. A fintech app might offer yield. A marketplace might charge transaction fees. A learning platform might issue certificates. A SaaS product might gate access based on plan status. A compliance-heavy product might freeze or restrict accounts. Normally, those rules live in the application. Your backend calculates interest. Your payments layer applies fees. Your database stores membership status. Your admin dashboard revokes credentials. Your API checks whether a user is allowed to transfer, redeem, or access something. Token extensions move some of that logic into shared token infrastructure. That does not mean every app should become a token app. It means that, when a token is the right primitive, the rules do not have to be reinvented from scratch. You can use audited, reusable building blocks that every client and integration has to respect. That is the big idea behind Token-2022. The token is no longer just a number in a balance bucket. It can have behavior. Interest-bearing tokens make display different from storage Arc 6 started with the interest-bearing extension. The exercise looked simple: create a token with a 5% interest rate, mint 1,000 tokens, then compare the raw balance with the displayed amount. The surprising part is that the ledger balance does not keep changing in the background. There is no cron job waking up every minute to update every account. There is no backend service recalculating balances and writing new rows. The token stores the rate and timing information. Readers calculate the interest-adjusted display amount when they need it. In Web2 terms, it is like a savings account APY where the displayed balance can grow without the underlying ledger entry being rewritten constantly. That is a subtle but important distinction. The raw on-chain amount is still the raw amount. The interest-bearing extension changes how that amount is interpreted. That is why the arc deliberately made the rate dramatic later. At 5%, the difference is easy to miss. At 150%, you can watch the displayed amount climb much faster and see the model more clearly. The lesson was not “make wild APY tokens.” The lesson was: Some token behavior is computed by readers, not stored as repeated balance updates. That is a useful mental model to carry into more advanced token work. Extensions can be composed The next step was combining multiple extensions in one mint. Arc 6 created a token with three behaviors: - metadata, so the token had a name, symbol, and URI - transfer fees, so transfers automatically withheld a percentage - interest, so displayed balances could grow over time This is where Token-2022 starts to feel different from the original SPL Token Program. You are not just creating a token and then building everything else around it. You are deciding which behaviors the token itself should support. In Web2 terms, this is closer to designing the schema and rules for a financial product before launch. You decide what the product is allowed to do, what fields it needs, which authorities exist, and which operations should be enforced by the platform. The important catch is that extensions are configured up front. You cannot casually bolt them on later after the mint already exists. That makes token design feel more like database schema design or API contract design than UI configuration. You should think before you mint. The other lesson was that extensions operate independently. Transfer fee logic and interest logic can both exist on the same token, but they are not the same feature. One affects what happens during transfer. The other affects how balances are displayed over time. Composability is powerful, but it does not remove the need to understand each part. Access control can live at the token level Arc 6 also introduced the default frozen account state. That sounds abstract, but the product pattern is familiar. Some assets should not be freely usable by default. Stablecoins, security tokens, regulated assets, compliance-gated products, and permissioned marketplaces all need some version of: This account exists, but it is not allowed to move yet. In Web2, that rule might live in your backend: if user.kyc_status !== "approved": reject transfer With a default-frozen Token-2022 mint, new token accounts start frozen. Transfers and mints fail until the right authority thaws the account. That is a very different trust model. You are not relying on every frontend, integration, script, or API route to remember the compliance check. The token program enforces the state. If the account is frozen, the transfer does not go through. That was the core lesson of the frozen-account exercise: the failure is useful. It proves the rule is enforced below the application layer. The pattern is not “add KYC UI.” The pattern is “make unauthorized movement impossible at the token level.” Credentials need different rules from currencies Arc 6 then moved from financial rules to identity and credentials. The revocable credential token combined two extensions: - non-transferable, so the holder could not sell or transfer the credential - permanent delegate, so the issuer could burn it from the holder’s account if it needed to be revoked That combination is a good example of why token design is not one-size-fits-all. A currency wants liquidity. A marketplace asset may want fees. A certificate wants the opposite of transferability. Its value depends on being attached to the right holder. A bootcamp certificate, professional license, compliance credential, or membership badge is only meaningful if the person who earned it is the person holding it. So non-transferability makes sense. But credentials also need revocation. A license can expire. A badge can be issued by mistake. A qualification can be withdrawn. A membership can be canceled. That is where permanent delegate fits. It gives an authority the ability to burn from a holder’s account without needing that holder to sign the burn transaction. That may sound harsh until you map it to Web2. If your company issues a certificate, you probably expect the issuer to be able to revoke it. The difference is that, on Solana, that power is expressed through token behavior rather than a private database update. This is where Arc 6 became less about “tokens as money” and more about “tokens as stateful credentials.” Reading configurations matters as much as creating them One of the most useful parts of the arc was not creating a new token at all. It was inspecting the tokens we had already made. Arc 6 asked us to compare the mints from the week and read their configurations back out: interest rate authority, transfer fee settings, metadata, freeze authority, default account state, data size, and rent-exempt cost. That matters because on-chain configuration is not something you should treat as write-only. If you are building seriously, you need to be able to answer: Which extensions does this mint use? Who controls the authorities? Can those authorities change? How large is the account? How much rent-exempt balance does it need? What rules will every holder be subject to? That is the token equivalent of inspecting a production database schema or reviewing cloud infrastructure before launch. You do not just create it and hope. You read it back. You compare it. You verify what the chain actually stores. Arc 6 also made one trade-off visible: extensions are not free. More extensions mean more account data, and more account data means higher rent-exempt cost. That is not necessarily a problem. It is just part of the design. Token design is product design The throughline of Arc 6 was judgment. Interest-bearing tokens, transfer fees, frozen accounts, non-transferable credentials, and permanent delegates are all useful, but not universally useful. Each one answers a different product question: Should the displayed balance grow over time? Should each transfer withhold a fee? Should new accounts start locked? Should this asset be transferable? Should the issuer be able to revoke it? Those are not just technical choices. They are product choices. The mistake is to start with the extension and then hunt for a use case. The better move is to start with the product rule and ask whether a Token-2022 extension already enforces it. That is why Arc 6 was a natural follow-up to Arc 5. Arc 5 taught the basic token lifecycle. Arc 6 taught that token behavior can be composed. Not every app needs custom program code immediately. Sometimes the right answer is to use the token program that already exists, configure it correctly, and understand the trade-offs. Writing and sharing made the combinations clearer Arc 6 ended by turning the week into a public explanation. That matters because token extensions are easy to list but harder to understand in combination. Writing forces the useful question: Which extension combination solves which real product problem? Interest alone is one pattern. Fees plus