.dwrite
Debug write namespace for encrypted transactions with inspection
The .dwrite namespace provides encrypted contract write operations with debug inspection. It broadcasts a real transaction (like .write) but also returns both plaintext and encrypted views for debugging and testing.
Overview
When you call contract.dwrite.functionName(...), the SDK:
Encodes your function call using the contract ABI (plaintext)
Encrypts the calldata using AES-GCM with a shared key derived via ECDH
Constructs a
TxSeismicwith encryption metadataSigns and broadcasts the encrypted transaction
Returns a
DebugWriteResultcontaining:plaintext_tx — Transaction before encryption
shielded_tx — Transaction with encrypted calldata
tx_hash — Transaction hash from broadcast
Important: The transaction is actually broadcast and consumes gas. This is not a dry run.
Usage Pattern
result = contract.dwrite.functionName(arg1, arg2, ...)Sync: Returns
DebugWriteResultimmediatelyAsync: Returns
DebugWriteResult(mustawait)
Parameters
Function Arguments
Pass function arguments as positional parameters:
Transaction Options (Keyword Arguments)
All transaction options are optional keyword arguments (same as .write):
value
int
0
ETH value to send (in wei)
gas
int | None
None
Gas limit (30_000_000 if None)
gas_price
int | None
None
Gas price in wei (uses network default if None)
Return Value
Returns a DebugWriteResult with three fields:
Field Details
plaintext_tx
PlaintextTx
Transaction with unencrypted calldata (what you intended)
shielded_tx
UnsignedSeismicTx
Full TxSeismic structure with encrypted calldata
tx_hash
HexBytes
Transaction hash from eth_sendRawTransaction
Examples
Sync Usage
Async Usage
Inspect Plaintext Calldata
Verify Encryption
Inspect Transaction Parameters
Analyze Gas Limit vs Usage
Compare with Production .write
Use Cases
Development and Testing
Debugging Encryption
Auditing Transaction Details
Testing Security Parameters
Important Warnings
Transaction is Actually Broadcast
.dwrite is NOT a dry run:
The encrypted transaction is broadcast
Gas is consumed
State changes are applied
You pay transaction fees
Use in Production
Don't use .dwrite in production:
Adds overhead (returns extra data)
No benefit over
.writefor end usersOnly useful for development/debugging
For production, use .write:
Cost Implications
.dwrite has the same gas cost as .write:
Same transaction is broadcast
Same encryption overhead
Only difference is SDK returns debug info (no on-chain difference)
Comparison with Other Namespaces
.write
Yes
HexBytes (tx hash)
Yes
Production shielded writes
.dwrite
Yes
DebugWriteResult
Yes
Development/debugging
.twrite
No
HexBytes (tx hash)
Yes
Transparent writes
Privacy Guarantees
Identical to .write
.dwrite has the same privacy guarantees as .write:
Calldata is encrypted on-chain
Only you and the TEE can see plaintext
Debug info is only in the SDK return value (not on-chain)
Debug Info is Client-Side
The plaintext_tx and shielded_tx fields are not broadcast:
Only the encrypted transaction is sent
Debug info exists only in your client
No privacy leak from using
.dwrite
Error Handling
Best Practices
When to Use .dwrite
Development — Verify calldata encoding is correct
Testing — Debug encryption/decryption issues
Auditing — Inspect transaction parameters before production
Debugging — Troubleshoot failed transactions
When to Use .write Instead
Production — No need for debug info
High-frequency calls — Avoid overhead of extra return data
Simple operations — Debug info not useful
Testing Workflow
Low-Level Alternative
For manual control with debug info:
See Shielded Write Guide for details.
See Also
.write Namespace — Production shielded writes (no debug info)
DebugWriteResult — Return type reference
PlaintextTx — Plaintext transaction structure
UnsignedSeismicTx — Shielded transaction structure
Shielded Write Guide — Full encryption workflow
Last updated

