Implementing SPCX, End to End

You've seen the structures. Now design the strongest one — a fully-backed, redeemable tokenized equity — at the level of authorities, mint logic, and key custody. This is the lesson where you could actually run the build review.

The mental model: an equity-backed stablecoin

SPCX is structurally a reserve-backed token — the same pattern as USDC, except the reserve is SpaceX shares in a broker-dealer's custody instead of dollars in a bank.¹ Everything in the design serves one invariant:

Mint only against deposited shares; burn only on redemption. If supply ever exceeds reserves, the token is fractionally backed and the whole product fails (the xStocks failure mode, Lesson 7). Protecting this invariant is the core engineering job.

The full architecture

Notice: the clever on-chain part is small; the off-chain custody, controller, KYC, and attestation are the bulk of the system — and every boundary arrow is a trust/integration point (Lesson 5).

The token design: Token-2022 extensions, mapped to what you know

Here is where your ERC-3643 knowledge transfers directly. Each Solana extension is a regulated-security control you already understand by another name:²

The whole permissioned-security pattern you learned on Ethereum exists on Solana — just assembled from program-level extensions rather than a suite of separate contracts. Same music, different instrument. (Caveat from Lesson 7: transfer hooks and confidential transfers don't compose, so SPCX trades privacy for the hook.)

The mint pipeline — defending the invariant

// The secure-mint guard, conceptually
fn mint(amount) {
  require(token.supply + amount <= proofOfReserve.custodied_shares); // ① invariant
  require(recipient.kyc_thawed);                                   // ② WHO
  // only now token.mint_to(recipient, amount);
}

The redemption pipeline — "minting in reverse"

Redemption is what makes SPCX a claim, not a bet (Lesson 7). The holder burns SPCX; the broker-dealer delivers the real share via ACATS/DTCC, transferable to any standard brokerage.⁵ The hard part is atomicity across two worlds: the on-chain burn and the off-chain delivery aren't natively atomic, so you need a settlement protocol (escrow + attestation, or a Delivery-vs-Payment design) so a holder can't burn and get nothing — or get a share without burning.⁶

The keys: your crown jewels

Every power above is a key (Lesson 6). Whoever holds it can mint, freeze, or claw back SPCX. This is the highest-stakes part of the design:

The Marketnode lens & interview angles

• Backing is an invariant, not a label. The engineering that matters is the supply≡reserves guard and the proof-of-reserve feed. That's the credibility difference between SPCX and a product that "never arrived."
• Solana ≠ a different planet. Your team's ERC-3643 knowledge ports to Token-2022 extensions almost concept-for-concept. Hire for the model, not the syntax.
• Interview probe (senior): "How do you guarantee a tokenized-equity issuer can never mint more tokens than shares it holds?" Listen for proof-of-reserve wired into mint logic, segregated custody, and independent attestation — not "we'll reconcile nightly."
• Interview probe (security): "Your token has a permanent-delegate/clawback key. Justify it to a regulator and secure it from an attacker." Tests both the compliance rationale and the key-governance instinct.

Primary source

For the backed-token mechanics: MetaMask — How tokenized securities work and Chainlink — Proof of Reserve. For the Solana primitives: Permanent Delegate, Default Account State, and Delivery-vs-Payment on Solana.