Volumen III – Tx24 & TXT Token
Tema Cerrado
06-abr-2026 21:59
#1741
|
Estais destinados a que os estafen os publican 3 imágenes de un bloc de notas y os volveis locos... Ojo que no digo que no sea verídico, pero como dice el compi de arriba al menos podrías poner un video. |
06-abr-2026 22:07
#1742
|
Muy buenas a todos.
Traigo una actualización importante en nuestro apartado tecnológico. Nuestro matching engine y los procesos y servicios alrededor suyo se consolidan, estabilizan e incrementan su potencia con una mayor eficiencia global en recursos. No es únicamente el matching engine puro lo que cuenta, es también la capacidad de mandar mensajes a igual o mayor ritmo y que todo se envíe, ejecute, recepcione y procese a iguales capacidades sin crear cuellos de botella, y que a su vez se haga de manera eficiente. Nuestro claim de 300.000 TX/s ha sido batido no solo en capacidad del matching puro, si no en la capacidad a posteriori de entradas y salidas. Hicimos nuestro sistema de trading 60 veces más rápido. Así fue. Cuando arrancamos, nuestro motor de órdenes procesaba 6,000 transacciones por segundo. Funcionaba bien, pero queríamos saber si podíamos hacerlo mejor. Mucho mejor. Lo primero que hicimos fue medir. Construimos herramientas para probar el sistema bajo presión y ver exactamente dónde se perdía el tiempo. Y descubrimos algo que no esperábamos. El cerebro de nuestro sistema, la parte que decide qué órdenes se cruzan entre sí, era rapidísimo. Podía resolver más de 400,000 operaciones por segundo. El problema no era el cerebro. El problema era el camino que recorrían los mensajes para llegar hasta él y volver. Imagínalo así: tenías un chef que podía cocinar un plato en 3 segundos, pero el camarero tardaba 5 minutos en llevarle el pedido y otros 5 en traer el plato a la mesa. No necesitábamos un chef más rápido. Necesitábamos mejores camareros. Fuimos cambiando piezas una a una. Primero optimizamos la configuración de la mensajería existente. Pasamos de 6,000 a 6,400 transacciones por segundo. Algo, pero no suficiente. Después reemplazamos el sistema de transporte de mensajes por uno diseñado para velocidades extremas, usado por bolsas de valores reales. Saltamos a 88,000 transacciones por segundo. Finalmente, cambiamos el formato en que viajan los mensajes. En vez de usar un formato de texto que cualquier humano podría leer, creamos un formato binario compacto que las máquinas procesan casi instantáneamente. Ese cambio nos llevó a más de 360,000 transacciones por segundo. Los tiempos de respuesta también cambiaron drásticamente. Antes, en la primera version que hicimos, una orden tardaba 4.5 milisegundos en procesarse. Ahora tarda 1 microsegundo. Para ponerlo en perspectiva: un microsegundo es a un segundo lo que un segundo es a 11 días. Lo más importante es lo que no hicimos. No reescribimos el sistema desde cero. No cambiamos las reglas de negocio. No rompimos nada que ya funcionaba. Los servicios que dependen de nuestro motor siguen funcionando exactamente igual, sin enterarse del cambio. Diseñamos la arquitectura para que podamos volver al sistema anterior con un cambio de configuración si fuera necesario. Cero riesgo. Para un exchange, la velocidad no es un lujo. Es lo que determina si puedes competir o no. Hoy podemos procesar más de 360,000 transacciones por segundo con tiempos de respuesta de microsegundos. Ese es nuestro nuevo estándar. Resultados de nuestros ultimos tests: ![]() ![]() ![]() ![]() ![]() ¿A quién pretende engañar este tipo con experimentos en su MacBook? O es un Dunning Kruger patológico o toma a la gente por imbécil... Si esto es lo que presenta ante un VC serio, se le ríen en la cara en el mejor de los casos.La primera imagen es un test de código ejecutado en un apple m2 darwin. Es decir, el amigo está moviendo datos dentro de su propio portátil... No hay red, no hay seguridad externa y no hay miles de personas operando a la vez... Es un test sintético que cualquier programador hace en una tarde para probar una función. La imagen 2 presume de microsegundos de latencia en comunicación interna.... De nada sirve que su servidor procese una orden en 1 microsegundo cuando cualquier clic desde vuestra casa tardaría 50.000 microsegundos o lo que sea solo en llegar al servidor por la latencia de internet. ![]() En fin... Y habrá quien aplauda...
|
06-abr-2026 22:17
#1743
|
A mi que consiga 300k tps o 288 millones me la pela, la cosa es que estas mierdas sean reales o no tienen que publicitarse, si la audiencia seguimos siendo 50 mataos de poco sirve. Y eso no vale solo por el token, también por el proyecto. Incluso si se completa la ronda de financiación y nadie conoce el exchange y nadie lo usa, sigue estando abocado al fracaso |
06-abr-2026 22:18
#1744
|
06-abr-2026 22:27
#1745
|
El insulto preventivo es el refugio de quien se ha quedado sin argumentos y con la cartera en rojo....
No hace falta que ningún soplapollas eche mierda, tu propio subconsciente se percata de la absoluta ausencia de hechos en el comunicado y por eso reaccionas así...Un podcast y un blog para un producto que no opera ni existe, y una app para trackear un token zombie... es literalmente una mofa para cualquiera con un mínimo IQ. ![]() me ha dado alegria verte por aqui, quedan pocas viejas glorias |
06-abr-2026 23:31
#1746
|
¿A quién pretende engañar este tipo con experimentos en su MacBook?
O es un Dunning Kruger patológico o toma a la gente por imbécil... Si esto es lo que presenta ante un VC serio, se le ríen en la cara en el mejor de los casos.La primera imagen es un test de código ejecutado en un apple m2 darwin. Es decir, el amigo está moviendo datos dentro de su propio portátil... No hay red, no hay seguridad externa y no hay miles de personas operando a la vez... Es un test sintético que cualquier programador hace en una tarde para probar una función. La imagen 2 presume de microsegundos de latencia en comunicación interna.... De nada sirve que su servidor procese una orden en 1 microsegundo cuando cualquier clic desde vuestra casa tardaría 50.000 microsegundos o lo que sea solo en llegar al servidor por la latencia de internet. ![]() En fin... Y habrá quien aplauda... |
06-abr-2026 23:45
#1747
| A ver dónde están todos los trolles ahora tras tremendo update de 288 millones de tps. Ya no ladrais eh? |
07-abr-2026 00:18
#1748
|
Gracias @Sr.Botones, creo que este es justo el tipo de comunicaciones que creo que pueden hacer que la gente de verdad apueste por el proyecto, como mínimo el personal técnico o de cierto nivel es lo que busca. Ojalá saquéis tiempo para postear este tipo de cosas de vez en cuando (sin revelar nada esencial a la competencia, obviamente).
Un vídeo en funcionamiento también sería muy interesante de ver. (Pongo un mensaje a continuación generalizando, no es por ti, simplemente cómo se va a tomar cada palabra mía con palillos, pues aunque te cite, debo contestar en general, aprecio tus palabras, y las de todos los que de verdad creeis en este proyecto, eso ante todo) Lo primero: bajad las expectativas sobre lo que se puede apreciar en una interfaz gráfica cuando hablamos de matching engines. No es una cuestión de diseño, es física. A microsegundos de latencia, lo importante ocurre bajo el capó. Los Hz de tu monitor ya te limitan lo que puedes ver, y cualquier dashboard bonito que pusiéramos encima sería, en el mejor caso, decoración. Lo que de verdad importa solo se aprecia en terminal, en métricas, en logs. Yo mismo lo he visto en acción y os digo esto de primera mano. La interfaz de TX24, hasta que incorporemos Social Trading o Metachart, va a ser funcional y limpia. No espectacular. Eso es intencionado. En todo caso, el video más espectacular será cuando acabemos el agente de IA para hacer interfaces únicas para cada usuario, ahí, que es más espectacular, se podrá ver algo. Lo segundo, y lo digo porque parece que la gente no tiene contexto: mantener la infraestructura arriba cuesta decenas de miles de euros al mes. El año que la tuvimos operativa, a pleno rendimiento y sin que prácticamente nadie la visitara ( y que ahora curiosamente se echa de menos, que casualidad), nos costó 45k euros mensuales. Multiplica por doce. Sumale prácticamente cero ingresos, porque la tesis de que "enseñando lo que hay, la gente vendrá" no funcionó como esperábamos. Eso es un hecho, no una queja. Aprendimos, ajustamos, seguimos. Cada arranque de producción real tiene un coste (y no poco). No lo hacemos cuando nos lo piden, lo hacemos cuando tiene sentido hacerlo. Eso es lo que significa gestionar un proyecto serio. Y lo tercero. Y esto ya es más personal: veo mucha gente nerviosa en el hilo y no termino de entender por qué. No me refiero a los que tienen dudas legítimas, que siempre son bienvenidas. Me refiero a los que llevan semanas en modo permanente, y que mantienen el hilo entre los tres primeros temas del subforo diariamente, invirtiendo tiempo real en algo que les genera aparentemente cero valor. De hecho ya ni tengo marketing de guerrilla porque la guerrilla, sois vosotros. A ver si os dais cuenta ya. Soy un random de internet construyendo un exchange. Ni más ni menos. Haré lo que tenga que hacer, cuando tenga que hacerlo y cómo tenga que hacerlo. Forocoches no decide la hoja de ruta de TX24. Cuando voy a un restaurante y no me convence, me voy. No me quedo en la puerta controlando quién entra y qué dice cada cliente. Reflexionad. |
Editado: 07-abr-2026 00:20 -
07-abr-2026 00:43
#1749
|
Si existe un plan gratuito es por algo. Al menos abrid el exchange a bajas revoluciones para testear |
Editado: 07-abr-2026 00:48 -
07-abr-2026 03:18
#1751
|
Esto dice Claude del texto: El texto está bien escrito para su audiencia — inversores retail y comunidad crypto — y la narrativa del “chef y los camareros” funciona muy bien para explicar que el cuello de botella no era el matching engine sino el messaging layer. Eso demuestra que entienden el problema, lo cual genera confianza. Dicho esto, hay varias cosas que me chirrían un poco si lo leo con ojo técnico: Las cifras suenan bien pero faltan detalles clave. 360K TX/s y 1μs de latencia son números que compiten con exchanges institucionales tipo LMAX o Nasdaq. Eso es perfectamente posible si hablamos de un benchmark sintético en un solo nodo con matching en memoria y serialización binaria (FlatBuffers, SBE, o similar). Pero no dicen nada sobre latencia p99, throughput bajo carga real con order book profundo, ni si eso es en un entorno de producción o en un benchmark aislado. Un exchange real tiene que manejar market data fan-out, risk checks, persistencia… y ahí las cifras bajan bastante. El salto de 4.5ms a 1μs es llamativo. Pasar de JSON/texto sobre algo tipo RabbitMQ o Redis a un protocolo binario sobre Aeron o similar justifica un salto de ese orden, sí. Pero “1 microsegundo” como latencia end-to-end incluyendo entrada y salida suena más a latencia del matching puro, no del ciclo completo. Es una distinción importante que no aclaran. “Cero riesgo” es una frase peligrosa. El hecho de poder hacer rollback con un config change está bien como patrón de diseño (feature flags, canary deploy), pero decir “cero riesgo” en un sistema financiero es una red flag para cualquiera que haya operado infraestructura de este tipo. Transmite o ingenuidad o marketing agresivo. Lo que no mencionan. No hablan de persistencia de órdenes, disaster recovery, auditoría, compliance, segregación de fondos, ni seguridad. Para un exchange esas son las cosas que realmente importan y las más difíciles de resolver. Un matching engine rápido es el “easy part” comparado con todo lo que rodea a operar un exchange regulado. En resumen: como comunicación a la comunidad, cumple. Como evaluación técnica para decidir si invertir, le falta mucho contexto. Los números no son imposibles, pero están presentados de la forma más favorable posible, que es exactamente lo que esperas de alguien que necesita financiación. No es una red flag en sí, pero tampoco es una prueba de nada — es marketing técnico bien ejecutado. |
07-abr-2026 11:16
#1752
|
Esto dice Claude del texto:
El texto está bien escrito para su audiencia — inversores retail y comunidad crypto — y la narrativa del “chef y los camareros” funciona muy bien para explicar que el cuello de botella no era el matching engine sino el messaging layer. Eso demuestra que entienden el problema, lo cual genera confianza. Dicho esto, hay varias cosas que me chirrían un poco si lo leo con ojo técnico: Las cifras suenan bien pero faltan detalles clave. 360K TX/s y 1μs de latencia son números que compiten con exchanges institucionales tipo LMAX o Nasdaq. Eso es perfectamente posible si hablamos de un benchmark sintético en un solo nodo con matching en memoria y serialización binaria (FlatBuffers, SBE, o similar). Pero no dicen nada sobre latencia p99, throughput bajo carga real con order book profundo, ni si eso es en un entorno de producción o en un benchmark aislado. Un exchange real tiene que manejar market data fan-out, risk checks, persistencia… y ahí las cifras bajan bastante. El salto de 4.5ms a 1μs es llamativo. Pasar de JSON/texto sobre algo tipo RabbitMQ o Redis a un protocolo binario sobre Aeron o similar justifica un salto de ese orden, sí. Pero “1 microsegundo” como latencia end-to-end incluyendo entrada y salida suena más a latencia del matching puro, no del ciclo completo. Es una distinción importante que no aclaran. “Cero riesgo” es una frase peligrosa. El hecho de poder hacer rollback con un config change está bien como patrón de diseño (feature flags, canary deploy), pero decir “cero riesgo” en un sistema financiero es una red flag para cualquiera que haya operado infraestructura de este tipo. Transmite o ingenuidad o marketing agresivo. Lo que no mencionan. No hablan de persistencia de órdenes, disaster recovery, auditoría, compliance, segregación de fondos, ni seguridad. Para un exchange esas son las cosas que realmente importan y las más difíciles de resolver. Un matching engine rápido es el “easy part” comparado con todo lo que rodea a operar un exchange regulado. En resumen: como comunicación a la comunidad, cumple. Como evaluación técnica para decidir si invertir, le falta mucho contexto. Los números no son imposibles, pero están presentados de la forma más favorable posible, que es exactamente lo que esperas de alguien que necesita financiación. No es una red flag en sí, pero tampoco es una prueba de nada — es marketing técnico bien ejecutado. |
07-abr-2026 12:32
#1754
|
Muy buenas a todos.
Traigo una actualización importante en nuestro apartado tecnológico. Nuestro matching engine y los procesos y servicios alrededor suyo se consolidan, estabilizan e incrementan su potencia con una mayor eficiencia global en recursos. No es únicamente el matching engine puro lo que cuenta, es también la capacidad de mandar mensajes a igual o mayor ritmo y que todo se envíe, ejecute, recepcione y procese a iguales capacidades sin crear cuellos de botella, y que a su vez se haga de manera eficiente. Nuestro claim de 300.000 TX/s ha sido batido no solo en capacidad del matching puro, si no en la capacidad a posteriori de entradas y salidas. Hicimos nuestro sistema de trading 60 veces más rápido. Así fue. Cuando arrancamos, nuestro motor de órdenes procesaba 6,000 transacciones por segundo. Funcionaba bien, pero queríamos saber si podíamos hacerlo mejor. Mucho mejor. Lo primero que hicimos fue medir. Construimos herramientas para probar el sistema bajo presión y ver exactamente dónde se perdía el tiempo. Y descubrimos algo que no esperábamos. El cerebro de nuestro sistema, la parte que decide qué órdenes se cruzan entre sí, era rapidísimo. Podía resolver más de 400,000 operaciones por segundo. El problema no era el cerebro. El problema era el camino que recorrían los mensajes para llegar hasta él y volver. Imagínalo así: tenías un chef que podía cocinar un plato en 3 segundos, pero el camarero tardaba 5 minutos en llevarle el pedido y otros 5 en traer el plato a la mesa. No necesitábamos un chef más rápido. Necesitábamos mejores camareros. Fuimos cambiando piezas una a una. Primero optimizamos la configuración de la mensajería existente. Pasamos de 6,000 a 6,400 transacciones por segundo. Algo, pero no suficiente. Después reemplazamos el sistema de transporte de mensajes por uno diseñado para velocidades extremas, usado por bolsas de valores reales. Saltamos a 88,000 transacciones por segundo. Finalmente, cambiamos el formato en que viajan los mensajes. En vez de usar un formato de texto que cualquier humano podría leer, creamos un formato binario compacto que las máquinas procesan casi instantáneamente. Ese cambio nos llevó a más de 360,000 transacciones por segundo. Los tiempos de respuesta también cambiaron drásticamente. Antes, en la primera version que hicimos, una orden tardaba 4.5 milisegundos en procesarse. Ahora tarda 1 microsegundo. Para ponerlo en perspectiva: un microsegundo es a un segundo lo que un segundo es a 11 días. Lo más importante es lo que no hicimos. No reescribimos el sistema desde cero. No cambiamos las reglas de negocio. No rompimos nada que ya funcionaba. Los servicios que dependen de nuestro motor siguen funcionando exactamente igual, sin enterarse del cambio. Diseñamos la arquitectura para que podamos volver al sistema anterior con un cambio de configuración si fuera necesario. Cero riesgo. Para un exchange, la velocidad no es un lujo. Es lo que determina si puedes competir o no. Hoy podemos procesar más de 360,000 transacciones por segundo con tiempos de respuesta de microsegundos. Ese es nuestro nuevo estándar. Resultados de nuestros ultimos tests: ![]() ![]() ![]() ![]() ![]() |
07-abr-2026 12:48
#1756
|
Esto dice Claude del texto:
El texto está bien escrito para su audiencia — inversores retail y comunidad crypto — y la narrativa del “chef y los camareros” funciona muy bien para explicar que el cuello de botella no era el matching engine sino el messaging layer. Eso demuestra que entienden el problema, lo cual genera confianza. Dicho esto, hay varias cosas que me chirrían un poco si lo leo con ojo técnico: Las cifras suenan bien pero faltan detalles clave. 360K TX/s y 1μs de latencia son números que compiten con exchanges institucionales tipo LMAX o Nasdaq. Eso es perfectamente posible si hablamos de un benchmark sintético en un solo nodo con matching en memoria y serialización binaria (FlatBuffers, SBE, o similar). Pero no dicen nada sobre latencia p99, throughput bajo carga real con order book profundo, ni si eso es en un entorno de producción o en un benchmark aislado. Un exchange real tiene que manejar market data fan-out, risk checks, persistencia… y ahí las cifras bajan bastante. El salto de 4.5ms a 1μs es llamativo. Pasar de JSON/texto sobre algo tipo RabbitMQ o Redis a un protocolo binario sobre Aeron o similar justifica un salto de ese orden, sí. Pero “1 microsegundo” como latencia end-to-end incluyendo entrada y salida suena más a latencia del matching puro, no del ciclo completo. Es una distinción importante que no aclaran. “Cero riesgo” es una frase peligrosa. El hecho de poder hacer rollback con un config change está bien como patrón de diseño (feature flags, canary deploy), pero decir “cero riesgo” en un sistema financiero es una red flag para cualquiera que haya operado infraestructura de este tipo. Transmite o ingenuidad o marketing agresivo. Lo que no mencionan. No hablan de persistencia de órdenes, disaster recovery, auditoría, compliance, segregación de fondos, ni seguridad. Para un exchange esas son las cosas que realmente importan y las más difíciles de resolver. Un matching engine rápido es el “easy part” comparado con todo lo que rodea a operar un exchange regulado. En resumen: como comunicación a la comunidad, cumple. Como evaluación técnica para decidir si invertir, le falta mucho contexto. Los números no son imposibles, pero están presentados de la forma más favorable posible, que es exactamente lo que esperas de alguien que necesita financiación. No es una red flag en sí, pero tampoco es una prueba de nada — es marketing técnico bien ejecutado. Estos son los mensajes que este hombre debería responder, daría tranquilidad a los que aún tienen fe en esto |
07-abr-2026 13:06
#1758
|
Yo creo que es el propio MM, que solo pone liquidez por arriba para que la gente tenga oportunidad de entrar pero no de salir Pero ni asi sube el precio de esto |
07-abr-2026 13:43
#1759
|
Voy a intentar responder, sí.
(Pongo un mensaje a continuación generalizando, no es por ti, simplemente cómo se va a tomar cada palabra mía con palillos, pues aunque te cite, debo contestar en general, aprecio tus palabras, y las de todos los que de verdad creeis en este proyecto, eso ante todo) Lo primero: bajad las expectativas sobre lo que se puede apreciar en una interfaz gráfica cuando hablamos de matching engines. No es una cuestión de diseño, es física. A microsegundos de latencia, lo importante ocurre bajo el capó. Los Hz de tu monitor ya te limitan lo que puedes ver, y cualquier dashboard bonito que pusiéramos encima sería, en el mejor caso, decoración. Lo que de verdad importa solo se aprecia en terminal, en métricas, en logs. Yo mismo lo he visto en acción y os digo esto de primera mano. La interfaz de TX24, hasta que incorporemos Social Trading o Metachart, va a ser funcional y limpia. No espectacular. Eso es intencionado. En todo caso, el video más espectacular será cuando acabemos el agente de IA para hacer interfaces únicas para cada usuario, ahí, que es más espectacular, se podrá ver algo. Lo segundo, y lo digo porque parece que la gente no tiene contexto: mantener la infraestructura arriba cuesta decenas de miles de euros al mes. El año que la tuvimos operativa, a pleno rendimiento y sin que prácticamente nadie la visitara ( y que ahora curiosamente se echa de menos, que casualidad), nos costó 45k euros mensuales. Multiplica por doce. Sumale prácticamente cero ingresos, porque la tesis de que "enseñando lo que hay, la gente vendrá" no funcionó como esperábamos. Eso es un hecho, no una queja. Aprendimos, ajustamos, seguimos. Cada arranque de producción real tiene un coste (y no poco). No lo hacemos cuando nos lo piden, lo hacemos cuando tiene sentido hacerlo. Eso es lo que significa gestionar un proyecto serio. Y lo tercero. Y esto ya es más personal: veo mucha gente nerviosa en el hilo y no termino de entender por qué. No me refiero a los que tienen dudas legítimas, que siempre son bienvenidas. Me refiero a los que llevan semanas en modo permanente, y que mantienen el hilo entre los tres primeros temas del subforo diariamente, invirtiendo tiempo real en algo que les genera aparentemente cero valor. De hecho ya ni tengo marketing de guerrilla porque la guerrilla, sois vosotros. A ver si os dais cuenta ya. Soy un random de internet construyendo un exchange. Ni más ni menos. Haré lo que tenga que hacer, cuando tenga que hacerlo y cómo tenga que hacerlo. Forocoches no decide la hoja de ruta de TX24. Cuando voy a un restaurante y no me convence, me voy. No me quedo en la puerta controlando quién entra y qué dice cada cliente. Reflexionad. Tiene la jeta de pedir reflexión... ![]() Pasar de quemar 45k/mes en infraestructura para 'nadie' a enseñar logs desde un MacBook... La lógica brilla por su ausencia. Si realmente existieran esos arranques de producción, veríamos logs de servidor remoto, no un terminal ejecutado en local desde un portátil. Y ahora resulta que es un "random" de internet. Ya no saca a relucir la VASP y demás parafernalia... Curioso que un "random" hable de inversores suizos y millones mientras emite un token al público sin tener un producto operativo. Los experimentos con gaseosa se hacen en casa, cuando uno pide dinero real, deja de ser un "random" para tener una responsabilidad profesional.
|
07-abr-2026 13:50
#1760
|
Tiene la jeta de pedir reflexión...
![]() Pasar de quemar 45k/mes en infraestructura para 'nadie' a enseñar logs desde un MacBook... La lógica brilla por su ausencia. Si realmente existieran esos arranques de producción, veríamos logs de servidor remoto, no un terminal ejecutado en local desde un portátil. Y ahora resulta que es un "random" de internet. Ya no saca a relucir la VASP y demás parafernalia... Curioso que un "random" hable de inversores suizos y millones mientras emite un token al público sin tener un producto operativo. Los experimentos con gaseosa se hacen en casa, cuando uno pide dinero real, deja de ser un "random" para tener una responsabilidad profesional. x1000Osease literalmente nos vende durante casi 2 años que la empresa es sólida y real y está todo prácticamente finiquitado, con un producto a la venta, se ven las costuras del proyecto y que no hay cimiento ninguno, se cae el mercado del producto que vende por decisión y mala gestión suya y todavía el tío se pregunta por que está la gente mosqueada y nos invita a reflexionar
|
Editado: 07-abr-2026 13:53 -
07-abr-2026 13:54
#1761
|
La gente no mejora, solo descansan. |
07-abr-2026 14:08
#1762
|
No se puede resumir mejor. Es que tiene el jetoncio de cemento armado el tío. Encima su consejo es "si no te gusta este desastre vendes y te piras" cuando ni siquiera se puede vender porque no le sale de los cojones en encender el market maker del que tanto presumía de su ética y funcionamiento hace medio año
x1000Osease literalmente nos vende durante casi 2 años que la empresa es sólida y real y está todo prácticamente finiquitado, con un producto a la venta, se ven las costuras del proyecto y que no hay cimiento ninguno, se cae el mercado del producto que vende por decisión y mala gestión suya y todavía el tío se pregunta por que está la gente mosqueada y nos invita a reflexionar ![]() A mi me preocupa lo de no haber vuelto a leerle el "confiad en el proceso". Esa frase se la ha llevado el viento |
07-abr-2026 14:42
#1764
|
Tiene la jeta de pedir reflexión...
![]() Pasar de quemar 45k/mes en infraestructura para 'nadie' a enseñar logs desde un MacBook... La lógica brilla por su ausencia. Si realmente existieran esos arranques de producción, veríamos logs de servidor remoto, no un terminal ejecutado en local desde un portátil. Y ahora resulta que es un "random" de internet. Ya no saca a relucir la VASP y demás parafernalia... Curioso que un "random" hable de inversores suizos y millones mientras emite un token al público sin tener un producto operativo. Los experimentos con gaseosa se hacen en casa, cuando uno pide dinero real, deja de ser un "random" para tener una responsabilidad profesional. |
07-abr-2026 15:21
#1766
Tú no lees lo que quieres leer, que va. Lo que citas parece más una poesía que nada
|
08-abr-2026 12:06
#1768
|
Muy buenas a todos.
Traigo una actualización importante en nuestro apartado tecnológico. Nuestro matching engine y los procesos y servicios alrededor suyo se consolidan, estabilizan e incrementan su potencia con una mayor eficiencia global en recursos. No es únicamente el matching engine puro lo que cuenta, es también la capacidad de mandar mensajes a igual o mayor ritmo y que todo se envíe, ejecute, recepcione y procese a iguales capacidades sin crear cuellos de botella, y que a su vez se haga de manera eficiente. Nuestro claim de 300.000 TX/s ha sido batido no solo en capacidad del matching puro, si no en la capacidad a posteriori de entradas y salidas. Hicimos nuestro sistema de trading 60 veces más rápido. Así fue. Cuando arrancamos, nuestro motor de órdenes procesaba 6,000 transacciones por segundo. Funcionaba bien, pero queríamos saber si podíamos hacerlo mejor. Mucho mejor. Lo primero que hicimos fue medir. Construimos herramientas para probar el sistema bajo presión y ver exactamente dónde se perdía el tiempo. Y descubrimos algo que no esperábamos. El cerebro de nuestro sistema, la parte que decide qué órdenes se cruzan entre sí, era rapidísimo. Podía resolver más de 400,000 operaciones por segundo. El problema no era el cerebro. El problema era el camino que recorrían los mensajes para llegar hasta él y volver. Imagínalo así: tenías un chef que podía cocinar un plato en 3 segundos, pero el camarero tardaba 5 minutos en llevarle el pedido y otros 5 en traer el plato a la mesa. No necesitábamos un chef más rápido. Necesitábamos mejores camareros. Fuimos cambiando piezas una a una. Primero optimizamos la configuración de la mensajería existente. Pasamos de 6,000 a 6,400 transacciones por segundo. Algo, pero no suficiente. Después reemplazamos el sistema de transporte de mensajes por uno diseñado para velocidades extremas, usado por bolsas de valores reales. Saltamos a 88,000 transacciones por segundo. Finalmente, cambiamos el formato en que viajan los mensajes. En vez de usar un formato de texto que cualquier humano podría leer, creamos un formato binario compacto que las máquinas procesan casi instantáneamente. Ese cambio nos llevó a más de 360,000 transacciones por segundo. Los tiempos de respuesta también cambiaron drásticamente. Antes, en la primera version que hicimos, una orden tardaba 4.5 milisegundos en procesarse. Ahora tarda 1 microsegundo. Para ponerlo en perspectiva: un microsegundo es a un segundo lo que un segundo es a 11 días. Lo más importante es lo que no hicimos. No reescribimos el sistema desde cero. No cambiamos las reglas de negocio. No rompimos nada que ya funcionaba. Los servicios que dependen de nuestro motor siguen funcionando exactamente igual, sin enterarse del cambio. Diseñamos la arquitectura para que podamos volver al sistema anterior con un cambio de configuración si fuera necesario. Cero riesgo. Para un exchange, la velocidad no es un lujo. Es lo que determina si puedes competir o no. Hoy podemos procesar más de 360,000 transacciones por segundo con tiempos de respuesta de microsegundos. Ese es nuestro nuevo estándar. Resultados de nuestros ultimos tests: ![]() ![]() ![]() ![]() ![]() Gracias por la info, la verdad es que aún no entendiendo yo nada del mecanismo intento de un exchange, tiene bastante buena pinta. Lo que pones en tu mensaje siguiente acerca de la interfaz gráfica tiene bastante sentido, al final no deja de ser algo que come recursos. 2 preguntas tengo ahora (si es que se pueden responder por tema legal/compliance o no revelar datos fundamentales, si no, no hay problema )- Se puede simular el comportamiento del exchange en un entorno más real tal y como pone alguien en un comentario siguiente al tuyo? Con "algo más real" me refiero a diferentes test de esfuerzo y tortura, posibles fallos etc - Hay alguna manera de empezar a echar a andar el exchange pero en "modo lento" para usuarios normalitos y en "modo rápido" para usuarios más avanzados o que estén dispuestos a pagar un premium? Imagino que ya habréis pensado en algo así y por vuestras razones no lo habréis hecho... Muchas gracias por todo! |
08-abr-2026 13:04
#1769
|
Voy a intentar responder, sí.
(Pongo un mensaje a continuación generalizando, no es por ti, simplemente cómo se va a tomar cada palabra mía con palillos, pues aunque te cite, debo contestar en general, aprecio tus palabras, y las de todos los que de verdad creeis en este proyecto, eso ante todo) Lo primero: bajad las expectativas sobre lo que se puede apreciar en una interfaz gráfica cuando hablamos de matching engines. No es una cuestión de diseño, es física. A microsegundos de latencia, lo importante ocurre bajo el capó. Los Hz de tu monitor ya te limitan lo que puedes ver, y cualquier dashboard bonito que pusiéramos encima sería, en el mejor caso, decoración. Lo que de verdad importa solo se aprecia en terminal, en métricas, en logs. Yo mismo lo he visto en acción y os digo esto de primera mano. La interfaz de TX24, hasta que incorporemos Social Trading o Metachart, va a ser funcional y limpia. No espectacular. Eso es intencionado. En todo caso, el video más espectacular será cuando acabemos el agente de IA para hacer interfaces únicas para cada usuario, ahí, que es más espectacular, se podrá ver algo. Lo segundo, y lo digo porque parece que la gente no tiene contexto: mantener la infraestructura arriba cuesta decenas de miles de euros al mes. El año que la tuvimos operativa, a pleno rendimiento y sin que prácticamente nadie la visitara ( y que ahora curiosamente se echa de menos, que casualidad), nos costó 45k euros mensuales. Multiplica por doce. Sumale prácticamente cero ingresos, porque la tesis de que "enseñando lo que hay, la gente vendrá" no funcionó como esperábamos. Eso es un hecho, no una queja. Aprendimos, ajustamos, seguimos. Cada arranque de producción real tiene un coste (y no poco). No lo hacemos cuando nos lo piden, lo hacemos cuando tiene sentido hacerlo. Eso es lo que significa gestionar un proyecto serio. Y lo tercero. Y esto ya es más personal: veo mucha gente nerviosa en el hilo y no termino de entender por qué. No me refiero a los que tienen dudas legítimas, que siempre son bienvenidas. Me refiero a los que llevan semanas en modo permanente, y que mantienen el hilo entre los tres primeros temas del subforo diariamente, invirtiendo tiempo real en algo que les genera aparentemente cero valor. De hecho ya ni tengo marketing de guerrilla porque la guerrilla, sois vosotros. A ver si os dais cuenta ya. Soy un random de internet construyendo un exchange. Ni más ni menos. Haré lo que tenga que hacer, cuando tenga que hacerlo y cómo tenga que hacerlo. Forocoches no decide la hoja de ruta de TX24. Cuando voy a un restaurante y no me convence, me voy. No me quedo en la puerta controlando quién entra y qué dice cada cliente. Reflexionad. reflexionad chicos, si habeis invertido en un exchange y perdeis pasta, no os quedeis en forocoches reflotando el hilo a ver quien hatea o me la chupa |
08-abr-2026 16:17
#1770
|
Gracias por la info, la verdad es que aún no entendiendo yo nada del mecanismo intento de un exchange, tiene bastante buena pinta.
Lo que pones en tu mensaje siguiente acerca de la interfaz gráfica tiene bastante sentido, al final no deja de ser algo que come recursos. 2 preguntas tengo ahora (si es que se pueden responder por tema legal/compliance o no revelar datos fundamentales, si no, no hay problema )- Se puede simular el comportamiento del exchange en un entorno más real tal y como pone alguien en un comentario siguiente al tuyo? Con "algo más real" me refiero a diferentes test de esfuerzo y tortura, posibles fallos etc - Hay alguna manera de empezar a echar a andar el exchange pero en "modo lento" para usuarios normalitos y en "modo rápido" para usuarios más avanzados o que estén dispuestos a pagar un premium? Imagino que ya habréis pensado en algo así y por vuestras razones no lo habréis hecho... Muchas gracias por todo! No te preocupes por no dominar todos los detalles técnicos, es completamente normal. Al igual que tú tienes tu propio ámbito de expertise, el nuestro es este, y precisamente para eso estamos aquí: para entenderlo por los dos. Con eso dicho, te respondo con mucho gusto. Sobre simular el comportamiento del exchange con pruebas de estrés: Puedo intentar montarlo en local, aunque los resultados, a priori, serán necesariamente inferiores a los que obtenemos corriendo cada servicio de forma independiente y aislada (el cuello de botella en ese caso es el HW no el SW), como cuando publicamos los resultados del matching engine. La razón es sencilla: un exchange completo es (me invento el dato) del orden de 10 procesos concurrentes, todos compitiendo por los recursos del mismo hardware (ya sea mi portátil o los equipos que tengamos disponibles). Eso crea un techo muy bajo. Cuando lo desplegamos en la nube, esos límites se vuelven dinámicos y escalables en función de la demanda real para cada servicio. Dicho esto, puedo prepararlo como ejercicio ilustrativo para que podáis ver el conjunto funcionando, siempre con la cuestión en mente de que los números no reflejan el rendimiento real en producción. Sobre la segunda cuestión: No existe un "modo reducido". Un exchange o está en marcha o está apagado; no hay punto intermedio. La infraestructura mínima necesaria para garantizar un servicio seguro, rápido y fiable es considerable. Solo en costes de cloud, estamos hablando de aproximadamente 45.000 USD mensuales, y a eso hay que sumarle el equipo humano detrás: supervisión 24/7, mantenimiento, compliance, custodia, finanzas, legal, desarrollo… El coste operativo es lo suficientemente elevado como para no hacerlo. Hay costes base obligatorios, vaya el exchange a todo trapo, o a medio gas, y muchos que incluso son independientes y de hecho muchos de ellos, fuera del ambiente tecnologico pero obligatorios igualmente, Lo que cambiarian son los gastos dinamicos en base a la saturacion... pero en general te da lo mismo, si te puedes meter en el fregado de poder cubrir gastos fijos, puedes cubrir los dinamicos sin problema. No es nuestro caso por ahora sin la ronda de financiación acabada. De hecho, esto fue uno de los factores que llevó a tomar la decisión de poner la plataforma offline. En su momento se arrancó en producción con la expectativa de que tener el producto visible facilitaría la captación de inversión. No fue así, y hay que reconocerlo con honestidad: fue un error de estrategia, y como todo en los negocios, uno aprende. Al comprobar que el interés inversor no llegaba por esa vía, la decisión lógica fue optimizar el modelo: pasar a una web-brochure conectada a redes, con blog y podcast, con un coste de mantenimiento radicalmente inferior, que nos permite construir marca y presencia de forma sostenible, y donde cualquier inversor o interesado tiene los datos de contacto disponibles de forma directa. Espero que las respuestas te sean satisfactorias. Saludos |
Editado: 08-abr-2026 17:04 -





O es un Dunning Kruger patológico o toma a la gente por imbécil... Si esto es lo que presenta ante un VC serio, se le ríen en la cara en el mejor de los casos.
Y habrá quien aplauda...
No hace falta que ningún soplapollas eche mierda, tu propio subconsciente se percata de la absoluta ausencia de hechos en el comunicado y por eso reaccionas así...
x1000
)