Update CONVENTIONS.md

Co-authored-by: Otto Allmendinger <otto.allmendinger@googlemail.com>

Author: lcovar

CONVENTIONS.md

@@ -5,11 +5,13 @@ This file documents API design and architecture patterns from code reviews. Foll
 These are hard rules, not suggestions. If you're unsure about a pattern, check the existing implementations in wasm-utxo.
 ---
 
-## 1. Uint8Array everywhere, no hex/base64 on Transaction
+## 1. Prefer Uint8Array, avoid unnecessary base conversions
 
-**What:** Transaction objects work exclusively with `Uint8Array` for binary data. No hex strings, no base64 strings.
+**What:** Generally, binary formats like transactions should use `Uint8Array` . Avoid base conversions in the wasm interface. 
 
-**Why:** Type safety at the boundary. If a method accepts or returns transaction bytes, it's always `Uint8Array`. String encodings (hex, base64) belong in serialization/API layers, not in the core transaction model. This prevents silent bugs where someone passes hex to a function expecting raw bytes.
+**Why:** Type safety at the boundary. If a method accepts or returns transaction bytes, it's always `Uint8Array`. String encodings (hex, base64) belong in serialization/API layers, not in the core transaction model. This prevents API bloat where we have to add encoding and decoding variants for various base conversion formats, as well as inefficiencies due to round-tripping binary data through two base conversions.
+
+Exceptions are allowed for instances where a hex encoded representations are conventional (Ethereum addresses for instance)
 
 **Good:**
 ```typescript