Privacy Architecture
“We keep ZERO personally identifiable information other than Credit Card data, for the explicit purpose of age verification.”
This is a structural bylaw, on par with the Cost+20% principle. It cannot be changed without supermajority governance approval and extensive legal review.
The Zero PII Commitment
What We Store
| Data Type | Stored? | Purpose |
|---|---|---|
| Credit Card | ✅ Yes | Age verification ONLY |
| Locale/Location | ✅ Yes | Delivery routing, node assignment, benefit access |
| Contact Email | ✅ Yes | Communication (can be anonymized relay) |
| Medallion ID | ✅ Yes | Identity verification (not linked to PII) |
| Wallet Address | ✅ Yes | Blockchain operations |
What We DO NOT Store
| Data Type | Stored? | Notes |
|---|---|---|
| Social Security Number | ❌ Never | Not needed, never requested |
| Demographics | ❌ Never | No gender, race, ethnicity fields exist |
| Religion | ❌ Never | Not collected, not stored |
| Political Affiliation | ❌ Never | Structurally impossible |
| Health Information | ❌ Never | Not applicable |
| Detailed Financial History | ❌ Never | Only aggregates for reporting |
| Account Count Per Person | ❌ Never | We do not correlate accounts |
Unlimited Accounts Policy
Members can have unlimited accounts. We do not track or limit how many accounts a single person has.
Requirements per account:
- Valid credit card payment (for age verification)
- That’s it.
We do not:
- Correlate accounts to individuals
- Track “this person has X accounts”
- Limit account creation
- Require unique identifiers across accounts
This is consistent with Zero PII — we cannot track what we do not store.
Architectural Enforcement
The database schema does not contain fields for demographic data. This is not a policy — it’s an architectural impossibility. You cannot store what you cannot record.
-- This field does NOT exist in our schema:
-- gender TEXT,
-- race TEXT,
-- religion TEXT,
-- etc.
Adding such fields would require:
- Governance supermajority vote
- Legal counsel approval
- Technical migration
- Public notification
Data Access Levels
1. PUBLIC (No Permission Needed)
Anyone can see:
- Total innovation count
- Project milestones
- Governance outcomes
- Platform metrics
No authentication required. No notification sent.
2. ANONYMOUS AGGREGATE (Notification Required)
Aggregated data, no individual identification:
- Voting patterns (not individual votes)
- Average transaction sizes
- Participation rates
- Session patterns (for academic research)
No authentication required, but notification is sent that data is being accessed for research or analysis.
3. PROJECT (Crown Approval Required)
Project-scoped data with authorization:
- Project financials
- Member participation (anonymized)
- Resource allocation
Requires authentication and project Crown approval.
4. MEMBER (Explicit Opt-In Required)
Individual member data:
- Personal activity history
- Detailed voting record
- Financial transactions
Requires explicit member consent. Members can revoke at any time.
Sponsor Targeting
Sponsors can specify criteria for their contributions, but ONLY non-demographic criteria:
Allowed Criteria ✅
- Location (e.g., “Lives in Butte, Montana”)
- Area code (e.g., “Area code 406”)
- Temporal (e.g., “Startup within last 3 months”)
- Group membership (e.g., “Self-identified as X church member”)
- Objective attributes we already have (locale, contact info)
Disallowed Criteria ❌
- Gender
- Race/Ethnicity
- Age (beyond adult verification)
- Religion (as targeting criterion, not self-identification)
- Political affiliation
- Any protected class
We cannot verify demographic criteria because we do not have demographic data. Self-identification is the member’s choice and Liana Banyan does not record or validate it.
Local S.O.P. Privacy Barrier
Local Standard Operating Procedures (S.O.P.s) are maintained at the node level:
- Nodes can arrange pickups and deliveries
- Harpers review S.O.P.s regularly for quality
- Liana Banyan Corporate keeps NO record of S.O.P. details
This is a structural firewall. The parent corporation cannot access node-level delivery arrangements by design.
┌─────────────────────────────────────────┐
│ LIANA BANYAN CORPORATE │
│ • No access to Local S.O.P. details │
│ • Only aggregates visible │
│ │
│ ════════╧════════ │
│ FIREWALL │
│ ════════╤════════ │
│ │
│ NODES (Local S.O.P.) │
│ • Pickup arrangements │
│ • Delivery instructions │
│ • Local accommodations │
│ │
│ Reviewed by: Harpers (quality only) │
└─────────────────────────────────────────┘
Academic Research Data
For PhD-grade research, we track anonymized patterns:
Innovation Metrics
- Innovation velocity (X innovations over Y days)
- Session burst patterns (W items in M minutes)
- Development timeline (37 years of documented history)
Governance Patterns
- Voting participation rates (not individual votes)
- Consensus levels
- Decision velocity
Financial Patterns
- Transaction volume (count, not amounts)
- Growth rates
- Economic flow patterns
Export Format
Researchers can request anonymized data exports:
{
"totalInnovations": 984,
"innovationVelocity": {
"daily": 5.2,
"weekly": 50,
"monthly": 120,
"allTimeAvgPerDay": 0.07
},
"sessions": {
"avgDurationMinutes": 145,
"avgItemsPerSession": 12,
"burstPatterns": {
"avgBurstDuration": 45,
"avgItemsPerBurst": 8
}
},
"developmentYears": 37
}
Blockchain Integration
Current: Base Testnet (By Design)
- Network: Base Sepolia
- Purpose: Development, validation, cost control
- Records: Innovation timestamps, medallion events, governance
Future: Mainnet (Optional Path)
Can we move to mainnet? Yes, if:
- Legal Review — SEC compliance analysis
- Governance Vote — Supermajority approval
- Technical Migration — Smart contract deployment
- Value Implications — Trading/transfer considerations
Mainnet enables:
- SEC filing capability (Reg A+, Reg D, Reg CF)
- Value trading and liquidity
- Public verification
- Real-world asset backing
Mainnet requires:
- Real gas costs (money)
- Regulatory compliance
- Public scrutiny
- Governance accountability
Notification System
Even for anonymous data, we notify:
[DATA ACCESS NOTIFICATION]
Level: ANONYMOUS_AGGREGATE
Purpose: Academic research on innovation velocity
Scope: All innovations Q1 2026
Timestamp: 2026-02-01T23:59:59Z
Members can see all data access events through their HoFund portal.
Bylaw Status
This privacy architecture is a structural bylaw, meaning:
- It cannot be casually changed
- Modification requires supermajority vote
- Legal review is mandatory for any changes
- Public notification period required
- On par with Cost+20% commitment
“Privacy isn’t a feature. It’s the foundation.”
FOR THE KEEP!