Liana Banyan Corporation — Structural Bylaws
These bylaws are FOUNDATIONAL. They cannot be changed without supermajority (75%) member vote, 90-day public comment period, and are subject to Founder veto during the founding period.
Amendment Requirements (All Bylaws)
| Requirement | Details |
|---|---|
| Member Vote | 75% supermajority required |
| Public Comment | 90-day period before vote |
| Board Override | NOT permitted |
| Founder Veto | Active during founding period |
| Executive Change | NOT permitted |
| Investor Pressure | NOT a valid reason |
BYLAW I: Cost+20% Model
The economic foundation of Liana Banyan.
The Principle
All products and services offered through Liana Banyan platforms SHALL be priced at:
Cost + 20%
Where “cost” includes:
- Raw materials
- Labor (at fair wages)
- Overhead allocation
- Transportation/logistics
Distribution of the 20%
| Allocation | Percentage | Purpose |
|---|---|---|
| Platform Operations | 8% | Infrastructure, development, maintenance |
| Member Benefits | 6% | Healthcare fund, education, mutual aid |
| Reserve Fund | 4% | Emergency reserves, expansion capital |
| Community Projects | 2% | Local initiatives, Cost of Doing Good |
What This Means
- No venture capital profit extraction
- No investor-driven price inflation
- Transparent pricing for all goods
- Members make money WITH, not FOR Liana Banyan
BYLAW II: Zero Personally Identifiable Information (PII)
We keep ZERO personally identifiable information other than Credit Card data, for the explicit purpose of age verification.
What We Collect (Exhaustive)
| Data Type | Purpose | Why Required |
|---|---|---|
| Payment Card | Age verification (18+) | Legal requirement |
| Location (Address/Zip) | Delivery, node assignment | Physical goods |
| Contact Information | Communication | Operational necessity |
That is ALL. Nothing else.
What We DO NOT Collect
| Data Type | Status | Notes |
|---|---|---|
| Social Security Number | ❌ NEVER | Not needed, never requested |
| Race/Ethnicity | ❌ NEVER | No field exists in database |
| Religion | ❌ NEVER | Not collected, not stored |
| Gender Identity | ❌ NEVER | No field exists |
| Political Affiliation | ❌ NEVER | Structurally impossible |
| Sexual Orientation | ❌ NEVER | No field exists |
| Income Level | ❌ NEVER | Not our business |
| Health Information | ❌ NEVER | Not applicable |
| Account Count Per Person | ❌ NEVER | We do not correlate |
Architectural Enforcement
The database schema does not contain fields for demographic data. This is not a policy — it is structurally impossible to collect what cannot be stored.
BYLAW III: 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.
What We Do NOT Do
| Action | Status |
|---|---|
| Correlate accounts to individuals | ❌ NEVER |
| Track “this person has X accounts” | ❌ NEVER |
| Limit account creation | ❌ NEVER |
| Require unique identifiers across accounts | ❌ NEVER |
Rationale
Consistent with Zero PII — we cannot track what we do not store. Each account is independent. A person may have business accounts, personal accounts, project accounts, etc.
BYLAW IV: Local S.O.P. Privacy Barrier
Liana Banyan Corporation keeps NO record of Local Standard Operating Procedures.
The Firewall
┌─────────────────────────────────────────────────┐
│ LIANA BANYAN CORPORATE │
│ • No access to Local S.O.P. details │
│ • Only aggregates visible │
│ • Cannot request, cannot store │
│ │
│ ══════════════════════════ │
│ STRUCTURAL FIREWALL │
│ ══════════════════════════ │
│ │
│ NODES (Local S.O.P.) │
│ • Pickup arrangements │
│ • Delivery instructions │
│ • Local accommodations │
│ • Member-specific arrangements │
│ │
│ Reviewed by: Harpers (quality only) │
└─────────────────────────────────────────────────┘
What Nodes Can Do
- Arrange pickups at alternate locations
- Coordinate with members on delivery preferences
- Maintain local delivery instructions
- Accommodate special circumstances
What Corporate CANNOT Do
- Access Local S.O.P. contents
- Request Local S.O.P. details
- Override node-level arrangements
- Store S.O.P. information in corporate systems
Harper Review
Harpers review Local S.O.P.s for quality assurance only — they do not report contents to corporate.
BYLAW V: Dual Redundancy Ledger Architecture
All critical records are maintained in BOTH the blockchain AND the database, with cross-validation.
Architecture
| System | Location | Purpose |
|---|---|---|
| IP Ledger (Blockchain) | Base Network | Immutable, public, SEC-capable |
| Hash-Chain (Database) | Supabase | Fast queries, offline backup, research |
Project Branching
┌─────────────────────────────────────────────────┐
│ IP LEDGER (BLOCKCHAIN - BASE) │
│ • Shared across ALL projects │
│ • Pure, immutable, canonical │
│ • SEC compliance capable │
│ • Public verification │
└─────────────────────────────────────────────────┘
║
MUST MATCH
║
┌─────────────────────────────────────────────────┐
│ PROJECT HASH-CHAINS (DATABASE) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ HexIsle │ │ 2ndSecond│ │ Dinner │ ... │
│ │ Branch │ │ Branch │ │ Branch │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ • Fast queries │
│ • Project-specific records │
│ • Cross-validates with blockchain │
└─────────────────────────────────────────────────┘
Cross-Validation Requirement
Project database branches MUST match the shared blockchain IP Ledger. Discrepancies are automatically flagged for review.
Network Configuration
| Network | Status | Purpose |
|---|---|---|
| Base Sepolia (Testnet) | DEFAULT | Development, validation, cost control |
| Base Mainnet | Available | SEC filing, value trading (requires governance vote) |
BYLAW VI: Data Access Level Framework
Even anonymous data access triggers notification.
Four Access Levels
Level 1: PUBLIC (No Permission)
| Aspect | Details |
|---|---|
| Authentication | Not required |
| Notification | Not required |
| Examples | Total innovation count, project milestones, governance outcomes |
Level 2: ANONYMOUS AGGREGATE (Notification Required)
| Aspect | Details |
|---|---|
| Authentication | Not required |
| Notification | REQUIRED |
| Examples | Voting patterns, average transaction sizes, participation rates |
Even anonymous aggregates trigger a notification that data is being accessed.
Level 3: PROJECT (Crown Approval Required)
| Aspect | Details |
|---|---|
| Authentication | Required |
| Authorization | Crown approval |
| Notification | Required |
| Examples | Project financials, participation metrics |
Level 4: MEMBER (Explicit Opt-In Required)
| Aspect | Details |
|---|---|
| Authentication | Required |
| Authorization | Explicit member consent |
| Notification | Required |
| Revocable | At any time |
| Examples | Personal activity history, detailed voting record |
BYLAW VII: Sponsor Targeting Restrictions
Sponsors may ONLY use non-demographic criteria.
Allowed Criteria ✅
| Criteria Type | Examples |
|---|---|
| Geographic Location | “Lives in Butte, Montana” |
| Area Code | “Has 406 area code” |
| Temporal | “Startup within last 3 months” |
| Group Membership | “Self-identified member of [group]” |
| Node Affiliation | “Assigned to Node X” |
Prohibited Criteria ❌
| Criteria Type | Status |
|---|---|
| Race/Ethnicity | PROHIBITED |
| Religion (as filter) | PROHIBITED |
| Age (beyond 18+) | PROHIBITED |
| Gender | PROHIBITED |
| Income | PROHIBITED |
| Any demographic | PROHIBITED |
Self-Identification Note
A sponsor may name a recognized group (e.g., “self-identified Catholic church member”) but this is:
- Self-identified by the recipient
- NOT verified by Liana Banyan
- NOT stored in any database
- Used only for that specific gift matching
BYLAW VIII: Mainnet Migration Governance
Moving to mainnet blockchain requires explicit governance approval.
Current State
- Network: Base Sepolia (Testnet)
- Status: Default by design
- Reason: Cost control, development flexibility
Mainnet Migration Requirements
| Step | Requirement |
|---|---|
| 1. Legal Review | SEC compliance analysis (Reg A+, Reg D, Reg CF, or exempt) |
| 2. Governance Vote | 75% supermajority approval |
| 3. Public Comment | 90-day period |
| 4. Technical Migration | Smart contract deployment, gas budgeting |
| 5. Value Implications | Trading, liquidity, price discovery review |
What Mainnet Enables
- SEC registration filing capability
- Value trading on secondary markets
- Real-world asset backing
- Public verification at scale
What Mainnet Requires
- Real gas costs (actual money)
- Regulatory compliance
- Public scrutiny
- Ongoing governance accountability
BYLAW IX: Executive Compensation Cap
Section 9.1 — CEO Salary Cap
$1,000,000 USD per year MAXIMUM
This is an UPPER LIMIT. Does NOT affect what the CEO earns from personal inventions, projects, or investments.
Section 9.2 — Founder’s Cost+20% Option
The Founder, while serving as CEO, may calculate salary as:
Personal Operating Costs + 20%
Including:
- Home office/workspace (garage = Corporate Headquarters)
- Utilities, equipment, transportation
- Other documented business expenses
“I use the same Cost+20% model you do. Make money WITH, not FOR.”
BYLAW X: Steward Compensation Model
All leadership positions use the same model: escrow risk, proportional authority, success-based reward.
The Steward Formula
Authority Ratio = (Escrowed Joules ÷ Project Cost) × Responsibility Scope
Reward = Project Success × Authority Ratio × Steward Multiplier
Escrow Requirement
To receive leadership authority:
- Escrow personal Joules (collateral)
- Escrow amount = maximum authority level
- Released upon successful completion + sign-off
- Forfeited if responsibilities not met
Authority Is Proportional
| Escrow | Authority | Risk | Reward |
|---|---|---|---|
| Minimal | Advisory only | Low | Low |
| Moderate | Operational | Medium | Medium |
| Substantial | Strategic | High | High |
| Full | Complete control | Maximum | Maximum |
Steward Selection (Portfolio Interface)
Project owners select via checkboxes:
| ☑ Financials + Taxes | Full authority over finances | | ☑ Marketing | Full authority over marketing | | ☑ Social Media | Full authority over social | | ☑ Production | Full authority over production |
No Micromanaging Clause
When you delegate, you DELEGATE.
The Steward:
- Is hired for expertise
- Pays the price (escrow) like you
- Gains the reward like you
- Has FULL authority within their domain
- Cannot be overridden on operational decisions
The Owner:
- Sets strategic direction
- Reviews outcomes
- Does NOT dictate methods
- May revoke delegation (with notice) but not micromanage
BYLAW XI: Corporate Headquarters
The Founder’s garage is designated as Corporate Headquarters.
This demonstrates:
- Lean operations
- Same Cost+20% model as members
- No unnecessary overhead
- Authenticity (“Built in a garage, like the greats”)
Summary of Structural Bylaws
| Bylaw | Core Principle |
|---|---|
| I. Cost+20% | Economic fairness, transparent pricing |
| II. Zero PII | Personally Identifiable Information — only credit card for age verification |
| III. Unlimited Accounts | No tracking, no limits, no correlation |
| IV. Local S.O.P. Barrier | Corporate cannot access node arrangements |
| V. Dual Redundancy | Blockchain + Database, must match |
| VI. Data Access Levels | Even anonymous data triggers notification |
| VII. Sponsor Restrictions | Non-demographic criteria only |
| VIII. Mainnet Governance | CEO/Founder initiation, FOUNDER VETO POWER |
| IX. Executive Compensation | $1M cap, Cost+20% option |
| X. Steward Model | Escrow + Authority + Success = Reward |
| XI. Corporate HQ | Garage = headquarters |
Legal Standing
These bylaws:
- Are incorporated into the corporate charter
- Exceed requirements of GDPR, CCPA, and state privacy laws
- Cannot be waived by contract
- Apply to all subsidiaries and affiliated projects
- Are binding on successors and assigns
“We built the walls so high that even we cannot climb over them. That is the point.”
FOR THE KEEP!