diff --git a/100.md b/100.md
index 01a3f01..09cd33c 100644
--- a/100.md
+++ b/100.md
@@ -61,13 +61,6 @@ Optionally, clients CAN prevent the sending of events signed by a locked user, a
 
 For the key thief, this is easily avoidable by using another client or developing a custom one, which is why it is defined as an optional feature in this NIP. However, any difficulty in the illicit use of a key will be welcomed.
 
-
-
-### NIP-59 Usage
-
-The operation of the Relays and C
-lients in the event of receiving an event using [NIP-59](./59.md) will be the same as described in the previous sections, except that the signer of the `seal` event (`kind:13`) will be used to validate whether the event should be accepted (in the case of Relays) or hidden/marked (in the case of Clients).
-
 ### Considerations
 
 1. Once a user is locked, **this action is irreversible**, so the keys would remain locked in the Relays and clients that implement this NIP forever.
@@ -75,4 +68,3 @@ lients in the event of receiving an event using [NIP-59](./59.md) will be the sa
 3. Although events continue to be retransmitted to Relays that do not implement this NIP, using clients that do implement it provides reliability in the event query.
 4. It is up to the clients to decide how to handle the events of a locked user. They can hide them, mark them in some way, or even allow the user to configure how these events are handled.
 5. The process proposed in this NIP implies that in the event of key theft, the thief can lock the user before the legitimate key owner does. This is assumed since the main problem in the event of Nostr key theft is identity theft, and not so much the ability to continue using them.
-6. As explained for NIP-59, any future NIP developed where the signature is not made by the event author, the control performed by Relays and clients should keep it in mind.