add smart accounts and multisig course

course-overviews.json

@@ -367,6 +367,22 @@
       "who_this_is_for": "Expert Rust developers and Solana researchers who want to understand the absolute fundamentals. Not for production use - purely educational and research-oriented.",
       "what_you_will_build": "A fully functional vault program with zero dependencies, implemented through raw pointer manipulation, manual validation, and direct syscall invocation.",
       "prerequisites": "Expert Rust skills including unsafe code, raw pointers, and memory management. Deep Solana knowledge. Completion of Introduction to Low-Level Solana recommended. This is advanced research-level content."
+    },
+    {
+      "id": "smart-accounts-and-multisig",
+      "title": "Smart Accounts & Multisig",
+      "overview": "Master program-controlled accounts and multi-party authorization on Solana through smart account architecture patterns and the Squads protocol. Traditional keypair-controlled accounts offer binary, all-or-nothing access that fails to meet the needs of teams, DAOs, and protocols managing significant assets. Smart accounts solve this by moving authorization logic on-chain, using Program Derived Addresses as keyless vaults governed by configurable rules including thresholds, roles, timelocks, and spending limits. This course covers the full spectrum from foundational concepts to production implementation. You'll understand how PDAs enable program-controlled vaults, explore architectural patterns for permission models and upgradeability, and deep-dive into the Squads v4 program — the leading smart account infrastructure on Solana. The multisig section covers the M-of-N threshold model, proposal lifecycle mechanics, vault management, and operational best practices. You'll also learn the SPL Token Program's built-in multisig feature, its limitations, and when to use each approach.",
+      "what_you_will_learn": [
+        "Understand how PDAs enable keyless, program-controlled vault accounts",
+        "Design smart account architectures with configurable permission models",
+        "Navigate the Squads v4 program: account types, instructions, and vault PDAs",
+        "Master the M-of-N multisig threshold model and proposal lifecycle",
+        "Implement SPL Token multisig for simple token authority use cases",
+        "Apply operational best practices for production multisig management"
+      ],
+      "who_this_is_for": "Developers building applications that require shared control over assets, program upgrade authorities, or organizational governance. Essential for anyone managing protocol treasuries, DAO operations, or institutional custody on Solana.",
+      "what_you_will_build": "Conceptual mastery of smart account and multisig patterns on Solana. You'll understand the Squads v4 architecture, know how to set up and operate multisig accounts, and be able to choose between SPL Token multisig and Squads for your use case.",
+      "prerequisites": "Basic understanding of Solana accounts, programs, and PDAs. Familiarity with the SPL Token Program is helpful for the token multisig lesson. No specific framework experience required."
     }
   ]
 }

lesson-meta-descriptions.json

@@ -175,5 +175,15 @@
     "winternitz-signatures-with-anchor": "Implement Winternitz signatures in Anchor: verify hash-based signatures, build quantum-resistant programs, and future-proof your applications.",
     "winternitz-signatures-with-pinocchio": "Add Winternitz to Pinocchio programs: native hash-based signature verification, quantum resistance without frameworks.",
     "conclusion": "Master post-quantum cryptography on Solana with security analysis, performance considerations, and strategies for quantum-resistant blockchain development."
+  },
+  "smart-accounts-and-multisig": {
+    "introduction": "Discover smart accounts and multisig on Solana: why keypair-controlled accounts fall short, how program-controlled accounts work, and what you'll learn in this course.",
+    "smart-account-fundamentals": "Master smart account fundamentals: PDAs as keyless vaults, authorization patterns, role-based access, and real-world use cases for program-controlled accounts.",
+    "smart-account-architecture": "Explore smart account architecture patterns: permission models, upgradeability trade-offs, on-chain vs off-chain logic, and CPI composability on Solana.",
+    "squads-smart-account-program": "Deep dive into Squads v4: account types, instruction set, vault PDAs, proposals, spending limits, and the leading smart account implementation on Solana.",
+    "multisig-fundamentals": "Learn multisig fundamentals: M-of-N threshold model, proposal-approval-execution lifecycle, participant roles, and security properties of multi-party authorization.",
+    "multisig-operations": "Master multisig operations: transaction lifecycle, config changes, vault management, spending limits, edge cases, and production best practices.",
+    "multisig-with-spl-token": "Understand SPL Token multisig: built-in multi-party authorization for token operations, setup walkthrough, limitations, and when to use it vs Squads.",
+    "conclusion": "Complete your smart accounts and multisig journey with SPL vs Squads comparison, ecosystem overview, key takeaways, and next steps for production implementation."
   }
 }

messages/en/courses.json

@@ -666,6 +666,36 @@
           "description": "Prepare mobile dApps for production. Implement crash reporting, analytics, RPC monitoring, and establish update strategies for live applications."
         }
       }
+    },
+    "smart-accounts-and-multisig": {
+      "title": "Smart Accounts & Multisig",
+      "description": "Master program-controlled accounts on Solana. Learn smart account architecture, multisig patterns, SPL Token multisig, and Squads protocol integration.",
+      "lessons": {
+        "introduction": {
+          "title": "Introduction to Smart Accounts & Multisig"
+        },
+        "smart-account-fundamentals": {
+          "title": "Smart Account Fundamentals"
+        },
+        "smart-account-architecture": {
+          "title": "Smart Account Architecture Patterns"
+        },
+        "squads-smart-account-program": {
+          "title": "Squads Smart Account Program"
+        },
+        "multisig-fundamentals": {
+          "title": "Multisig Fundamentals"
+        },
+        "multisig-operations": {
+          "title": "Multisig Operations & Mechanics"
+        },
+        "multisig-with-spl-token": {
+          "title": "SPL Token Multisig Approach"
+        },
+        "conclusion": {
+          "title": "Conclusion"
+        }
+      }
     }
   }
 }

src/app/content/courses/courses.ts

@@ -374,6 +374,23 @@ export const courses: CourseMetadata[] = withCourseNumber([
       { slug: "program-interaction" },
     ],
   },
+  {
+    slug: "smart-accounts-and-multisig",
+    language: "General",
+    color: BRAND_COLOURS.general,
+    difficulty: 2,
+    isFeatured: true,
+    lessons: [
+      { slug: "introduction" },
+      { slug: "smart-account-fundamentals" },
+      { slug: "smart-account-architecture" },
+      { slug: "squads-smart-account-program" },
+      { slug: "multisig-fundamentals" },
+      { slug: "multisig-operations" },
+      { slug: "multisig-with-spl-token" },
+      { slug: "conclusion" },
+    ],
+  },
   {
     slug: "dapp-store-publishing",
     language: "Mobile",

src/app/content/courses/smart-accounts-and-multisig/conclusion/en.mdx

@@ -0,0 +1,88 @@
+import { ArticleSection } from "../../../../components/ArticleSection/ArticleSection";
+
+# Conclusion
+
+Congratulations! You've completed the Smart Accounts & Multisig course. You now understand how program-controlled accounts work on Solana, the architectural patterns behind them, and the practical tools available for multi-party authorization.
+
+<ArticleSection name="What You've Learned" id="what-youve-learned" level="h2" />
+
+### Smart Accounts
+
+- **PDAs as keyless vaults**: Program Derived Addresses enable accounts that no private key can control — only program logic determines who can act and under what conditions.
+- **Authorization patterns**: From simple signer verification to role-based access, timelocks, and spending limits, smart accounts support configurable security policies.
+- **Architecture trade-offs**: Immutable vs. upgradeable programs, on-chain vs. off-chain logic, flat vs. role-based permissions — each choice affects security, flexibility, and trust assumptions.
+
+### Multisig
+
+- **M-of-N threshold model**: Multiple parties must agree before actions execute, eliminating single points of failure.
+- **Proposal lifecycle**: The propose → approve → execute flow provides structure, accountability, and auditability for every action.
+- **Participant roles**: Proposers, voters, and executors serve different functions, enabling organizational structures that mirror real-world governance.
+- **Operational mechanics**: Vault management, config transactions, spending limits, and staleness handling are the building blocks of production multisig systems.
+
+### Implementation Options
+
+- **SPL Token Multisig**: Built into the Token Program, simple to set up, limited to token operations, fixed signer set, synchronous signing.
+- **Squads Protocol**: Full-featured smart account infrastructure with flexible permissions, async proposals, arbitrary CPI, spending limits, and dynamic configuration.
+
+<ArticleSection name="SPL Token Multisig vs Squads — When to Use What" id="comparison" level="h2" />
+
+**Use SPL Token Multisig when:**
+- You only need multi-party control over a mint authority or token account
+- Your signer set is small (≤ 11) and won't change
+- You want zero external dependencies
+- Your signers can coordinate synchronously
+
+**Use Squads when:**
+- You need to control SOL, interact with DeFi, or execute arbitrary instructions
+- Your organization may add or remove members over time
+- You need asynchronous proposals and approval workflows
+- You want spending limits, timelocks, or role-based permissions
+- You're managing a protocol treasury, program upgrade authority, or DAO
+
+For most production use cases, Squads is the recommended choice. SPL Token multisig is appropriate for simple, static token authority setups.
+
+<ArticleSection name="Ecosystem Overview" id="ecosystem" level="h2" />
+
+Smart accounts and multisig are foundational infrastructure across the Solana ecosystem:
+
+### Squads Protocol
+
+The dominant smart account platform on Solana. Used by major protocols, DAOs, and institutions. The v4 program is open-source and audited, with an active SDK and UI at [app.squads.so](https://app.squads.so).
+
+### Realms (SPL Governance)
+
+SPL Governance provides DAO governance with token-weighted voting. While it overlaps with multisig in some areas, its focus is on token-holder governance rather than team-based multisig.
+
+### Program Upgrade Authority
+
+Solana's runtime allows program upgrade authorities to be set to any address — including multisig accounts. This is the standard practice for production programs, ensuring no single developer can push an unreviewed upgrade.
+
+### Custody Providers
+
+Institutional custody solutions on Solana (Fireblocks, Copper, Anchorage) use smart account patterns internally for multi-party authorization of client assets.
+
+<ArticleSection name="Key Takeaways" id="key-takeaways" level="h2" />
+
+1. **Never use a single keypair for high-value accounts.** The operational overhead of multisig is negligible compared to the risk of key compromise or loss.
+
+2. **Choose your threshold carefully.** Too low and a small group of compromised keys can drain assets. Too high and operational friction or member unavailability can lock the account.
+
+3. **Separate roles when possible.** The person proposing an action shouldn't be the same person executing it. Role separation creates accountability.
+
+4. **Plan for key loss.** Your multisig configuration should allow for member rotation without losing access. Document the recovery process.
+
+5. **Simulate before approving.** Transaction simulation prevents expensive mistakes. Every multisig member should verify what they're signing.
+
+6. **Use spending limits for routine operations.** Don't force a full proposal cycle for small, routine transfers. Spending limits reduce friction without sacrificing security for high-value operations.
+
+<ArticleSection name="Next Steps" id="next-steps" level="h2" />
+
+To put your knowledge into practice:
+
+- **Set up a Squads multisig** on devnet using the [Squads SDK](https://github.com/Squads-Protocol/v4) and practice the full proposal lifecycle
+- **Explore the Squads v4 source code** to understand the on-chain implementation details
+- **Try SPL Token multisig** for a simple mint authority setup to understand the differences firsthand
+- **Review the security considerations** from this course and apply them to your existing projects
+- **Check the [Program Security course](/en/courses/program-security)** if you haven't already — the security vulnerabilities covered there are directly relevant to smart account implementations
+
+Smart accounts and multisig are not just security tools — they're organizational primitives that enable teams, DAOs, and protocols to operate with shared authority and accountability on-chain.

src/app/content/courses/smart-accounts-and-multisig/introduction/en.mdx

@@ -0,0 +1,98 @@
+import { ArticleSection } from "../../../../components/ArticleSection/ArticleSection";
+
+# Introduction to Smart Accounts & Multisig
+
+On Solana, every account is owned by a program. The System Program owns your wallet. The Token Program owns your token accounts. The authority to act on those accounts is determined by whoever holds the private key — a single Ed25519 keypair that grants total, binary control.
+
+This model is simple and fast, but it doesn't scale to real-world needs. Treasuries shouldn't depend on one person's hardware wallet. DAOs can't operate with a single signer. Custody solutions need programmable authorization that goes beyond "has the key or doesn't."
+
+Smart accounts and multisig protocols solve this by moving authorization logic on-chain. Instead of a private key being the sole gatekeeper, a program defines who can act, under what conditions, and with what approvals.
+
+<ArticleSection name="Why Smart Accounts Matter" id="why-smart-accounts-matter" level="h2" />
+
+Consider the problems with keypair-controlled accounts:
+
+**Single point of failure.** If the private key is lost or compromised, the account is gone. There's no recovery, no fallback, no appeal.
+
+**No granular permissions.** A keypair grants all-or-nothing access. You can't give someone permission to transfer tokens but not close accounts. You can't limit spending to a daily cap. You can't require a second approval for large transactions.
+
+**No organizational control.** Teams, DAOs, and protocols need shared control over assets. A keypair can't represent "3 of 5 board members must approve." It can't enforce that the CFO can spend up to 100 SOL but needs board approval for more.
+
+**No programmable policies.** Business logic like timelocks, spending limits, whitelists, and conditional execution are impossible with raw keypairs.
+
+Smart accounts address all of these by wrapping account control in program logic.
+
+<ArticleSection name="Keypair vs Program-Controlled Accounts" id="keypair-vs-program" level="h2" />
+
+In the traditional model, the relationship is direct:
+
+```
+┌──────────────────┐
+│  Account         │
+│  Owner: System   │
+│  Lamports: 100   │
+└──────────────────┘
+        │
+   [Ed25519 Key]
+        │
+   Full Control
+```
+
+The private key holder can transfer lamports, close the account, or reassign ownership. There's no middle layer.
+
+With a smart account, a program mediates all access:
+
+```
+┌──────────────────┐     ┌──────────────────┐
+│  Vault (PDA)     │     │  Smart Account   │
+│  Owner: Program  │◄────│  Program         │
+│  Lamports: 100   │     │                  │
+└──────────────────┘     │  - Who can act?  │
+                         │  - What rules?   │
+                         │  - What quorum?  │
+                         └──────────────────┘
+                                  │
+                         ┌────────┼────────┐
+                      [Key A]  [Key B]  [Key C]
+                              2 of 3
+```
+
+The vault is a Program Derived Address (PDA). No private key can sign for it directly. Only the smart account program can authorize actions on the vault, and it does so according to rules defined in on-chain state.
+
+<ArticleSection name="The Building Blocks" id="building-blocks" level="h2" />
+
+Smart accounts and multisig on Solana rely on a few core primitives:
+
+### Program Derived Addresses (PDAs)
+
+PDAs are addresses derived from seeds and a program ID that don't lie on the Ed25519 curve. No private key exists for them. The only way to sign for a PDA is through `invoke_signed` in the owning program. This makes PDAs perfect for program-controlled vaults: assets held at a PDA can only be moved when the program's authorization logic approves.
+
+### Cross-Program Invocations (CPIs)
+
+Programs interact with each other through CPIs. A smart account program uses CPI to transfer tokens, interact with DeFi protocols, or execute arbitrary instructions on behalf of its vault. The combination of PDA signing and CPI enables smart accounts to act as autonomous agents governed by on-chain rules.
+
+### On-Chain Configuration State
+
+The rules governing a smart account — members, thresholds, permissions, timelocks — are stored in on-chain accounts. Changing these rules requires going through the same authorization logic, creating a self-governing system.
+
+<ArticleSection name="Real-World Applications" id="real-world" level="h2" />
+
+Smart accounts and multisig are not theoretical constructs. They're used across the Solana ecosystem:
+
+- **Protocol treasuries** where foundation funds require multi-party approval before any spending
+- **DAO governance** where token holders vote on proposals that execute through smart accounts
+- **Custody solutions** where institutional clients need configurable authorization policies
+- **Team operations** where developer teams manage program upgrade authority through multisig
+- **Escrow systems** where funds are released only when predefined conditions are met
+
+<ArticleSection name="Course Roadmap" id="course-roadmap" level="h2" />
+
+This course is divided into two sections:
+
+**Section 1: Smart Accounts** covers the fundamentals of program-controlled accounts, architectural patterns for building them, and a deep dive into the Squads Smart Account Program — the most widely adopted implementation on Solana.
+
+**Section 2: Multisig** covers the M-of-N threshold model, the proposal/approval/execution lifecycle, SPL Token's built-in multisig feature, and how Squads implements full-featured multisig on top of smart accounts.
+
+By the end, you'll understand how smart accounts work under the hood, when to use different multisig approaches, and how to integrate with the Squads protocol for production use cases.
+
+Let's start with the fundamentals of smart accounts.