Owner Or Founder Guide¶

What To Understand First¶

1. Upgradeability Model
2. Roles And Custody
3. Permission Matrix
4. Threat Model
5. Evidence Status

What You Are Allowed To Decide¶

• Governance structure and signer separation.
• Whether upgrade, emergency, registrar, and operational powers are colocated or split.
• Production readiness gates and evidence requirements.
• Incident escalation authority and external communications.

What You Must Never Do¶

• Put production roles on EOAs.
• Treat a green docs build as protocol assurance.
• Approve a deposit window while governance or readiness evidence is unresolved.
• Collapse roleAdmin, executor, registrar, and guardian roles into one signer set without an explicit risk decision.
• Claim formal verification exists unless artifacts are present.

Operational Responsibilities¶

Maintain the authority map, require evidence for upgrades, keep the guardian path independent, and ensure operators can stop when facts are missing. The founder/owner role does not need to decode every line of Solidity, but must ensure the organization does not rely on undocumented trust.

Failure Modes To Recognize¶

Weak role custody, stale source docs, incomplete evidence, rushed upgrades, emergency pressure, and false confidence from partial tests are governance failures before they become technical failures.

Escalation¶

Escalate immediately for unknown queued upgrades, role-admin transfer, implementation policy drift, deposit readiness drift, slashing, or claim payout anomaly.

Role Operating Guide¶

What This Person Must Understand First¶

The Owner or founder must understand protocol authority boundaries, emergency escalation, signer custody, launch evidence, and residual-risk acceptance. The four questions must stay separate: Upgrade governance asks which code is official, Deposit permissioning asks who may deposit, Custody/readiness asks whether the deposit route is safe, and Economic/claim safety asks whether funds can later leave safely.

Allowed To Do¶

This role may approve governance direction, require evidence, stop unsafe launches when the relevant runbook, permission matrix, and reviewer approval support the action.

Must Never Do¶

This role must never submit ad hoc privileged transactions without review.

Pages To Read In Order¶

1. System Map
2. Permissioned vs Permissionless Deposits
3. Permission Matrix
4. Source Manifest
5. The runbook for the exact action being performed.

Routine Responsibilities¶

Keep evidence current, record decisions, reconcile action tickets to onchain events, and raise drift quickly. Do not rely on memory when a source manifest, event log, or contract read can answer the question.

Incident Responsibilities¶

Stop routine automation for the affected layer, preserve evidence, notify the correct owner, and avoid broad remediation until the failing layer is identified.

Escalation Triggers¶

Escalate on unknown governance actions, mismatched implementation metadata, unexpected allowlist-admin transfer, stale oracle data, slashing/exit anomalies, failed custody readiness, or any claim that cannot be tied to current source and onchain evidence.