El challenge
Argentina Builder Challenge es una hackathon virtual a nivel nacional organizada por BAF y Stellar. Durante dos semanas, builders de todo el país diseñan, construyen y lanzan aplicaciones reales sobre la infraestructura de Stellar.
- Fechas: 12 al 27 de septiembre de 2026
- Cierre de aplicaciones: 21 de septiembre. Es el último día para anotarse.
- Cierre de entregas (submission deadline): 27 de septiembre. Es cuando cada equipo entrega su proyecto final (deck + demo). Son dos fechas distintas, no la confundas.
- Modalidad: virtual a nivel nacional, con hubs presenciales opcionales de un solo día en el kickoff
- Costo: gratuito
- Tagline: Build With Impact on Stellar
Elegibilidad
- Residentes en cualquier parte de Argentina, participando de manera virtual
- Equipos internacionales permitidos, siempre que al menos el 50% de los integrantes resida actualmente en Argentina
- Equipos de 2 a 4 personas
- En el track Genesis podés participar individual y te ayudamos a conseguir un equipo; en Scale la aplicación es como equipo
Virtual o presencial, mismas condiciones. No hay ninguna diferencia en premios ni elegibilidad entre un equipo 100% virtual y uno que pasa por un hub. La única diferencia es la mentoría: todos los equipos tienen acceso a mentoría online durante las dos semanas; solo quienes asisten a un hub suman, además, mentoría presencial ese día.
Genesis y Scale
Genesis — Proyectos nuevos
Para builders en etapa temprana, estudiantes o cualquier persona construyendo sobre Stellar por primera vez.
- Podés aplicar individual o con equipo ya formado
- Si aplicás individual, el team-matching del kickoff es activo, no informal. Alguien del equipo de BAF te va a ayudar esa misma noche a conseguir equipo, no queda librado a que te organices solo con quien tengas al lado
- Podés elegir seguir solo si lo preferís, pero nadie termina el kickoff sin equipo por falta de ayuda
- El proyecto se construye desde cero durante el challenge
- El repositorio se crea a partir del 12 de septiembre
- Uso de AI, scaffolding y librerías open source: permitido y recomendado
- Código propio anterior al kickoff no puede ser la base del proyecto
Scale — Proyectos existentes
Para equipos con un producto que ya existe, dentro o fuera del ecosistema Stellar. La aplicación se hace como equipo.
"Producto que existe" se demuestra con al menos una de estas evidencias: producto desplegado y accesible, repositorio con historial anterior al 12/09, tracción demostrable, o financiamiento previo de Stellar (SCF, Instawards).
Durante el challenge, el equipo entrega una feature nueva y acotada más un funding-readiness package (deck, arquitectura, roadmap a 3 meses y borrador de aplicación a Instawards/SCF), desarrollados en un repo o branch nuevo a partir del kickoff.
Requisitos del proyecto
- Resolver un caso de uso real y concreto, financiero o no. No califican demos técnicos sin usuario final, forks sin propósito ni proyectos puramente especulativos
- Integrar al menos un building block de Stellar: anchors, activos locales, Soroban, SDKs oficiales, wallets del ecosistema, protocolos DeFi existentes
- Hacer commits regularmente a lo largo de las dos semanas, no todos juntos al final. Es un chequeo mandatorio de la hackathon: se revisa en cada workshop y cada office hour, no solo en los 3 checkpoints formales
CATEGORÍAS (sirven de guía, no hay que encajar perfecto en una)
- Pagos
- DeFi & Real-World Assets
- Herramientas financieras locales
- Integración abierta (categoría para casos de uso no financieros)
Fechas clave
| Fecha | Instancia |
|---|---|
| 12/09 | Kickoff. Inicio oficial del challenge. Hubs presenciales opcionales de un día en CABA, Corrientes y Salta |
| 12 al 27/09 | Dos semanas de build. Workshops y office hours de mentoría técnica |
| 21/09 | Checkpoint 1 |
| 24/09 | Checkpoint 2 |
| 26/09 | Checkpoint 3, el día antes de la entrega final |
| 27/09 | Submission final, de manera virtual |
El Demo Day es 100% virtual: el submission se hace online, sin evento presencial ese día.
El submission final es obligatorio con repositorio y su historial completo de commits, no solo deck y demo. Es la única forma de comprobar que el producto se construyó durante el período del challenge (12 al 27/09), y no antes.
Los checkpoints son los momentos donde cada equipo entrega el código en el que estuvo trabajando hasta ese punto. No son una presentación ni un pitch, son una entrega de avance real.
Acompañamiento durante el challenge
- Workshops virtuales durante las dos semanas (2 por semana): intro a Soroban y building blocks, anchors y activos locales, AI-powered building, pitch y funding readiness
- Office hours con mentores del ecosistema, en horarios a coordinar durante las dos semanas. En cada una se revisa que el equipo esté haciendo commits regulares, no solo en los checkpoints formales
- WhatsApp como canal para preguntas y mentorías durante todo el challenge
Criterios y jurado
Los mismos cuatro criterios para todos los proyectos, sin importar track ni categoría, con el mismo peso cada uno:
| Criterio | Peso |
|---|---|
| Validación del problema | ¿Existe un problema real? ¿El equipo entiende quién lo tiene y por qué importa resolverlo? |
| Foco de negocio | ¿Hay una propuesta de valor clara? ¿Existe oportunidad real de adopción o crecimiento? |
| Foco de producto | ¿La solución resuelve el problema de forma clara y útil? ¿Pensada para usuarios reales? |
| Ejecución técnica | ¿El equipo logró construir algo funcional? ¿Tiene sentido la integración con Stellar? |
Cada criterio pesa 25%.
Jueces: entre 3 y 5, del ecosistema Stellar y del mundo builder/negocio. Un juez que haya mentoreado 1:1 a un equipo se abstiene de puntuarlo; el promedio sale de los jueces restantes.
Desempate: ante un empate, gana primero quien tenga mejor puntaje en ejecución técnica; si sigue empatado, se mira validación del problema.
Qué se llevan los mejores
El premio del challenge es un camino a un Instaward, para hasta 3 equipos de esta edición. No es un número fijo garantizado (puede ser menos de 3, según la calidad de las aplicaciones), pero nunca más de 3. Se eligen con los mismos 4 criterios de siempre: validación del problema, foco de negocio, foco de producto, ejecución técnica.
"Camino a un Instaward" significa mentoría 1:1 con BAF, no plata garantizada. Trabajamos directo con esos equipos para que su aplicación a Instaward quede lista y sólida. No es una garantía al 100%: la decisión final de aprobarla es de SDF, no de BAF.
Qué es un Instaward, en concreto
Financiamiento chico y acelerado: entre USD 1.000 y 5.000 iniciales, para un sprint de 30 días con un alcance bien definido y acotado. No se aplica de forma abierta como a otros fondos: se accede a través de tu Ambassador Chapter local, y prioriza a quienes ya demuestran compromiso, colaboración y capacidad real de ejecución.
REGLAS DE ELEGIBILIDAD
- Tu equipo no puede tener más de un Instaward activo a la vez. Si ya estás en una ronda activa (sea tu ronda 1, 2 o 3), no podés aplicar a otro Instaward hasta que esa ronda termine. No hay ronda doble.
- Tope de 3 rondas de Instaward por proyecto, en total, a lo largo del tiempo (1 inicial + hasta 2 de seguimiento), con un acumulado máximo de USD 15.000. Esta es la estructura real de SDF, no un límite que fija el challenge.
- Si tu proyecto ya recibió un Stellar Build Award (el fondo grande del SCF, de hasta USD 150.000, distinto de los Instawards), no podés aplicar al camino a Instaward de este challenge.
EL RESTO DE LOS PREMIOS
- Pipeline del Stellar Community Fund: los Instawards son el primer paso de un camino que puede llegar hasta USD 150.000
- Mentoría del ecosistema: acceso a builders y mentores de Stellar durante todo el challenge
- Workshops: sesiones hands-on de Soroban, integraciones, tooling y AI-powered building
Causales y propiedad intelectual
CAUSALES DE DESCALIFICACIÓN
- Plagio o uso de código de otro equipo sin atribución
- Incumplimiento del código de conducta (tolerancia cero con acoso o discriminación)
- Datos falsos en la aplicación (por ejemplo, mentir sobre el porcentaje de integrantes residentes en Argentina)
- Incumplir la regla de Instawards del punto 8 (dos activos en simultáneo, o superar el tope de 3 consecutivos)
- No mantener un historial de commits regular a lo largo del challenge. Un repo con toda la actividad concentrada en las últimas horas antes de un checkpoint o de la entrega final no cumple el requisito del punto 4
- Presentar como nuevo (Genesis) un producto construido antes del 12/09. El historial de commits del repositorio, obligatorio en el submission final, es la evidencia que se usa para verificar esto
Propiedad intelectual: el código construido durante el challenge es 100% de los equipos. Se recomienda licencia open source (MIT o Apache 2.0), pero no es obligatoria.