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)

RequirementDetails
Member Vote75% supermajority required
Public Comment90-day period before vote
Board OverrideNOT permitted
Founder VetoActive during founding period
Executive ChangeNOT permitted
Investor PressureNOT 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%

AllocationPercentagePurpose
Platform Operations8%Infrastructure, development, maintenance
Member Benefits6%Healthcare fund, education, mutual aid
Reserve Fund4%Emergency reserves, expansion capital
Community Projects2%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 TypePurposeWhy Required
Payment CardAge verification (18+)Legal requirement
Location (Address/Zip)Delivery, node assignmentPhysical goods
Contact InformationCommunicationOperational necessity

That is ALL. Nothing else.

What We DO NOT Collect

Data TypeStatusNotes
Social Security Number❌ NEVERNot needed, never requested
Race/Ethnicity❌ NEVERNo field exists in database
Religion❌ NEVERNot collected, not stored
Gender Identity❌ NEVERNo field exists
Political Affiliation❌ NEVERStructurally impossible
Sexual Orientation❌ NEVERNo field exists
Income Level❌ NEVERNot our business
Health Information❌ NEVERNot applicable
Account Count Per Person❌ NEVERWe 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

ActionStatus
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

SystemLocationPurpose
IP Ledger (Blockchain)Base NetworkImmutable, public, SEC-capable
Hash-Chain (Database)SupabaseFast 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

NetworkStatusPurpose
Base Sepolia (Testnet)DEFAULTDevelopment, validation, cost control
Base MainnetAvailableSEC 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)

AspectDetails
AuthenticationNot required
NotificationNot required
ExamplesTotal innovation count, project milestones, governance outcomes

Level 2: ANONYMOUS AGGREGATE (Notification Required)

AspectDetails
AuthenticationNot required
NotificationREQUIRED
ExamplesVoting patterns, average transaction sizes, participation rates

Even anonymous aggregates trigger a notification that data is being accessed.

Level 3: PROJECT (Crown Approval Required)

AspectDetails
AuthenticationRequired
AuthorizationCrown approval
NotificationRequired
ExamplesProject financials, participation metrics

Level 4: MEMBER (Explicit Opt-In Required)

AspectDetails
AuthenticationRequired
AuthorizationExplicit member consent
NotificationRequired
RevocableAt any time
ExamplesPersonal activity history, detailed voting record

BYLAW VII: Sponsor Targeting Restrictions

Sponsors may ONLY use non-demographic criteria.

Allowed Criteria ✅

Criteria TypeExamples
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 TypeStatus
Race/EthnicityPROHIBITED
Religion (as filter)PROHIBITED
Age (beyond 18+)PROHIBITED
GenderPROHIBITED
IncomePROHIBITED
Any demographicPROHIBITED

Self-Identification Note

A sponsor may name a recognized group (e.g., “self-identified Catholic church member”) but this is:

  1. Self-identified by the recipient
  2. NOT verified by Liana Banyan
  3. NOT stored in any database
  4. 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

StepRequirement
1. Legal ReviewSEC compliance analysis (Reg A+, Reg D, Reg CF, or exempt)
2. Governance Vote75% supermajority approval
3. Public Comment90-day period
4. Technical MigrationSmart contract deployment, gas budgeting
5. Value ImplicationsTrading, 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:

  1. Escrow personal Joules (collateral)
  2. Escrow amount = maximum authority level
  3. Released upon successful completion + sign-off
  4. Forfeited if responsibilities not met

Authority Is Proportional

EscrowAuthorityRiskReward
MinimalAdvisory onlyLowLow
ModerateOperationalMediumMedium
SubstantialStrategicHighHigh
FullComplete controlMaximumMaximum

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

BylawCore Principle
I. Cost+20%Economic fairness, transparent pricing
II. Zero PIIPersonally Identifiable Information — only credit card for age verification
III. Unlimited AccountsNo tracking, no limits, no correlation
IV. Local S.O.P. BarrierCorporate cannot access node arrangements
V. Dual RedundancyBlockchain + Database, must match
VI. Data Access LevelsEven anonymous data triggers notification
VII. Sponsor RestrictionsNon-demographic criteria only
VIII. Mainnet GovernanceCEO/Founder initiation, FOUNDER VETO POWER
IX. Executive Compensation$1M cap, Cost+20% option
X. Steward ModelEscrow + Authority + Success = Reward
XI. Corporate HQGarage = headquarters

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!