Home • Why it works • Technical • FSC Architecture • AI & Autonomy • Past & Post

FSC Architecture

This page is for builders: how FairShareCoin is structured, where constraints live, and how the system scales.

Scope & Status

Current stage: alpha (local-first)
Architecture direction is defined; components are being hardened iteratively
Identity verifier model is planned around ICAO standards; production rollout is phased
When wording differs from implementation, fairsharecoin/foundation is authoritative

System Model

FSC combines three layers: identity-anchored issuance, transaction routing, and auditable ledger state. The key design goal is simple: constrain privilege at issuance, then let value move through real usage.

Issuance layer: uniqueness checks for one-person base issuance eligibility
Transfer layer: signed messages routed through nodes
State layer: validated balances + history commitments for integrity and recovery

Transfer Pipeline (Email-Like UX, Cryptographic Core)

User experience is intentionally message-like: choose recipient, amount, send. Under the hood, each transfer follows a strict verification path.

Client builds signed transfer intent
Node validates signature, limits, and state preconditions
Transaction is accepted/rejected deterministically
Ledger state updates and propagates across peers
Recipient view updates after confirmation

Node Roles

Full nodes: validation, state integrity, ledger serving, and policy enforcement
Relay/partial nodes: routing and targeted verification roles
Light clients: wallet-facing clients using compact state proofs/endpoints

Identity Source & COINMINT_ID Direction

FSC’s uniqueness anchor is COINMINT_ID: a deterministic identity-derived identifier used for issuance eligibility, not public identity disclosure.

Design intent

Use ICAO-compliant document verification flow when live
Derive deterministic identity key from stable identity attributes
Exclude unstable fields (e.g. expiry date, nationality, sex marker) from uniqueness basis
Use public namespace separator (“public pepper”) for system-domain separation

Renewal continuity

Passport renewal should preserve identity continuity and prevent duplicate issuance. The model re-verifies under the same uniqueness logic and links continuity without reminting extra base issuance.

See technical identity section

KEYMINT Lifecycle & Signing Hygiene

KEYMINT is the operational signing layer: it reduces long-term key exposure and improves key rotation ergonomics.

KEYMINT: transfer-capable signing key derived/linked under wallet authority
CLEARKEYS: invalidates active transfer keys (e.g., compromise response)
KEYREMINT: issues replacement transfer keys without changing ownership
Era markers: optional “start/end” checkpoints for key generations, so nodes can sync and verify key history faster

Wallet Recovery

Recovery is continuity-based, not “new account minting.” If credentials are lost, holder re-establishes control via verified continuity and relinks operational credentials.

User generates new operational credentials
Continuity proof is submitted under identity anchor policy
Node verifies linkage against existing wallet authority
Access is restored without issuing extra FSC

Abuse Controls

Rate-limits by wallet behavior and endpoint class
Recipient-side filtering controls
No “global silence switch” by default architecture direction
Deterministic validation path to reduce discretionary enforcement

Scaling: Pruning, Snapshots, and Sharding Direction

FSC scaling strategy is to keep full verification possible while reducing default storage burden. Pruning and signed snapshots reduce historical overhead; sharding is a modular expansion path.

Estimated Storage with Pruning (No Sharding)

User Base	Estimated Storage	Notes
1 million	~5 GB	Global ledger, compact metadata model
21 million	~105 GB	Consumer-hardware feasible
100 million	~500 GB	Pruned metadata heavy use case
1 billion	~5 TB	Infrastructure-grade full participation
10 billion	~50 TB	Global scale, strongly benefits from sharding

Estimated Storage per Node with 100 Shards

User Base	Storage per Shard
1 million	~50 MB
21 million	~1.05 GB
100 million	~5 GB
1 billion	~50 GB
10 billion	~500 GB

Indicative Network Resource Footprint

Order-of-magnitude estimates (assuming ~10 transfers/user/year) suggest FSC can remain lightweight relative to many high-throughput systems.

User Base	Yearly Transactions	Total Storage	Bandwidth per Full Node (year)	CPU per Full Node (year)
1 million	10 million	~2.5 GB	~256 MB	~33 seconds
21 million	210 million	~52.5 GB	~5.4 GB	~11.6 minutes
100 million	1 billion	~250 GB	~25 GB	~55 minutes
1 billion	10 billion	~2.5 TB	~250 GB	~9.2 hours
10 billion	100 billion	~25 TB	~2.5 TB	~3.8 days

Architecture goal: keep fairness constraints strict, implementation simple, and participation feasible on ordinary hardware wherever possible.

From identity to infrastructure, every layer exists to protect one core rule: one being, one base share.

Top
AI & Autonomy →
← Back to Technical