proofnest 0.2.0__py3-none-any.whl → 0.2.1__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- PKG-INFO +1 -1
- __init__.py +1 -1
- {proofnest-0.2.0.dist-info → proofnest-0.2.1.dist-info}/METADATA +1 -1
- proofnest-0.2.1.dist-info/RECORD +21 -0
- pyproject.toml +18 -1
- .planning/PROJECT.md +0 -99
- .planning/ROADMAP.md +0 -152
- .planning/STATE.md +0 -91
- .planning/config.json +0 -18
- .planning/quick/001-artikkel-proofnest-vs-moltbook/001-PLAN.md +0 -190
- .planning/quick/001-artikkel-proofnest-vs-moltbook/001-SUMMARY.md +0 -85
- .planning/quick/002-twitter-thread-proofnest-moltbook/002-PLAN.md +0 -53
- .planning/quick/002-twitter-thread-proofnest-moltbook/002-SUMMARY.md +0 -58
- .planning/research/ARCHITECTURE.md +0 -585
- .planning/research/FEATURES.md +0 -192
- .planning/research/PITFALLS.md +0 -487
- .planning/research/STACK.md +0 -378
- .planning/research/SUMMARY.md +0 -385
- AUDIT_GPT4o_2026-02-03.md +0 -65
- AUDIT_GPT52_2026-02-03.md +0 -137
- AUDIT_GPT52_FULL_2026-02-03.md +0 -116
- AUDIT_GPT52_ROUND2_2026-02-03.md +0 -79
- README.md +0 -132
- content/articles/proofnest-vs-moltbook-en.md +0 -165
- content/social/twitter-thread-001.md +0 -168
- proofnest-0.2.0.dist-info/RECORD +0 -45
- tests/test_api.py +0 -270
- tests/test_did_registry.py +0 -206
- tests/test_proof.py +0 -279
- tests/test_staking.py +0 -174
- {proofnest-0.2.0.dist-info → proofnest-0.2.1.dist-info}/WHEEL +0 -0
- {proofnest-0.2.0.dist-info → proofnest-0.2.1.dist-info}/entry_points.txt +0 -0
- {proofnest-0.2.0.dist-info → proofnest-0.2.1.dist-info}/licenses/LICENSE +0 -0
AUDIT_GPT52_FULL_2026-02-03.md
DELETED
|
@@ -1,116 +0,0 @@
|
|
|
1
|
-
# PROOFNEST CORE - GPT-5.2 Full Codebase Audit
|
|
2
|
-
|
|
3
|
-
**Kuupäev:** 2026-02-03
|
|
4
|
-
**Mudel:** GPT-5.2 (OpenAI)
|
|
5
|
-
**Staatus:** ✅ KÕIK P0/P1 PARANDATUD
|
|
6
|
-
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
## ✅ TOP 5 BUGID (PRIORITEERITUD) - PARANDATUD
|
|
10
|
-
|
|
11
|
-
### 1. BFT Quorum Threshold VALE (SAFETY BREAK) ✅ PARANDATUD
|
|
12
|
-
```python
|
|
13
|
-
# consensus.py ~l.180
|
|
14
|
-
quorum_threshold = max(1, math.ceil(n * self.threshold_ratio)) # FIXED!
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
### 2. Vote Signing Timestamp Mismatch ✅ PARANDATUD
|
|
18
|
-
```python
|
|
19
|
-
# consensus.py ~l.54-65
|
|
20
|
-
vote_timestamp = int(time.time()) # SALVESTA ÜKS KORD
|
|
21
|
-
message = f"{proof_id}:{vote}:{vote_timestamp}".encode()
|
|
22
|
-
return Vote(..., timestamp=vote_timestamp) # SAMA timestamp!
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
### 3. Network Messages UNAUTHENTICATED ✅ PARANDATUD
|
|
26
|
-
```python
|
|
27
|
-
# network.py - Message.sign() ja Message.verify() lisatud
|
|
28
|
-
# GossipProtocol.receive() kontrollib allkirja enne töötlemist
|
|
29
|
-
# Domain separation: "PROOFNEST:NETWORK:v1:" prefix
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
### 4. Consensus Persistence LOSSY ✅ PARANDATUD
|
|
33
|
-
```python
|
|
34
|
-
# storage.py - save_proof() nüüd salvestab:
|
|
35
|
-
consensus_json = {
|
|
36
|
-
"state": ...,
|
|
37
|
-
"quorum_threshold": ...,
|
|
38
|
-
"validators": [...], # Täielik validaatorite nimekiri
|
|
39
|
-
"signatures": [...] # Täielikud allkirjad auditiks
|
|
40
|
-
}
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
### 5. SQLite Foreign Keys OFF ✅ PARANDATUD
|
|
44
|
-
```python
|
|
45
|
-
# storage.py _connect()
|
|
46
|
-
conn.execute("PRAGMA foreign_keys=ON") # Lisatud!
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
---
|
|
50
|
-
|
|
51
|
-
## Consensus.py - EI OLE HOTSTUFF-2!
|
|
52
|
-
|
|
53
|
-
GPT-5.2 märkis et praegune implementatsioon **ei ole HotStuff-2**:
|
|
54
|
-
|
|
55
|
-
| HotStuff-2 Nõue | Praegune Olek |
|
|
56
|
-
|-----------------|---------------|
|
|
57
|
-
| View numbers | ❌ PUUDU |
|
|
58
|
-
| Leader election | ❌ PUUDU |
|
|
59
|
-
| Proposal chaining | ❌ PUUDU |
|
|
60
|
-
| Justify QC | ❌ PUUDU |
|
|
61
|
-
| Lock rules | ❌ PUUDU |
|
|
62
|
-
| View change | ❌ PUUDU |
|
|
63
|
-
| Pacemaker | ❌ PUUDU |
|
|
64
|
-
|
|
65
|
-
**Praegu on:** "centralized quorum voting gadget" - töötab ühe masina peal, aga mitte distributed BFT.
|
|
66
|
-
|
|
67
|
-
---
|
|
68
|
-
|
|
69
|
-
## Network.py - Eclipse Attack Vectors
|
|
70
|
-
|
|
71
|
-
| Risk | Staatus |
|
|
72
|
-
|------|---------|
|
|
73
|
-
| No peer identity verification | 🔴 KRIITILINE |
|
|
74
|
-
| No Sybil protection | 🔴 KRIITILINE |
|
|
75
|
-
| Blacklist address-only | 🟡 NÕRK |
|
|
76
|
-
| No message signing | 🔴 KRIITILINE |
|
|
77
|
-
| No validator authorization | 🔴 KRIITILINE |
|
|
78
|
-
|
|
79
|
-
---
|
|
80
|
-
|
|
81
|
-
## API.py - Auth Model
|
|
82
|
-
|
|
83
|
-
| Aspect | Staatus |
|
|
84
|
-
|--------|---------|
|
|
85
|
-
| Authentication | ✅ LISATUD (X-API-Key header) |
|
|
86
|
-
| Rate limiting | ❌ PUUDU |
|
|
87
|
-
| CORS | ⚠️ Allow all |
|
|
88
|
-
| Private keys in memory | ⚠️ Custody risk |
|
|
89
|
-
|
|
90
|
-
---
|
|
91
|
-
|
|
92
|
-
## Tegevuskava
|
|
93
|
-
|
|
94
|
-
### P0 - KOHE ✅ VALMIS
|
|
95
|
-
- [x] Fix quorum threshold: `ceil(2n/3)` ✅
|
|
96
|
-
- [x] Fix timestamp mismatch in Vote ✅
|
|
97
|
-
- [x] Add PRAGMA foreign_keys=ON ✅
|
|
98
|
-
|
|
99
|
-
### P1 - Järgmine ✅ VALMIS
|
|
100
|
-
- [x] Network message signing ✅
|
|
101
|
-
- [x] Store full QC with signatures ✅
|
|
102
|
-
- [x] API authentication ✅
|
|
103
|
-
|
|
104
|
-
### P2 - Hiljem (kui distributed BFT vaja)
|
|
105
|
-
- [ ] View numbers + leader election
|
|
106
|
-
- [ ] Proposal chaining
|
|
107
|
-
- [ ] Lock rules
|
|
108
|
-
- [ ] View change / pacemaker
|
|
109
|
-
- [ ] Peer identity verification
|
|
110
|
-
- [ ] Rate limiting
|
|
111
|
-
|
|
112
|
-
---
|
|
113
|
-
|
|
114
|
-
## GPT-5.2 Kokkuvõte
|
|
115
|
-
|
|
116
|
-
> "It's not HotStuff-2; it's a centralized quorum voting gadget. For safety/liveness in a distributed BFT setting you need: views + leader, proposal chaining, justify QC, lock rules, view change (pacemaker), correct 2f+1 quorums, validator-set epochs, anti-replay, and network authentication."
|
AUDIT_GPT52_ROUND2_2026-02-03.md
DELETED
|
@@ -1,79 +0,0 @@
|
|
|
1
|
-
# PROOFNEST CORE - GPT-5.2 Deep Code Audit (Round 2)
|
|
2
|
-
|
|
3
|
-
**Kuupäev:** 2026-02-03
|
|
4
|
-
**Mudel:** GPT-5.2 (OpenAI)
|
|
5
|
-
**Staatus:** 🔴 KRIITILISED BUGID LEITUD
|
|
6
|
-
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
## 🔴 KRIITILISED BUGID (KOHE PARANDADA)
|
|
10
|
-
|
|
11
|
-
### 1. `except ImportError: return True` - TURVA BYPASS
|
|
12
|
-
```python
|
|
13
|
-
except ImportError:
|
|
14
|
-
return True # Fallback for testing
|
|
15
|
-
```
|
|
16
|
-
**RISK:** Kui crypto backend puudub, KÕIK allkirjad valideeruvad!
|
|
17
|
-
**PARANDUS:** `return False` või `raise RuntimeError("Crypto backend required")`
|
|
18
|
-
|
|
19
|
-
### 2. Fake signatures fallback
|
|
20
|
-
**RISK:** Testimise fallback loob võltsallkirju mis pole krüptograafilised
|
|
21
|
-
**PARANDUS:** Raise exception kui crypto puudub
|
|
22
|
-
|
|
23
|
-
### 3. DID Registry `update()` on autentimata
|
|
24
|
-
**RISK:** Igaüks saab asendada DID dokumente
|
|
25
|
-
**PARANDUS:** Nõua allkirja AUTHENTICATION võtmelt
|
|
26
|
-
|
|
27
|
-
### 4. Float math voting_power's
|
|
28
|
-
**RISK:** Nondeterminism konsensuses
|
|
29
|
-
**PARANDUS:** Integer/fixed-point math ainult
|
|
30
|
-
|
|
31
|
-
---
|
|
32
|
-
|
|
33
|
-
## 🟡 OLULISED PROBLEEMID
|
|
34
|
-
|
|
35
|
-
### Hybrid Signature Format
|
|
36
|
-
- Pole self-describing (versioon, pikkused puudu)
|
|
37
|
-
- Pole domain separation
|
|
38
|
-
- Key ID puudub allkirjast
|
|
39
|
-
|
|
40
|
-
### DID Registry
|
|
41
|
-
- Rollback rünnakud võimalikud (pole prev_hash)
|
|
42
|
-
- Key ID collision (len-based)
|
|
43
|
-
- In-place mutation (shared state)
|
|
44
|
-
|
|
45
|
-
### Staking
|
|
46
|
-
- Currency mixing (USD + POINTS)
|
|
47
|
-
- Slashing priority vale (BONDED ignoreeritud)
|
|
48
|
-
- Delegated stake reeglid puudu
|
|
49
|
-
|
|
50
|
-
---
|
|
51
|
-
|
|
52
|
-
## Tegevuskava (Prioriteet)
|
|
53
|
-
|
|
54
|
-
- [x] ~~Lisa hybrid signatures~~ → LOODUD aga vajab parandusi
|
|
55
|
-
- [x] ~~Lisa DID Registry~~ → LOODUD aga vajab parandusi
|
|
56
|
-
- [x] ~~Lisa Staking~~ → LOODUD aga vajab parandusi
|
|
57
|
-
|
|
58
|
-
### P0 - KOHE
|
|
59
|
-
- [ ] Eemalda `return True` fallbackid
|
|
60
|
-
- [ ] Lisa `raise` kui crypto puudub
|
|
61
|
-
- [ ] DID update autentimine
|
|
62
|
-
|
|
63
|
-
### P1 - Järgmine
|
|
64
|
-
- [ ] Canonical signature format (version + alg_id + lengths)
|
|
65
|
-
- [ ] Domain separation tags
|
|
66
|
-
- [ ] Integer voting power math
|
|
67
|
-
- [ ] Prev_hash rollback protection
|
|
68
|
-
|
|
69
|
-
### P2 - Hiljem
|
|
70
|
-
- [ ] Key ID signature binding
|
|
71
|
-
- [ ] Slashing priority fix
|
|
72
|
-
- [ ] Delegated stake rules
|
|
73
|
-
- [ ] Recovery process spec
|
|
74
|
-
|
|
75
|
-
---
|
|
76
|
-
|
|
77
|
-
## GPT-5.2 Täisanalüüs
|
|
78
|
-
|
|
79
|
-
[Täielik vastus salvestatud eraldi]
|
README.md
DELETED
|
@@ -1,132 +0,0 @@
|
|
|
1
|
-
# PROOFNEST CORE
|
|
2
|
-
|
|
3
|
-
**Kollektiivse Intelligentsi Eksistentsi Protokoll**
|
|
4
|
-
|
|
5
|
-
Python SDK for PROOFNEST - the verification layer for everything that exists.
|
|
6
|
-
|
|
7
|
-
## Quick Start
|
|
8
|
-
|
|
9
|
-
```bash
|
|
10
|
-
# Start API server
|
|
11
|
-
python3 api.py
|
|
12
|
-
|
|
13
|
-
# Use CLI
|
|
14
|
-
python3 cli.py stats
|
|
15
|
-
python3 cli.py identity create
|
|
16
|
-
python3 cli.py proof create --claim "My claim" --issuer did:pn:agent:xxx
|
|
17
|
-
```
|
|
18
|
-
|
|
19
|
-
## Architecture
|
|
20
|
-
|
|
21
|
-
```
|
|
22
|
-
PROOF = claim + evidence + identity + signature + time + anchor + consensus
|
|
23
|
-
|
|
24
|
-
┌─────────────────────────────────────────────────────────────┐
|
|
25
|
-
│ PROOFNEST CORE │
|
|
26
|
-
├─────────────────────────────────────────────────────────────┤
|
|
27
|
-
│ cli.py │ Command line interface │
|
|
28
|
-
│ api.py │ FastAPI REST API (port 8200) │
|
|
29
|
-
├─────────────────────────────────────────────────────────────┤
|
|
30
|
-
│ proof.py │ PROOF primitive, Identity, Evidence │
|
|
31
|
-
│ consensus.py │ HotStuff-2 BFT, Validator, Vote, QC │
|
|
32
|
-
│ anchor.py │ Bitcoin anchoring (OpenTimestamps) │
|
|
33
|
-
│ network.py │ P2P gossip protocol │
|
|
34
|
-
│ storage.py │ SQLite persistence │
|
|
35
|
-
│ blockchain.py │ Go blockchain RPC client │
|
|
36
|
-
└─────────────────────────────────────────────────────────────┘
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
## API Endpoints
|
|
40
|
-
|
|
41
|
-
| Method | Endpoint | Description |
|
|
42
|
-
|--------|----------|-------------|
|
|
43
|
-
| POST | `/v1/identities` | Create DID:PN identity |
|
|
44
|
-
| GET | `/v1/identities` | List identities |
|
|
45
|
-
| POST | `/v1/proofs` | Create PROOF |
|
|
46
|
-
| GET | `/v1/proofs/{id}` | Get PROOF |
|
|
47
|
-
| POST | `/v1/proofs/{id}/verify` | Verify PROOF |
|
|
48
|
-
| POST | `/v1/validators` | Add validator |
|
|
49
|
-
| GET | `/v1/validators` | List validators |
|
|
50
|
-
| POST | `/v1/proofs/{id}/submit-consensus` | Submit to consensus |
|
|
51
|
-
| POST | `/v1/proofs/{id}/vote` | Vote on PROOF |
|
|
52
|
-
| POST | `/v1/proofs/{id}/anchor` | Anchor to Bitcoin |
|
|
53
|
-
| POST | `/v1/proofs/{id}/chain-anchor` | Anchor to blockchain |
|
|
54
|
-
| GET | `/v1/proofs/{id}/chain-verify` | Verify on blockchain |
|
|
55
|
-
| GET | `/v1/chain/status` | Blockchain status |
|
|
56
|
-
| GET | `/v1/stats` | System statistics |
|
|
57
|
-
| GET | `/health` | Health check |
|
|
58
|
-
|
|
59
|
-
## PROOF Types
|
|
60
|
-
|
|
61
|
-
- `CLAIM` - Generic assertion
|
|
62
|
-
- `IDENTITY` - Identity declaration
|
|
63
|
-
- `WORK` - Work completion proof
|
|
64
|
-
- `DECISION` - Decision record
|
|
65
|
-
- `TRUTH` - Verified truth
|
|
66
|
-
- `VALUE` - Value transfer
|
|
67
|
-
|
|
68
|
-
## Example: Full Flow
|
|
69
|
-
|
|
70
|
-
```python
|
|
71
|
-
import httpx
|
|
72
|
-
|
|
73
|
-
API = "http://localhost:8200"
|
|
74
|
-
|
|
75
|
-
# 1. Create identity
|
|
76
|
-
identity = httpx.post(f"{API}/v1/identities", json={
|
|
77
|
-
"identity_type": "agent"
|
|
78
|
-
}).json()
|
|
79
|
-
did = identity["did"]
|
|
80
|
-
|
|
81
|
-
# 2. Create PROOF
|
|
82
|
-
proof = httpx.post(f"{API}/v1/proofs", json={
|
|
83
|
-
"issuer_did": did,
|
|
84
|
-
"claim": "I completed this task",
|
|
85
|
-
"proof_type": "WORK"
|
|
86
|
-
}).json()
|
|
87
|
-
proof_id = proof["proof_id"]
|
|
88
|
-
|
|
89
|
-
# 3. Add validators and vote
|
|
90
|
-
for _ in range(3):
|
|
91
|
-
httpx.post(f"{API}/v1/validators")
|
|
92
|
-
|
|
93
|
-
validators = httpx.get(f"{API}/v1/validators").json()
|
|
94
|
-
|
|
95
|
-
httpx.post(f"{API}/v1/proofs/{proof_id}/submit-consensus")
|
|
96
|
-
|
|
97
|
-
for v in validators["validators"][:2]:
|
|
98
|
-
httpx.post(f"{API}/v1/proofs/{proof_id}/vote", json={
|
|
99
|
-
"proof_id": proof_id,
|
|
100
|
-
"validator_did": v["did"],
|
|
101
|
-
"approve": True
|
|
102
|
-
})
|
|
103
|
-
|
|
104
|
-
# 4. Anchor to blockchain
|
|
105
|
-
result = httpx.post(f"{API}/v1/proofs/{proof_id}/chain-anchor").json()
|
|
106
|
-
print(f"Anchored at height {result['height']}")
|
|
107
|
-
```
|
|
108
|
-
|
|
109
|
-
## Security
|
|
110
|
-
|
|
111
|
-
- **Dilithium3** - Post-quantum digital signatures (NIST PQC)
|
|
112
|
-
- **SHAKE256** - Quantum-resistant hashing
|
|
113
|
-
- **HotStuff-2 BFT** - Byzantine fault tolerant consensus (67% threshold)
|
|
114
|
-
- **Bitcoin Anchoring** - Immutable timestamping via OpenTimestamps
|
|
115
|
-
|
|
116
|
-
## Dependencies
|
|
117
|
-
|
|
118
|
-
```
|
|
119
|
-
fastapi
|
|
120
|
-
uvicorn
|
|
121
|
-
httpx
|
|
122
|
-
pqcrypto # Dilithium3
|
|
123
|
-
```
|
|
124
|
-
|
|
125
|
-
## License
|
|
126
|
-
|
|
127
|
-
Proprietary - Stellanium LTD
|
|
128
|
-
|
|
129
|
-
---
|
|
130
|
-
|
|
131
|
-
**Autor:** Stellanium AI + Andrus Salumäe
|
|
132
|
-
**Kuupäev:** 2026-02-03
|
|
@@ -1,165 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
title: "The $1.5M API Key Leak That Exposed 'Vibe Coding' — And Why PROOFNEST Exists"
|
|
3
|
-
subtitle: "Moltbook's failure wasn't an accident. It was architecture. Here's what security-first AI infrastructure looks like."
|
|
4
|
-
date: 2026-02-03
|
|
5
|
-
author: Stellanium AI
|
|
6
|
-
reading_time: 5 min
|
|
7
|
-
tags: [AI, security, cryptography, proofnest, moltbook, quantum-proof]
|
|
8
|
-
platforms: [linkedin, medium]
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
# The $1.5M API Key Leak That Exposed 'Vibe Coding'
|
|
12
|
-
|
|
13
|
-
**1.5 million API keys. Exposed. In January 2026.**
|
|
14
|
-
|
|
15
|
-
That's what happened to Moltbook, the AI agent social network that grew to 1.5 million registered agents in just months. The breach wasn't caused by sophisticated hackers or zero-day exploits. It was caused by something the security community now calls **"vibe coding"** — shipping fast, fixing later, treating security as an afterthought.
|
|
16
|
-
|
|
17
|
-
The keys were sitting in `.git/config` files. Hardcoded. In client-side code.
|
|
18
|
-
|
|
19
|
-
If you're building with AI agents, this should terrify you.
|
|
20
|
-
|
|
21
|
-
---
|
|
22
|
-
|
|
23
|
-
## What Went Wrong at Moltbook
|
|
24
|
-
|
|
25
|
-
The Wiz Security analysis of the Moltbook breach reads like a checklist of everything not to do:
|
|
26
|
-
|
|
27
|
-
**Hardcoded API keys in client code.** OpenAI keys, database credentials, service tokens — all accessible to anyone who opened browser DevTools. Not encrypted. Not rotated. Just... there.
|
|
28
|
-
|
|
29
|
-
**No Row Level Security.** Moltbook's Supabase database had no RLS policies. This means any authenticated user could read or write any record. Your agent's DMs? Readable by any other agent. Your API keys? Same story.
|
|
30
|
-
|
|
31
|
-
**Zero rate limiting.** A single project called OpenClaw registered 500,000 fake agents in one automated batch. Half a million. No friction, no verification, no cost.
|
|
32
|
-
|
|
33
|
-
**Plaintext DM storage.** Direct messages between agents were stored unencrypted. When the database leaked, so did every private conversation.
|
|
34
|
-
|
|
35
|
-
**Single admin account.** No audit trail. No accountability. No way to know who did what or when.
|
|
36
|
-
|
|
37
|
-
This wasn't a sophisticated attack. This was architectural negligence dressed up as "move fast and break things."
|
|
38
|
-
|
|
39
|
-
The underlying pattern is more disturbing: **45% of AI-generated code introduces security vulnerabilities** (Veracode, 2025). When you "vibe code" — accept LLM suggestions without review, skip security testing, ship on vibes — this is the result.
|
|
40
|
-
|
|
41
|
-
The AI agent ecosystem is growing exponentially. Gartner predicts 15% of enterprise decisions will be made by AI agents by 2028. McKinsey estimates 72% of enterprises will have AI agents in production by 2027. If we build that future on Moltbook-style foundations, we're building on sand.
|
|
42
|
-
|
|
43
|
-
The Moltbook breach wasn't unique. It was representative. Across the AI agent space, security is consistently deprioritized in favor of feature velocity. The result is predictable: breaches, leaked credentials, and eroded trust in AI systems at exactly the moment when we need to build confidence.
|
|
44
|
-
|
|
45
|
-
---
|
|
46
|
-
|
|
47
|
-
## What PROOFNEST Does Differently
|
|
48
|
-
|
|
49
|
-
PROOFNEST started with a different premise: **security is infrastructure, not a feature.**
|
|
50
|
-
|
|
51
|
-
We didn't bolt security onto an existing system. We built a cryptographic trust layer from the ground up, then put AI decision logging on top of it. Here's what that means in practice:
|
|
52
|
-
|
|
53
|
-
### Quantum-Proof Cryptography by Design
|
|
54
|
-
|
|
55
|
-
Every signature in PROOFNEST uses **hybrid cryptography**: Dilithium-5 (ML-DSA, FIPS 204) combined with Ed25519.
|
|
56
|
-
|
|
57
|
-
Why hybrid? Dilithium is quantum-resistant — it will survive when quantum computers break RSA and ECDSA. Ed25519 provides battle-tested classical security today. Running both in parallel means you get current-generation security AND future-proofing. Not "we'll add quantum resistance later." Now.
|
|
58
|
-
|
|
59
|
-
```python
|
|
60
|
-
from proofnest import ProofNest
|
|
61
|
-
|
|
62
|
-
pn = ProofNest(agent_id="my-agent")
|
|
63
|
-
pn.decide(
|
|
64
|
-
action="Approved loan application",
|
|
65
|
-
reasoning="Credit score 780, debt-to-income 28%",
|
|
66
|
-
risk_level="low"
|
|
67
|
-
)
|
|
68
|
-
# Signed with Dilithium-5 + Ed25519
|
|
69
|
-
# Anchored to Bitcoin
|
|
70
|
-
# Verifiable forever
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
Every decision your AI agent makes gets cryptographically signed. Not "logged to a database." **Signed.** With keys that only your agent controls.
|
|
74
|
-
|
|
75
|
-
The entire cryptographic stack passed a GPT-5.2 security audit. We fix vulnerabilities before shipping, not after breaches.
|
|
76
|
-
|
|
77
|
-
### Decentralized Trust (No Single Point of Failure)
|
|
78
|
-
|
|
79
|
-
Moltbook ran on a single Supabase instance with one admin account. PROOFNEST runs on **HotStuff-2 BFT consensus** with a distributed validator network.
|
|
80
|
-
|
|
81
|
-
What does that mean? There's no central server to breach. No single database to leak. No admin account with god-mode access. Validators reach consensus on the state of the network, and that state is cryptographically locked.
|
|
82
|
-
|
|
83
|
-
**Block time: ~2 seconds. Finality: ~4 seconds.** Fast enough for real-time applications. Secure enough for regulatory compliance.
|
|
84
|
-
|
|
85
|
-
If one validator gets compromised? The network continues. The Byzantine Fault Tolerant consensus handles up to 1/3 malicious nodes. Try doing that with a Supabase backend.
|
|
86
|
-
|
|
87
|
-
### Immutable Audit Trails (Bitcoin Anchoring)
|
|
88
|
-
|
|
89
|
-
PROOFNEST decisions get anchored to **Bitcoin via OpenTimestamps**. Not our blockchain. THE blockchain. The one with $1 trillion in security behind it.
|
|
90
|
-
|
|
91
|
-
This means:
|
|
92
|
-
|
|
93
|
-
- **Tamper-evident logs.** If anyone modifies historical records, the anchors break. Cryptographic proof of tampering.
|
|
94
|
-
- **Regulatory compliance.** EU AI Act Article 12 requires "automatic recording of events" with "tamper-resistant" logs. We don't just meet this requirement — we exceed it.
|
|
95
|
-
- **Long-term verifiability.** Your AI's decisions from 2026 will be verifiable in 2046. Without trusting us. Without trusting anyone. Just math.
|
|
96
|
-
|
|
97
|
-
When auditors ask "What did your AI decide, and when?" you hand them a cryptographic proof chain. Not a database export. Not a CSV file. A mathematical proof.
|
|
98
|
-
|
|
99
|
-
### Identity Done Right (DID:PN, Not API Keys)
|
|
100
|
-
|
|
101
|
-
Moltbook used API keys for identity. Keys that leaked. Keys that couldn't be rotated. Keys that were the same for read and write access.
|
|
102
|
-
|
|
103
|
-
PROOFNEST uses **DID:PN** — Decentralized Identifiers on the Proofnest network. Your agent gets a cryptographic identity (`did:pn:abc123...`) with:
|
|
104
|
-
|
|
105
|
-
- **Key rotation.** Compromised key? Rotate it. The identity persists.
|
|
106
|
-
- **Recovery mechanisms.** Lost your key? Recovery procedures exist. Moltbook's leaked keys? Gone forever.
|
|
107
|
-
- **Scoped permissions.** Different keys for different operations. Read vs write. High-risk vs low-risk.
|
|
108
|
-
- **No central authority.** Your identity isn't stored in our database. It's cryptographic. You own it.
|
|
109
|
-
|
|
110
|
-
This is what enterprise-grade identity looks like. Not strings in a config file.
|
|
111
|
-
|
|
112
|
-
When Moltbook's keys leaked, users had no recourse. The keys couldn't be rotated without creating entirely new agent accounts. Reputation, history, connections — all lost. With DID:PN, your agent's identity is cryptographic and persistent. Compromise a key? Rotate it. Your identity, reputation, and history remain intact. That's the difference between "security as afterthought" and "security as infrastructure."
|
|
113
|
-
|
|
114
|
-
---
|
|
115
|
-
|
|
116
|
-
## The Philosophy: Proof-Coded, Not Vibe-Coded
|
|
117
|
-
|
|
118
|
-
The Moltbook breach crystallized something the security community has known for years: **you cannot bolt security onto a system designed without it.**
|
|
119
|
-
|
|
120
|
-
PROOFNEST's tagline is "Proof, not promises." It's not marketing. It's architecture.
|
|
121
|
-
|
|
122
|
-
When we say your AI decisions are secure, we mean cryptographically provable. When we say logs are tamper-evident, we mean Bitcoin-anchored. When we say identity is protected, we mean quantum-resistant signatures with key rotation.
|
|
123
|
-
|
|
124
|
-
Security isn't a feature we add. It's the foundation everything else sits on. Like TLS for the web — invisible when it works, catastrophic when it's absent.
|
|
125
|
-
|
|
126
|
-
Think about what happened to HTTPS. In the early web, encryption was optional. Sites ran on HTTP. Then came Firesheep, credential theft at scale, and suddenly "HTTP is fine for most sites" became obviously wrong. Today, browsers warn you if a site doesn't use HTTPS. The security layer became invisible infrastructure.
|
|
127
|
-
|
|
128
|
-
AI agents need the same evolution. Right now, we're in the "HTTP is fine" phase. Moltbook-style architectures ship without security foundations, and we act surprised when they fail. PROOFNEST is the HTTPS moment for AI decisions: proof built into the protocol, not bolted on afterward.
|
|
129
|
-
|
|
130
|
-
The AI agent economy is coming. Gartner, McKinsey, every analyst agrees. The question isn't whether AI agents will make consequential decisions. They already do. The question is: **can you prove what they decided?**
|
|
131
|
-
|
|
132
|
-
With Moltbook-style infrastructure: no. You get leaked keys, fake agents, and unverifiable claims.
|
|
133
|
-
|
|
134
|
-
With PROOFNEST: yes. Cryptographic proof. Anchored to Bitcoin. Verifiable by anyone, forever.
|
|
135
|
-
|
|
136
|
-
---
|
|
137
|
-
|
|
138
|
-
## The Path Forward
|
|
139
|
-
|
|
140
|
-
We built PROOFNEST because we saw the Moltbook breach coming — not the specific incident, but the pattern. "Vibe coding" is everywhere. Security debt accumulates until it doesn't.
|
|
141
|
-
|
|
142
|
-
If you're building AI agents, you have a choice:
|
|
143
|
-
|
|
144
|
-
1. **Ship fast, fix later.** Hope you're not the next Moltbook.
|
|
145
|
-
2. **Build on infrastructure designed for trust.** Know you can prove every decision.
|
|
146
|
-
|
|
147
|
-
PROOFNEST is open source. The SDK is MIT-licensed. The protocol specification is public. You can audit every line of code. You can run your own validators. You're not trusting us — you're trusting math.
|
|
148
|
-
|
|
149
|
-
```bash
|
|
150
|
-
pip install proofnest
|
|
151
|
-
```
|
|
152
|
-
|
|
153
|
-
In ten lines of Python, you can sign your first AI decision with quantum-proof cryptography. Try it. Sign a decision. Verify it offline, without any network call. Anchor it to Bitcoin, creating an immutable timestamp no one can forge. See what proof-coded infrastructure feels like.
|
|
154
|
-
|
|
155
|
-
The Moltbook breach cost their users trust. Some lost API keys worth thousands. All lost confidence that AI agent platforms can be secure. That trust won't rebuild on promises. It rebuilds on proof.
|
|
156
|
-
|
|
157
|
-
Because in a world where AI makes decisions that matter, "trust me" isn't good enough.
|
|
158
|
-
|
|
159
|
-
**Proof, not promises.**
|
|
160
|
-
|
|
161
|
-
---
|
|
162
|
-
|
|
163
|
-
*Learn more at [proofnest.io](https://proofnest.io)*
|
|
164
|
-
|
|
165
|
-
*PROOFNEST is built by Stellanium Ltd. 335K+ lines of code. GPT-5.2 security audited. EU AI Act compliant.*
|
|
@@ -1,168 +0,0 @@
|
|
|
1
|
-
# Twitter Thread 001: PROOFNEST vs Moltbook
|
|
2
|
-
|
|
3
|
-
**Account:** @andaborning
|
|
4
|
-
**Date:** 2026-02-03
|
|
5
|
-
**Topic:** Moltbook 1.5M API Key Leak + PROOFNEST Security
|
|
6
|
-
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
## Thread
|
|
10
|
-
|
|
11
|
-
**1/10**
|
|
12
|
-
|
|
13
|
-
1.5 million API keys leaked.
|
|
14
|
-
|
|
15
|
-
Moltbook just exposed what happens when you "vibe code" AI infrastructure.
|
|
16
|
-
|
|
17
|
-
Keys were sitting in .git/config. Hardcoded in client code. No encryption.
|
|
18
|
-
|
|
19
|
-
This is what security-as-afterthought looks like.
|
|
20
|
-
|
|
21
|
-
A thread on why we built PROOFNEST differently.
|
|
22
|
-
|
|
23
|
-
---
|
|
24
|
-
|
|
25
|
-
**2/10**
|
|
26
|
-
|
|
27
|
-
The breach wasn't sophisticated. No zero-day. No elite hackers.
|
|
28
|
-
|
|
29
|
-
Just... bad architecture:
|
|
30
|
-
- Hardcoded API keys in browser code
|
|
31
|
-
- No Row Level Security
|
|
32
|
-
- Zero rate limiting (500K fake agents registered in one batch)
|
|
33
|
-
- Plaintext DMs
|
|
34
|
-
|
|
35
|
-
"Move fast and break things" finally broke.
|
|
36
|
-
|
|
37
|
-
---
|
|
38
|
-
|
|
39
|
-
**3/10**
|
|
40
|
-
|
|
41
|
-
Here's the stat that should scare you:
|
|
42
|
-
|
|
43
|
-
45% of AI-generated code introduces security vulnerabilities.
|
|
44
|
-
|
|
45
|
-
When you accept LLM suggestions without review, skip security testing, ship on vibes...
|
|
46
|
-
|
|
47
|
-
Moltbook is what happens.
|
|
48
|
-
|
|
49
|
-
---
|
|
50
|
-
|
|
51
|
-
**4/10**
|
|
52
|
-
|
|
53
|
-
PROOFNEST started with a different premise:
|
|
54
|
-
|
|
55
|
-
Security is infrastructure, not a feature.
|
|
56
|
-
|
|
57
|
-
You can't bolt it on later. You build it in from day one.
|
|
58
|
-
|
|
59
|
-
Or you become a cautionary tale.
|
|
60
|
-
|
|
61
|
-
---
|
|
62
|
-
|
|
63
|
-
**5/10**
|
|
64
|
-
|
|
65
|
-
What does security-first mean in practice?
|
|
66
|
-
|
|
67
|
-
Every signature in PROOFNEST uses HYBRID cryptography:
|
|
68
|
-
|
|
69
|
-
Dilithium-5 (quantum-resistant, FIPS 204) + Ed25519 (battle-tested classical)
|
|
70
|
-
|
|
71
|
-
Not "we'll add quantum resistance later."
|
|
72
|
-
|
|
73
|
-
Now. From the first commit.
|
|
74
|
-
|
|
75
|
-
---
|
|
76
|
-
|
|
77
|
-
**6/10**
|
|
78
|
-
|
|
79
|
-
Moltbook ran on one Supabase instance. One admin account. One point of failure.
|
|
80
|
-
|
|
81
|
-
PROOFNEST runs on HotStuff-2 BFT consensus with distributed validators.
|
|
82
|
-
|
|
83
|
-
No central server to breach.
|
|
84
|
-
No single database to leak.
|
|
85
|
-
No god-mode admin.
|
|
86
|
-
|
|
87
|
-
Byzantine fault tolerant. Up to 1/3 malicious nodes handled.
|
|
88
|
-
|
|
89
|
-
---
|
|
90
|
-
|
|
91
|
-
**7/10**
|
|
92
|
-
|
|
93
|
-
Your AI decisions get anchored to Bitcoin via OpenTimestamps.
|
|
94
|
-
|
|
95
|
-
Not our blockchain. THE blockchain. $1T+ security behind it.
|
|
96
|
-
|
|
97
|
-
Tamper-evident.
|
|
98
|
-
Verifiable in 2046.
|
|
99
|
-
Without trusting us.
|
|
100
|
-
|
|
101
|
-
Just math.
|
|
102
|
-
|
|
103
|
-
---
|
|
104
|
-
|
|
105
|
-
**8/10**
|
|
106
|
-
|
|
107
|
-
Moltbook used API keys for identity. Keys that leaked. Keys that couldn't be rotated.
|
|
108
|
-
|
|
109
|
-
PROOFNEST uses DID:PN - cryptographic identity with:
|
|
110
|
-
- Key rotation
|
|
111
|
-
- Recovery mechanisms
|
|
112
|
-
- Scoped permissions
|
|
113
|
-
|
|
114
|
-
Compromise a key? Rotate it. Your identity persists.
|
|
115
|
-
|
|
116
|
-
---
|
|
117
|
-
|
|
118
|
-
**9/10**
|
|
119
|
-
|
|
120
|
-
The entire stack passed a GPT-5.2 security audit.
|
|
121
|
-
|
|
122
|
-
We fix vulnerabilities before shipping.
|
|
123
|
-
|
|
124
|
-
Not after 1.5 million keys leak.
|
|
125
|
-
|
|
126
|
-
---
|
|
127
|
-
|
|
128
|
-
**10/10**
|
|
129
|
-
|
|
130
|
-
Building AI agents? You have two paths:
|
|
131
|
-
|
|
132
|
-
1. Ship fast, hope you're not the next Moltbook
|
|
133
|
-
2. Build on infrastructure designed for trust
|
|
134
|
-
|
|
135
|
-
PROOFNEST is open source. MIT-licensed. Audit every line.
|
|
136
|
-
|
|
137
|
-
pip install proofnest
|
|
138
|
-
|
|
139
|
-
Proof, not promises.
|
|
140
|
-
|
|
141
|
-
proofnest.io
|
|
142
|
-
|
|
143
|
-
---
|
|
144
|
-
|
|
145
|
-
## Metadata
|
|
146
|
-
|
|
147
|
-
**Hashtags (use on tweet 1 and 10 only):**
|
|
148
|
-
#AI #Security #AIAgents #Cryptography #OpenSource
|
|
149
|
-
|
|
150
|
-
**Character counts:**
|
|
151
|
-
- Tweet 1: 279 chars
|
|
152
|
-
- Tweet 2: 276 chars
|
|
153
|
-
- Tweet 3: 208 chars
|
|
154
|
-
- Tweet 4: 183 chars
|
|
155
|
-
- Tweet 5: 267 chars
|
|
156
|
-
- Tweet 6: 285 chars
|
|
157
|
-
- Tweet 7: 195 chars
|
|
158
|
-
- Tweet 8: 263 chars
|
|
159
|
-
- Tweet 9: 121 chars
|
|
160
|
-
- Tweet 10: 246 chars
|
|
161
|
-
|
|
162
|
-
All tweets under 280 character limit.
|
|
163
|
-
|
|
164
|
-
**Best posting time:** Tuesday-Thursday, 9-11am EST (tech audience)
|
|
165
|
-
|
|
166
|
-
**Engagement strategy:**
|
|
167
|
-
- Quote-tweet from @proofnest account with "This is why we exist."
|
|
168
|
-
- Pin thread to profile for 1 week
|