Risks · Disposition
Defend, accept, monitor
The disposition framework. Architectural commitments to defend; residual risks to accept; external conditions to monitor.
Defend / Accept / Monitor
The architecture’s risks are categorized into three dispositions:
- Defend: architectural commitments that cannot be relaxed; these are the principles that, if violated, collapse the architecture
- Accept: residual risks we live with; the architecture cannot eliminate them, but they are bounded
- Monitor: external conditions that could shift adversely; not directly controllable, but we track for early warning
This document is the disposition summary. It’s the answer to “what does the architecture stand on?”
What we defend (architecture must hold)
These are the seven binding principles from 00-foundations/03-binding-principles.md. Each is enforced architecturally; violating any collapses the architecture’s regulatory or operational viability.
| Principle | What collapses if violated |
|---|---|
| 1. Per-property isolation | Horizontal common enterprise → securities classification |
| 2. Earth Credits ≠ Governance positions | Investment-contract characterization → securities classification |
| 3. Permissioned membership | Public-offering characterization → securities classification |
| 4. Cryptographic attestation, not testimony | Assay-office thesis collapses; methodology becomes testimony-dependent |
| 5. Templates not customization (with Template C exception) | Audit economics break; operational legibility lost |
| 6. Coalition entities are counterparties, not parents | Trust direction violated; cross-DAO entanglement |
| 7. Graduated smart-contract complexity | Audit cost explodes for templates that don’t need DAOs; technological fragility for cases that don’t justify it |
Defend disposition: any proposed change that violates any of these is rejected. The architecture’s binding principles are non-negotiable.
What we accept (residual risk we live with)
These are real risks the architecture cannot eliminate. We accept them because:
- The cost of eliminating them would compromise the architecture’s binding principles, or
- The risk is bounded enough that operational containment is sufficient, or
- The risk is inherent to the conservation domain (not architecture-specific)
| Accepted risk | Why we accept |
|---|---|
| Some landowners will not engage (architectural complexity) | Some landowners need predictability or simpler instruments; we are not for everyone |
| Some bad actors will destroy property (despite NRD-lite enforcement) | Determined bad actors with land-use rights can destroy faster than legal remedies can restore. Real conservation depends on relationships and reputation, not just legal instruments |
| Some smart contract bugs will happen | Smart contract bugs happen; per-property containment limits blast radius; we accept the architecture’s exposure |
| Cross-border disputes will be hard | Cross-border governance is hard; mediation-first reduces cost; we accept that some disputes will be lawyer-time-expensive |
| Methodology evolution is a permanent operational concern | Methodology will update; some properties may not ratify; operational complexity is real |
| Coalition entity reputation risks | Public will conflate coalition entity bad behavior with the architecture; mitigation is communication discipline, not prevention |
| Earth Credit price uncertainty in early years | First-cohort properties are price discovery; we accept communicating uncertainty to landowners |
| Buffer pool absence affects credit reversal handling | Methodology-level work needed before scaling; not architectural |
Accept disposition: these risks materialize in specific incidents but don’t collapse the architecture. We manage them operationally.
What we monitor (could shift adversely)
These are external factors not under Landseed’s control. We track them for early warning of architectural impact.
| Monitored factor | What could change adversely | Trigger for response |
|---|---|---|
| SEC commentary on DAO governance tokens | Stricter characterization of DAO benefit units | Architecture-level perimeter review |
| CFTC commentary on Earth Credits and similar commodities | Shift to commodity-securities characterization for Earth Credits | Earth Credit / registry separation may need strengthening |
| State DAO LLC statute changes (Vermont, Wyoming, Marshall Islands) | Statute repealed or weakened | Wrapper jurisdiction migration |
| Federal DAO legislation | Hypothetical federal DAO statute | Re-evaluation of state-level wrapper jurisdiction |
| EU MiCA implementation evolution | Stricter ART characterization including governance tokens | Wrapper-jurisdiction confirmation; communication discipline |
| Securities law evolution generally | Howey/Reves jurisprudence shifts | Architecture-level perimeter review |
| Foreign jurisdiction regulatory changes (Argentina CNV, Ecuador, Bangladesh, Madagascar) | Stricter regulatory regimes | Per-jurisdiction perimeter review |
| Property-law statutory evolution (conservation easement statutes, environmental servitude laws) | Changes that affect VECR mappings | Per-jurisdiction template review |
| §170(h) qualified-holder requirements | Tightening that affects affiliated 501(c)(3) structure | Affiliated 501(c)(3) operations review |
| Methodology-stewardship continuity (EC-M-1.1 evolution and steward succession) | Methodology stewardship interrupted | Methodology Foundation/Trust formation |
| Land-trust ecosystem posture | Land trusts treat DAOs as competition | Engagement strategy with land-trust ecosystem |
| Indigenous-rights-advocacy ecosystem | Critique of DAO-based conservation | Template C deployment review; outside review intensification |
| Banking access for Marshall Islands and other offshore wrappers | Banking-restriction tightening | Wrapper-jurisdiction migration |
| Stablecoin regulatory environment (USDC, etc.) | Stricter regulation of stablecoin treasuries | Treasury operational adjustment |
| Climate events affecting deployments | Major catastrophes affecting many properties | Buffer pool draws (per 05-interfaces/05); Foundation board emergency review if pool exceeds 50% draw |
| Methodology-stewardship continuity | Stewards become unavailable, methodology stalls | Foundation formation per 07-execution/05; multi-year transition plan |
Monitor disposition: annual review of all monitored factors as part of compliance. Significant adverse shifts trigger architecture-level response.
How the three dispositions interact
| Scenario | Disposition |
|---|---|
| New regulation makes “cash distribution only” infeasible (we’d have to in-kind) | This would force a Defend → review: do we accept in-kind risk? Or does the architecture pivot? |
| Smart contract bug exploits one Tier 2 deployment | This is an Accept event; per-property isolation contains; we manage operationally |
| Vermont BBLLC statute is repealed | This is a Monitor event triggering Defend response: migrate to alternative wrapper |
| Regulatory shift in Argentina creates exposure | Monitor event; per-jurisdiction perimeter review; if blocking, pause Argentina deployments |
| the co-architect pulls back on Template C | Accept event (Strategic test 13); stage-by-stage co-signing reduces probability; if it happens, the architecture re-evaluates |
The dispositions inform response prioritization. Defend events are architecture-threatening; Accept events are managed operationally; Monitor events require ongoing tracking.
What’s NOT in any disposition
Some things appear in failure-mode discussions but don’t fit the three dispositions:
- Specific property-level events (storm damage, fire, pest outbreak) — these are methodology-layer concerns
- Specific transactional disputes — handled through ordinary legal process, not architecture
- Specific landowner withdrawals — handled through operating agreement procedures
- Specific operational delays — handled through project management
These are operational reality, not architecture-level risks.
What this document is for
This document is the summary disposition. It tells anyone reading the architecture what’s stable, what’s accepted, and what’s being watched. It’s the “operational summary” of the risks documented in 02-pressure-tests.md and the questions in 03-open-questions.md.
For the co-architect specifically: this is the document that summarizes “what could go wrong, and what’s our response framework.” It’s a one-page version of the architecture’s risk posture.
Annual disposition review
The Defend/Accept/Monitor categorization is reviewed annually:
- Have any Accept items become Defend (e.g., we should now defend more vigorously)?
- Have any Monitor items become Accept (e.g., adverse shift has materialized)?
- Have any Defend items become Monitor (e.g., previously-fixed posture is now uncertain)?
This is the periodic recalibration of the architecture’s risk posture.