La última vez que cargué fondos a un exchange, después de copiar la dirección la revisé dos veces más y volví a comprobar el memo, por miedo a que el dinero llegara pero no lo pudieran identificar como mío. Luego, al ver la documentación de integración del exchange para @Dusk , entendí que Dusk exige para la recarga del backend algo más detallado que “poner el memo correcto”: primero se elige el modelo de cuenta pública de Moonlight y luego se decide si cada persona tiene su propia cuenta o si se comparte una cuenta con memo.
Si se usa una cuenta compartida, el memo solo sirve para decirle al sistema a quién debe atribuirse ese dinero, pero no es adecuado como único comprobante para evitar entradas duplicadas. Dos usuarios podrían introducir el mismo memo por error, o la misma pieza de datos podría volver a escanearse debido a un reinicio del backend. Por eso, la documentación oficial recomienda usar el ID de transacción de Dusk como idempotency key; en otras palabras, poner un “candado” para que cada recarga solo se registre una vez. #dusk
Hay otro límite fácil de pasar por alto: el exchange no debería añadir saldo al usuario inmediatamente solo porque detecta que aumentó el saldo de Moonlight. Necesita escanear el historial ya archivado y finalizado de transferencias directas, y además poner en una zona de aislamiento las recargas con memo faltante, con formato incorrecto, desconocido o duplicado, en lugar de registrar automáticamente “porque sí”.
Más en detalle: el backend debe escribir el registro de recarga y avanzar el checkpoint de verificación del bloque dentro de la misma transacción de base de datos. Si primero se avanza el checkpoint y luego se ingresa el saldo, y el servicio se cae, podría saltarse el dinero del usuario; si primero se ingresa el saldo pero no se guarda el progreso, al reescaneo podría procesarse dos veces. La conversión de Phoenix, los pagos de contratos y los retiros de staking también deben configurarse con reglas de eventos separadas; no se deben mezclar con una recarga normal.
Toda esta lógica se parece mucho a un almacén de paquetería: el memo es la etiqueta del destinatario, el ID de transacción es el número de guía que no se repite, y finalized es el estado de que el paquete realmente ya quedó asentado en el almacén. Si solo miras uno de esos elementos, podrías provocar paquetes perdidos o envíos duplicados.
Por eso, al ver la adaptación del exchange de $DUSK , no me fijo solo en si “permite recargar y retirar”, sino en si el backend puede lograr que, tras la finalización, se registre el ingreso de forma correcta, que el ID de transacción se deduzca (sin duplicados), y que el checkpoint y el libro contable se envíen en la misma confirmación. La verdadera experiencia a nivel financiero no es que en la interfaz el giro pase rápido, sino que aunque se reinicie el backend o se vuelva a escanear, nunca den de más ni de menos ni un solo centavo al usuario. #dusk
Si se usa una cuenta compartida, el memo solo sirve para decirle al sistema a quién debe atribuirse ese dinero, pero no es adecuado como único comprobante para evitar entradas duplicadas. Dos usuarios podrían introducir el mismo memo por error, o la misma pieza de datos podría volver a escanearse debido a un reinicio del backend. Por eso, la documentación oficial recomienda usar el ID de transacción de Dusk como idempotency key; en otras palabras, poner un “candado” para que cada recarga solo se registre una vez. #dusk
Hay otro límite fácil de pasar por alto: el exchange no debería añadir saldo al usuario inmediatamente solo porque detecta que aumentó el saldo de Moonlight. Necesita escanear el historial ya archivado y finalizado de transferencias directas, y además poner en una zona de aislamiento las recargas con memo faltante, con formato incorrecto, desconocido o duplicado, en lugar de registrar automáticamente “porque sí”.
Más en detalle: el backend debe escribir el registro de recarga y avanzar el checkpoint de verificación del bloque dentro de la misma transacción de base de datos. Si primero se avanza el checkpoint y luego se ingresa el saldo, y el servicio se cae, podría saltarse el dinero del usuario; si primero se ingresa el saldo pero no se guarda el progreso, al reescaneo podría procesarse dos veces. La conversión de Phoenix, los pagos de contratos y los retiros de staking también deben configurarse con reglas de eventos separadas; no se deben mezclar con una recarga normal.
Toda esta lógica se parece mucho a un almacén de paquetería: el memo es la etiqueta del destinatario, el ID de transacción es el número de guía que no se repite, y finalized es el estado de que el paquete realmente ya quedó asentado en el almacén. Si solo miras uno de esos elementos, podrías provocar paquetes perdidos o envíos duplicados.
Por eso, al ver la adaptación del exchange de $DUSK , no me fijo solo en si “permite recargar y retirar”, sino en si el backend puede lograr que, tras la finalización, se registre el ingreso de forma correcta, que el ID de transacción se deduzca (sin duplicados), y que el checkpoint y el libro contable se envíen en la misma confirmación. La verdadera experiencia a nivel financiero no es que en la interfaz el giro pase rápido, sino que aunque se reinicie el backend o se vuelva a escanear, nunca den de más ni de menos ni un solo centavo al usuario. #dusk