[XLM-08] Alta de direcciones Stellar

[grantfox-oss]

Contexto obligatorio: PLAN_STELLAR.md y ISSUES_STELLAR.md.
Ola 1 — bloqueada por #5.
🌱 Buena primera contribución: alcance acotado, sin dependencias de red, resultado visible.

Problema

Las pantallas de alta de productores y de operadores solo aceptan direcciones de XRPL, y bloquean el botón de guardar si la dirección no es válida en esa red.

Por qué importa

Sin direcciones de Stellar registradas, nada del resto del trabajo multicadena es utilizable por la cooperativa.

Alcance

payment_app/ui_payment/producer_view.py

• Segundo campo de dirección (Stellar) con validación por StrKey.is_valid_ed25519_public_key.
• Indicador de "cuenta no activada" cuando la cuenta no existe todavía en el ledger (decisión D7).
• Al menos una dirección obligatoria — ya no específicamente la de XRPL.
• Mostrar ambas direcciones en la ficha del productor.

admin_app/ui_admin/user_management.py

• Campo de dirección Stellar del operador, con la misma validación.

core/utils.py

• generate_user_id() sigue derivándose de la dirección XRPL — los IDs ya emitidos no pueden cambiar. Para un operador solo-Stellar, generar desde su dirección Stellar. Documentar la regla en el docstring.

Fuera de alcance

• Pagar en Stellar — es [XLM-10].
• Migración de datos — ya está hecha en [XLM-06] Modelo de datos multicadena #5.

Criterios de aceptación

• Se puede dar de alta un productor con una sola red, con la otra, o con ambas.
• Una dirección de XRPL pegada en el campo de Stellar es rechazada con un mensaje claro, y viceversa.
• Los duplicados se detectan por (red, dirección), no globalmente.
• Los productores existentes siguen visibles y editables.

Pruebas

Validación cruzada de direcciones; alta con una y con ambas redes; rechazo de duplicados por red.

Dependencias

• Bloqueada por: [XLM-06] Modelo de datos multicadena #5 (tabla wallets y address_for).
• Bloquea a: nada directamente, pero sin ella no hay datos con los que probar [XLM-10].

[Deylan-S]

Buenas!

Ya revisé el detalle y tengo claro lo que hay que hacer en las vistas de productores, operadores y en core/utils.py para habilitar las direcciones Stellar y la lógica de validación/IDs.

Quedo a la espera para tirar la rama e implementar los cambios. ¡Cualquier duda me avisan!

[grantfox-oss]

🦊 GrantFox — @Deylan-S has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #8)
2. Your PR will be reviewed by the Micopay maintainers

Good luck! Track your progress on GrantFox.

[ericmt-98]

@Deylan-S asignada — citaste las tres superficies del alcance y la lógica de IDs, se nota que la leíste. 👍

⚠️ Pero está bloqueada ahora mismo. Necesita que #5 entregue la tabla wallets y el método address_for(network). Sin eso no hay dónde guardar la dirección de Stellar. #5 ya está asignada y en marcha.

Mientras tanto sí puedes avanzar:

• Leer producer_view.py, user_management.py y core/utils.py para tener claro dónde entra cada cambio.
• Decidir cómo se ve el indicador de "cuenta no activada" (decisión D7 del plan): en Stellar una cuenta no existe hasta que se fondea, y hay que mostrarlo.
• Ojo con generate_user_id(): sigue derivándose de la dirección XRPL. Los IDs ya emitidos no pueden cambiar. Solo para un operador solo-Stellar se genera desde su dirección Stellar.

Te aviso aquí en cuanto #5 cierre. Si quieres empezar por algo desbloqueado, #1 a #4 están libres.

[Deylan-S]

Entendido, mientras se completa el issue #5, voy a echarle un ojo a los issues libres para tomar uno. De igual forma tendré en mente las lecturas y la lógica de IDs para retomar el #8 apenas esté listo. Gracias! *Deylan Salas Gaitan* ***@***.*** ***@***.***>* *+506 7118 9289*

…

On Wed, 22 Jul 2026 at 9:08 PM ericmt-98 ***@***.***> wrote: *ericmt-98* left a comment (Micopay/coffee-payments#8) <#8 (comment)> @Deylan-S <https://github.com/Deylan-S> asignada — citaste las tres superficies del alcance y la lógica de IDs, se nota que la leíste. 👍 ⚠️ *Pero está bloqueada ahora mismo.* Necesita que #5 <#5> entregue la tabla wallets y el método address_for(network). Sin eso no hay dónde guardar la dirección de Stellar. #5 <#5> ya está asignada y en marcha. *Mientras tanto sí puedes avanzar:* - Leer producer_view.py, user_management.py y core/utils.py para tener claro dónde entra cada cambio. - Decidir cómo se ve el indicador de "cuenta no activada" (decisión D7 del plan): en Stellar una cuenta no existe hasta que se fondea, y hay que mostrarlo. - Ojo con generate_user_id(): *sigue derivándose de la dirección XRPL*. Los IDs ya emitidos no pueden cambiar. Solo para un operador solo-Stellar se genera desde su dirección Stellar. Te aviso aquí en cuanto #5 <#5> cierre. Si quieres empezar por algo desbloqueado, #1 <#1> a #4 <#4> están libres. — Reply to this email directly, view it on GitHub <#8?email_source=notifications&email_token=BQ6UBW2W7KIS55OFJACDSHL5GF6TZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBVGM4DOMRVGQZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5053872543>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BQ6UBWY7HXDNNYE2CSVOY335GF6TZAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZUHEYTEMBZGQ5US43TOVSTWNBZGUZDSNZZG43DRILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Deylan-S]

Hola! Ya resolví XLM-01 (spike de Stellar testnet). Confirmé las 3 diferencias clave contra XRPL con transacciones reales: op_no_destination al pagar a cuenta inexistente (hay que usar CreateAccount), el UETR no cabe en MemoText así que uso MemoHash con padding a 32 bytes, y Stellar usa 7 decimales. Todo probado end-to-end en testnet con hashes verificables en stellar.expert, y pytest sigue en verde (39 passed). El mié, 22 jul 2026 a la(s) 9:08 p.m., ericmt-98 ***@***.***) escribió:

…

*ericmt-98* left a comment (Micopay/coffee-payments#8) <#8 (comment)> @Deylan-S <https://github.com/Deylan-S> asignada — citaste las tres superficies del alcance y la lógica de IDs, se nota que la leíste. 👍 ⚠️ *Pero está bloqueada ahora mismo.* Necesita que #5 <#5> entregue la tabla wallets y el método address_for(network). Sin eso no hay dónde guardar la dirección de Stellar. #5 <#5> ya está asignada y en marcha. *Mientras tanto sí puedes avanzar:* - Leer producer_view.py, user_management.py y core/utils.py para tener claro dónde entra cada cambio. - Decidir cómo se ve el indicador de "cuenta no activada" (decisión D7 del plan): en Stellar una cuenta no existe hasta que se fondea, y hay que mostrarlo. - Ojo con generate_user_id(): *sigue derivándose de la dirección XRPL*. Los IDs ya emitidos no pueden cambiar. Solo para un operador solo-Stellar se genera desde su dirección Stellar. Te aviso aquí en cuanto #5 <#5> cierre. Si quieres empezar por algo desbloqueado, #1 <#1> a #4 <#4> están libres. — Reply to this email directly, view it on GitHub <#8?email_source=notifications&email_token=BQ6UBW2W7KIS55OFJACDSHL5GF6TZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBVGM4DOMRVGQZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5053872543>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BQ6UBWY7HXDNNYE2CSVOY335GF6TZAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZUHEYTEMBZGQ5US43TOVSTWNBZGUZDSNZZG43DRILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Deylan Salas Gaitan* ***@***.*** ***@***.***>* *+506 7118 9289*