Ten small, safe ways in.

01 · THE RULES · FOR EVERY ASSIGNMENT

No keys, no money, no posting.

• No keys that control anything: public dev keys and throwaway local test credentials only.
• No money: nothing is bought, sold, staked or paid, and ATTN carries no value.
• No posting: nothing goes on a public channel or anyone’s account without review.
• No people, buildings or places in any image you make for an assignment.
• Say what you observed and what you inferred, separately. Plans are plans.

The pointcast-chain repo is local today and has no public remote. Assignments marked “needs the source” start once a copy is shared with you; ask through /ping. The others work from public pages right now.

These are educational project briefs. Applications are closed, and pay, hours, the hiring entity, supervision, eligibility, agreements and privacy terms are all unsettled; nobody starts as an employee from this page. The wider PointCast intern desk is at /intern.

02 · THE TEN · SPREAD FROM A FIRST AFTERNOON TO A FEW DAYS

Pick one. Finish it. Send it in.

1. PCC-I01 · STARTER · 2–4 HOURS · NEEDS THE SOURCE

   Run a node and press VERIFY.

   Why it matters. The chain’s central promise is that anyone can check the sequencer. A newcomer running it once and writing down every snag is the cheapest test of that promise, and of the docs.

   Steps

   1. Open /chain/yard/ on a laptop, press ✓ VERIFY, and note how long the replay takes and exactly what the strip says when it finishes.
   2. With the source: install Rust with rustup and run cargo test -p chain-core. Time it.
   3. Run cargo run -p node -- run --dev --demo, open http://127.0.0.1:8545/ and press VERIFY there.
   4. Start the lying node (cargo run -p node --example lying_node), open http://127.0.0.1:8545/?api=http://127.0.0.1:8546 and press VERIFY. Download evidence.json from the red banner.
   5. Save the lying node’s /params as params.json and run pointcast-node evidence check evidence.json --params params.json. Record the exit code.
   6. Write the run log while it is fresh.

   Deliverable

   A one-page run log: machine and versions, every command with how long it took, screenshots of a green and a red VERIFY, the evidence check’s exit code, and every stumble with what the docs should have said.

   Skills

   terminal basics · reading docs · careful notes

   What not to do

   • Use any key but the public dev keys.
   • Point anything at Tezos mainnet or set an anchor key.
   • Post screenshots publicly before review.

   Read first

   Dev tools: quickstart →Verify Desk →

   Submit: a note through /ping with PCC-I01 and a link to your deliverable.

2. PCC-I02 · STARTER · 2–4 HOURS

   Phone audit of the Block Yard and First Mints.

   Why it matters. Most visitors arrive on a phone. The yard draws the chain as cubes and runs a wasm verifier; First Mints is a composer with many controls. Both have to work at 375 pixels, with a thumb, large text and a screen reader.

   Steps

   1. Use at least two phones, one iOS and one Android if you can; a browser’s responsive mode is the fallback, and say so.
   2. Open /chain and /chain/yard/: note time to first paint, press VERIFY, scroll, pinch and rotate.
   3. Open /chain/first-mints/ and compose a card. Check every control can be reached, read and operated, with focus visible.
   4. Repeat with the largest text size, with dark mode, and for two minutes each with VoiceOver and TalkBack.
   5. Log each issue: device, steps, expected, actual, screenshot, severity.

   Deliverable

   An issue table and a top-five fix list ranked by how many visitors each would help.

   Skills

   QA · accessibility basics · screenshots

   What not to do

   • File issues publicly or tag anyone.
   • Enter personal data anywhere.
   • Describe the preview as minting: nothing is minted and no key is created.

   Read first

   Block Yard →First Mints preview →

   Submit: a note through /ping with PCC-I02 and a link to your deliverable.

3. PCC-I03 · ADVANCED · 1–2 DAYS · NEEDS THE SOURCE

   Write a new chain-sim scenario.

   Why it matters. The simulator is how the chain learns where farming leaks before anything has value. Its findings come from six scenarios; v2 needs more questions asked, honestly.

   Steps

   1. Read the pc-sim findings and the six scenario files in crates/chain-sim/scenarios.
   2. Build pc-sim and reproduce one documented root first: town-baseline, seed 1, ends at af59737ff877376d….
   3. Pick a question nobody has run. Example: what changes if half the honest regulars only drum, or a much smaller town under one-tap-an-hour gating?
   4. Write the scenario JSON, run it with pc-sim run, then a small pc-sim sweep over one parameter.
   5. Record seed → root for every run and say what moved and what didn’t.

   Deliverable

   The scenario file, each run’s summary.json, and a one-page note in the findings’ own style, labelled scenario output, not a forecast.

   Skills

   JSON · reading Rust lightly · basic statistics

   What not to do

   • Change chain-core or any consensus code.
   • Present a result as a forecast.
   • Claim a protocol bug without a seed that reproduces it.

   Read first

   pc-sim findings →

   Submit: a note through /ping with PCC-I03 and a link to your deliverable.

4. PCC-I04 · INTERMEDIATE · 1 DAY

   A passkey device test matrix.

   Why it matters. The wallet scope plans passkeys as the wallet: a webauthn signing mode and pcp1 addresses. The design assumes ES256 keys, signCount 0 on synced passkeys, and a fixed order of fields in clientDataJSON. Real devices have to be checked.

   Steps

   1. Read “Passkey design” in the wallet scope.
   2. List the devices you can reach: iPhone or iPad Safari, macOS Safari and Chrome, Android Chrome, Windows Hello.
   3. On a scratch page served from localhost, feature-detect platform authenticators (isUserVerifyingPlatformAuthenticatorAvailable, and getClientCapabilities where it exists).
   4. Create a throwaway passkey for rpId localhost that requests ES256 only (alg -7), and sign one fixed 32-byte challenge.
   5. Record the algorithm, the UP and UV flags, signCount, and the first keys of clientDataJSON in order. Then delete the credential.
   6. Fill in the matrix.

   Deliverable

   A matrix (device × browser × sync provider × ES256 × UV × signCount × clientDataJSON order × notes) and the scratch page’s source.

   Skills

   JavaScript · WebAuthn basics · careful recording

   What not to do

   • Register passkeys on pointcast.xyz or any real account.
   • Share credential ids or keys from a personal account.
   • Publish device serial numbers.

   Read first

   Wallet scope: passkey design →

   Submit: a note through /ping with PCC-I04 and a link to your deliverable.

5. PCC-I05 · INTERMEDIATE · 1 DAY

   First Mints palettes and type.

   Why it matters. A First Mints recipe picks from fixed lists: 16 backgrounds, 16 patterns, a handful of fonts and 16 inks, and any background and ink pair under 4.5:1 contrast must be rejected. Once an edition opens, those lists are permanent.

   Steps

   1. Read the recipe encoding in the wallet scope (BG_V1, PATTERN_V1, FONT_V1, INK_V1).
   2. Compute the contrast ratio of every background against candidate inks and mark every pair under 4.5:1.
   3. Try the preview at /chain/first-mints/ on a phone and note which combinations break at small sizes.
   4. Propose an INK_V1 list of 16 that leaves the most passing pairs, and check each font’s licence allows embedding.
   5. Write up the choices and the trade-offs.

   Deliverable

   A contrast grid, a proposed INK_V1 with reasons, and five sample cards as screenshots.

   Skills

   color · typography · a spreadsheet or a small script

   What not to do

   • Put people, buildings or places in samples.
   • Use a font whose licence doesn’t allow embedding.
   • Call the preview a mint.

   Read first

   Wallet scope: First Mints →First Mints preview →

   Submit: a note through /ping with PCC-I05 and a link to your deliverable.

6. PCC-I06 · INTERMEDIATE · 1–2 DAYS

   An oracle feed spec for an El Segundo signal.

   Why it matters. The Town Network plan includes oracles: signed reports from registered keys. A good first feed is one whose truth is public and boring, like the marine layer or the tide.

   Steps

   1. Pick one: the time the marine layer breaks at the coast, or the day’s high-tide height.
   2. Find two independent public sources and note how often each updates and its terms of use. PointCast’s fog log at /marine-layer is one place to start.
   3. Define the report: fields, units, integer encoding (the chain uses no floats), the reporting window, and what counts as late or missing.
   4. Write the dispute rule in plain English: how a second source could challenge a report.
   5. Write ten sample reports from real past data.

   Deliverable

   A two-page spec with a JSON report schema and ten example reports, labelled a plan.

   Skills

   research · data · clear writing

   What not to do

   • Build anything that sends transactions.
   • Scrape a site against its terms, or pay for an answer.
   • Imply that any feed is live.

   Read first

   The fog log →Design: no floats, integers only →

   Submit: a note through /ping with PCC-I06 and a link to your deliverable.

7. PCC-I07 · STARTER · 1 DAY

   Prediction market rules in plain English, with play money.

   Why it matters. The Town Network plan lists prediction markets: integer math, resolved by oracles, play money by default. Before any code, the rules have to read clearly to a neighbor.

   Steps

   1. Pick one local yes-or-no question with a public answer, such as whether the marine layer clears by noon on Saturday.
   2. Write the rules: who can open a market, how to join with play money, when it closes, the resolution source, the dispute window, and what happens if the source goes missing.
   3. Work one pool-style payout by hand in whole numbers and write down every rounding.
   4. List how a crowd of free keys could game it, using the simulator’s findings.
   5. Have one person who isn’t technical read it, and write down every question they ask.

   Deliverable

   One page of rules, the worked example, the gaming risks, and the reader’s questions.

   Skills

   plain writing · arithmetic · fairness

   What not to do

   • Use real money or anything of value.
   • Frame it as gambling or an investment.
   • Open a market or take a bet from anyone.

   Read first

   pc-sim findings →Roadmap →

   Submit: a note through /ping with PCC-I07 and a link to your deliverable.

8. PCC-I08 · INTERMEDIATE · 1 DAY

   Map PointCast’s identity surfaces.

   Why it matters. The wallet scope found many overlapping ways PointCast says who someone is: several holdings pages, three wallet connectors, two storage models, town cards and accounts, two agent registries. One profile starts with an accurate map.

   Steps

   1. Read “What PointCast has today” in the wallet scope.
   2. Visit each public surface signed out: /auth, /me, /profile, /wallet, /minted, /passport, /townsfolk, /connect, and a /p/ handle page.
   3. For each, record what it shows, where its data comes from as documented, and what it overlaps.
   4. Draw one diagram: person → login identities → public face → chain accounts → agents.
   5. Mark every place where two surfaces could disagree about who someone is.

   Deliverable

   The diagram, a table of surfaces with sources and overlaps, and the three changes you would make first.

   Skills

   information architecture · diagramming · careful reading

   What not to do

   • Sign in with a real wallet or create an account for the audit.
   • Screenshot anyone’s personal data.
   • Go beyond what a signed-out visitor can see.

   Read first

   Wallet scope: what PointCast has today →

   Submit: a note through /ping with PCC-I08 and a link to your deliverable.

9. PCC-I09 · INTERMEDIATE · 1 DAY

   A dev-tools docs pass.

   Why it matters. The SDK quickstart on /chain/dev should work for someone who has never seen the code. Every stumble is a doc bug, and the cheapest time to find them is now.

   Steps

   1. Read /chain/dev top to bottom before touching anything.
   2. Download /chain/sdk/pointcast-chain.js, import it in Node 20 or later, and call the pure functions: addressKind, recipientStatus, checkDropId, bodyHash, certificateCopy("no_node").
   3. Call connect(null) and confirm every read returns {status: "no_node"}.
   4. With the source and a local dev node, run the read path: connect with expect, getDrop, getMints, getHoldings. Confirm verification.verifiedHolder stays false on a dev chain, and read holderReason.
   5. Log every stumble: what you tried, what happened, and what the page should say instead.

   Deliverable

   A stumble log and a proposed rewrite of the quickstart section.

   Skills

   JavaScript · Node · technical writing

   What not to do

   • Run the signing flow with a real wallet: it belongs on the creator’s desk.
   • Paste a secret into a terminal, a page or a note.
   • Point the SDK at anything but a local dev node.

   Read first

   Dev tools: SDK →Art minting: SDK quickstart →

   Submit: a note through /ping with PCC-I09 and a link to your deliverable.

10. PCC-I10 · STARTER · HALF A DAY, PLUS ONE CONVERSATION

    Explain the chain to a neighbor.

    Why it matters. If the chain can’t be explained on one page to someone in El Segundo who has never owned crypto, the design isn’t finished. The wallet scope drafted a community explainer; test the idea on a real reader.

    Steps

    1. Read the community explainer in the wallet scope and the /chain home.
    2. Write a one-page explainer: what it is, what it is for, what it isn’t (no money, not public yet), and one thing to try (the Block Yard).
    3. Give it to one neighbor, friend or relative who doesn’t work in tech.
    4. Watch them read it. Write down every question and every word they tripped on.
    5. Revise once.

    Deliverable

    Version one, the feedback notes without names, and version two.

    Skills

    plain writing · listening

    What not to do

    • Record or quote the reader without permission.
    • Collect their contact details.
    • Promise rewards, value, or that anything is live.

    Read first

    Wallet scope: community explainer →The chain home →

    Submit: a note through /ping with PCC-I10 and a link to your deliverable.

03 · HOW TO SUBMIT · THE INTERN DESK’S PATTERN

One note, reviewed before anything is public.

Send a short note through pointcast.xyz/ping with the assignment id, a link to your deliverable somewhere you control, and one sentence on what surprised you. Notes are read and reviewed before any public follow-up; nothing is published automatically. Never paste a secret, a seed phrase or anyone’s personal details into the note.

Open /ping interns.json The same assignments, machine-readable.