Al revisar una respuesta técnica, un valor null invita a pensar que falta información. A veces es así; otras veces, el campo utiliza ese valor con un significado definido. En Ethereum, el destinatario de una transacción de creación de contrato ofrece un buen ejemplo para leer antes de corregir.
Comprueba qué objeto estás leyendo
La documentación JSON-RPC de Ethereum indica que el campo to es nulo cuando la transacción es de creación de contrato. En el recibo, contractAddress recoge la dirección creada cuando corresponde; en otras transacciones ese campo es nulo.
Son campos de un esquema concreto. No traslades esa interpretación a cualquier pantalla que diga «destinatario» ni a otra red sin revisar su documentación. Una interfaz puede transformar los nombres o mostrar una selección de los datos.
Conserva el hash durante la comparación
Para un ejercicio de lectura, abre los datos de una transacción ya publicada y su recibo. Comprueba que ambos se refieren al mismo hash y a la misma red. Anota el valor de to y, por separado, el de contractAddress. No hace falta conectar una cartera ni enviar una operación para estudiar campos públicos.
Si el recibo aún no está disponible, deja esa comprobación pendiente. Una ausencia temporal no justifica rellenar la dirección con una suposición. Tampoco conviene convertir automáticamente un valor nulo en una cadena vacía si después perderás su significado.
Una dirección creada no explica todo lo ocurrido
Identificar la clase de transacción es un paso descriptivo. No demuestra que el contrato haga lo que promete una aplicación, que su código sea seguro o que exista una relación comercial legítima detrás.
La lectura puede continuar con lo que un recibo exitoso permite afirmar. En tu nota final, separa el dato observado, la definición que utilizaste y las preguntas todavía abiertas. Así, «to es null» deja de parecer un error automático y se convierte en una observación que puedes comprobar.