Week 38 · 2026

Highlights

The Advanced track opened (D4, #2011)

Paulo Bressan published Advanced lecture 1, Detecting vulnerabilities, and with it the track introduction that reframes the whole curriculum: Intermediate asked does this transaction follow my rules?, Advanced asks what can someone do with these rules that I never intended?

The lecture is 469 lines and it teaches a method rather than a list. It starts from five attacker goals — steal tokens, block someone from getting theirs, halt the protocol, block people from using it, slow it down — and states plainly what an attacker can and cannot do (they can run your validator offline before they send anything; they cannot forge a signature or make a validator say yes). Then: single-step attacks that fit in one transaction (double satisfaction; reading the wrong end of the validity window) and multi-step ones that need a sequence (trust no UTxO, spam until it breaks, dust tokens, reward stealing, a handler that says yes to everything, one UTxO everybody needs). Each links out to the handbook's full treatment.

The hands-on half is the part worth copying. The reader grows the Intermediate gift card into a shop that issues many cards, then:

1. Writes the attack as a test that passes. Two locked UTxOs, one burned card, six green checks — "a passing test is the proof that the attack works."
2. Closes the door, by counting locked inputs instead of asking for one burn, and marks the attack fail.
3. Finds the second door the fix leaves open — one card releases any locked UTxO, so a 5 ADA card can drain a 50 ADA one — and writes that as a passing test too.
4. Closes it by giving each card its own asset name and binding it in the locked UTxO's datum.
5. Is handed a third door and no code: the shop can mint a duplicate card name and drain its own customer. The lecture names the missing guarantee ("every card name is created once"), says where the check belongs, and stops.

Three Aiken validators ship the three states — giftcard_shop_open.ak (the vulnerable one), giftcard_shop.ak (counted), giftcard_shop_named.ak (per-name) — and the prose imports its snippets from them via extractRegion, so nothing in the lecture can drift from code that compiles. A Scalus variant is marked coming soon.

The PR is stacked on #2003, so most of its 88-file diff is the Intermediate work carried forward; the genuinely new part is the advanced lecture, its introduction and the shop.

Lectures 11 and 12 came back from review (D4, #2003)

Ten of the week's eleven Developer Portal commits are review turns on the Intermediate PR: multi validators and modifying state reworked and their design steps aligned with lecture 10's shape, so all four design lectures now walk the same path from idea to architecture. #2003 is still open.

Event-triggered assets became a tokenized-bond specification (D5)

Nine commits, all on 28-explore-event-triggered-assets, turned last month's scaffolding into a 200-line spec and a 332-line Typst design, backed by ~670 lines of Aiken across issuance, registry, transfer, third_party, types and the validator.

The instrument is a tokenized bond: a CIP-113 programmable token that steps up 4% at each of four annual deadlines and, from the last one on, may graduate into a plain native asset at the schedule's final value. Three postures define it:

• Ownership rides the token UTxO's inline stake credential, so it moves with the token at every transfer, and transfers are never gated — the token stays DEX-compatible for its whole life.
• The schedule update is holder-passive. The CIP-68 reference token's datum is rewritten in place with no signatures at all; the only gate is the transaction's validity range, and because the new value is a pure lookup of baked constants, a late submission simply lands on the current step. Nobody has to be trusted to keep the bond current.
• A graduation can never redirect a payout. This is what the week actually decided.

Three design changes landed:

• Register and issue collapsed into one transaction. A single RegisterAndMint arm now validates registration authority, node shape and the first mint together — no window in which the instance is registered but nobody holds tokens.
• An owner signature check at graduation (Monday's commit), and then the harder half of the problem: CIP-113 attributes ownership by the stake credential only, so the framework cannot know which payment key the payout should land at. A native asset sent to an unverified spending key is unrecoverable, so there is no safe fallback.
• Payout registration is the answer: an owner-signed self-transfer that writes a payment_credential into the token's own datum. Opt-in and re-settable. The third-party graduation path preserves datums byte-for-byte, so a third party can complete a graduation for an opted-in token but can never point the payout somewhere else. Absent both a signature and a commitment, the transaction is rejected.

The spec is written with the same discipline as the DAO's — design choices tabulated with rationale, eight numbered invariants, and a threat model that separates what is defended from what is explicitly out of scope (asset-identity continuity across the flip is named as an open ecosystem question, not solved here).

Smart wallet got its diagrams (D5)

One commit, 523 lines: a transaction-first docs/smart-wallet/design.typ on the pluggable-authorization-credential branch. That makes four primitives now designed on paper before the code — the pattern the library has settled into.

The tracker (D1)

One commit, gathering the week's activity.

Nothing merged, three things in flight

A zero-merge week, which the counters make look quieter than it was: #2003 (Intermediate 10–13) and #2011 (Advanced 1) are both open on the Developer Portal, #31 is open on the tracker, and the event-triggered-assets branch is a spec away from implementation. Of the 22 commits, 21 are work on branches that have not landed yet.