docs(runbook): verify fee account trustline before registering tokens or rotating fee account (closes #141)

[rushikeshgarad2024-dev]

Summary of Changes

Addresses Issue #141 and threat model finding DoS.15 (unverified fee account trustlines leading to transaction reverts during protocol fee collection in deposit_with_fee_at / release_with_fee_at):

1. New Pre-flight Verification Tool (scripts/admin/verify-fee-trustline.sh):
   • Implements automated Horizon querying to verify that candidate fee_account G-addresses exist, hold active trustlines for required/registered asset pairs, and have is_authorized: true.
2. Pre-flight Checklist Update (docs/multisig-preflight.md):
   • Added Section 4.B specifying fee account trustline verification requirements before register_supported_token or set_fee_account operations.
3. Operations Runbook & Event Alerting (docs/contract-ops-runbook.md):
   • Documented operational verification commands and recommended event alerting hooks for FeeAccountUpdated and TokenRegistered.
4. Integration with scripts/admin/verify-multisig.sh:
   • Updated guidance step to cross-reference trustline pre-flight checks.

Closes #141.

[almanax-ai]

Business Logic: false positive issuer match in verify-fee-trustline.sh

The trustline match predicate can succeed even when the provided issuer does not match, because it includes (.asset_issuer == $issuer or $code == $issuer). If an operator supplies malformed input (e.g., missing :ISSUER) or an attacker convinces ops to verify only by ASSET_CODE, the script may incorrectly PASS a fee account that lacks the correct trustline, leaving deposit_with_fee_at / release_with_fee_at vulnerable to the same revert/DoS condition this PR aims to mitigate.

Require exact asset_code+asset_issuer matching for credit assets (and reject inputs that are not CODE:ISSUER), so the script cannot pass on code-only matches or wrong issuers.

Suggested change

	'[.[] | select(.asset_code == $code and (.asset_issuer == $issuer or $code == $issuer))] | .[0]')
	'[.[] | select(.asset_code == $code and .asset_issuer == $issuer)] | .[0]')

---

Fix with MCP

Almanax found a vulnerability. Can you take a look and fix it?
Finding ID: 8b0424b8-3a25-4529-bfae-b9d14299c424

Actions

• Reply /almanax ask <question> to ask a follow-up question.
• Reply /almanax dismiss [<reason>] and it won't appear again in future scans.
• Reply /almanax resolve [<reason>] to mark the finding as resolved.
• Reply /almanax severity <level> [<reason>] to override the severity.

[almanax-ai]

Input and Parameter Validation: non-conservative is_authorized default in verify-fee-trustline.sh

For required trustlines, the script treats missing .is_authorized as true (.is_authorized // true). If Horizon omits this field in some responses/edge cases, the script can incorrectly mark an unauthorized trustline as authorized, again undermining the operational DoS mitigation.

Default missing .is_authorized to false when asserting required trustlines, so the script fails closed and forces manual verification.

Suggested change

	IS_AUTH=$(echo "$MATCH" | jq -r '.is_authorized // true')
	IS_AUTH=$(echo "$MATCH" | jq -r '.is_authorized // false')

---

Fix with MCP

Almanax found a vulnerability. Can you take a look and fix it?
Finding ID: deb2bf4e-96f1-4373-b765-d78b568850d8

Actions

• Reply /almanax ask <question> to ask a follow-up question.
• Reply /almanax dismiss [<reason>] and it won't appear again in future scans.
• Reply /almanax resolve [<reason>] to mark the finding as resolved.
• Reply /almanax severity <level> [<reason>] to override the severity.

[rushikeshgarad2024-dev]

Thank you for the review @almanax-ai[bot]!

Updated verify-fee-trustline.sh in the latest commit:

1. Enforced exact .asset_code == $code and .asset_issuer == $issuer matching to eliminate false positives on credit assets.
2. Updated .is_authorized default to fail-closed (.is_authorized // false).

/almanax resolve