# FAQ

<details>

<summary><strong>Why signatures from EOAs are rejected even if they are valid?</strong></summary>

TargetBase is built for **smart account–based execution**, not direct EOA calls. All protected functions must be executed **via a DelegatedAccount** that has been pre-approved. This creates an enforcement layer where **EOAs cannot bypass authorization logic**.

</details>

<details>

<summary><strong>What happens if someone tries to reuse the same signed authorization twice?</strong></summary>

They can’t. TargetBase prevents this via **dual-layer replay protection**:

1. **Nonce Check** — must match `nonces[msg.sender]`
2. **Authorization Hash Tracking** — once a signature hash is used, it’s permanently recorded and rejected on future calls

This means even if an attacker copies calldata across chains, it still won’t execute.

</details>

<details>

<summary><strong>Can I rotate the master key without breaking existing signatures?</strong></summary>

Yes. When rotating the master key, all future authorizations must be signed with the new key, but **already-executed signatures remain final**. Pending signatures signed by the old key become invalid, this is intentional for security. This means that you also need to create a new attestor image which includes the private key of the latest master key.

</details>

<details>

<summary><strong>Does the contract owner have god mode? Can they bypass requireAuth?</strong></summary>

No. TargetBase does **not** implicitly grant owner privileges over normal functionality. The owner **only controls**:

* Master key rotation
* Recovery key update
* Emergency nonce reset

Actual business logic must still pass through `requireAuth`.

</details>