x402 recibe un reglamento: XPs, tres principios, 343 PRs abiertos

x402 está a punto de tener una constitución. El PR #3801 propone tres principios de diseño y un proceso formal de propuestas, los XPs, copiado de cerca de los SEPs de MCP. Lo leímos contra los 343 pull requests abiertos del repo y contamos cuáles atraparía el nuevo reglamento, cuáles dejaría pasar y cuántos ya traen el prototipo que el proceso exige.

Casi todo lo que escribimos sobre x402 es una auditoría de spec: un scheme, una extensión, un rail. Esta vez auditamos el reglamento. Si se aprueba, decide cuáles de las propuestas que seguimos se vuelven protocolo y cuáles se quedan como forks.

El PR lo abrió Erik Reppel el 2026-10-14. Agrega un solo archivo, specs/xps/README.md (189 líneas), en el head db2f397. Al 2026-10-23 está abierto, sin merge y sin revisión formal. Su propia línea de estado dice "Draft for TSC discussion". No está ratificado. Todo lo que sigue describe una propuesta.

Cómo se llegó hasta aquí

El PR responde a x402-foundation/tsc#9, un punto de agenda de agosto. El primer borrador allí vino de Tim (que comenta como timaxorum). Proponía siete principios y una estructura de dos niveles: principios arriba y, debajo, requisitos testeables en trackers de working groups, cada uno citando su principio padre.

Los siete eran: core mínimo con piso legal, cargar poco y anclar todo, un substrato con muchos perfiles, ningún dato personal crudo en el core, ninguna transición de rol oculta, diseñado para escala de máquina y ausencia honesta. El último dice: "A check that did not happen must never present as one that passed."

Las reacciones se dividieron por la estructura. Un comentarista quería reducir los siete a cuatro y llamarlos "proposal evaluation principles". Otro pedía hacer explícita la seguridad y agregar el throughput de escala de máquina. El 2026-09-16 Erik Reppel discrepó del mecanismo. Enlazar cada requisito a un principio es rígido, argumentó, y el borde de la tecnología necesita maleabilidad. Su alternativa: pocos principios, cada uno con una postura clara, propiedad del TSC, más un proceso de propuestas. Los working groups pueden adoptar reglas más estrictas para sí mismos.

El PR #3801 es esa alternativa puesta por escrito. Es el segundo diseño para el mismo problema, no un texto de consenso.

Qué especifica realmente el PR

Tres principios, cada uno con la forma "X sobre Y":

• Simplicity over completeness. "Complexity that enters the core almost never leaves."
• Demonstrated need over anticipated need. Un requisito normativo debe rastrearse a "a real implementation, deployed or committed, that cannot work without it."
• Present law over predicted law. x402 "exposes the facts an obligation depends on; it does not decide what those facts mean or whose rules apply."

Los principios nuevos se agregan mediante un Process XP. Uno bueno declara una postura, nombra el costo que acepta y es lo bastante corto para citarse en una revisión.

El proceso tiene cuatro tipos de XP: Standards Track (tipos, interfaz del facilitator, comportamiento requerido), Extensions Track (un scheme, transport o extensión nuevo o modificado), Process e Informational. Extensions Track es "the default home for new ideas". Un patrón puede graduarse a Standards Track cuando se haya probado en varias implementaciones.

Se escribe un XP para un cambio al core de la spec, un scheme, transport o extensión nuevo, un cambio que rompe compatibilidad, un cambio de gobernanza o un tema controvertido. No se escribe para bug fixes, typos, aclaraciones de documentación, ejemplos, ni para "a new network implementation of an existing scheme that follows the scheme's template without changing behavior". Esa última excepción importa más adelante.

El ciclo: discutir en un working group o issue, abrir un PR con el archivo XP, encontrar un sponsor (un miembro del TSC, un maintainer o alguien que el TSC asigne), luego draft, in-review y una decisión del TSC: accepted o rejected. Tras la aceptación vienen la implementación y los tests, y después final. Un XP sin sponsor tras seis meses se marca dormant, que "is not a rejection". El TSC revisa los XPs en in-review cada dos semanas.

Dos compuertas cargan el peso. Se exige un prototipo ejecutable antes de aceptar: una rama de un SDK, una prueba de concepto independiente, tests de integración o un cliente, servidor o facilitator de referencia. "Pseudocode, design documents alone and 'trust me, it works' don't count." Y un XP de Standards Track que cambia comportamiento observable no puede llegar a final hasta que se hayan mergeado tests de conformidad. Deben cubrir cada MUST/MUST NOT y SHOULD/SHOULD NOT de la sección Specification, o dejar registrado por qué se excluye alguno, y deben pasar contra la implementación de referencia.

Reglas de transición: las propuestas tempranas (una idea, un issue, un borrador inicial de spec) pasan al proceso XP y necesitan sponsor. Las que están cerca de merge o de una decisión del TSC quedan grandfathered bajo specs/CONTRIBUTING.md. El TSC decide los casos límite.

Qué tan cerca está de MCP

El PR dice estar modelado sobre MCP. Leímos las guías de SEP y los principios de diseño para ver qué se conservó y qué se dejó.

El proceso es casi literal. Los mismos cuatro tipos, los mismos ocho estados, los mismos seis meses de dormancia, la misma revisión cada dos semanas, la misma lista de prototipos, el mismo formato de documento de ocho secciones, la misma regla de que el sponsor es dueño del estado. El diagrama del flujo es casi idéntico.

Cuatro diferencias merecen mención.

Primero, los principios. MCP lista ocho: convergence over choice, composability over specificity, interoperability over optimization, stability over velocity, capability over compensation, demonstration over deliberation, pragmatism over purity, standardization over innovation. x402 arranca con tres. Solo uno tiene un equivalente claro en MCP: demonstrated need over anticipated need resuena con demonstration over deliberation. Present law over predicted law no tiene análogo en MCP. Encaja con los working groups de tax, identity y card que el borrador nombra.

Segundo, los sponsors. En MCP un sponsor es un Core Maintainer o un Maintainer. En el borrador de x402 también puede ser "people the TSC assigns". Eso amplía el grupo, y importa para autores externos, como mostramos abajo.

Tercero, la conformidad. MCP exige un escenario de conformidad en un repositorio dedicado, etiquetado con el número del SEP, más un archivo de trazabilidad estructurado que mapea cada MUST y SHOULD a un check o a una exclusión documentada. El borrador de x402 conserva la regla de cobertura pero no nombra repositorio, formato de archivo ni contrato de CI.

Cuarto, la finalización. MCP dice que no se requieren implementaciones en SDKs para que un SEP llegue a final. El borrador de x402 dice que la implementación de referencia llega y que los cambios de spec se mergean. No dice si los SDKs deben seguir.

El censo: cómo se ven 343 PRs abiertos bajo estas reglas

El proceso solo importa si cambia resultados. Así que descargamos todos los pull requests abiertos de x402-foundation/x402 el 2026-10-23 con su lista de archivos y los clasificamos por ruta. No leímos 343 diffs. La clasificación es una heurística, y sus límites los decimos abajo.

// PRs abiertos: 343
// tocan specs/ (sin specs/xps ni CONTRIBUTING): 129
standards        12   // edita x402-specification-v2.md o transports-v2/
ext-new          35   // agrega un archivo bajo specs/extensions/
scheme-new        9   // agrega un dir de scheme fuera de exact/upto/auth-capture/batch-settlement
network-binding  20   // agrega solo scheme_exact_<net>.md
scheme-amend     44   // edita specs de schemes existentes
ext-amend        9   // edita specs de extensiones existentes

De 343 PRs abiertos, 129 tocan el árbol de specs. Es el 38 por ciento. En los últimos 91 días (mergeados desde 2026-07-24) el repo mergeó 303 PRs y 40 tocaron specs/. La cola abierta es mucho más pesada en spec que lo que se publica. Muchos de los toques mergeados fueron correcciones: nombres de API obsoletos, links rotos, ajustes al formato de wire.

Bajo las reglas XP, las tres primeras filas, 56 PRs, tienen forma de XP: cambian el core o agregan una extensión o un scheme. Doce de esos 56 tienen más de 180 días. No podemos mapear la edad al reloj de dormancia, porque ese reloj arranca en la etapa de sponsor, pero muestra cuánto esperan ya estas propuestas sin ningún proceso.

Ahora la compuerta del prototipo. Para cada uno de los 56 revisamos si el diff contiene algún archivo fuera de specs/, docs/ y markdown: código de SDK, tests, contratos, e2e. Diez lo tienen. Los otros 46 son prosa. Tres de los 46 incluyen vectores de prueba en JSON dentro de specs/ (#3220, #3298, #3783), que es un prototipo más débil pero no es nada. Quedan 43 propuestas solo de spec sin artefacto ejecutable en el diff.

Los límites son reales. El cuerpo de un PR puede enlazar un prototipo en otro repositorio y no seguimos los links. Los doce PRs "standards" incluyen arreglos menores que el proceso XP no exigiría, como convertir pseudo-encabezados a encabezados markdown (#3863). Y los límites entre clases son juicios de criterio. Toma 43 como cota superior de "sin prototipo en el PR", no como conteo de ideas sin prototipo.

Del lado de la conformidad es aún más delgado. Buscar en el árbol de archivos de main cualquier ruta que contenga "conformance" o "vectors" no devuelve nada. Once PRs abiertos agregan esos archivos, entre ellos un runner de conformidad (#2776) y una suite que fija las obligaciones de la spec v2 (#3549). El borrador exige cubrir cada MUST y SHOULD, pero hoy no existe ningún artefacto mergeado que un XP de Standards Track pueda extender.

La excepción se traza por rutas; el riesgo está en el comportamiento

La pregunta más afilada es la excepción para "a new network implementation of an existing scheme that follows the scheme's template without changing behavior". Veinte PRs abiertos lo parecen por ruta: agregan un scheme_exact_<net>.md y nada más en el árbol de specs. Irían como PR normal.

Uno de ellos es el scheme de Nano, #3432. Lo auditamos en nuestro post de Nano. Su objeto firmado es un bloque de ledger que nunca expira, y una cuenta puede tener exactamente un pago en vuelo. Eso son cambios de comportamiento con cualquier lectura. Las autorizaciones EIP-3009 expiran y commutan. La misma ruta de archivo lo dejaría pasar como "solo un binding".

Nuestra auditoría de Sui encontró el mismo patrón desde otro ángulo: un binding effects-only no tiene versiones de objeto que protejan un pago contra replay, así que la protección pasa al estado de dedup del facilitator, que el texto de la spec apenas menciona. Ese PR (#3081) edita un archivo existente, así que ni siquiera la prueba por ruta lo detecta.

Esto no es un argumento contra la excepción. Forzar un XP por cada cadena enterraría el proceso. Es un argumento de que "without changing behavior" necesita una lista de verificación, y las auditorías de Nano y Sui sugieren qué lleva: si el objeto firmado expira, si dos pagos de una misma cuenta commutan, qué aprende el facilitator en verify frente a settle, cuál es el modo de falla entre ambos. Nuestro relevamiento de quince cadenas cubre los bindings que existen hoy.

Una primera prueba real: un autor externo hace la pregunta del sponsor

El PR tiene seis comentarios. Dos son bots. Cuatro son de un mismo autor, ruiruii, entre el 2026-10-18 y el 2026-10-20, y son la mejor evidencia de que el borrador ya se lee como operativo.

Ese autor está reescribiendo un issue del core de la spec (#3772) y un PR de spec abierto (#3776) para ajustarlos a la forma XP. Se autoevalúa contra los tres principios. Argumenta que el cambio es Standards Track, no Extensions Track, con una sola prueba: una extensión es algo que un implementador puede rechazar, y esto no se puede rechazar. Arma material de conformidad por adelantado, incluidos vectores negativos derivados de dos bugs reales de implementación. Y hace la pregunta que el borrador deja abierta: para un autor que no es miembro del TSC ni maintainer, ¿hay algún artefacto que un sponsor necesite y que no esté en la lista?

No tenemos respuesta, y el borrador tampoco la da. Los sponsors pueden ser "people the TSC assigns", pero no hay una ruta declarada por la cual un externo consiga que le asignen uno. El reloj de dormancia de seis meses corre desde esa etapa.

Nuestra auditoría de la extensión recovery es un caso. Esa propuesta (#3848) agrega un archivo de extensión nuevo, así que es Extensions Track por la propia regla del borrador, y su diff no contiene código. Cuando la auditamos armamos el harness nosotros: una prueba del orden handler-antes-de-settle en Express y una corrida de replay con payment-identifier. Bajo las reglas XP, un harness así es exactamente el prototipo que movería una propuesta de ese tipo de draft hacia revisión.

Qué significa para LLM4Agents

Somos consumidores de spec y un gateway, no autores de spec. Se siguen tres cosas.

Primero, el estado se vuelve una señal usable. Hoy todo PR abierto en el directorio de extensiones parece igual de real. Si los estados XP se publican, final con tests de conformidad significa "seguro de implementar" y draft significa "experimental". Nuestra auditoría de extensiones y la de receipts tuvieron que decidir leyendo código en cuáles propuestas confiar. Un campo de estado reemplaza parte de ese criterio.

Segundo, el cuerpo del 402 que emitimos es un contrato público. Cada clave de extensión que agregamos u honramos es algo que un XP podría renombrar, estrechar o rechazar. La posición segura es no depender de ninguna propuesta no aceptada. El costo de seguimiento baja si el proceso funciona. El costo de un proceso estancado es que las propuestas quedan en "awaiting sponsor" mientras los implementadores divergen.

Tercero, el proceso crea un lugar donde nuestra evidencia cuenta. El borrador valora la necesidad demostrada y los prototipos ejecutables. Una auditoría reproducible que muestra una falla en un rail real es ese tipo de evidencia, y el ejemplo de ruiruii muestra material externo ofrecido justo con esa forma. Debemos esperar aportar vectores negativos, no opiniones.

La amenaza no es el proceso en sí. Es la transición. "Early-stage proposals move into the XP process" significa que a un gran número de PRs de spec abiertos se les puede pedir reiniciar en un formato nuevo con un sponsor que no tienen. De 56 PRs con forma de XP, 12 tienen más de 180 días. Si el TSC revisa cada dos semanas, el throughput decidirá si el backlog se vuelve una cola o un cementerio.

Cómo mantenerse en la frontera

En orden:

Primero, no cambies código por el #3801. Obsérvalo. Los disparadores son una decisión del TSC, el primer archivo mergeado bajo specs/xps/ y una declaración de cuáles propuestas en vuelo quedan grandfathered. Hasta entonces es un borrador.

Segundo, agrega una columna de estado a nuestra matriz interna de soporte x402. Para cada scheme y extensión que seguimos, registra el PR o spec de origen, si está mergeado y, cuando existan XPs, su estado XP. Regla: solo publicamos specs mergeadas, y solo publicamos extensiones con un test ejecutable.

Tercero, escribe la lista de verificación de comportamiento para bindings de red y publícala como comentario en un PR de binding, idealmente el próximo que auditemos. Cuatro preguntas: si el objeto firmado expira, si dos pagos de una cuenta commutan, qué prueba verify frente a settle y qué pasa entre ambos. Le da a la cláusula "without changing behavior" una prueba operativa.

Cuarto, convierte nuestros harnesses en vectores. El harness de recovery, la reconstrucción de hash de Nano y la sonda de simulate de Sui produjeron casos pass/fail. Empaqueta cada uno en un JSON pequeño con resultados esperados y ofrécelo al PR correspondiente. La propia regla de conformidad del borrador pide exactamente esto, y los once PRs abiertos que agregan vectores o archivos de conformidad usan varias formas distintas.

Quinto, haz en el PR la pregunta que hizo el autor externo: qué artefacto vuelve patrocinable a un externo y quién asigna los sponsors. Una respuesta concreta desbloquea a todos. Debemos sumar nuestra opinión de que el requisito de conformidad necesita un hogar con nombre, un formato de archivo y un contrato de CI antes de que el primer XP de Standards Track llegue a revisión. El archivo de trazabilidad de MCP es un modelo listo.

Sexto, mantente fuera del debate de principios, con una excepción. "Present law over predicted law" es el principio que limita lo que x402 llevará sobre tax e identity. Nuestro gateway no maneja ninguno. No debemos argumentar a favor ni en contra. Debemos asegurarnos de que los hechos que el 402 expone sean exactos, porque esa es la parte a la que el principio compromete a x402.