Skip to content

Commit 9744bee

Browse files
TheNewAutonomyTheNewAutonomy
committed
Add business use cases and use official logo
Add partner-researched business use case pages (authentication, timestamping, provenance, supply chain, waste management), plus a brand-assets page. Update navbar to use the official Catalyst logo from the Community media pack. Made-with: Cursor
1 parent 36d8425 commit 9744bee

9 files changed

Lines changed: 260 additions & 1 deletion

File tree

‎site/docs/contributing/style-guide.md‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,14 @@ Be consistent after defining once:
2727
- Commands must be copy/pasteable.
2828
- Include **expected output snippets** when operators/users need to know what “success” looks like.
2929

30+
## Screenshots and images
31+
32+
- Store screenshots under `site/static/img/screenshots/` and link them like:
33+
- `![Alt text](/img/screenshots/<file>.png)`
34+
- Prefer **cropped** screenshots that show only the relevant UI.
35+
- Do not include secrets in screenshots (keys, recovery phrases, auth tokens, IPs if sensitive).
36+
- Prefer official logos from the **[media pack](https://github.com/catalyst-network/Community/tree/master/media-pack)**.
37+
3038
## Security and safety requirements
3139

3240
- Never instruct users to paste private keys into websites, issue trackers, logs, or support chats.

‎site/docs/overview/brand-assets.md‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
sidebar_position: 1
3+
title: Brand assets (logos)
4+
---
5+
6+
Official Catalyst logo files live in the community media pack:
7+
8+
- [Catalyst media pack](https://github.com/catalyst-network/Community/tree/master/media-pack)
9+
10+
## How to use in docs
11+
12+
Prefer:
13+
14+
- **SVG** where available (best scaling), otherwise
15+
- **PNG** for screenshots and UI surfaces.
16+
17+
## Notes
18+
19+
- If you add screenshots, use the official logo assets rather than screenshots of the website.
20+
- Keep logos unmodified (no recolors/stretching) unless brand guidelines say otherwise.
21+

‎site/docs/use-cases/business/_category_.json‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
{
2+
"label": "Business use cases",
3+
"position": 20,
4+
"link": {
5+
"type": "generated-index",
6+
"title": "Business use cases",
7+
"description": "Partner-researched use cases for businesses. These are older research docs; treat them as conceptual starting points."
8+
}
9+
}
10+

‎site/docs/use-cases/business/authentication.md‎

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
---
2+
title: Authentication (email trust & anti-impersonation)
3+
sidebar_position: 1
4+
---
5+
6+
:::note
7+
This page is based on an **older partner research PDF** and is provided as a conceptual use case. It describes “Timescribe” style flows that are **not shipped as a built-in Catalyst product** today.
8+
:::
9+
10+
## Problem
11+
12+
Email impersonation and phishing are effective because recipients cannot reliably verify the sender’s identity. Even when organizations adopt anti-malware tools, spoofing and Business Email Compromise can still succeed.
13+
14+
## What Catalyst enables (conceptually)
15+
16+
- **Verifiable signatures**: messages can carry a signature that recipients can verify against an organization identity key.
17+
- **Immutable audit trail**: a tamper-resistant record of “message fingerprints” can help prove timing and provenance.
18+
- **Automation**: identity proofs can be generated automatically by a mail gateway or client plugin.
19+
20+
## A practical architecture
21+
22+
1) **Organization identity** is established (KYC/verification outside the chain, then publish a public key + metadata).
23+
2) Outbound email is processed by:
24+
- a **mail gateway** (recommended), or
25+
- a **client plugin**
26+
3) The gateway:
27+
- hashes the email (or selected fields),
28+
- signs the hash with the org key,
29+
- optionally timestamps the signed hash on-chain.
30+
4) Recipients verify:
31+
- the signature matches the org key,
32+
- the timestamp/audit entry exists (optional).
33+
34+
## What’s required (today)
35+
36+
This use case requires application-layer work:
37+
38+
- an email gateway/plugin
39+
- a registry of “known org keys” (could be on-chain via contracts, or off-chain with on-chain anchoring)
40+
- UX that makes “verified sender” obvious
41+
42+
## Verify
43+
44+
- Run a demo where a signed email is accepted and a forged email is flagged.
45+
- Store only **hashes** on-chain (never store email contents).
46+
47+
## Links
48+
49+
- **Catalyst website**: `https://catalystnet.org/`
50+
- **Docs**: `https://docs.catalystnet.org/`
51+

‎site/docs/use-cases/business/food-provenance.md‎

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
---
2+
title: Food provenance (traceability & trust)
3+
sidebar_position: 3
4+
---
5+
6+
:::note
7+
Based on an older partner research PDF. Treat as a conceptual use case (not a shipped Catalyst app).
8+
:::
9+
10+
## Problem
11+
12+
Consumers and regulators increasingly want trustworthy answers to:
13+
14+
- where was this product produced?
15+
- when was it harvested/processed?
16+
- did it meet handling/storage standards?
17+
18+
Paper-based or siloed databases make end-to-end provenance hard to verify and easy to forge.
19+
20+
## What Catalyst enables (conceptually)
21+
22+
- **Shared source of truth** across multiple parties (producer → logistics → retailer)
23+
- **Non-forgeable attestations**: each party signs the data they add
24+
- **Auditability**: a tamper-evident timeline of custody and claims
25+
26+
## A practical architecture
27+
28+
1) At harvest/production, create a **batch identifier** (or token) for the lot.
29+
2) At each handoff, write an attestation:
30+
- who handled it (identity key)
31+
- what happened (event type)
32+
- when/where (timestamp, location)
33+
- optional sensor evidence (IoT readings) stored off-chain, anchored by hash
34+
3) End users scan a QR code and see:
35+
- the provenance timeline
36+
- the signed claims
37+
38+
## Verify
39+
40+
- Pick a product batch and trace it end-to-end.
41+
- Show that a forged “producer claim” cannot be verified without the producer key.
42+

‎site/docs/use-cases/business/supply-chain.md‎

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
title: Supply chain resilience (visibility & automation)
3+
sidebar_position: 4
4+
---
5+
6+
:::note
7+
Based on an older partner research PDF written during COVID-era supply chain disruption. Treat as a conceptual use case (not a shipped Catalyst app).
8+
:::
9+
10+
## Problem
11+
12+
Supply chains are complex, cross-company systems. During disruptions, organizations need:
13+
14+
- real-time visibility into inventory and logistics
15+
- shared, verifiable data across many parties
16+
- automation to reduce manual paperwork and reconciliation
17+
18+
## What Catalyst enables (conceptually)
19+
20+
- **End-to-end visibility** via a shared ledger of events
21+
- **Reduced “cost of trust”** by using signed, tamper-evident records
22+
- **Process automation** via smart contracts (e.g., settlement on delivery milestones)
23+
- **Interoperability** by anchoring existing systems’ outputs (don’t replace everything at once)
24+
25+
## A practical architecture
26+
27+
1) Model the chain as a set of signed events (manufacture, ship, clear customs, receive).
28+
2) Use off-chain systems for high-volume data, but anchor commitments (hashes) on-chain.
29+
3) Trigger workflows (alerts, settlements, compliance checks) from verified events.
30+
31+
## Verify
32+
33+
- Demonstrate a trace for a shipment with signed handoffs.
34+
- Demonstrate automated settlement triggers only when the required events exist.
35+

‎site/docs/use-cases/business/timestamping.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
title: Timestamping (prove data existed at a time)
3+
sidebar_position: 2
4+
---
5+
6+
:::note
7+
Based on an older partner research PDF. Treat as a conceptual use case (not a shipped Catalyst app).
8+
:::
9+
10+
## Problem
11+
12+
For IP, legal, and compliance workflows, you often need proof that:
13+
14+
- a document existed at a specific time
15+
- the document has not been modified since
16+
- the proof remains available long-term
17+
18+
## What Catalyst enables (conceptually)
19+
20+
- **Tamper-evident proofs** by anchoring a document hash on-chain
21+
- **Attribution** by signing the hash with an identity key
22+
- **Persistence** via replication across nodes
23+
24+
## Steps (conceptual flow)
25+
26+
1) Compute a cryptographic hash of the file (the “fingerprint”).
27+
2) Sign the hash with the user/org key.
28+
3) Submit the signed hash + timestamp metadata on-chain (or store off-chain and anchor a commitment on-chain).
29+
4) Later, to verify:
30+
- recompute hash
31+
- verify the signature
32+
- verify the on-chain timestamp/commitment exists
33+
34+
## Verify
35+
36+
- Demonstrate that changing a single byte in the document changes the hash.
37+
- Demonstrate the signature fails if the proof is tampered with.
38+
39+
## Security
40+
41+
Never publish sensitive document contents on-chain. Publish only:
42+
43+
- hashes / commitments
44+
- minimal metadata (and only if non-sensitive)
45+

‎site/docs/use-cases/business/waste-management.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
---
2+
title: Waste management (recycling incentives & accountability)
3+
sidebar_position: 5
4+
---
5+
6+
:::note
7+
Based on an older partner research PDF. Treat as a conceptual use case (not a shipped Catalyst app).
8+
:::
9+
10+
## Problem
11+
12+
Waste management faces challenges in:
13+
14+
- tracking materials through collection → sorting → processing
15+
- proving correct disposal/recycling
16+
- incentivizing consumer behavior (deposit/return schemes)
17+
- holding parties accountable for mishandling
18+
19+
## What Catalyst enables (conceptually)
20+
21+
- **Traceability**: link physical items/batches to digital identifiers (QR/dot codes).
22+
- **Accountability**: each participant signs actions (collection, transfer, processing).
23+
- **Incentives**: programmatic rewards for verified recycling events.
24+
- **Auditability**: regulators and partners can verify claims without trusting a single database.
25+
26+
## A practical architecture
27+
28+
1) Assign a code to a bottle/item (or a batch/container).
29+
2) When an item is deposited:
30+
- scan item + bin
31+
- record an event
32+
- issue a reward (optional)
33+
3) When waste is transferred:
34+
- record custody handoffs
35+
4) At the processing facility:
36+
- verify the material meets criteria
37+
- finalize proofs and settlement/rewards
38+
39+
## Verify
40+
41+
- Run a pilot with a small set of bins and a recycling partner.
42+
- Ensure the system records only the minimum needed data (privacy-by-design).
43+

‎site/docusaurus.config.ts‎

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -91,7 +91,11 @@ const config: Config = {
9191
title: 'Catalyst Docs',
9292
logo: {
9393
alt: 'Catalyst Docs',
94-
src: 'img/logo.svg',
94+
// Prefer the official logo from the Catalyst media pack.
95+
// Source: https://github.com/catalyst-network/Community/tree/master/media-pack
96+
src: 'https://raw.githubusercontent.com/catalyst-network/Community/master/media-pack/logo-black.png',
97+
srcDark:
98+
'https://raw.githubusercontent.com/catalyst-network/Community/master/media-pack/logo-white.png',
9599
},
96100
items: [
97101
{

0 commit comments

Comments
 (0)