Module 4: Bitcoin in Your Community

Module 4 applies learning from Modules 1–3 to local daily life. It is a required part of the Bitcoin Diploma, not a free-choice bonus module, and it is not globally defined as “spending.” Every certificated learner completes one approved locally relevant task, but educators select the context because currencies, tools, laws, risks, infrastructure, and community needs vary.

It is the Connect stage of Problem → Solution → Action → Connect. The learner must connect the earlier modules to a local need or opportunity and a realistic existing alternative before practising a safe task. The intended outcome is sound local reasoning and safe performance, not adoption or a favorable conclusion about Bitcoin.

Guiding question:

How do the problem, solution, and safe action connect to this community?

Learner promise:

I can demonstrate one approved local Bitcoin-as-money task and explain its purpose, trade-offs, failure points, safety considerations, and realistic next steps.

If this is your first time teaching Module 4: Do not start by choosing a popular tool. Start with a local need, compare the existing option, verify current facts, and select the smallest safe task that can show useful learning. A well-supported simulation is a successful lesson; a live payment is not required merely to make the module feel practical.

Use guided discussion to support the formative competency F1 and the course-ending reflection to support the formative competency F2. Neither creates a certification gate.

Ask first:

1. Which Module 1 problem, Module 2 response, and Module 3 safe action are learners connecting?
2. What real local problem or opportunity are we examining?
3. How is it handled now?
4. Which function of money is involved?
5. Could Bitcoin improve the complete path?
6. What new cost, custody, privacy, price, legal, operational, or safety risk appears?
7. Can learners examine or practise the path safely?
8. What observable action would show the competency?

A valid conclusion may be that Bitcoin is not the best option for the case. The module assesses reasoning and safe performance, not adoption.

1. Learn the local context

Investigate:

• currencies and units of account
• common cash, bank, mobile-money, and card payment methods
• internet, electricity, data, and device reliability
• banking and identity access
• common wage, merchant, donation, or remittance patterns
• Bitcoin knowledge and tool availability
• language and accessibility needs
• fraud, coercion, surveillance, and physical-safety risks
• legal, tax, accounting, consumer, and reporting context; and
• available technical or community support.

Do not ask learners to reveal personal financial details to complete this research. Use public information, voluntary community consultation, and invented cases. The Bitcoin Diploma AI assistant can help you draft research questions and identify gaps to investigate. Verify local conditions through current primary sources and community consultation before using them in a lesson.

2. Define the local need or opportunity

Write one sentence:

Learners will examine whether Bitcoin can help ________ by comparing or demonstrating ________ under the local conditions of ________.

If the sentence starts with a product name, return to the need.

3. Select a focused module

Choose one primary task and, at most, one supporting task for a minimum module. Suitable areas may include:

• receiving payment for work
• an everyday purchase
• family remittance or cross-border payment comparison
• merchant payment and refund flow
• community or nonprofit donation
• on-ramp and off-ramp comparison
• Lightning payment where appropriate
• local resource or merchant discovery
• circular-economy mapping
• local money-problem analysis; or
• another approved locally relevant Bitcoin-as-money task.

Every certification activity must map to C7 and preserve the purpose of C7.1 and C7.2 through a locally relevant activity.

The Activity Library can offer practice ideas. Select and validate the local task yourself; a library activity does not automatically meet C7.

4. Verify facts, tools, and expertise

For every tool or service, record:

• exact name and version
• publisher and verified source
• custody model
• supported network and payment requests
• setup, funding, and recovery path
• fees, spreads, limits, and liquidity constraints
• data collected and privacy consequences
• compatibility and device requirements
• failure and support process
• ownership or policy changes
• local legal or tax relevance
• alternative if the tool fails; and
• date checked.

Invite a qualified local expert when needed. Brief them on the competencies, no-promotion boundary, privacy rules, and assessment role. The educator remains responsible for the learning environment.

5. Design Presentation → Practice → Production

Presentation: Demonstrate the complete local path, including the non-Bitcoin alternative, costs, custody, failure points, and stop conditions.

Practice: Learners rehearse with printed materials, a simulation, test environment, or approved low-stakes setup.

Production: Learners complete the defined task or direct its decisions with only permitted support, then explain the relevant trade-offs.

6. Make the assessment opportunity clear

Before class, specify:

• competency and suitable activity
• observable action sequence
• required verification behavior
• required explanation
• permitted prompt level
• privacy and consent boundaries
• safety-critical errors
• offline equivalent
• Showing competency: Yes and Showing competency: Not yet; and
• optional notes and reassessment route.

7. Debrief and choose a safe next step

Ask learners to identify:

• the local need
• the existing alternative
• the Bitcoin path
• who controls the keys and records at each stage
• total costs and time
• strongest benefit
• most serious risk or failure point
• locally specific rule or condition
• evidence observed; and
• smallest responsible next step.

The next step may be further learning, another simulation, checking a current rule, seeking qualified help, or deciding not to use the path.

Do not deliver a live Module 4 activity until every check passes

If a check below is not satisfactory, use a simulation, printed route, or a different activity. Do not compensate for an unsafe or unverified route by asking learners to accept more risk.

Do not deliver a live module until every required answer is satisfactory.

Complete this before delivery.

If direct observation cannot fit, redesign the scheduled route before delivery: add approved assessor capacity, reduce the cohort, or advertise a longer integrated course. Do not add an assessment-only follow-up after the advertised Bitcoin Diploma.

Do not demonstrate a tool simply because it is popular locally. Use this comparison:

Before a Lightning workshop, verify and explain:

• whether the wallet is custodial or self-custodial
• how it is funded
• whether funding or withdrawal uses an on-chain transaction or service
• recovery and continuity if the provider or device fails
• whether the request is an invoice, supported Lightning address, or another type
• amount, unit, recipient, expiry, fee, limits, and liquidity considerations
• what success, pending, expiry, or failure looks like
• how both parties independently confirm the result; and
• the offline simulation.

Purpose: Compare the complete route for an existing local payment, an on-chain path, and a Lightning path where appropriate.

Setup: Use a realistic invented payment amount and recipient. Prepare dated local fee, exchange, timing, custody, and access information. If data cannot be verified, clearly label it hypothetical.

Learner task: Complete:

Production: The learner chooses a path for the invented case, demonstrates or sequences the relevant payment request and verification, and explains why the other path might be better under a changed condition.

Debrief: Did Bitcoin improve the complete route, or only one visible step? Who bears volatility, conversion, custody, and failure risk?

Safety: No real transfer or named provider is required. Use printed payment information.

Purpose: Practise a point-of-sale payment and compare on-chain and Lightning where locally appropriate.

Presentation: The merchant creates the correct request; the customer verifies recipient, payment type, amount, unit, and fee; both parties confirm the result.

Practice: Use a low-value item, test environment, or simulation. Include one failed or expired request.

Production: The learner completes the approved payment role and explains:

• why the selected rail fits the amount and timing
• who controls the wallet
• how receipt is confirmed
• what happens if sender and merchant displays disagree; and
• when to stop.

Debrief: A fast payment is not automatically private, self-custodial, final in the same way, or suitable for higher value.

Purpose: Map a payment from the payer's starting value to the recipient's usable outcome.

Learner decisions:

• Is the obligation priced in local currency, bitcoin, or sats?
• When is the exchange rate fixed?
• Who pays fees and spreads?
• Does the recipient want bitcoin or local currency?
• Who controls keys at each stage?
• Which path provides liquidity or conversion?
• Is either fiat payment reversible?
• What records or tax treatment may apply?
• What happens if a service delays or prevents withdrawal?
• Does the complete path improve cost, time, access, or control?

Production: Demonstrate or simulate the receive step and verify the final amount and status. Explain the main benefit, risk, and failure point.

Safety: Use an invented family or work case. Do not ask learners about their own wages, migration status, relatives, transfers, or tax affairs.

Purpose: Show that merchant adoption requires operations beyond displaying a receive button.

Cover:

• display currency and exchange-rate timing
• on-chain, Lightning, or both
• custody and staff permissions
• receive-device security
• customer and merchant confirmation
• receipts and records
• refunds using a newly verified return request
• conversion or movement of received funds
• accounting and tax review
• internet or wallet failure; and
• support and escalation.

Production: The learner performs or directs a payment and refund scenario. They must authenticate the customer, request fresh return information, check the destination and amount, identify who pays any fee, and record the result without exposing unnecessary data.

Debrief: Why is sending a refund automatically to an assumed original address unsafe? Who becomes responsible when several staff share one wallet?

Purpose: Design a safe donation route for a nonprofit, classroom project, or simulated community group.

Learners decide:

• how donors verify the genuine payment request
• whether receipt is on-chain, Lightning, or both
• who controls the wallet and backup
• who can authorize spending
• what transparency is useful
• which donor information should remain private
• what records may be required
• how a mistaken or fraudulent request is handled; and
• what happens if the custodian, device, or service fails.

Production: Demonstrate a verified sample donation request and explain custody, transparency, privacy, and the main failure point.

Safety: Do not collect real donations during an assessment unless an approved organizational process, consent, records, and legal review already exist. A simulation usually serves the learning competency better.

Purpose: Compare routes without recommending acquisition or evasion.

Include earning, direct exchange, a service, an ATM or kiosk, merchant use, or conversion where locally relevant.

Ask:

• What identity data are collected?
• Who stores them and for how long?
• What is the full price, spread, fee, and withdrawal cost?
• Can bitcoin be withdrawn to a wallet the learner controls?
• When is the fiat side final or reversible?
• What fraud, counterparty, physical, and privacy risk exists?
• What support or dispute process exists?
• Which local rule applies?

Production: The learner chooses a path for an invented case, sequences the safe checks, and explains which risk is reduced and which is added.

Safety: Do not facilitate an actual peer-to-peer cash trade as a default classroom exercise. Never direct learners to evade KYC, tax, exchange, or other local rules.

Purpose: Evaluate whether a voluntary local loop solves a real problem.

Map:

1. who can earn bitcoin.
2. where it can be used.
3. which merchants can pay suppliers or workers.
4. who must exchange to or from fiat.
5. who controls keys at each stage.
6. who provides education and technical support.
7. what happens when internet or electricity fails.
8. what price, custody, fraud, and privacy risks participants carry; and
9. whether the loop depends on giveaways or one organizer.

For resource discovery, verify:

• when a listing was last checked
• whether the merchant or group still operates
• which payment method is accepted
• whether an alternative payment is available
• whether publication has consent; and
• whether the contact is offering education or promoting an investment or private exchange.

Production: The learner verifies one prepared resource, adds it to the map with a date and safety note, and explains how it supports or fails to support a local loop.

Safety: A map listing, meetup membership, or community reputation is not proof of trustworthiness. Do not publish home locations or private contacts.

If one person or group controls bitcoin for others, they are acting as a custodian. Explain the added responsibilities:

• authorization rules
• separation of duties
• backup and succession
• records and transparency
• privacy and access control
• dispute and loss handling
• legal status; and
• concentration of trust.

Do not turn community-custody design into a beginner implementation exercise. Use a scenario and seek appropriate legal and security review.

• What local need are we trying to solve?
• Which current option is the strongest comparison?
• Which function of money is involved?
• Is Bitcoin better after considering the complete route?
• Who controls the keys, accounts, and records at each stage?
• Who pays fees and bears exchange-rate risk?
• Which identity or transaction information becomes visible?
• Can the payment be reversed, disputed, or refunded?
• What happens when internet, electricity, wallet, service, or recipient fails?
• Which claim is globally stable and which is locally specific?
• Which fact requires a current authoritative source?
• Is participation genuinely voluntary?
• Does the design create dependence on one service or organizer?
• What would count as success besides transaction volume?
• What is the smallest safe next step?

• Starting with a fashionable tool instead of a need.
• Treating a named wallet, exchange, map, merchant, or community as an endorsement.
• Using outdated fees, versions, custody claims, legal information, or listings.
• Comparing only an advertised fee rather than total received and the complete path.
• Ignoring custody during conversion, funding, or withdrawal.
• Treating one successful payment as proof of security or usefulness.
• Assuming Lightning convenience means self-custody.
• Treating KYC or no-KYC as universally superior.
• Ignoring accounting, tax, employment, privacy, or consumer context.
• Pressuring merchants, workers, or learners to participate.
• Counting adoption or transaction volume without testing whether a real problem is solved.
• Building around one trusted organizer without naming the custody dependence.
• Having no offline, no-funds, refund, failure, or support process.
• Assuming that a local example applies globally.

The selected local activity should let the educator notice the C7 competency by observing whether the learner can:

• identify the local purpose
• complete the required action or simulation in the correct sequence
• verify the relevant recipient, address, invoice, amount, unit, fee, status, or resource
• preserve privacy and secrets
• respond safely to a failure or changed condition
• explain custody and control
• compare the Bitcoin path with a realistic alternative
• identify the strongest benefit and most serious risk
• name a relevant local condition or limit; and
• select a responsible next step, including deciding not to proceed.

Different local tasks may produce equivalent evidence. They do not become equivalent merely because each involves Bitcoin.

For review, each learner or team may present:

• local need
• current alternative
• Bitcoin path
• custody at each stage
• strongest benefit
• most serious risk
• main failure point
• locally verified fact
• evidence observed; and
• safe next step.

Ask another learner to pose one verification question and identify one trade-off.

Team presentation does not provide individual certification evidence. Each learner seeking certification must produce individually identifiable practical evidence against the C7 rubric, including C7.1 and C7.2, under direct observation by an educator.

Then use the Module 4 Student Guide closing question. Keep the response private or optional, following the light module-closing reflection guidance above.

Close with:

Bitcoin can function as money when people voluntarily use it to earn, save, receive, send, spend, price, or settle value. The Connect stage begins with a real need, compares a realistic alternative, makes custody and costs clear, respects local law and safety, and leaves people free to decide.