Integrity rules

Cross-cutting rules that constrain how interfaces between coalition entities and the per-property architecture can be built or extended. Each rule is enforced architecturally where possible; otherwise enforced through Landseed’s compliance discipline.

Rule 1 — One-way trust by default

Trust flows in one direction. Every interface follows the hierarchy from 01-trust-direction.md:

Methodology → Attestations → Registry → DAO/LLC
                                      → Exchange → Fund

Cycles (entity A trusts B trusts C trusts A) create governance and security pathologies. The architecture does not build cycles.

Enforced:

• Smart contract design (Tier 2) — no upstream callbacks
• Coalition entity charters — define inputs and outputs explicitly
• Compliance review for new interfaces

Rule 2 — All cross-entity transfers are cryptographically attested

Money or credit movements between entities are recorded as cryptographically attested events. End-to-end audit trail. Anyone can trace a buyer’s payment back to a property’s measurement.

Enforced:

• attestation protocol generates receipts for relevant events
• Coalition entity operating procedures require attestation anchoring
• Audits verify the chain of custody

Examples:

• Methodology output → Registry: attested measurement event
• Registry → Buyer: attested issuance event; attested sale event
• Buyer → DAO treasury: attested revenue routing event

Rule 3 — Bright lines hold across coalition entities

The eight bright lines in 04-perimeter/01-eight-bright-lines.md apply not just inside DAOs but across the coalition.

Specifically:

• Exchange can’t list benefit units (Bright Line 1 — non-transferable)
• Fund can’t hold benefit units (Bright Line 4 — no fund-of-DAOs)
• Market Makers can’t trade benefit units (Bright Line 1)
• Captain Landseed can’t promote them as investments (Bright Line 6 — communication discipline)
• Registry can’t issue credits to DAO members (Bright Line 5 — credits go to buyers, not members)

Each coalition entity’s charter must reflect these rules.

Enforced:

• Charter review for new coalition entities
• Bright-line audit annually
• Halt-and-escalate if any coalition entity proposes to cross a bright line

Rule 4 — New coalition entities require interface specification + perimeter analysis

When a new coalition entity is proposed (a future entity not on the current list), its design must include:

• A written interface specification against existing DAOs/LLCs
• A securities-perimeter analysis specific to the entity’s structure
• An evaluation of trust-direction implications
• A proposed charter documenting Bright Line compliance

Without these, the entity is not built.

Enforced:

• Landseed PBC governance review of any new coalition entity
• Outside counsel review for novel structures
• Alex + the co-architect sign-off

Rule 5 — Coalition entities cannot acquire DAO positions

A specific application of Rule 3 worth restating. No coalition entity can acquire benefit units in any property DAO/LLC. This includes:

• Exchange holding benefit units as collateral
• Fund holding benefit units as investments
• Market Makers having benefit units on their books
• Any future coalition entity proposing to take governance positions

The only path for a coalition entity to have any relationship with a DAO is as a counterparty:

• Buyer of credits
• Seller of credits (rare)
• Service provider
• Audit entity
• Information provider

None of these involve holding benefit units.

Enforced:

• Coalition entity charters explicitly preclude position-holding
• Beneficiary registry composition does not include coalition entity seats
• Pre-deployment self-check (04-perimeter/07-pre-deployment-self-check.md) Q1

Rule 6 — Information flows do not become governance flows

A subtle but important rule: a coalition entity providing information to a DAO does not gain governance rights through the information provision.

For example:

• Signal Markets may provide ecological forecasts that a DAO’s management plan ratification considers — but Signal Markets does not vote
• Earth Pulse Network may provide sensor data that affects methodology assessment — but Earth Pulse does not approve management decisions
• Captain Landseed may publish about a property — but Captain Landseed does not influence the property’s governance

Information is information. Governance is governance. They don’t blur.

Enforced:

• Operating agreements explicitly limit external information’s role to “consideration” not “decision”
• Smart contract (Tier 2) does not auto-execute on external information
• Compliance review for any proposed automated information→governance flow

Rule 7 — Service providers are not stakeholders

Coalition entities and other parties that provide services to a DAO (legal counsel, audit firms, banking partners, KYC vendors, fiat off-ramp partners) are service providers, not stakeholders.

Specifically:

• They are paid for services (per service agreement)
• They do not hold benefit units
• They do not have governance rights
• Their relationship is contractual, not membership

This distinction matters because:

• Service providers have no fiduciary duty to other DAO members
• Service providers’ exit doesn’t trigger succession mechanics
• Service providers can be replaced without governance changes

Enforced:

• Service contracts (not membership agreements) for service providers
• Beneficiary registry only includes stakeholders, not service providers

Rule 8 — Coalition entity governance is separate from DAO governance

Each coalition entity has its own governance, separate from per-property DAO governance:

• Registry has Landseed PBC governance + audit committee
• Exchange (when built) has its own governance
• Fund (when built) has its own governance for investor protection
• Captain Landseed has Landseed PBC governance
• Earth Pulse Network has Landseed PBC governance + relevant partners

These governances are independent. A change in a coalition entity’s governance does not require DAO ratification (and vice versa).

Enforced:

• Coalition entity charters reference only their own governance
• DAO operating agreements reference only their own governance
• Cross-references are limited to interface specs (what each entity does at the boundary)

What integrity rules do NOT achieve

For clarity:

• They do NOT make Landseed-PBC immune to corporate failures (the methodology IP licensing into a foundation is what does that)
• They do NOT eliminate coalition entity reputation risks (a coalition entity’s bad behavior can damage the whole ecosystem; that’s a reputation risk, not an architecture failure)
• They do NOT prevent unintended consequences from interface evolution (annual review is the discipline)
• They do NOT eliminate operational complexity (multi-entity coordination is real)

What happens when integrity rules are violated

Violation	Response
Trust cycle proposed	Reject; restructure
Cross-entity transfer not cryptographically attested	Halt the transfer; resolve before continuing
Coalition entity crosses a bright line	Halt-and-escalate; do not allow operational continuation while violation persists
New coalition entity proposed without interface spec	Block formation until spec exists
Coalition entity attempts to acquire benefit units	Reject; if attempted via informal pressure, escalate
Information→governance flow attempted automatically	Disable; require explicit governance review
Service provider claims stakeholder status	Re-clarify relationship; if intractable, replace service provider
Coalition entity governance entangles with DAO governance	Untangle; restore separation

These responses are operational discipline, not architectural fixes. The rules themselves don’t change.

Annual interface review

Each year, Landseed compliance reviews:

• All coalition entity charters (still aligned with bright lines?)
• All cross-entity interfaces (still one-way trust?)
• All cross-entity transfers (cryptographically attested?)
• All coalition entity governances (still separate from DAOs?)
• All service-provider relationships (still service, not stakeholder?)

Findings are documented and remediated.

Summary

The interface integrity rules collectively ensure that the architecture’s per-property isolation, regulatory perimeter, and trust direction hold even as coalition entities evolve. The rules are operational discipline, not architectural constraints — but they are necessary for the architecture to function safely over decades.

If the rules ever appear to weaken, halt-and-escalate.