el SDK de Stellar esta tres versiones mayores atrasado

[leocagli]

Los dos frontends declaran una version del SDK que quedo muy atras.

La evidencia

sgs_frontend/package.json      "@stellar/stellar-sdk": "^14.4.2"
template_frontend/package.json "@stellar/stellar-sdk": "^14.4.2"

publicado hoy en npm:          17.0.0

Tres versiones mayores de diferencia.

Y no es una actualizacion cosmetica. Buscando en el codigo real (73 archivos, sin
contar node_modules ni docs):

authorizeEntry        26 apariciones en 8 archivos
TransactionBuilder    10 apariciones en 5 archivos
rpc.Server             2 apariciones en 2 archivos
Networks.              2 apariciones en 2 archivos

authorizeEntry es justamente una de las que cambio: en la v16 dejo de tener un
networkPassphrase por defecto. Ocho archivos la usan.

Los cambios rompientes conocidos de la v16

• axios se reemplaza por fetch
• serverURL pasa a ser un URL nativo de solo lectura
• exige Node 22 o superior
• minAccountSequenceAge pasa a bigint
• Transaction deja de ser generico
• authorizeInvocation() toma un solo objeto
• authorizeEntry() pierde el networkPassphrase por defecto
• Asset.code y Asset.issuer quedan de solo lectura
• desaparece FastSigning

Antes de escribir codigo

Vale la pena decidir primero si los dos frontends van a seguir existiendo (ver la
issue de la duplicacion). Actualizar dos copias del mismo codigo es hacer el trabajo
dos veces.

• Decidir a que version se salta: la 17, o la 16 como escalon intermedio
• Actualizar y arreglar lo que rompa, empezando por los 8 archivos de
  authorizeEntry
• Comprobar la version de Node que hace falta y dejarla escrita en el README
• Probar el flujo completo contra testnet: conectar billetera, invocar, y ver el
  resultado. Que compile no alcanza.

---

Como se toma este trabajo: comentá la issue con un plan concreto (que archivo, que
funcion, y como lo vas a verificar). Se asigna por la calidad de ese plan, no por
orden de llegada. La PR va despues de la asignacion, con el cambio real adentro.

[Santia2004]

Hi! I would like to work on this issue. I have solid experience with TypeScript/JavaScript, backend architectures, and Soroban/Stellar integrations, and I have recently contributed clean, merged implementations across campaign repositories. Please feel free to assign it to me. Thanks!

[somotochukwu-dev]

Hi
Please assign this issue to me
Thanks

[Ranjeet2063]

Hi maintainers,

I'd love to take ownership of this issue.

Technical Approach:

1. Core Work: Deliver a clean, modular solution for el SDK de Stellar esta tres versiones mayores atrasado adhering strictly to Bitcoindefi/Stellar-Game-Studio's architecture.
2. Quality Gate: Cover implementation with automated unit tests for edge cases and core workflows.

Background: Active open-source contributor with 130+ merged PRs across Web3/Stellar ecosystems.

I am ready to start immediately—please assign this to me!

[guptakumarranjeet150]

Hey team,

I can tackle el SDK de Stellar esta tres versiones mayores atrasado. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Bitcoindefi/Stellar-Game-Studio
• Implementation: Deliver a clean, modular solution for el SDK de Stellar esta tres versiones mayores atrasado strictly following Bitcoindefi/Stellar-Game-Studio conventions.
• Testing: Cover changes with automated tests ensuring CI passes smoothly.
• PR: Atomic commit with clean git hygiene and passing CI

Ready to deliver a clean, tested PR within 12–24 hours. Please assign!

[shobhamerabacha-star]

Hey team,

I can tackle el SDK de Stellar esta tres versiones mayores atrasado. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Bitcoindefi/Stellar-Game-Studio
• Implementation: Deliver a clean, modular solution for el SDK de Stellar esta tres versiones mayores atrasado strictly following Bitcoindefi/Stellar-Game-Studio conventions.
• Testing: Cover changes with automated tests ensuring CI passes smoothly.
• PR: Atomic commit with clean git hygiene and passing CI

Happy to pick this up today—please assign to me!

[ranjeet150]

Hi everyone,

I can tackle el SDK de Stellar esta tres versiones mayores atrasado. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Bitcoindefi/Stellar-Game-Studio
• Implementation: Deliver a clean, modular solution for el SDK de Stellar esta tres versiones mayores atrasado strictly following Bitcoindefi/Stellar-Game-Studio conventions.
• Testing: Cover changes with automated tests ensuring CI passes smoothly.
• PR: Atomic commit with clean git hygiene and passing CI

Excited to work on this—please assign to me and I'll submit a clean PR shortly!

[Rodrigoue9]

Buenas @leocagli! Te dejo el plan técnico concreto para la migración a Stellar SDK v17.0.0:

1. Archivos afectados y funciones clave

• sgs_frontend/package.json y template_frontend/package.json:
  • Actualización de @stellar/stellar-sdk de ^14.4.2 a ^17.0.0.
  • Definición de "engines": { "node": ">=22.0.0" } y actualización de la documentación en README.md.
• Los 8 archivos con authorizeEntry:
  • sgs_frontend/src/utils/authEntryUtils.ts (injectSignedAuthEntry): En v16/v17 networkPassphrase ya no tiene valor por defecto; se asegura el pasaje explícito en la llamada a authorizeEntry. Adaptación del callback del preimage para retornar los buffers tipados correctamente.
  • sgs_frontend/src/games/dice-duel/diceDuelService.ts (prepareStartGame): Migración de la firma de auth entry pasando el passphrase obligatorio.
  • sgs_frontend/src/games/number-guess/numberGuessService.ts (prepareStartGame): Ajuste idéntico con firma de preimage de Player 1.
  • sgs_frontend/src/games/twenty-one/twentyOneService.ts (prepareStartGame): Ajuste idéntico para auth entry.
  • sgs_frontend/src/services/devWalletService.ts (signAuthEntry): Compatibilidad con el payload hasheado de preimage XDR bajo v17.
  • template_frontend/src/utils/authEntryUtils.ts, template_frontend/src/games/number-guess/numberGuessService.ts y template_frontend/src/services/devWalletService.ts: Mismo refactor simétrico para mantener paridad entre ambos frontends.
• Cliente RPC y Red:
  • sgs_frontend/src/utils/ledgerUtils.ts y template_frontend/src/utils/ledgerUtils.ts (calculateValidUntilLedger):
    • Adaptación de new rpc.Server(rpcUrl) al cliente moderno con fetch nativo (sin axios) y manejo de serverURL inmutable.
• Builders de transacciones:
  • En los 5 archivos que usan TransactionBuilder: tipado de minAccountSequenceAge a bigint y eliminación de referencias a genéricos en Transaction.

2. Plan de verificación paso a paso

1. Compilación y Linteo: npm run build y chequeo de tipos estricto en sgs_frontend y template_frontend bajo Node 22.
2. Pruebas de simulación y firma local: Verificar que devWalletService genera y firma auth entries válidas sin warnings.
3. Flujo end-to-end en Stellar Testnet:
   • Conectar Freighter en el navegador.
   • Ejecutar la secuencia completa de prepareStartGame (generación de auth entry).
   • Enviar la transacción al nodo RPC de Testnet (soroban-testnet.stellar.org) y validar la inclusión en el ledger.

Quedo a disposición para tomar la issue si te parece bien el enfoque.