I used to study contract privacy, my eyes always fixed on the storage area. The encrypted fields are right there, making it easy to feel reassured. But today, when I dug into the subscription conditions for RUES, two qualifiers pinned me down. A contract tied to @Dusk can hide the state, but subscription isn’t something you do blindly—it first recognizes the contract_id, then the event_name. Visibility is already split into branches right here.
I laid out D-03 and D-37 into two columns. On the left I wrote storage encryption, and on the right I wrote the event layer. In the subscription example, the JSON header and raw event bytes are what I circled—events emitted by the contract $DUSK will be delivered to subscribers under those conditions. When I could read the raw event bytes as-is, it felt like receiving an error message telling me not to let storage-layer conclusions cover the log layer. Subscription fields aren’t decoration; they determine who can collect which fragments of behavior.
In plain terms, locking the file cabinet doesn’t mean the package log at the front door is locked too. The state is like the materials inside the cabinet, while events are more like the pickup slips posted on the door. An indexer may not be able to touch encrypted fields, but it may still diligently organize time, calls, and names. Once I put the two columns together, it slowly clicked: privacy isn’t a single button—it’s the result of visibility calculated separately for each layer.
There’s a very practical boundary here. Events don’t have to directly expose asset quantities for risk to form. Put the timestamps, the recurring call relationships, and the associated names together, and observers can already make near-accurate inferences. If you only query contract state, you’ll miss a query path. Isolating the event layer as its own item on the checklist isn’t nitpicking—it’s to prevent the later realization that the behavior outline was already assembled by the logs.
So now I don’t just ask whether storage is encrypted; I also ask how the events are sent, who can subscribe, and whether fields are desensitized. I’d rather spend an extra minute reading the fields than treat default visibility as default privacy. Storage encryption is certainly useful, but it doesn’t automatically mean logs are confidential. In the privacy-contract checklist, the event layer should have its own line. The busier the indexer, the more you shouldn’t skip that line. #dusk
I laid out D-03 and D-37 into two columns. On the left I wrote storage encryption, and on the right I wrote the event layer. In the subscription example, the JSON header and raw event bytes are what I circled—events emitted by the contract $DUSK will be delivered to subscribers under those conditions. When I could read the raw event bytes as-is, it felt like receiving an error message telling me not to let storage-layer conclusions cover the log layer. Subscription fields aren’t decoration; they determine who can collect which fragments of behavior.
In plain terms, locking the file cabinet doesn’t mean the package log at the front door is locked too. The state is like the materials inside the cabinet, while events are more like the pickup slips posted on the door. An indexer may not be able to touch encrypted fields, but it may still diligently organize time, calls, and names. Once I put the two columns together, it slowly clicked: privacy isn’t a single button—it’s the result of visibility calculated separately for each layer.
There’s a very practical boundary here. Events don’t have to directly expose asset quantities for risk to form. Put the timestamps, the recurring call relationships, and the associated names together, and observers can already make near-accurate inferences. If you only query contract state, you’ll miss a query path. Isolating the event layer as its own item on the checklist isn’t nitpicking—it’s to prevent the later realization that the behavior outline was already assembled by the logs.
So now I don’t just ask whether storage is encrypted; I also ask how the events are sent, who can subscribe, and whether fields are desensitized. I’d rather spend an extra minute reading the fields than treat default visibility as default privacy. Storage encryption is certainly useful, but it doesn’t automatically mean logs are confidential. In the privacy-contract checklist, the event layer should have its own line. The busier the indexer, the more you shouldn’t skip that line. #dusk