Full lesson

sca

Solana Commerce Application

What it does

From the project README:

A Solana blockchain tool designed as Proof-Of-Concept, to illustrate how blockchain can be used to tackle real world problems. The particular problem we are addressing here is the lack of safety when selling items over the internet.

Original

Sergio-Flores-Torres/sca

SuperStack fork

Blockchains/sca @ 699122f

Stars

0

Last push (original)

2026-09-06

Languages

TypeScript, Rust, Shell

Detected stack

Native Rustweb3.js

Categories

Other

Licence

MIT

Architecture

31 source files. By extension: .ts ×25, .rs ×6.

❌ Does not build as-is, checked 2026-11-02 Tested on 2026-11-02: full log results.json

Build it yourself: step-by-step guide

Every command below was run on 2026-11-02 by tests/run_fork.py against the pinned commit, and the results come from that run. The full output is in the committed log.

1. Prerequisites (versions we tested with)

• Rust: rustc 1.99.1 (58cf8f9c3 2026-10-13)
• Solana CLI (Agave): solana-cli 1.18.17 (src:c027cfc3; feat:4215500110, client:Agave)
• Node.js: v24.22.1
• npm: 11.21.1
• pnpm: 10.34.6

2. Clone at the tested commit

git clone https://github.com/Blockchains/sca.git && cd sca
git checkout 699122f3f3d117d763ed286227ed026b9031d3c2

3. Configure

No environment file is needed.

7. Deploy to a local validator

8. Run and exercise it

Proof: program IDs and transactions

• sca: FfqDdvxk1VJbc9XGDXqMRetnXWEpC2qZoKDDPisVUXSU (local validator)

Deploy to devnet (free)

solana config set --url devnet
solana airdrop 2   # or https://faucet.solana.com
anchor deploy --provider.cluster devnet   # native: solana program deploy target/deploy/<name>.so
# point the frontend RPC env var at https://api.devnet.solana.com

Notes: Native (non-Anchor) program. The repo's hardcoded program ID is swapped for a fresh local keypair, and the Pinata upload is stubbed because it needs a Pinata JWT.

How it works

Every instruction handler in the program, with the accounts struct it validates. Each link points to the line at the pinned commit.

Extend it

1. Add an integration test that runs the main flow end to end and asserts every account state change.
2. Add a negative test: call each instruction with the wrong signer or account and check that it fails.
3. Add an event (emit!) to each state-changing instruction and subscribe to it from the client.
4. Replace any unchecked AccountInfo with typed accounts plus has_one/seeds constraints.
5. Make the frontend read the cluster from an env var, deploy it to GitHub Pages and point it at your devnet program.
6. Wire the build into CI by copying this site's verify-forks workflow.

Key code, explained

Excerpts chosen automatically where the code uses the most Solana concepts, pinned to the fork's commit.

	// Check SELLER account validity	is_signed_by_writable_account(seller_account_info, "SELLER account is not a valid account.")?;		// Get the OPERATIONACCOUNT account 	let operation_account_info = next_account_info(accounts_iter)?; 	// Check OPERATIONACCOUNT account validity	is_owned_and_writable(program_id, operation_account_info, "OPERATIONACCOUNT account is not a valid account.")?;  	// ================ Enforce configuration rules section  	// Get the estimated creation time for tracking operation validity, etc	// This is in unixepoch seconds; in tests the time is days off, so it needs to be validated further 	let unix_timestamp = match Clock::get() {		Err(_e) => {			msg!("WARN: Could not get a valid Clock. Using zero time.");			0		},		Ok(clock) => clock.unix_timestamp,	}; 	// Load the account so that we can read it and/or modify it.

How to run, build and test

These commands come from the repo's own manifests (package.json scripts, Anchor.toml, Cargo, go.mod, Makefile). Check the README for prerequisites and environment variables.

What you could build from it

• Fork the SuperStack copy and extend it within the Other gaps listed on the idea page.
• Learn the pattern first: Program Derived Addresses (PDAs)
• Learn the pattern first: Cross-Program Invocations (CPIs)