Week 41 · 2026

Highlights

The onboarding path entered staging review (D4, #2058)

Paulo Bressan opened the PR that brings the whole Beginner and Intermediate path into staging: 168 files, +36,381 lines. This is the material built and reviewed over the past months, now assembled into the path a newcomer will follow, not 36,000 lines of new work this week. The PR is still a draft; the onboarding has not reached the published portal.

The path runs from a wallet and a working atomic-swap dApp through six Beginner lectures and thirteen Intermediate ones. Web developers follow it in order. EVM developers get shortcuts and comparisons where the account model differs from UTxOs. Technical founders start with What to build, then join the same path. That page now uses AlphaGrowth's ecosystem audit as its source. Every onboarding Aiken project was aligned on v1.1.24.

The curriculum stays the reference behind the lectures' Go deeper links. Advanced remains a placeholder in this PR, with its own review branch.

Advanced gained an optimization exercise, and patterns gained measured examples (D4, #2059, #2063)

#2059 brings the two Advanced lectures together. The separate vulnerability and optimization PRs (#2011 and #2053) were closed in favor of that combined draft, not merged. The new Optimization lecture teaches the three limits a transaction must fit under: memory, CPU, and bytes. Its payout-queue exercise makes the reader measure a contract, then improve it in three steps:

• Put the input's position in the redeemer, and verify it instead of searching for it.
• Check the queue once per transaction, through a withdraw-zero handler, instead of checking each payment again in every spend.
• Walk inputs and outputs together, replacing several list traversals with one.

The lecture's tests at sixty payouts go from 16.59 M memory / 7.85 B CPU to 11.50 M / 3.82 B. It also measures compiled-script size and explains the trade-off: the extra handler saves execution units but adds bytes. Those test figures include building the transaction, so they are comparisons, not exact on-chain fees.

#2063 opened a separate Design patterns section, intended to follow the course and eventually replace the curriculum's pattern pages. Three patterns are in the branch by the end of the week: transaction-level validation, UTxO indexers, and batch indexers. Each starts with the naive contract, writes the pattern by hand, then uses aiken-design-patterns v1.9.0. Runnable Aiken and Mesh projects include attack tests and benchmarks; the pages read their cost figures from generated costs.json files. Both PRs remain drafts against new-onboarding.

The examples got a maintenance check (D4, #2062)

The lectures already import their snippets from runnable projects. #2062 adds the missing check that those projects keep working: weekly CI, also run on relevant PRs and by manual dispatch.

Each Aiken project is checked with its pinned compiler, then rebuilt. The validator hashes must match both the committed blueprint and its off-chain copy, because those are the hashes the lectures print. Each npm project gets a fresh install, tests, and a build. Without lockfiles, the weekly install also checks whether a new dependency release broke an example. The PR is open; the scheduled run starts only after the workflow reaches the default staging branch.

cardano-init got a docs site and a more useful doctor (D3, #94, #88, #90, #91, #89)

Five PRs merged, all from Paulo Bressan. #94 published the documentation site with mdBook. It separates the user guide, contributor instructions, and maintainer design documents. The new user guide covers installation, commands, the tools catalog, infrastructure, and the JSON interface for coding agents. Newcomers are pointed back to the Developer Portal's onboarding path. The Pages deployment passed on Saturday.

The CLI changes make it easier to find both a starting point and help:

• #88: outside a generated project, doctor now says no Cardano project was detected, tells the user how to scaffold one, and lists the installed tools it can find. It no longer prints a reassuring DEPS OK just because just is installed. JSON gains project_detected and environment.tooling.
• #90: inside a project, doctor lists the stack's editor extensions, language servers, playgrounds, and community help channels. The links live in the tool registry, so they follow the tools the developer actually chose.
• #91: short flags and aliases make commands quicker to type, such as -n, --on, --off, and -d. The existing long names and JSON interface stay compatible.
• #89: the devnet smoke workflow no longer opens an issue when a runner disappears without a step failing. Actual step failures and timeouts still trigger an alert; infrastructure interruptions no longer look like broken generated projects.

Two more PRs opened but had not merged by Sunday. #92 adds a default spec/ folder to generated projects, with a worked gift-card specification and --no-spec to skip it. #93 adds a pre-generation notice when a newer release exists, with an update command matched to the installation method. Its lookup is cached daily, fails quietly, and is disabled for JSON and CI runs. These belong to next week's merge report.

Smart wallet restrictions now cover deposits too (D5)

Francisco Joray extended the smart wallet's delegated-script mechanism to both directions of value flow. The datum now has separate spenders and depositors maps, each carrying per-script Data. Every configured deposit script must approve a Deposit; with an empty map, deposits are open. Deposit scripts can advance their own state, so an asset allowlist or a deposit counter does not need a special case in the wallet validator.

The separation needed tighter continuation rules:

• A spend keeps the wallet alive, with its depositor map unchanged and its spender keys fixed. Spender state may advance, but the spend cannot add or remove a restriction.
• A spend cannot add value. Every asset in the continuation must be no greater than in the input, so funds cannot enter through Spend and bypass the deposit scripts.
• A deposit preserves the spend restrictions, keeps the depositor keys, and can only add value. Changing either permission set belongs to the admin's renamed UpdatePermissions action.

The Mesh and Tx3 drivers were updated to the new shape, and a usage guide now explains deployment and the external settings UTxO. The spec also names the delegated-script trust boundary: a script controls its own state, and a bad one can bloat the datum or refuse unregistration. Pluggability does not remove the need to review what a wallet delegates to. This remains work on an unmerged exploration branch.

The tokenized bond gained ADA backing and coupon redemptions (D5)

Sofia Bobbiesi and Francisco Joray revised the bond design substantially. The earlier model turned a growing programmable asset into a native asset at maturity. The new spec instead describes ADA principal in a vault, transferable certificates, and redeemable coupon tokens:

• Register once, deposit many. The issuer registers the instrument once. Anyone can then deposit a fixed principal unit; the same transaction adds that ADA to the vault and mints one CIP-113 certificate for the depositor.
• Each certificate has its own clock. Its start is pinned to the deposit transaction's validity upper bound, and step records the last coupon claimed. Transferring the certificate transfers the remaining claims without resetting either field.
• Coupons are ordinary native assets. Their names encode the lovelace amount they are worth. A scheduled claim advances the certificate's step; redemption burns the coupon and pays the encoded ADA from the vault.
• Maturity retires the certificate and issues a final principal-only coupon, redeemed through the same burn-to-pay path.

The spec explicitly assumes vault solvency and owner custody. Deposits fund principal, not coupons; holders rely on the owner to fund coupon payments and not drain the vault. Those are assumptions, not on-chain guarantees.

The on-chain rewrite began with new certificate, coupon, and vault modules and revised issuance and transfer logic. The old transformation and native-graduation modules, along with their old tests, were removed. Usage guides also arrived for the exploration, but the redesigned lifecycle still needs its replacement tests and off-chain alignment. It has not merged.

Two more signatories, and the bounty workflow took shape (D1, D6, #169)

Angel Castillo of Biglup Labs and Chris Gianelloni of Blink Labs joined the pledge, taking the merged list to 36 signatories by Sunday.

The same PR brought in a draft bounty-program guide for the community collaboration deliverable. It sets out a $50,000 pool, a proposed GitHoney escrow workflow tied to maintainer-approved issues, payment after merge, and a public register linking work to on-chain funding and payouts. Input Output (IO) would fund the work first and claim reimbursement at the DX.06 milestone. This is preparation, not a program launch: reward sizes, payment currency, approvers, recipient checks, and the funding arrangements still need decisions.

A note on the counters

The six merges are five cardano-init PRs and the pledge PR. The seven opened PRs are two on cardano-init and five on the Developer Portal; one of the portal drafts was replaced by the combined Advanced PR during the week.

Of 52 commits, 29 are contracts-library, 12 cardano-init, 7 the Developer Portal, and 4 this tracker. Much of the contract and portal work is still on branches under review. The staging PR assembles earlier work, so its large diff should not be read as this week's output. No release was published during the reporting window.