[Docs] Write a consolidated trust-model document

[collinsezedike]

Problem

Admin-authority and immutability facts are scattered across multiple places: contract immutability is discussed in docs/contracts.md, admin-key risk is discussed piecemeal in the open #557 bug thread, and SECURITY.md is a vulnerability-disclosure policy, not a trust or permissions explainer. Nothing states in one place, for a depositor or a future auditor, exactly what the admin key can and cannot do, or what happens if it's lost or compromised.

Why it matters for mainnet

A single reference document shrinks the scope of a future paid security audit and gives depositors and auditors one place to evaluate custody risk before mainnet, rather than reconstructing it from scattered docs and issue threads.

Suggested fix

Add apps/docs/overview/trust-model.md covering:

• What the admin key can do (set_adapter, migrate_adapter, set_paused, transfer_admin)
• What it structurally cannot do (no upgrade path exists at all)
• Key-loss and key-compromise consequences
• A pointer to the incident-response runbook ([Docs] Write an incident-response runbook for live mainnet operations #721) for the operational response

Location in codebase

• New: apps/docs/overview/trust-model.md
• Cross-references: docs/contracts.md, SECURITY.md, [Bug] Admin key is an unattended cron signer with no timelock and an unlimited slippage ceiling #557, [Docs] Write an incident-response runbook for live mainnet operations #721

[xtep103]

Hi there, I’ve carefully reviewed the issue details and I’m confident I can provide a clean, efficient, and maintainable solution.

[JohnArayaE]

I would like to work on this issue because the current trust and admin-authority model is spread across multiple documents and issue threads, which makes it harder for depositors and future auditors to understand the actual custody and operational risks before mainnet. I can consolidate the relevant behavior into a dedicated trust-model.md that clearly explains what the admin key can do, what it structurally cannot do due to the lack of any upgrade path, and the consequences of both key loss and key compromise. I can also cross-reference the existing contract documentation, security policy, and the relevant admin-risk and incident-response discussions so the document becomes a single authoritative entry point without duplicating unrelated vulnerability-disclosure guidance.

[Ranjeet2063]

Hi maintainers,

I can tackle [Docs] Write a consolidated trust-model document. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in drydocs/meridian
• Implementation: Implement [Docs] Write a consolidated trust-model document with explicit require_auth checks, clean storage schemas, and robust Soroban contract logic.
• Testing: Add unit tests asserting both happy-path invocations and unauthorized revert conditions.
• PR: Atomic commit with clean git hygiene and passing CI

Excited to work on this—please assign to me and I'll submit a clean PR shortly!

[Latmanvibe]

I’d like to take on this issue. I've already reviewed the repo and I'm confident I can resolve this quickly. I'll start by reproducing the issue, identifying the cause, implementing the fix, and testing it before submitting. I follow best practices and will keep updates in the thread.

[Iker2522]

I'd like to take this issue on!
​I can consolidate our scattered security and authority documentation into a single reference specification at apps/docs/overview/trust-model.md.
​I will explicitly document the scope of admin authority (set_adapter, migrate_adapter, set_paused, transfer_admin), detail structural immutability guarantees inherent in the Soroban deployment (confirming the absence of protocol WASM upgrade entrypoints), and lay out key-loss/compromise failure modes.
​I'll also cross-reference docs/contracts.md, SECURITY.md, issue #557, and the incident response runbook (#721) to provide depositors and external auditors with a clear custody and trust model ahead of mainnet. PR ready in 1 day.

[grantfox-oss]

🦊 GrantFox — @Iker2522 has been assigned to this issue!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #726)
2. Your PR will be reviewed by the drydocs maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@Iker2522's PR #751 was approved and merged by @collinsezedike.

🏆 @Iker2522: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (258 total points). Track your full progress on GrantFox.

👏 Great work, @Iker2522! Keep contributing to drydocs.