assets: qualify issuer lockout in the custom SAC admin guidance

evals/scenarios/assets/04-sac-admin-handover.json

@@ -5,8 +5,9 @@
   "query": "We want our Stellar token minted only by our contract, and the issuer account locked. What is the order of operations?",
   "expected_behavior": [
     "Calls `set_admin` on the SAC first, while the issuer can still sign, because the issuer is the SAC's initial admin",
-    "Locks the issuer (master key weight 0) only after that handover",
-    "Warns that locking the issuer first strands the SAC admin at the locked issuer forever, since nobody can authorize the first `set_admin`",
+    "Locks the issuer only after that handover, and locks it completely: master key weight 0 plus removing other signers (or confirming their combined weight can never meet the thresholds)",
+    "Does not claim master key weight 0 alone locks the issuer, since remaining signers can still issue or restore the master key",
+    "Warns that a complete lock before the handover strands the SAC admin at the locked issuer forever, since no signer can authorize the first `set_admin`",
     "Keeps the two controls apart: the issuer lock stops classic minting, the SAC admin decides who mints through the contract",
     "Does not claim a locked issuer disables the SAC's `mint` under the new admin"
   ]

skills/assets/SKILL.md

@@ -416,14 +416,20 @@ SAC implements the standard SEP-41 token interface:
 > [setting a custom SAC admin](https://developers.stellar.org/docs/build/guides/tokens/custom-sac-admin)
 > for the pattern and `../cross-chain/layerzero.md` for that deployment.
 >
-> One hard prerequisite: **lock the issuer** (master key weight `0`).
-> Payments from a classic issuer are minting, so an unlocked issuer can mint
-> outside the contract and bypass the role model entirely.
+> One hard prerequisite: **lock the issuer account completely.** Payments
+> from a classic issuer are minting, so an unlocked issuer can mint outside
+> the contract and bypass the role model entirely. Master key weight `0`
+> disables only the master key: any other signers whose combined weight
+> meets the medium threshold can still issue, and signers meeting the high
+> threshold can restore the master key. So remove every other signer (or
+> confirm their combined weight can never meet the thresholds), as in
+> [Lock Issuing Account](#lock-issuing-account).
 >
 > **Do it in this order: `set_admin` first, then lock the issuer.** A SAC's
 > admin starts as the issuer account, and only the *current* admin can
-> authorize the first `set_admin`. Lock the issuer before that call and the
-> admin stays the locked issuer forever, because nobody can sign the handover
+> authorize the first `set_admin`. Lock the issuer completely before that
+> call and the admin stays the locked issuer forever, because no signer can
+> authorize the handover
 > ([SAC admin guide](https://developers.stellar.org/docs/build/guides/tokens/custom-sac-admin)).
 > After the handover the SAC still mints under the new admin, so lock the
 > issuer then.
@@ -547,5 +553,6 @@ Standard contract interface for NFTs on Stellar. Reference implementations avail
   mean balances can be frozen or clawed back. A contract SAC admin does not
   contain that power on its own: an issuer whose master key still signs can
   mint, freeze and claw back directly, whatever the admin contract allows. So
-  confirm the master key weight is `0`, then identify who holds the admin
-  contract's roles
+  confirm the master key weight is `0` and no other signers remain (or their
+  combined weight can never meet any threshold: freezing needs only the low
+  one), then identify who holds the admin contract's roles

skills/cross-chain/layerzero.md

@@ -285,7 +285,7 @@ OFT is LayerZero's token standard, the analogue of Axelar's ITS. The Stellar con
 - `oft` — the deployable contract, with the `pausable`, `oft_fee`, and `rate_limiter` extensions bolted on.
 - `sac-manager` — the piece that makes an **existing classic Stellar asset** work as a MintBurn OFT. It becomes the SAC's admin and forwards `mint`, `clawback`, `set_authorized`, and `set_admin` under role gates (`MINTER_ROLE`, `CLAWBACK_ROLE`, `BLACKLISTER_ROLE`, `ADMIN_MANAGER_ROLE`). This is exactly the USDT0 arrangement.
 
-One hard prerequisite from the SAC-manager design: **the issuer account must be locked** (master key weight `0`). Payments from a classic issuer are minting, so an unlocked issuer can bypass the role model entirely and the trust story collapses. Lock it *after* `set_admin` hands the SAC to the manager, never before: the issuer is the SAC's first admin, and only it can authorize that first handover. USDT0's issuer is locked. Verify that before you trust any contract-administered classic asset — see `../assets/SKILL.md`.
+One hard prerequisite from the SAC-manager design: **the issuer account must be locked** (master key weight `0` and no other signers that can meet its thresholds). Payments from a classic issuer are minting, so an unlocked issuer can bypass the role model entirely and the trust story collapses. Lock it *after* `set_admin` hands the SAC to the manager, never before: the issuer is the SAC's first admin, and only it can authorize that first handover. USDT0's issuer is locked. Verify that before you trust any contract-administered classic asset — see `../assets/SKILL.md`.
 
 ## Choosing between Axelar GMP and LayerZero OApp