diff --git a/bip-XXXX/guardian-fsm.png b/bip-XXXX/guardian-fsm.png
new file mode 100644
index 0000000000..bfb2ac5a3c
Binary files /dev/null and b/bip-XXXX/guardian-fsm.png differ
diff --git a/bip-XXXX/guardian-monitoring.png b/bip-XXXX/guardian-monitoring.png
new file mode 100644
index 0000000000..152a4b7d64
Binary files /dev/null and b/bip-XXXX/guardian-monitoring.png differ
diff --git a/bip-guardian-wallet.mediawiki b/bip-guardian-wallet.mediawiki
new file mode 100644
index 0000000000..95eee4f4cd
--- /dev/null
+++ b/bip-guardian-wallet.mediawiki
@@ -0,0 +1,316 @@
+<pre>
+  BIP: TBD
+  Layer: Applications
+  Title: Guardian Address Wallet Implementation
+  Author: Bitcoin Guardian <bitcoinguardian@proton.me>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
+  Status: Draft
+  Type: Standards Track
+  Created: 2025-09-19
+  License: BSD-3-Clause
+</pre>
+
+==Abstract==
+
+This proposal introduces the concept of a Guardian Address and defines a standard signalling mechanism that allows bitcoin wallets to become locked in response to an activation event. A single external control address triggers a security lockdown across one or more unrelated wallets without requiring any on-chain linkage between them. The goal is to prevent theft of bitcoin by enabling users to broadcast a standardized on-chain lock that causes cooperating wallets to enter a restricted mode, disabling the ability to spend UTXOs under duress.
+
+The design allows a separation of key material between the user's spending wallet and a Guardian Address; a discrete identity that signals lock state changes via a transaction embedding data in an <code>OP_RETURN</code> (~$1 at 2.31 sat/vB, ~1BTC=124K USD). This enables emergency responders, user level software, and wallet applications to recognize a distress signal without exposing user spending address(es) or balances. Rapid wallet responses with fast wallet locks (95% signal detection in <10s on testnet3) enable coordination with a physical response.
+
+Adoption requires minimal overhead for wallet developers. This approach does not alter spending rules. It is a voluntary signalling protocol that requires adoption by wallet and custodial software to be effective. BIP compliant wallets will be able to offer this security mechanism without compromising privacy or usability. This standard is intended to be optional and without breaking compatibility for existing wallets or nodes.
+
+==Motivation==
+
+Bitcoin users are increasingly the targets of physical threats including robbery and coercion.<ref>Investigating Wrench Attacks, DOI: 10.4230/LIPIcs.AFT.2024.24</ref>
+A non-exhaustive list is maintained with details of physical attacks on bitcoin users<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>, which provides some insight into the prevalence and severity of attacks. Notably the incidence of attacks is also increasing. Security controls have been implemented in some self-hosted wallets as a means to prevent theft of bitcoin. One such is a decoy wallet, which presents a wallet with a smaller balance of bitcoin when a duress PIN is entered. However, this comes with two significant downsides:
+
+* An assumption is made that the attacker does not know about or understand the purpose of a decoy wallet. If a sophisticated attacker is able to link an address to the real world identity of the user, they may already know the true balance of the bitcoin holder. If the attacker does not know the balance of the user they are attacking, they may still suspect the user has unlocked a decoy wallet given the lower than anticipated balance.
+* In the case that the attacker does not know the wallet opened is a decoy wallet, the attack still results in the loss of bitcoin for the user.
+
+Current self-custody solutions do not provide a safe way to respond under physical duress without risking loss of funds. In addition, participants in the Bitcoin ecosystem commonly use both self-hosted and centralized services<ref>https://river.com/learn/how-many-people-use-bitcoin/</ref>. There's no mechanism that currently exists that can act as a self-sovereign "kill switch" for both user scenarios of a self-hosted wallet or a user with a self-hosted and centralized wallet.
+
+In addition, existing self-custody solutions do not support integration with a privacy perserving response to physically protect users.
+
+This proposal introduces an interoperable mechanism to:
+
+* Allow users to trigger a wallet lockdown using a separate device or operation.
+* Preserve privacy by decoupling the Guardian Address from wallet addresses.
+* Enable wallet software to observe chain state and mempool to react defensively, signalling an active attack.
+* Protect a multiple wallet user (e.g., self-custodial wallet, exchange account, institutional wallet, custodian) with a single on-chain emergency trigger.
+* Allow businesses or multi-user custodial setups designating a Guardian Address to coordinate responses and align with risk management frameworks.
+
+==Specification==
+
+===Wallet Behavior===
+
+The wallet Guardian lifecycle has four distinct states as visualized in this finite state machine:
+
+[[File:bip-XXXX/guardian-fsm.png|thumb|Guardian FSM]]
+
+For each state, the order of operations MUST be adhered to as defined in this BIP.
+
+====No Guardian Configuration====
+
+This is the state of an unconfigured Guardian Address in a wallet. No Guardian Addresses are monitored for protocol signals. No action will be taken in the wallet if any Guardian Address signals a state change. This is also the behavior of non-cooperating BIP wallets that do not implement the standard, ensuring this specification is kept optional and will not affect the operation of existing wallets or nodes.
+
+====Guardian Addition====
+
+* Wallets MUST allow only one Guardian Address at a time. If one is already configured, wallets MUST require the user to remove it first (see Guardian Removal).
+* Wallets MUST reject any address that matches a spending address managed by the wallet, to enforce key separation and accidental spending of the Guardian signal UTXO.
+* Wallets MUST ensure that a Guardian Address maintains at least one reserved UTXO for signalling purposes.
+* Wallets MUST validate the address by querying the blockchain and mempool for signals:
+** MUST Collect all valid signals from the Guardian Address with an <code>OP_RETURN</code> signal matching the grammar: <code>guardv1.Lock=(true|false)#<nonce></code>, case sensitive, ASCII raw ≤40 bytes. Signals MUST match the grammar defined in BIP-A (note: placeholder until BIP assignment).
+** MUST Sort them by nonce in ascending order.
+** MUST Reject if no signals exist (address not instantiated) or if the highest nonce signal sets <code>Lock=true</code>. This prevents accidental locking of the wallet with a Guardian Address outside of the user's control.
+** MUST Reject if the highest nonce is 0 (invalid instantiation) or exceeds a practical high value (e.g., >65,535; wallets SHOULD alert users for high values to indicate a potential nonce exhaustion issue).
+* If valid, store the address state and its current highest nonce locally.
+* Wallets MUST transition to Guardian Monitoring if these operations complete.
+
+====Guardian Monitoring====
+
+[[File:bip-XXXX/guardian-monitoring.png|thumb|Guardian Monitoring Substate]]
+
+====Guardian Address Polling====
+
+* If the previously checked block is not set (the wallet is polling the Guardian Address for the first time) wallets MUST poll the Guardian Address from activation block height 914021 onwards (note: placeholder block height will be updated if the BIP progresses to a future BIP assigned height). This is to prevent wallets from polling the entire chain history for the Guardian Address signals.
+* The configured Guardian Address MUST be sourced from the same storage as used in the Guardian Addition.
+* Addresses other than the configured Guardian Address MUST NOT be polled for Guardian Monitoring.
+* The configured Guardian Address SHOULD be polled every 30 seconds. The lower the polling interval, the faster the wallet can respond to the user triggering the lock of the wallet.
+* The configured Guardian Address MUST be checked every time a new block is created, even if the block is produced before the polling interval.
+* The Guardian Address MUST be polled for transactions that are pending in the mempool.
+* Signal transactions MUST be treated equally whether they are included in a block or still in the mempool.
+* Wallets MUST warn users if the Guardian balance drops to zero or UTXOs are moved without a valid signal <code>OP_RETURN</code>.
+* Wallets MUST validate the address by querying the blockchain and mempool for signals:
+** Collect all valid signals from the Guardian Address with an <code>OP_RETURN</code> signal matching the grammar: <code>guardv1.Lock=(true|false)#<nonce></code>, case sensitive, ASCII, ≤40 bytes. Signals MUST match the grammar defined in BIP-A<ref>BIP-A https://github.com/bitcoin/bips/</ref>
+** Sort them by nonce in ascending order.
+** Reject if the highest nonce is 0 (invalid instantiation) or exceeds a practical high value (e.g., >65,535; wallets SHOULD alert users for high values to indicate potential nonce exhaustion issues).
+* Wallets MUST store the current block as the previously checked block. This optimizes for speed at wallet startup.
+* Wallets MUST transition to Guardian State Evaluation if signals present.
+* Wallets MUST wait for the polling interval before checking for new signals.
+
+====Guardian State Evaluation====
+
+=====Nonce Conflict Resolution=====
+
+Guardian signals use a monotonic nonce to prevent replay attacks and ensure deterministic evaluation of the Guardian state. Wallets MUST resolve conflicts between signals using the following rules:
+
+=====Monotonicity=====
+
+* Nonces MUST be strictly greater than the last observed valid nonce.
+* Wallets MUST ignore any signal with a nonce less than or equal to the locally stored nonce of the configured Guardian Address.
+* Wallets MUST warn the user if a stale nonce is observed.
+
+=====Duplicate Nonces=====
+
+* If two signals share the same nonce and are both confirmed on-chain, the transaction included at the earliest block height MUST take precedence.
+* If two signals share the same nonce and are both unconfirmed in the mempool, wallets MUST treat the first seen transaction (by mempool arrival time) as canonical until confirmation.
+* Once one of the duplicates is confirmed, the confirmed transaction MUST override any unconfirmed duplicate. Local storage MUST be updated accordingly.
+* Wallets MUST warn the user if duplicate nonce usage is detected with different payloads.
+
+=====Invalid Nonces=====
+
+* Nonces are 32 bit unsigned integers (0 ≤ nonce ≤ 2^32-1). Values outside this range MUST be rejected and MUST warn the user.
+* Wallets SHOULD alert the user if the nonce exceeds a high value (e.g., 65,535) to indicate possible nonce exhaustion or misconfiguration.
+
+=====Mempool Conditions=====
+
+* Wallets MUST treat a signal as effective once it is visible in the mempool, without waiting for block inclusion.
+* If such a signal later disappears (due to eviction, replacement, or block reorg), wallets MUST retain the resulting state until a higher nonce signal is observed. This ensures wallets are locked in adversarial mempool conditions. Store a local <code>signal_observed</code> record that includes <code>txid</code>, <code>nonce</code>, <code>observed_time</code>, and <code>state</code> (<code>Lock</code>/<code>Unlock</code>) so users can audit why the wallet Guardian state has changed.
+* Wallets MUST NOT revert to an earlier state purely because the mempool transaction disappeared.
+* To mitigate censorship, users SHOULD broadcast signals to multiple mining pools.
+
+=====Latest State Selection=====
+
+* At any given evaluation, the signal with the highest valid nonce MUST be interpreted as the latest Guardian state, regardless of confirmation status.
+* Signals MUST be processed in ascending nonce order to ensure sequential evaluation.
+* If there is a state delta between the received signal and local storage, wallets MUST transition with the highest nonce signal to the Guardian Lock Change substate.
+* If there are no state changes, wallets MUST transition to Guardian Address Polling substate.
+
+====Guardian Lock Change====
+
+* Wallets MUST update the Guardian lock state in local storage with the signal presented.
+* Wallets MUST update the latest used Guardian nonce in local storage with the signal presented.
+* Wallets MUST update the global Guardian lock state user interface and allow UTXOs in the wallet to be spent according to lock state. If the lock state is true, wallets MUST NOT allow UTXOs in the wallet to be spent.
+* Wallets MUST NOT automatically unlock after any time period or modify state in local storage from sources other than signals from the configured Guardian Address.
+* Wallets MAY provide the user a pathway to view funds and history, but MUST NOT broadcast new transactions if Guardian Locked.
+* Wallets MUST transition into the Guardian Address Polling substate after the state change.
+
+====Guardian Removal====
+
+* The Guardian Monitoring substate MUST currently be Guardian Address Polling.
+* Wallets MUST validate the existing configured Guardian Address in local storage is unlocked.
+* If the Guardian Address state is locked, wallets MUST NOT allow the removal of the Guardian configuration.
+
+==Attack Scenarios==
+
+====Device Theft====
+
+Alice the attacker. Bob the Bitcoin user. Alice coerces Bob under duress to login to his device and applications. Bob's device contains a self-hosted wallet, a Bitcoin exchange application, access to Bob's e-mails, and a two-factor authentication application. After forcing Bob to unlock the device and provide access, Alice takes the device and begins to attempt the Bitcoin theft.
+
+Prior to the attack, Bob configured a Guardian Address across all of his Bitcoin wallets. Though he no longer has his device as it has been stolen by Alice, Bob broadcasts a Guardian Lock message to the Bitcoin blockchain using a pre-signed transaction that he has available outside of the stolen device. Centralized services Bob uses have recognized the distress signal and accounts have been frozen. The self-hosted wallet is Guardian Locked and does not allow UTXOs to be spent. Despite having all the information to gain access to Bob's collective Bitcoin holdings, Alice's attack has not resulted in the loss of any Bitcoin.
+
+After the attack is over and the threat has been mitigated, Bob is able to recover access to his wallets by broadcasting a Guardian Unlock transaction with the private key of the Guardian Address.
+
+If Bob regains the device, he is able to recover access to his wallet(s) by broadcasting a Guardian Unlock transaction with the private key of the Guardian Address. No UTXOs could be spent while the device was stolen since Bob locked the wallet(s). Now Bob has unlocked the wallet(s) he has the ability to spend UTXOs that were previously locked.
+
+====Public Figure====
+
+Alice the attacker. Bob the Bitcoin public figure. Bob's public status makes him a target for threat actors. Bob wants a balance between his own personal freedom and security from physical attacks. He keeps a private security team on response near his residence, but lives in his family house with privacy.
+
+Alice is an intruder that is attempting to break into the house to demand bitcoin be transferred. A security automation system recognises threat and locks wallets via broadcasting a pre-signed Guardian Lock transaction. This locks Bob's wallets and prevents spending of UTXOs through theft.
+
+The security team has also been alerted since they monitor the Guardian Address. They do not know which wallets belong to Bob, maintaining his privacy while keeping his bitcoin safe. His physical security has been protected with the response ensuring his family's safety.
+
+==Threat Model and Limitations==
+
+Guardian Addresses will not protect wallets that are airgapped or otherwise unable to query address state from the latest block height.
+
+If a Guardian Address key is lost or compromised, the user MUST rotate to a new Guardian Address. Wallet funds are unaffected since the Guardian cannot spend UTXOs, but monitoring and <code>Lock/Unlock</code> state depends on a secure Guardian.
+
+This mechanism provides resilience if Guardian keys or pre-signed transactions are not accessible under coercion. It does not protect if attackers demand Guardian material directly or prevent the broadcast of a lock signal.
+
+Guardian provides signaling and coordination, not enforceable spending constraints. It is therefore effective in some coercion or theft scenarios, but not all. The following table summarizes the expected impact of the Guardian Address mechanism under various threat scenarios, with and without external monitoring (e.g., security teams, automated alerts, or third-party services actively watching the Guardian Address for signals). External monitoring enhances deterrence by acting as a distress beacon, potentially triggering physical or operational responses that disrupt an attacker's plans.
+
+{| class="wikitable"
+! Threat
+! Guardian Impact (No External Monitoring)
+! Guardian Impact (With External Monitoring)
+|-
+| '''Device Theft''' (phone/laptop stolen)
+| ✅ Lock can be broadcast remotely, rendering the attacker's copy of the wallet unusable. Funds remain safe until the user broadcasts an Unlock signal.
+| ✅ Same as without monitoring, plus external responders (e.g., security team) are alerted to the theft via the Lock signal, potentially enabling recovery efforts or tracking.
+|-
+| '''Custodian Account Compromise'''
+| ✅ Custodian may freeze withdrawals or require manual review upon Lock, limiting exposure for centralized accounts.
+| ✅ Enhanced by external monitoring, as custodians or third parties can act faster (e.g., freezing accounts or notifying authorities) upon seeing the Lock signal in the mempool.
+|-
+| '''Travel in Unsafe Jurisdictions'''
+| ✅ User may proactively Lock funds before exposure, reducing risk of forced spending. Pre-signed transactions enable rapid response without carrying keys.
+| ✅ Lock signal can alert local or remote responders (e.g., private security), increasing deterrence as attackers may fear intervention, especially in high-risk areas.
+|-
+| '''Opportunistic Mugging''' ("hand over your wallet now")
+| ⚠️ A Lock may be triggered via voice/automation or pre-signed transaction if the user can safely broadcast it, but success is not guaranteed under immediate threat. Signal Boxes improve chances with diverse activation methods.
+| ⚠️/✅ External monitoring improves outcomes: the Lock signal could alert nearby responders (e.g., police or security), deterring the attacker if they suspect intervention. Success depends on response speed and attacker awareness.
+|-
+| '''Sustained Coercion''' (attacker controls victim)
+| ❌ Guardian cannot guarantee safety; an attacker may escalate threats to force disclosure of keys or prevent lock broadcast. Physical separation of pre-signed transactions mitigates but doesn't eliminate risk.
+| ⚠️ Limited protection, but external monitoring may deter escalation if the attacker knows the Lock signal could trigger a physical response (e.g., police or security team arrival). Effectiveness depends on response speed and attacker's knowledge of the Guardian.
+|-
+| '''Loss or Theft of Guardian Key'''
+| ⚠️ Wallet remains spendable; signaling is disabled until rotated to a new Guardian Address. A leaked pre-signed Lock transaction may cause a one-time griefing Lock, but is recoverable with an Unlock signal.
+| ⚠️ Same as without monitoring. External responders may still act on a griefing Lock, causing temporary inconvenience but not affecting fund security. Users must rotate the Guardian Address promptly.
+|}
+
+Guardian Addresses should be considered an additional layer of defense against common theft and coercion scenarios. It MUST NOT be relied upon as complete protection against determined physical attacks. Users leveraging external monitoring (e.g., via APIs, watchtowers, or private security integrations) can enhance deterrence, as the Lock signal serves as a distress beacon, but success depends on the speed and reliability of the response mechanism.
+
+==Compatibility==
+
+The proposal is backwards compatible with existing wallets and Bitcoin nodes as it uses standard address formats and <code>OP_RETURN</code>. Non-cooperative wallets will ignore the signalling mechanism. This BIP does not attempt to cryptographically restrict spending conditions at the consensus layer.
+
+Vault and covenant constructions (e.g., pre-signed vaults, deleted key covenants, or future consensus changes such as <code>OP_VAULT</code> or <code>OP_CHECKTEMPLATEVERIFY</code>) provide enforceable spending constraints that protect coins even if signing keys are compromised. These tools are powerful for self custody, but they apply only to UTXOs that have been intentionally placed under covenant rules, and they cannot directly influence how centralized custodians manage user balances.
+
+The Guardian Address standard is intended to be complementary to spending rule mechanisms. It can operate across both self-hosted and custodial wallets, providing a uniform way to trigger emergency responses. This BIP requires no changes to Bitcoin consensus and can be deployed immediately by cooperating wallet software and service providers. It can be combined with vault implementations. For example, a Guardian Lock signal could trigger a watchtower or co-signer to broadcast a pre-signed re-vault transaction, or could instruct a custodian to freeze withdrawals pending further verification.
+
+In this layered model, spending rules provide strong technical enforcement, while the Guardian Address provides operational coordination and rapid signalling across diverse custody wallets. Spending rules and Guardian Addresses are synergistic in this respect.
+
+The minimum protocol signalling payload in an <code>OP_RETURN</code> output is 19 vBytes for a <code>Lock</code> and 20 vBytes for an <code>Unlock</code> in version 1 of the protocol. The transaction is built with 20 vBytes for the canonical identifier and operation, and 20 vBytes for the monotonic nonce. The protocol is lightweight enough to ensure Guardian signalling transactions will be relayed by nodes with a default maximum <code>OP_RETURN</code> transaction limit of 40 vBytes, such as some Bitcoin Knots deployments.
+
+==Security Considerations==
+
+This signalling mechanism is an application layer security feature and does not change consensus rules or script enforcement.
+
+A griefing vector exists where an unauthorized third party broadcasts a <code>Lock</code> signal from the Guardian Address. This could happen if the griefing attacker gains access to the pre-signed <code>Lock</code> signal transaction and broadcasts it to the mempool. However, this lockout is temporary, recoverable, and fully under the user's control. A monotonic nonce is included in each protocol signal so that even if a pre-signed transaction is obtained and used by an attacker, it may only be used once, limiting the impact of this to a single occurrence. This griefing vector is further mitigated by user education of secure pre-signed transaction storage. The trade off favors wide usability and deployment over strict tamper resistance hardware requirments, since key material is not required to be carried by the user.
+
+Wallets will always retain the ability to reset their Guardian state by creating a new transaction with <code>Lock=false</code> signed by the same Guardian private key and the incrementing monotonic nonce.
+
+Users MUST ensure their pre-signed Lock transactions reference a stable UTXO. Wallets SHOULD warn users if the UTXO required for a pre-signed <code>Lock</code> transaction is no longer available.
+
+Non-RBF eliminates the ability to replace pre-signed <code>Lock</code> transactions with a tampered <code>OP_RETURN</code>, which is crucial for the signal integrity and nonce based replay protection.
+
+This design intentionally avoids requiring secure enclaves or hardware protected state. Instead, the device that triggers the lock stores only a pre-signed transaction and not signing material, reducing the risk of key material compromise while still enabling <code>Lock</code> activation.
+
+Users MAY use hardware for managing Guardian key signing with secure storage.
+
+A forced signalling attack occurs when an attacker coerces the victim to send an undesired signal. The key material for the Guardian Address must be physically unavailable to the user in a secure location to prevent this scenario.
+
+To reduce forced Unlock risks, wallets MAY implement a configurable delay (e.g., 24 hours) before processing Unlock signals, allowing time for external responders to act.
+
+The choice of mining pool by the user can affect the response time of the wallets implementing the standard. Private mining pools are sometimes used for transaction privacy so that transactions are only visible on-chain once they are included in a block. If a user broadcasts the pre-signed signal transaction to a such a pool, the wallet lock time could be 10 minutes, or even longer depending on the transaction inclusion interval. For this reason users SHOULD broadcast signals to public mining pools so that wallets are able to view and act on the unconfirmed signal before block inclusion.
+
+State changes of the Guardian Address are limited to <code>10^21 − 1</code> transitions, making nonce exhaustion an unlikely event given the infrequent nature of signalling transactions.
+
+==Privacy Considerations==
+
+This BIP avoids any on-chain link between a user's spending wallet and their Guardian Address. Because the Guardian Address appears as an independent address posting infrequent signalling transactions with <code>OP_RETURN</code>, it is indistinguishable from any other transaction format.
+
+No PII or linking information is included on-chain. Furthermore, wallets that monitor a Guardian Address do so locally. No external observer can deduce which wallets are watching a given Guardian status.
+
+Users MAY also periodically rotate their Guardian Address if additional unlinkability is desired.
+
+Guardian Address transactions are infrequent and non-financial in nature. The presence of a Guardian signal in <code>OP_RETURN</code> does not expose anything about balances, identity, IP addresses, physical location or wallet associations.
+
+No on-chain link between the Guardian and the spending wallets exists. However, wallets implementing the BIP will periodically poll nodes for the latest Guardian state, which could expose a link between the wallet and the Guardian Address. Wallet users on untrusted networks may elect to use a local or private node in environments where the interception of network traffic is a concern.
+
+Polling follows a similar IP exposure model to transaction broadcast but risks address interest leaks in naive implementations. Use Neutrino (BIP-158) or delegated private nodes to avoid direct queries.
+
+Users SHOULD NOT make transactions on-chain between their Guardian Address and their spending wallet to prevent an association that connects the two entities.
+
+==Rationale==
+
+===UTXO Fragility vs. Key Fragility===
+
+Users face a trade off between carrying Guardian key material and relying on pre-signed transactions. Carrying the key increases coercion risk, since an attacker could force the user to sign a transaction under duress. Pre-signed transactions avoid this risk but introduce UTXO fragility: if the referenced UTXO is spent or becomes invalid, the pre-signed transaction cannot be used.
+
+This proposal favors pre-signed transactions as the safer approach under coercion scenarios. They minimize the risk of key compromise, enable rapid signalling, and allow users to keep Guardian keys physically separate from everyday devices.
+
+===Single vs. Multiple Guardians===
+
+Managing multiple Guardians introduces significant complexity. Each Guardian requires its own key, increasing operational overhead. Because this is a signalling protocol, conflicting messages are possible. For example, one Guardian may broadcast a Lock while another broadcasts an Unlock. Resolving such conflicts would require an arbitration mechanism, adding ambiguity and complexity to wallet behavior.
+
+To avoid these issues, this proposal specifies support for a single Guardian Address. This ensures deterministic state evaluation, simplifies implementation, and reduces the risk of misconfiguration.
+
+===Nonce Encoding===
+
+The nonce is encoded as a decimal ASCII integer for human readability and ease of debugging. While binary encodings were considered, they provide minimal space savings (10 bytes vs. 4) at the cost of greater implementation complexity.
+
+===Justification of OP_RETURN Usage===
+
+Guardian signals must be effective as soon as they are broadcast to the mempool, not after block inclusion. Taproot leaf commitments or covenants are invisible until mined, which makes them unsuitable for realtime coercion response.
+
+<code>OP_RETURN</code> of ≤83 bytes is standard and supported in Bitcoin Core. The protocol payload is ≤40 bytes, well under relay limits. This ensures protocol transactions will be relayed irrespective of node configuration for this opcode.
+
+Using <code>OP_RETURN</code> does not consume a spendable UTXO and does not pollute the UTXO set. Alternatives like “dust” marker outputs would bloat UTXO sets.
+
+Parsing <code>OP_RETURN</code> is trivial for wallets. Using Taproot annexes or witness data would complicate light client parsing and prevent efficient use of BIP-158 filters.
+
+Alternatives considered and rejected:
+
+* Taproot commitments: invisible until mined.
+* PSBT/gossip extensions: off-chain, non-universal, not enforceable.
+* Dedicated covenant: requires consensus change.
+
+Therefore, <code>OP_RETURN</code> is the minimal, mempool visible, backwards compatible choice.
+
+==Reference Implementation==
+
+An implementation in Electrum demonstrates the Guardian Address signal protocol, including:
+
+* Configuration of a Guardian Address in wallet settings.
+* Mempool and blockchain polling for OP_RETURN signals.
+* State machine handling for Lock/Unlock transitions, preventing UTXO spends when locked.
+* Signal generation via a standalone Python tool for creating pre-signed Lock/Unlock transactions.
+
+The source code is available at https://github.com/bitcoinguardian/electrum. This serves as a model for self-custodial wallets, while custodial services may adapt the protocol to their infrastructure.
+
+Guardian Signal tooling is available at https://github.com/bitcoinguardian/GASPv1-draft
+
+A demo with testnet integration and Guardian integration is available at https://github.com/bitcoinguardian/electrum/tree/master/demo
+
+==Acknowledgements==
+
+With thanks to @thec00n @OzMozis for feedback and comments of this BIP.
+
+This BIP has been possible due to diligent prior and ongoing work by Jameson Lopp into physical attacks in the Bitcoin ecosystem.
+
+==References==
+<references />
\ No newline at end of file