This document defines the constitutional governance architecture for the Ternary Logic (TL) autonomous protocol. It is established to ensure the long-term survivability, operational neutrality, and perpetual auditability of the system under the non-negotiable No Switch Off mandate.
This constitution defines the protocol itself as the supreme authority. The governance bodies herein created (the Technical Council, the Stewardship Custodians, and the Smart Contract Treasury) are subjects under this constitution. They are granted limited, enumerated powers for the sole purpose of system maintenance, extension, and optimization. They possess no authority to alter the foundational axioms of the protocol.
"In TL, the constitution is not written in parchment but in protocol; it cannot be amended, only better maintained. Governance is the janitor of eternity, not the architect of tomorrow." -Lev Goukassian
This Article establishes the axiomatic, non-negotiable, and immutable foundation of the Ternary Logic system. It defines the protocol as the constitution and the governance bodies as subjects created by, and subordinate to, this constitution. Governance is a mechanism for maintenance and extension, not mutation.
The foundational principles of Ternary Logic are defined as constitutionally immutable. These elements are technically and legally beyond the authority of any governance body, vote, emergency procedure, or protocol-level action. This "substantive rigidity" ensures that the governance bodies constituted by this protocol cannot subsequently alter the fundamental structure of their own creation.
Any proposal, vote, or smart contract function call attempting to modify, suspend, or reinterpret the following elements is considered void ab initio and constitutionally invalid. The core Protocol Contract (defined in Article V) shall be technically constructed to lack any function or administrative privilege capable of effecting such a change.
The Immutable List:
- The Eight Pillars of Ternary Logic.
- The triadic logic structure of the system (
$+1, 0, -1$ ). - The causal sequence of operation: (Epistemic Hold
$\rightarrow$ Immutable Ledger$\rightarrow$ Decision Logs$\rightarrow$ Governance). - The Three Mandates: No Spy, No Weapon, and No Switch Off.
- The evidentiary requirements that form Ternary Logic's integrity.
- The existence and fundamental function of Anchors and the requirement for cross-chain notarization.
- The foundational Goukassian Principle.
This axiomatic framework is designed to prevent meta-constitutional conflicts, such as those that have led to contentious hard forks in other decentralized systems. In Ternary Logic, a majority vote to revert the ledger or violate a core mandate is not merely illegitimate; it is technically impossible.
"No Switch Off' is not a feature. It is the First Cause that makes all other features possible. Governance without termination is governance without ultimate coercion." -Lev Goukassian
The governance bodies are granted limited and enumerated powers to manage the protocol's operational parameters. All powers not explicitly granted to the governance bodies are reserved by the protocol itself.
Permitted Operational Parameters (Subject to Governance):
- Anchor selection, certification criteria, and rotation schedules.
- Cryptographic upgrades (e.g., transition to new hashing algorithms, post-quantum cryptographic standards).
- Protocol performance tuning, network resource optimization, and gas-fee structures.
- The cadence of mandatory third-party technical and financial audits.
- Treasury disbursement rules, grant criteria, and funding allocations.
- Node operator certification rules, performance bond requirements, and the parameters for automated revocation and "slashing".
- Emergency fallback procedures, limited exclusively to network continuity (e.g., Anchor migration).
The Governance Mandate:
Governance shapes the room.
Governance never touches the foundation.
They may maintain TL.
They may extend TL.
They may optimize TL.
But they cannot mutate TL.
This Article defines the separation of powers among the three governing bodies. This tri-cameral structure (Technical, Ethical, and Economic) is designed to create a "three-body equilibrium." It prevents the consolidation of power and system capture by ensuring no single body possesses the authority to unilaterally control the protocol's code, its ethical application, or its financial resources.
Mandate: The Technical Council is charged with the technical evolution, cryptographic security, and operational performance of the TL protocol. Its structure is analogous to a permanent, high-authority "technical oversight committee" common in mission-critical open-source systems.
Obligations:
- Protocol Evolution: To propose, draft, and implement all protocol upgrades necessary for security, performance, and extension.
- Code Stewardship: To maintain the official, public-facing core codebase and system architecture.
- Certification Standards: To define and publish the technical certification standards required for all node operators.
- Network Monitoring: To continuously monitor network health, liveness, and security, and to execute pre-approved emergency fallback procedures in the event of systemic stress.
- Audits: To commission and publish all mandatory third-party technical audits.
Rights:
- Proposal Right: The exclusive right to submit technical upgrade proposals to the Governance Contract.
- Log Access: The right to access all real-time system performance logs and node-monitoring data.
- Revocation Proposal: The right to submit proposals to the Revocation Contract to modify automated slashing or revocation parameters.
Mandate: The Stewardship Custodians serve as the ethical and constitutional guardians of the protocol. Their primary function is to provide binding ethical review, enforce the Immutable Mandates defined in Article I, and act as the system's principal anti-capture safeguard. This body functions as a dedicated "ethical review board", but one that possesses binding, on-chain veto power.
Obligations:
- Mandate Veto: To review every technical proposal submitted by the Technical Council. The Custodians must veto any proposal that, in their judgment, creates a credible risk of violating any Immutable Mandate (e.g., introducing a function that could enable surveillance, in violation of "No Spy").
- Anti-Capture Review: To continuously monitor the governance system, node operator ecosystem, and Anchor network for signs of state, corporate, or insider capture, and to publish findings.
- Fiduciary Oversight: To review and approve the purpose and ethical bounds of all Treasury disbursement rules and grant programs.
- Anchor Oversight: To review and approve the selection criteria for Anchor Host Chains, specifically ensuring geographic, political, and institutional diversity.
Rights:
- Constitutional Veto: The right to cast a binding, on-chain veto against any Type 3 (Joint-Approval) proposal, halting its implementation.
- Audit Access: The right to access all immutable Decision Logs for audit, ensuring transparency of all governance actions.
- Emergency Review: The right to initiate an emergency review of any governance actor or network operator, and to publish a public report of findings.
Mandate: The Smart Contract Treasury is an autonomous, non-political fiduciary agent. It is not a voting body. Its sole mandate is to autonomously fund the system's maintenance and evolution based on verifiable, on-chain rules pre-approved by the other two governing bodies.
Automated Functions:
- Autonomous Disbursement: The Treasury shall automatically release funds (e.g., to maintenance teams, grant recipients, or auditors) only upon the successful on-chain verification of pre-defined, automated milestones (e.g., "protocol upgrade vX.Y is deployed and verified," "audit report Z is published to IPFS").
- Automated Funding: The Treasury shall manage the automated collection and deposit of network fees to ensure its own perpetual sustenance.
Governance Parameters:
The Treasury's behavior is governed, but its actions are autonomous.
- The parameters of disbursement (e.g., "allocate 30% of fees to protocol maintenance," "allocate 20% to ecosystem grants") are proposed by the Technical Council.
- These parameters must be reviewed for ethical alignment and approved by the Stewardship Custodians (see Article IV) before they are encoded as new rules in the Treasury Contract.
- The Smart Contract Treasury has no authority to alter or reinterpret core principles, pillars, or constitutional mechanics. It funds the system; it does not govern it. All changes to TL's foundational architecture remain permanently outside its scope.
"Most constitutions enumerate freedoms. TL's constitution enumerates forbidden futures: No Spy, No Weapon, No Switch Off. Everything else is engineering." -Lev Goukassian
This Article defines the human layer of governance. The composition, terms, and rotation schedules are engineered to balance deep, mature judgment and domain expertise with robust, long-term resistance to capture, power consolidation, and conflicts of interest.
- Size: The Council shall consist of 9 members. This size is deemed small enough to permit decisive technical action while large enough to resist simple capture or collusion.
- Eligibility: Members must possess demonstrable, world-class expertise in one or more of the following fields: cryptography, distributed systems architecture, formal verification, protocol engineering, or large-scale network security. Members are selected as individuals and shall not act as representatives of any corporation or state.
- Diversity: The composition must maintain geographic and institutional diversity. No more than 2 members may be concurrently affiliated with the same primary corporation, university, or government entity.
- Terms: Members shall serve 3-year terms. Terms shall be staggered, with one-third (3) of the Council members rotating or seeking renewal annually.
- Renewal: A member may serve a maximum of three (3) consecutive 3-year terms (9 years total). Following a 9-year service period, a member must observe a mandatory 3-year cool-down period before being eligible for renomination. This model allows the organization to "reap the benefits of an individual's mature judgment and deep knowledge" while enforcing rotation.
- Size: The Custodians shall consist of 11 members. This odd number prevents tied votes on critical veto measures.
- Eligibility: Members must possess demonstrable, recognized expertise and a public track record in one or more of the following fields: constitutional law, systems ethics, regulatory compliance, public-interest technology, international law, or national security (with a focus on mandate compliance, e.g., non-proliferation or digital rights).
- Diversity: The composition must maintain geographic, institutional, and domain (legal, ethical, policy) diversity. No more than 2 members may be concurrently affiliated with the same primary corporation, law firm, university, or government entity.
- Terms: Members shall serve 4-year terms. Terms shall be staggered to ensure continuity.
- Renewal: A member may serve a maximum of two (2) consecutive 4-year terms (8 years total). Following an 8-year service period, a member must observe a mandatory 4-year cool-down period before being eligible for renomination.
To ensure expertise-based selection rather than vulnerability to political capture, a standing, independent Nominating Committee shall be maintained.
- Composition: This committee shall be composed of 7 individuals: 2 outgoing (or term-limited) members of the Technical Council, 2 outgoing (or term-limited) members of the Stewardship Custodians, and 3 external domain experts selected and approved by the existing Custodians.
- Process: The Nominating Committee is responsible for sourcing, vetting, and verifying the credentials of all candidates based on the strict eligibility criteria defined in Sections 3.1 and 3.2.
- Confirmation: The Committee shall present a final slate of qualified candidates for any open seats. The final confirmation of a new member is approved by a Qualified Majority (>=66%) vote of the existing members of the respective body that the candidate is joining.
This Article defines the formal, on-chain mechanics of decision-making. TL shall employ a hybrid governance model. Deliberation, discussion, and proposal drafting shall occur off-chain (e.g., via secure, dedicated forums). The final, binding vote, however, shall be recorded immutably on-chain via the Governance Contract.
A high quorum is required to ensure that all decisions reflect a broad consensus of the active governance bodies and are not passed by a small, active minority.
- Standard Quorum: A quorum of 75% (rounded up) of all active, non-recused members of a body is required for any vote to be considered valid and binding.
- Technical Council: 7 of 9 members.
- Stewardship Custodians: 9 of 11 members.
- Quorum Failure: If quorum is not met, a vote is void, and the proposal must be re-submitted.
Different decision types require different levels of consensus. All thresholds are calculated based on the voting members present (assuming quorum is met).
- Type 1: Simple Majority (>50%)
- Description: For routine, low-risk, or time-sensitive operational matters.
- Applies To:
- Routine performance tuning.
- Setting the cadence for pre-approved audits.
- Execution of emergency fallback procedures (e.g., Anchor migration).
- Body: Technical Council only.
- Type 2: Qualified Majority (>=66%)
- Description: For significant operational changes or new appointments.
- Applies To:
- Modification of node certification rules.
- Rotation or selection of Anchor Host Chains.
- Confirmation of new (non-incumbent) members to either body.
- Body: Technical Council or Stewardship Custodians, acting within their respective domains.
- Type 3: Supermajority (>=75%)
- Description: For high-sensitivity changes to the protocol's logic or financial rules.
- Applies To:
- Approval of new Treasury disbursement rules.
- Major cryptographic upgrades.
- Any upgrade to the core Governance, Treasury, or Revocation contracts.
- Body: Requires Joint Approval (see Section 4.3).
If either body reaches quorum but cannot reach the required majority for a Type-2 or Type-3 action within the defined decision window, the proposal enters a Time-Bound Epistemic Hold. During this period, both bodies must provide written justifications. At expiration, the proposal defaults to rejection unless both bodies independently elevate it for reconsideration. This prevents governance paralysis while upholding caution as the default posture.
The most critical (Type 3) decisions require concurrent approval from both bodies. This is the primary on-chain enforcement of the separation of powers and the core anti-capture mechanism.
Process:
- Proposal: The Technical Council drafts a Type 3 proposal (e.g., a new cryptographic algorithm) and passes it with an internal >=75% supermajority vote.
- Constitutional Review: The proposal is automatically and non-censorably sent on-chain to the Stewardship Custodians for a Mandate Compliance Review.
- Veto or Approval: The Custodians vote.
- If Approved (>=75% supermajority): The proposal is ratified. The Governance Contract is authorized to execute the change (e.g., unlock the contract upgrade path).
- If Vetoed (<75% approval): The proposal is rejected and void. The Custodians must publish a report detailing the constitutional or ethical grounds for the veto. This veto is final.
As defined in Article I, Section 1.1, any vote, proposal, or action intended to modify, suspend, or reinterpret any element from the Immutable List is constitutionally invalid. The Governance Smart Contract shall not contain any function, interface, or logic to process or recognize such a proposal.
"We solved the centralization problem by weaponizing the three-body problem: three chambers in permanent orbital tension, where any two colluding merely destabilize the third, and the system corrects." -Lev Goukassian
This Article details the technical enforcement of this constitution. The smart contract architecture must be simultaneously upgradable for maintenance and extension, yet immutable in its core principles. This paradox is resolved through a modular, proxy-based architecture.
Ternary Logic's governance shall be implemented utilizing the Diamond Standard (EIP-2535). This architecture is essential to technically enforcing the "maintain/extend but not mutate" mandate of Article I.
- The Diamond (Protocol Contract): The central proxy contract serves as the single, stable, and immutable address for all TL governance. Its logic is minimal, acting as a router that delegates function calls to various implementation contracts ("facets"). This proxy contract is the immutable foundation (Article I).
- The Facets (Implementation Contracts): The logic for governance (voting), the treasury (disbursement), and registration (Anchors, nodes) will be contained in separate, modular "facet" contracts.
- The Mandate Enforced: This model allows the governance bodies to "shape the room" by upgrading a facet (e.g., to implement a new voting rule approved via Joint-Approval). It simultaneously prevents them from "touching the foundation," as the core Diamond proxy itself is not upgraded. This modularity also resolves the 24KB smart contract size limit, allowing for complex and feature-rich governance logic.
The TL architecture shall consist of one immutable proxy and four primary upgradable facets.
- Protocol Contract (The Diamond Proxy): This is the immutable core. It maps function selectors to the active facets. Its upgradeability function shall be permanently renounced or frozen immediately after deployment.
- Governance Contract (Facet 1): Upgradable. Encodes the logic from Articles III and IV, including member lists, term limits, quorum requirements, and all voting procedures.
- Treasury Contract (Facet 2): Upgradable. Encodes the autonomous fiduciary logic, managing fee collection and rule-based milestone disbursements.
- Anchor Registry Contract (Facet 3): Upgradable. Maintains the canonical, on-chain list of certified Anchor Host Chains and their rotation rules.
- Revocation Contract (Facet 4): Upgradable. Manages node operator certification, reputation scores, and the automated logic for performance-based slashing and revocation.
All upgradable facets shall utilize the UUPS (Universal Upgradeable Proxy Standard, EIP-1822).
- Technical Rationale: UUPS is preferred over the Transparent Proxy Pattern. The Transparent pattern places upgrade logic in the proxy and requires an admin check on every transaction, incurring significant gas overhead. UUPS places the upgrade logic in the implementation contract (the facet), making the proxy itself "dumber," cheaper, and more efficient, as admin checks only occur during an actual upgrade function call.
- Security and Immutability: This pattern is critical for the "No Switch Off" mandate. The core Diamond proxy contains no upgrade logic. The ability to upgrade is contained within the facets themselves. The upgradeTo function within each facet will be owned by the Governance Contract and can only be successfully called after receiving the ratified Joint-Approval (Type 3 vote) signature. This provides a path for maintenance without compromising the immutability of the foundation.
No new or upgraded contract facet shall be deployed to the production environment until it has received a Triple-Signoff:
- External Audit: A passed, public audit and formal verification by an independent, pre-approved third-party security firm.
- Technical Approval: A >=75% supermajority vote from the Technical Council (verifying technical soundness and security).
- Mandate Approval: A >=75% supermajority vote from the Stewardship Custodians (verifying compliance with Article I).
"The Treasury is not a wallet with a committee. It is a financial perpetual motion machine that funds its own conscience, dispensing virtue on a proof-of-work basis." -Lev Goukassian
This Article defines the physical, network-level decentralization of the governance contracts. To ensure persistence and fulfill the "No Switch Off" mandate, the system's governance state cannot be captive to any single blockchain or consensus mechanism.
The complete Diamond governance architecture (defined in Article V) shall be deployed and maintained on a minimum of five (5) distinct, high-security, and ideologically diverse public blockchains, known as "Host Chains."
This redundancy ensures that no single chain failure, 51% attack, critical bug, or jurisdictional regulatory action on one Host Chain can halt, capture, or terminate Ternary Logic's governance. The canonical state of TL governance is the aggregate consensus of its contracts across all active Anchors. A minimum of five heterogeneous public chains is required to ensure resilience against regional outages, regulatory capture, or the collapse of any single ecosystem. This distribution guarantees TL continuity even if entire jurisdictions or technologies fail. Anchoring is not diversification for its own sake; it is structural survival.
Host Chains shall be selected by the Technical Council (Type 2 Vote) and approved by the Stewardship Custodians, based on a public set of criteria:
- Verifiable Decentralization: Quantifiable node distribution, client diversity, and consensus participation.
- Cryptographic Security: The proven strength and robustness of the chain's consensus algorithm and economic security.
- Long-Term Liveness: Demonstrated economic viability and a consistent record of high uptime.
- Institutional and Jurisdictional Diversity: The set of Host Chains must not be concentrated in any single jurisdiction or under the control of a cartel of affiliated entities.
If a Host Chain fails, is compromised, captured, or formally deprecated by its own community, the Technical Council shall execute an emergency fallback procedure (Type 1 Vote). This procedure is explicitly defined as the power to migrate the governance state from the failing chain to a new, pre-vetted Host Chain, ensuring continuity. The Anchor Registry Contract (Facet 3) maintains the canonical list of active Host Chains, allowing the system to route around failure.
Note on Type 1 Emergency Migration Authority: A Q2 2026 constitutional research audit identified the Type 1 Anchor migration power as the governance architecture's most significant capture vector, as it is exercisable by simple majority without prior Custodian involvement. A retrospective Custodian review right for Type 1 migrations is under consideration as a constitutional amendment via the Joint-Approval process. Full research findings are documented in the Governance folder.
This Article details how the tri-cameral separation of powers (Article II) and the Joint-Approval voting mechanism (Article IV) create a "three-body equilibrium" that no single actor or colluding faction can dominate.
The system is designed to default to "inaction" in the face of ambiguity or conflict, prioritizing safety and mandate compliance over speed.
- Technical vs. Ethical Veto: The Technical Council (technical experts) holds the power of proposal. The Stewardship Custodians (mandate guardians) hold the power of veto. This prevents a technically "efficient" upgrade that is ethically or constitutionally compromising (e.g., a "No Spy" violation) from ever being implemented.
- Ethical vs. Economic Veto: The Custodians approve the purpose of funding (e.g., "Grant for ZK-proof research"). The Treasury Contract, however, autonomously disburses funds only upon verifiable completion of milestones. This prevents the Custodians from abusing the treasury for discretionary, political, or unmerited projects.
- Economic vs. Technical Veto: The Treasury provides autonomous funding, but its rules cannot direct the Technical Council's research or force the implementation of a specific feature. This prevents "economic capture," where the protocol's financial resources are used to co-opt its technical development.
"We replaced 'checks and balances' with cryptographic chastity belts. The Immutable Mandates are not values to be debated; they are axioms that render debate illegitimate." -Lev Goukassian
This equilibrium provides robust defenses against common capture vectors:
- State Capture: A state actor attempting to force a violation of the "No Spy" or "No Weapon" mandate would face an insurmountable barrier. They would need to simultaneously compromise a >=75% supermajority of both the 9-member Technical Council and the 11-member Stewardship Custodians, whose members are geographically diverse, institutionally independent, and ethically vetted. The Joint-Approval mechanism makes this scenario practically impossible.
- Corporate Capture: A corporation attempting to insert proprietary, anti-competitive, or non-neutral code into the protocol would be vetoed by the Stewardship Custodians for violating the system's core principles of neutrality. Staggered terms and diversity rules (Article III) prevent a corporation from "stacking" the bodies over a short period.
- Insider Collusion: A rogue Technical Council cannot push a malicious upgrade without Custodian approval. A rogue Custodian body cannot defund the system (as the Treasury is autonomous) or change the code. Collusion would require capturing both independent bodies simultaneously, a risk mitigated by separate eligibility criteria, staggered terms, and independent nomination.
This Article details the specific legal and technical safeguards that enforce the system's non-negotiable mandate for continuous, uninterrupted operation. The "No Switch Off" protocol is not an active process; it is a permanent, structural condition of the system.
The primary enforcement of the "No Switch Off" mandate is achieved through an absence of function.
- The immutable Protocol Contract (the Diamond proxy, Article V) shall be deployed without any function call for pause(), suspend(), freeze(), or admin_kill().
- It is technically impossible to terminate a system that lacks an "off" switch.
- The only upgradeability path (UUPS on facets) is controlled by the Joint-Approval governance process (Article IV), which is itself constitutionally bound by the "No Switch Off" mandate. A proposal to deploy a "poison" facet designed to halt the system would be vetoed by the Stewardship Custodians as a direct violation of Article I.
- No individual, institution, coalition, or smart contract may terminate the TL system or authorize any action that disables it. Continuity is mandatory and non-waivable. TL may evolve, but it cannot be extinguished.
The "No Switch Off" mandate is physically and geographically guaranteed by the Anchor deployment architecture (Article VI).
The system's liveness is defined by the survival of any one Anchor. Even if 4 of the 5 Host Chains are simultaneously shut down, captured, or fail, the complete Ternary Logic governance state and logic persist on the 5th chain. The system remains fully operational and capable of migrating its state to new, healthy Host Chains.
The only "emergency" power granted to governance is not to stop the system, but to ensure its continuity. The Technical Council's "emergency fallback procedure" (Type 1 Vote) is explicitly defined as a power to migrate governance to a new Host Chain in the event of systemic failure of an existing one. This is a vote for preservation, not for termination.
This Article provides the operational schematics, tables, and workflows that synthesize all preceding Articles into a functional, integrated governance model.
This schedule explicitly defines the separation of powers.
| Governance Body | Mandate | Specific Powers & (Vote Type) |
|---|---|---|
| Technical Council | Protocol Integrity & Evolution | - Propose technical upgrades (Type 3) - Propose Treasury rules (Type 3) - Define node certification rules (Type 2) - Select Anchor Host Chains (Type 2) - Execute emergency continuity fallbacks (Type 1) - Approve routine performance tuning (Type 1) - Confirm new Council members (Type 2) |
| Stewardship Custodians | Mandate Compliance & Anti-Capture | - Veto or Approve all Type 3 proposals (Type 3) - Approve Anchor selection criteria (Type 2) - Confirm new Custodian members (Type 2) - Commission non-technical/mandate audits (Type 2) - Publish anti-capture review reports (N/A) |
| Smart Contract Treasury | Autonomous Fiduciary | - Autonomously disburse funds on milestone verification (Automated) - Autonomously collect network fees (Automated) - Cannot vote or make discretionary decisions |
(Diagram Description)
The organizational chart illustrates a "flat," non-hierarchical structure. It depicts three parallel, independent pillars: Technical Council, Stewardship Custodians, and Smart Contract Treasury.
- An arrow flows from the Technical Council (labeled "Proposal") to the Stewardship Custodians.
- An arrow flows from the Stewardship Custodians (labeled "Veto / Approval") to the Protocol Contract.
- Arrows from both the Council and Custodians point to the Smart Contract Treasury (labeled "Set Disbursement Rules"), demonstrating joint oversight.
- An arrow from the Smart Contract Treasury (labeled "Autonomous Disbursement") points to "Network Maintenance" and "Ecosystem Grants."
This visual representation reinforces that the Council and Custodians are parallel bodies, not subordinate to one another, and that both are required to govern the system's most critical functions.
This technical diagram illustrates the contract architecture based on EIP-2535.
- A central box, labeled "Protocol Contract (Diamond Proxy) - Immutable - (Article I)", serves as the single entry point.
- All external calls (from users or governance) are shown entering this central proxy.
- The proxy contains a "Facet Lookup Table" and arrows (labeled "delegatecall") pointing to four separate contract boxes ("Facets").
- These facets are labeled:
- "Governance Contract (Facet 1) - Upgradable" (Handles voting, terms)
- "Treasury Contract (Facet 2) - Upgradable" (Handles autonomous finance)
- "Anchor Registry (Facet 3) - Upgradable" (Handles Host Chain list)
- "Revocation Contract (Facet 4) - Upgradable" (Handles node slashing)
- This diagram visually demonstrates how the logic (facets) can be upgraded without altering the foundation (proxy).
This flowchart visualizes the Type 3 (Joint-Approval) voting process.
- Start: Technical Council drafts proposal (off-chain).
- Vote 1 (On-Chain): Technical Council votes.
- Decision: [Pass >=75%?]
- No: (End: Proposal Fails).
- Yes: Proposal is automatically forwarded to Stewardship Custodians.
- Vote 2 (On-Chain): Stewardship Custodians conduct Mandate Review.
- Decision: [Pass >=75%?]
- No: (End: Proposal Vetoed. Custodians publish report).
- Yes: Action: Governance Contract is authorized to execute the upgrade (e.g., calls upgradeTo on the relevant facet).
- End: Protocol is successfully upgraded.
This workflow visualizes the automated revocation and slashing process, emphasizing "rule of law" over discretionary action. Operators whose certification is revoked retain the right to a structured appeal. Appeals follow a two-step process: an internal Custodian review panel followed by an independent technical audit commissioned through the Smart Contract Treasury. This ensures fairness without compromising the system's security posture.
- Start: On-chain monitoring services (e.g., Oracles, other nodes) detect node misbehavior (e.g., critical downtime, invalid data submission).
- Trigger: Data is fed to the Revocation Contract (Facet 4).
- Action: The contract autonomously applies the pre-approved penalty based on severity.
- Minor Offense: Automated stake "slashing".
- Severe/Repeat Offense: Immediate Access Revocation. The node's credentials are struck from the active-duty registry.
- Log: The revocation action is immutably written to the public Decision Log.
- Alert (Audit): The Stewardship Custodians are automatically alerted to review the event for pattern analysis and anti-capture monitoring (this is an audit function, not an approval function).
- Appeal: The revoked node operator may file a formal, off-chain appeal to the Technical Council (for technical review) or the Custodians (for rules-process review).
- End: The automated revocation stands unless and until it is overturned by a formal governance vote to re-certify the node.
This diagram illustrates the predictable, continuous annual cycle of governance.
- Q1:
- Annual Technical & Financial Audits are published.
- The independent Nominating Committee convenes to vet candidates for upcoming open seats.
- Q2:
- Council rotations occur (3 members' terms end/renew).
- Custodian rotations occur (2-3 members' terms end/renew).
- Newly confirmed members are seated.
- Q3:
- Technical Council proposes the Treasury disbursement rules and budget for the next 12-month cycle.
- Stewardship Custodians review and vote (Approve/Veto) the proposed Treasury rules.
- Q4:
- Technical Council submits major protocol upgrade proposals for the following year, allowing a long lead-time for public comment and Custodian review.
- Mandate compliance reports are published by the Custodians.
This staggered and cyclical process ensures stability, prevents power vacuums, and establishes a predictable cadence for protocol evolution.
This constitution is the supreme and binding law of the Ternary Logic protocol. All governance actions, smart contracts, and protocol upgrades are subordinate to it. The powers of the Technical Council, the Stewardship Custodians, and the Smart Contract Treasury are derived from this constitution, and they possess no authority beyond that which is explicitly enumerated herein. The Immutable Mandates defined in Article I, Section 1.1, are absolute, perpetual, and may not be abridged by any entity.
"We didn't build a better democracy. We built a better gravity: constant, invisible, and indifferent to opinion. The three chambers don't wield power, they orbit it." -Lev Goukassian
This Article acknowledges the current deployment status of the governance architecture and establishes the evidentiary foundation supporting this constitution.
This constitution is currently instantiated at the software governance layer. The procedural guarantees defined herein, including tri-cameral separation of powers, Joint-Approval supermajority requirements, Time-Bound Epistemic Hold, and cross-chain Anchor persistence, are enforced by smart contracts executing on public blockchains.
Full physical enforcement of the Immutable Mandates requires deployment of DITL (Delay-Insensitive Ternary Logic) hardware, where the Epistemic Hold is not a policy commitment but a physical voltage state at half-Vdd, where No Log = No Action is a circuit-level interlock enforced by hysteretic C-elements, and where No Switch Off is the structural absence of any kill circuit in silicon. Until that hardware is deployed, this constitution operates in a transitional mode: procedurally enforceable, not yet physically guaranteed.
The governance bodies acknowledge this distinction. Software governance provides accountability, auditability, and coordination. Hardware governance provides enforcement. Both are necessary. Neither alone is sufficient.
In Q2 2026, this constitution was subjected to a comprehensive independent research audit examining the Technical Council, Stewardship Custodians, and Smart Contract Treasury against adversarial failure models, historical capture precedents, post-quantum cryptographic timelines, and the human-AI adversarial frontier as of Q2 2026.
The research program produced the following findings of constitutional significance:
- The Type 1 emergency Anchor migration authority (Article VI, Section 6.3) was identified as the architecture's largest single capture vector and is the subject of a proposed constitutional amendment via the Joint-Approval process.
- The mandatory Custodian veto obligation is enforceable at the social and legal layer only. Against state-level legal compulsion combined with synthetic evidence at Q2 2026 human detection rates, DITL hardware enforcement is required for full Mandate protection.
- The rule-accretion pathway, where three bodies acting within permitted scope can cross the janitor/architect boundary through cumulative operational rule-encoding, was identified as a novel constitutional tension requiring ongoing Custodian vigilance.
Complete research documentation, confidence-marked findings, and the 15-item priority update table are published in the Governance research folder.
Hardware reference: DOI: 10.5281/zenodo.18716142
Published framework: DOI: 10.1007/s43681-025-00910-6
Primary Contact: leogouk@gmail.com
Successor Contact: support@tl-goukassian.org
(see Succession Charter)