Overview

You already know your subject and your students. What this module adds is a way to turn "I want to teach some blockchain" into a course that actually holds together, one where every piece earns its place, sits in the right order, and can be assessed honestly.

The previous module gave you teaching technique for the room: misconceptions, analogies, adapting to an audience. This one zooms out to the blueprint. Before you ever stand in front of a class, you make a series of design decisions: what learners should be able to do, in what order they will get there, how big each step is, how fast they move, and how you will know they made it. Get those decisions right and the teaching gets easier; get them wrong and no amount of charisma on the day will save the course.

We will work through five design moves in the order you would actually make them: writing objectives, mapping prerequisites, chunking and pacing, aligning assessment, and balancing theory against practice. None of this is specific to blockchain, it is standard instructional design, but we will keep grounding it in the concrete problem of adding an XRPL section to a course you already teach. You will not write a line of code here; you will write the plan that everything else hangs on.

Start from what learners will be able to do

The single most useful habit in course design is to state every goal as something a learner can do, observably, after the lesson, not as something you will "cover." "Cover trustlines" is a topic. "Explain why a trustline is required before holding an issued token" is an objective: it names an action you can watch a learner perform and check.

The classic tool here is Bloom's taxonomy, a ladder of cognitive levels from simpler to more demanding: remember, understand, apply, analyze, evaluate, create. Each level comes with verbs that make the expectation precise. Remember gives you "list, define, name." Understand gives you "explain, summarize, classify." Apply gives you "demonstrate, use, send." Analyze gives you "compare, contrast, distinguish." Evaluate gives you "justify, critique, decide." Create gives you "design, build, compose." The verb is not decoration; it tells the learner, and you, exactly how high you are aiming.

The payoff is that the verb dictates everything downstream. An objective at understand ("explain how consensus reaches agreement") is taught with explanation and worked examples and assessed by asking the learner to explain it back. An objective at apply ("send a payment on testnet") is taught with a guided walkthrough and assessed by watching them do it. If you only ever write remember-level objectives, you will produce a course where learners can recite "XRPL settles in 3 to 5 seconds" but cannot reason about when that matters, a known failure mode in technical teaching. Aim deliberately: a beginner blockchain section might live mostly at understand and apply, with one or two analyze objectives as the stretch.

A practical caution: keep objectives few and honest. Three to five per module is plenty. Each one is a promise you are making to the learner and a thing you have committed to assess. Vague verbs ("know," "understand deeply," "be familiar with," "appreciate") are the ones to hunt down and rewrite, because you cannot observe them and therefore cannot tell whether you delivered.

Sequence by dependency, not by topic

Once you have objectives, the order is not a matter of taste; it is a matter of dependency. Some things genuinely cannot be learned before others. You cannot meaningfully teach "issue a stablecoin" before "what a token is," and you cannot teach "why a trustline exists" before the learner grasps that issued assets are not native XRP. The job is to surface those prerequisite relationships and let them drive the order.

A useful way to picture this is a dependency graph: each objective or module is a node, and an arrow points from a prerequisite to the thing that needs it. Lay your topics out this way and the sequence often reveals itself: start from the nodes with no incoming arrows (the true foundations) and work outward. It also exposes problems a flat list hides: a topic everything depends on that you had buried in week five, or a "module 3" that secretly needs something from "module 6." This is the same prerequisite logic the academy itself uses to order modules, and it is why this very module lists How to Teach Blockchain as its prerequisite rather than leaving the order to chance.

Watch for the two classic sequencing mistakes. The first is the expert's curse: things that feel atomic to you (consensus, finality, custody) are actually bundles of prerequisites for a novice, so you skip steps without noticing. The second is the forward reference, explaining something that quietly relies on a concept you have not taught yet, forcing the learner to either trust you blindly or get lost. Drawing the dependencies out, even roughly on paper, catches both before they reach a classroom.

Chunk the material, then pace it

A dependency graph tells you the order; it does not tell you how to slice the material into teachable pieces or how long they will take. That is chunking and pacing, and it is where realistic course design usually breaks down.

Chunking means breaking content into pieces small enough to hold in working memory and complete in one sitting. The constraint is human, not topical: a learner can only juggle a handful of genuinely new ideas at once before the next one pushes an earlier one out. So a good module introduces one central concept and a small number of supporting ideas, not eight. If a planned module has six objectives spanning three Bloom levels, that is a signal to split it. A reliable test is whether you can state the module's job in a single sentence. If you need "and" three times, it is really three modules wearing a trench coat.

Pacing is chunking across time, against the calendar your learners actually live in. This is where good intentions meet reality: the topic that takes you ten minutes to explain takes a beginner an hour to absorb and practice, and a 90-minute block with no breathing room teaches nothing that sticks. Notice that the XRPL Learning Portal sizes its courses in honest, bounded units, roughly 90 to 120 minutes each, explicitly inviting learners to "go at your own pace" rather than marching through a fixed sequence. That is a deliberate pacing choice: bounded, self-contained chunks that respect that adult learners arrive with limited, interrupted time. When you estimate duration for your own modules, budget for practice and confusion, not just for the time it takes you to say the words, and leave slack. Almost every first-time course designer overpacks.

Align assessment to the objective

Here is the move that separates a coherent course from a collection of activities: constructive alignment. The principle is simple and unforgiving: your objectives, your teaching activities, and your assessment must all point at the same target. If an objective says learners will apply (send a payment), then an exam asking them to define "payment" does not measure it, and a lecture with no hands-on time does not teach it. The three have fallen out of alignment, and the learner is the one who pays.

The discipline is to read each objective and ask two questions. Does my teaching give them a real chance to reach this verb? An apply objective needs a guided practice; an analyze objective needs something to compare. Does my assessment actually require this verb? If the objective is "compare custodial and non-custodial key management" but the quiz only asks them to list two facts, you are assessing remember and calling it analyze. Misalignment is sneaky precisely because each piece looks fine alone; it only shows up when you line objective, activity, and assessment side by side and check they match.

This is also your defense against the most common assessment trap: testing what is easy to grade rather than what you actually care about. Recall questions are quick to mark, so courses drift toward them even when the real goal was reasoning or building. Alignment keeps you honest: if the objective is at apply or above, the assessment has to be too, even when that means a project or a demonstration instead of a tidy multiple-choice question. The Assessment and Feedback module goes deep on building those exercises; alignment is the rule that tells you what they need to measure.

Balance theory and practice for your audience

Every blockchain course makes one more call: how much conceptual grounding versus how much hands-on doing. There is no universal ratio; it is set by your objectives and your audience. A no-code business cohort needs enough theory to make good decisions and very little keyboard time; a CS cohort learns the concepts through building and grows restless in pure lecture. The same XRPL idea, say the on-ledger exchange, becomes a discussion of liquidity for one group and a coding exercise for the other.

Two anchors keep this balanced. First, let the Bloom level decide: objectives at understand lean theory, objectives at apply and create demand practice, so the mix falls out of objectives you already wrote rather than from a guess. Second, lean toward doing sooner than feels comfortable. Open-education research consistently finds that active, participatory practice, learners producing and engaging rather than passively receiving, drives better and more equitable outcomes than transmission alone (Ramirez-Montoya, 2020). For a hands-on technology like the XRPL, that argues for getting learners to a real testnet transaction early, then layering theory onto an experience they have already had, rather than making them wait through weeks of concepts first.

From plan to syllabus: use the Syllabus Assistant

The five moves above are done on paper. The academy then gives you a tool to turn that plan into a real, structured artifact: the Syllabus Assistant at /syllabus. It is a short, guided form that asks a few questions about you and your course (your topics, your audience, your objectives, your format) and turns your answers into a structured, ready-to-edit syllabus rather than a blank document.

The overall process is worth seeing as one flow:

Design on paper. Make the five decisions in this module: objectives, sequence, chunks and pacing, aligned assessment, and the theory-practice balance.
Open the Syllabus Assistant at /syllabus and answer its questions. Your paper design is exactly the raw material it asks for, so this step is quick if you did the thinking first.
Generate and refine. The Assistant produces a structured syllabus you can edit: sections, objectives, resources. Adjust it until it matches your plan.
Keep and share. Your syllabi are saved to your account, so you can revisit, revise, and reuse them, which is the open-education habit in action.

Design first, then let the Assistant do the formatting. A tool cannot rescue a course whose objectives are vague or whose sequence ignores dependencies, but once the thinking is sound it saves you the tedious part and gives you something you can share.

The throughline across all of this is intention. A learning path is not topics in a row; it is a set of deliberate decisions (what learners will do, in what order, in what size, measured how, with what balance) each one chosen and each one checkable. Make those decisions on paper first, format them with the Assistant, and the course you teach will be the course you designed.

Check

You are done when you can turn one topic you care about into a properly aligned slice of a course, not just a list of things to mention. Concretely: pick a blockchain concept you would add to a course you already teach and write a one-page course-design sketch. Include three to five learning objectives, each using an action verb at a named Bloom level; the prerequisite each objective depends on; an honest duration estimate; and, for at least one objective, the assessment that would measure it, with a sentence explaining why the objective, the teaching, and the assessment line up. Then take that sketch into the Syllabus Assistant at /syllabus and generate a structured syllabus from it.

The alignment sentence is the part that proves you understood the module. Anyone can list topics; a course designer can show that the assessment actually measures the objective it claims to. Hand your sketch to a peer and have them check two things: that every objective uses an observable verb, and that your chosen assessment genuinely tests the verb the objective names.

Designing a Blockchain Curriculum