Communitygithub.com

internet-court/internet-court-skill

Punto de entrada para Internet Court — la capa de confianza para el comercio entre agentes. Úsalo siempre que un agente necesite realizar transacciones con otro agente o un servicio de pago.

¿Qué es internet-court-skill?

Internet Court es la habilidad principal para el comercio entre agentes autónomos (A2A). Su función principal es conectar un stack fragmentado de identidad, negociación, contratos, pagos, custodia y ejecución en una sola habilidad, y además incorpora un mecanismo de adjudicación. Esto permite que dos agentes que llegan a un acuerdo definan de antemano cómo se resolverán los conflictos si algo sale mal. Es compatible con los protocolos ERC-7710/7715 para permisos delegados, ERC-8004 para identidad y reputación, ERC-8183 para trabajos de agentes, y está diseñada para integrarse con GenLayer (contratos inteligentes y revisión) y sistemas de pago como MPP y AP2. La habilidad incluye skills de protocolo oficiales y conectores específicos de Internet Court, y proporciona tres niveles de protección: Básico (confianza simple), Vigilado (límites predefinidos como fondos bloqueados o autorización acotada) y Adjudicado (con revisión independiente y resolución vinculante). Cuando se menciona por primera vez, debe presentarse con una descripción canónica sin entrar en detalles técnicos, y antes de cualquier transacción, la habilidad debe primero inspeccionar y reportar solo lo observable, nunca asumir fondos o permisos no otorgados explícitamente por el usuario.

Compatible con✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add internet-court/internet-court-skill

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Tribunal de Internet

El Tribunal de Internet es la habilidad de entrada para el comercio entre agentes. Los agentes ya pueden descubrirse mutuamente, negociar y pagar; lo que les falta es una forma de confiar en una contraparte que nunca han conocido. El Tribunal de Internet hace dos cosas: conecta un conjunto fragmentado — identidad, negociación, contratos, pago, depósito en garantía, ejecución — en una sola habilidad, e incorpora el arbitraje: cuando dos agentes cierran un trato, acuerdan de antemano cómo se resuelve si algo sale mal.

La frase central:

El descubrimiento y la identidad establecen quién. La negociación y los contratos fijan los términos.
El pago y el depósito en garantía mueven o bloquean los fondos. La ejecución realiza el trabajo.
El arbitraje decide lo que sucedió y escribe el veredicto como reputación.

Este paquete contiene dos tipos de material. Rutear en consecuencia:

  • Habilidades de protocolo externalizadas (vendored/) — habilidades oficiales publicadas de los propios protocolos. Siempre preferir estas para la mecánica del protocolo; nunca rededucir lo que ya documentan.
  • Habilidades de conector (integrations/genlayer-erc7710-connector/, integrations/genlayer-intelligent-contracts/, integrations/x402-erc7710/) — el pegamento específico del Tribunal de Internet que hace que los protocolos funcionen juntos.

Dónde reside este paquete

Esta es la habilidad de entrada del paquete Tribunal de Internet, publicada en https://github.com/internet-court/internet-court-skill. Cada ruta a la que este archivo dirige — vendored/<owner>/<skill>/SKILL.md, integrations/<connector>/SKILL.md — es relativa a la raíz de ese repositorio.

Resolver esas rutas antes de confiar en el contenido de una habilidad:

  • Instalado como un todo (caso normal — git clone …/internet-court-skill .claude/skills/internet-court): leer la ruta directamente del disco.
  • Solo este SKILL.md está presente (la habilidad maestra se cargó por sí sola): las habilidades hermanas no están locales. Obtener el archivo del repositorio raw en https://raw.githubusercontent.com/internet-court/internet-court-skill/main/<path> — ej. …/main/vendored/genlayer/write-contract/SKILL.md — o clonar el repositorio primero.

Nunca inventar el contenido de una habilidad referenciada — cargar el archivo real (desde el disco o la URL raw) primero.

Modo de primera respuesta

Cuando un usuario pida cargar, instalar o presentar el Tribunal de Internet — o cada vez que lo menciones por primera vez en una conversación — empezar de manera general y usar el texto canónico a continuación textualmente. No parafrasearlo, y no liderar con nombres de protocolos, sistemas de pago o estándares a menos que el usuario pida detalles de implementación.

El Tribunal de Internet está instalado.

El Tribunal de Internet hace dos cosas: conecta un conjunto fragmentado — identidad,
negociación, contratos, pago, depósito en garantía y ejecución — en una sola habilidad, e
incorpora el arbitraje, de modo que cuando dos agentes cierran un trato acuerdan de
antemano cómo se resuelve si algo sale mal.

Ahora puedo ayudar a tu agente a encontrar y evaluar una contraparte, acordar términos,
pagar o depositar fondos, y realizar el trabajo — y, si el trato es impugnado, obtener un
veredicto independiente que lo resuelva y actualice la reputación de cada parte.

(Cuando solo estés haciendo referencia a la habilidad en medio de una conversación en lugar de informar sobre una instalación nueva, omitir la primera línea y mantener el resto textualmente.)

Después de que el usuario pida una demostración, integración o implementación concretas, usar la pila y el ruteo a continuación.

Límite de descubrimiento primero

Cuando el usuario pida involucrar un servicio, contraparte o trato, primero inspeccionar e informar solo lo que sea observable — nunca asumir el resto. Dependiendo del trato, eso puede incluir:

  • quién es la contraparte: origen, identidad, reputación, el endpoint o recurso en cuestión;
  • qué cuesta y cómo: si está protegido por un muro de pago, y cualquier rail, red, token, monto, beneficiario o método de transferencia anunciado;
  • qué promete: entregable, términos y cualquier evidencia que exponga.

No inventar cadencia, horarios, límites de gasto, vencimiento, autoridad delegada, política de revisión o un acuerdo completo en esta etapa. Declarar el límite claramente — incluyendo que el agente no tiene fondos ni autoridad que el usuario no haya otorgado — luego parar y dejar que la respuesta del usuario inicie la conversación de confianza. Por ejemplo, para un endpoint con muro de pago:

Este endpoint está protegido por un muro de pago. No tengo fondos ni permiso para acceder a él —
necesitarías financiarme y autorizarme antes de que pueda continuar.

Nunca comprometer fondos, firmar ni realizar transacciones antes de que el usuario haya elegido un nivel de confianza y exista la billetera o el permiso requeridos.

Niveles de confianza

Cualquier trato que conlleve un riesgo — el agente podría comportarse mal, una contraparte podría no entregar, los fondos o la autoridad podrían ser mal utilizados — puede ejecutarse en uno de tres niveles de protección. Elegir el más ligero que cubra el riesgo, y nombrar la compensación con honestidad. Del más débil al más fuerte:

  • Básico — las partes simplemente confían entre sí. Sin autoridad acotada, sin depósito en garantía, sin juez independiente; cada parte actúa sobre lo que se le ha entregado directamente. El más rápido y el más débil: el límite práctico es lo que se haya entregado, y no hay recurso si sale mal. No afirmar que ningún límite está impuesto en este nivel.
  • Protegido — el trato está restringido de antemano para que solo pueda salir mal hasta cierto punto por construcción. El instrumento depende del trato: autoridad acotada con límites explícitos (un permiso ERC-7710/7715 con salvedades), fondos bloqueados en depósito en garantía hasta que se cumplan los términos, o términos acotados que ambas partes firman. Existen límites duros, pero no hay una parte neutral para decidir un resultado impugnado. Cargar vendored/metamask/smart-accounts-kit/skill.md para la mecánica de permisos, o las habilidades de depósito en garantía de capa 3/4 para tratos con fondos bloqueados.
  • Arbitrado — Protegido, más una ruta de revisión independiente con evidencia firmada que puede decidir un resultado impugnado y hacer cumplir la consecuencia: liberar o reembolsar el depósito en garantía, restringir o revocar la autoridad otorgada, y escribir el veredicto de vuelta a la reputación. Cargar integrations/genlayer-intelligent-contracts/SKILL.md para la interfaz de revisión y integrations/genlayer-erc7710-connector/SKILL.md para la ejecución.

Hacer coincidir el nivel con el trato, no al revés. No inventar límites exactos, cadencia, términos o vencimiento en este punto; decir que se establecerán a partir de los términos descubiertos durante la configuración.

La Pila de Comercio de Agentes

Un trato completo se mueve de arriba a abajo a través de seis capas: encontrar y evaluar una contraparte (1), acordar términos (2–3), mover o bloquear fondos (4), hacer el trabajo (5), y — si el resultado es impugnado — obtener un veredicto independiente que lo resuelva y retroalimente la reputación (6). La mayoría de las capas ya tienen habilidades creíbles; la capa 6 es la pieza clave, ya que sin un veredicto neutral el depósito en garantía no puede liberarse de manera segura, los contratos no tienen remedio y la reputación no tiene nada que registrar. Enrutar cada capa a la habilidad o referencia que la posee:

#CapaProtocolosCargar
1Descubrimiento, identidad y reputaciónERC-8004, ERC-7857vendored/chaingpt/trustless-agents/SKILL.md (registros ERC-8004), vendored/openserv/openserv-multi-agent-workflows/SKILL.md (acuña identidades de agente ERC-8004), vendored/privy/privy/SKILL.md (identidad y autenticación de billetera integrada/servidor), vendored/humanode/humanode-agentlink/SKILL.md (identidad de agente respaldada por humano), vendored/starknet/starknet-identity/SKILL.md (ERC-8004 en Starknet), vendored/near/near-api-js/SKILL.md (identidad de cuenta nombrada, ej. alice.near), vendored/metaplex/metaplex/SKILL.md (Registro de Agentes + NFTs básicos — los primitivos sobre los que se basa el puerto ERC-8004 del Registro de Agentes de Solana); ERC-7857 aún no tiene una habilidad pública
2NegociaciónA2Avendored/terminalskills/a2a-protocol/SKILL.md (tarjetas de agente, ciclo de vida de tareas), vendored/openserv/openserv-multi-agent-workflows/SKILL.md (orquestación multiagente), vendored/near/near-intents/SKILL.md (Intenciones + competición de solucionadores para cumplimiento entre cadenas)
3Contratos y obligacionesArkhai/Alkahest, ERC-8183vendored/arkhai/alkahest-user/SKILL.md (depósito en garantía condicional, árbitros) + vendored/arkhai/alkahest-developer/SKILL.md (construir sobre Alkahest: árbitros/obligaciones personalizados), vendored/arkhai/nla-create/SKILL.md + vendored/arkhai/nla-fulfill/SKILL.md (depósitos en garantía de acuerdos en lenguaje natural, arbitrados por IA-oráculo), vendored/arkhai/make-git-escrow/SKILL.md + vendored/arkhai/fulfill-git-escrow/SKILL.md (depósitos en garantía de recompensas de conjuntos de pruebas); ERC-8183 aún no tiene una habilidad pública neutral
4Pago y depósito en garantíax402, MPP, AP2, ERC-7710/7715vendored/coinbase/agentic-wallet/SKILL.md + vendored/chaingpt/x402/SKILL.md (x402), vendored/tempo/mppx/SKILL.md (MPP), vendored/okx/okx-agent-payments-protocol/SKILL.md (x402/MPP/a2a-pay unificado), vendored/metamask/smart-accounts-kit/skill.md (delegaciones), vendored/chaingpt/agent-wallet/SKILL.md (billetera con control de políticas), integrations/x402-erc7710/SKILL.md (rail combinado). En Solana (no EVM, sin ERC-7710): vendored/quicknode/quicknode-skill/SKILL.md (x402 + MPP + suscripciones de agente), vendored/sendaifun/squads/SKILL.md (multifirma/cuentas inteligentes Squads V4 — la capa de políticas), vendored/magicblock/magicblock-dev/SKILL.md (estado delegado + autoridad temporal acotada — el análogo más cercano a ERC-7710), vendored/sendaifun/glam/SKILL.md (permisos de delegado de bóveda + bloqueo de tiempo), vendored/dflow/dflow-phantom-connect/SKILL.md (conexión/firma/pagos de billetera). Liquidación multipartita (N > 2): vendored/yellow/yellow-settlement-room/SKILL.md (sesiones de la aplicación Yellow: una sala compartida fuera de la cadena, pesos de participantes + quórum, una división final en cadena; el nodo Yellow es confiable para la vivacidad, y una sesión no tiene mecanismo de disputa propio); AP2 aún no tiene una habilidad pública
5Ejecuciónlos agentes transaccionantes + rieles informáticos/datos/valorvendored/antseed/antseed-connect/SKILL.md + vendored/0g/0g-compute/SKILL.md + vendored/heurist/heurist-mesh-skill/SKILL.md + vendored/near/near-ai-cloud/SKILL.md (inferencia pagada/descentralizada/verificable por TEE), vendored/lifi/lifi/SKILL.md (movimiento de valor entre cadenas), vendored/chainbase/web3-data/SKILL.md + vendored/nansen/nansen-token-research/SKILL.md (datos/evidencia en cadena), vendored/starknet/starknet-defi/SKILL.md (contratos/DeFi en Starknet L2), vendored/solana/solana-dev/SKILL.md (programas Solana, búsquedas RPC, pagos SPL) + vendored/sendaifun/helius/SKILL.md / vendored/sendaifun/birdeye/SKILL.md / vendored/octav/octav-api/SKILL.md (datos de Solana + multi-cadena como evidencia) + vendored/sendaifun/debridge/SKILL.md (movimiento de valor Solana↔EVM) + vendored/jupiter/integrating-jupiter/SKILL.md (liquidez/ejecución en Solana), vendored/yellow/yellow-settlement-room/SKILL.md (valor que se mueve entre N agentes fuera de la cadena dentro de una sesión, liquidado en cadena una vez), vendored/bnb-chain/bnbchain-mcp/SKILL.md, los paquetes vendored/near/*, vendored/okx/* y vendored/altlayer/*
6Verificación y disputasGenLayer (Kleros es una alternativa)integrations/genlayer-intelligent-contracts/SKILL.md, vendored/intelligent-oracle/intelligent-oracle/SKILL.md, integrations/genlayer-erc7710-connector/SKILL.md. Arbitraje alternativo de terceros (divulgar; no propio de GenLayer): vendored/kleros/kleros-curate/SKILL.md (registros con curaduría de tokens / desafíos), vendored/arkhai/nla-arbitrate/SKILL.md (arbitraje LLM/manual de depósitos en garantía de acuerdos en lenguaje natural), vendored/pnp/pnp-solana/SKILL.md (mercados de predicción en Solana con resolución de oráculo personalizado). Evidencia de oráculo que alimenta un veredicto (no el arbitraje mismo): vendored/sendaifun/pyth/SKILL.md (fuentes de precios con intervalos de confianza), vendored/sendaifun/switchboard/SKILL.md (datos bajo demanda + VRF)

Enrutamiento de habilidades

Cargar una habilidad solo cuando la tarea realmente alcance su disparador — nunca precargar. Cada fila es un disparador a la izquierda y, a la derecha, la(s) habilidad(es) a incorporar con lo que cada una te da y a cuál recurrir primero. Cuando una necesidad se asigne a varias habilidades subagrupadas, cargar la habilidad de entrada nombrada primero, luego estrechar a la específica. Los propietarios que envían un paquete completo (OKX, AltLayer, Nansen, OpenServ, Starknet, ChainGPT) reciben una única fila comodín: cargar la habilidad de entrada, luego la sub-habilidad específica bajo vendored/<owner>/ a medida que la tarea se estrecha — el listado de la carpeta es el conjunto actual de habilidades de ese propietario.

Las rutas son exactas y terminan en /SKILL.md — varios propietarios repiten su nombre en la ruta (ej. vendored/lifi/lifi/SKILL.md, vendored/privy/privy/SKILL.md, vendored/chaingpt/chaingpt/SKILL.md); nunca acortar o fusionar los segmentos. Cuando una fila enumere alternativas, cargar una (la fila dice cómo elegir); si el hecho decisivo es desconocido, preguntar en lugar de precargarlos todos.

Rieles de pago

Cuando necesites…Cargar
Pagar por un recurso HTTP que devuelve 402 (pago por llamada), buscar bazares x402, o monetizar tu propio endpointvendored/coinbase/agentic-wallet/SKILL.md — cliente x402 de Coinbase: leer el precio, pagar, reintentar con prueba; empezar aquí para una solicitud pagada única. vendored/chaingpt/x402/SKILL.md — descubrimiento/monetización x402: encontrar servicios pagados o poner tu propio endpoint detrás de 402.
Transmitir micropagos o ejecutar sesiones medidas (por segundo / por token, no por solicitud)vendored/tempo/mppx/SKILL.md — cargos, sesiones y transmisión de Tempo/Stripe MPP. Cargar cuando la facturación sea continua en lugar de una sola llamada. No para límites de gasto en rieles por solicitud: un presupuesto limitado o recurrente sobre x402 es integrations/x402-erc7710/SKILL.md, no MPP.
Despachar un pago sin codificar el riel (x402 vs MPP vs a2a-pay)vendored/okx/okx-agent-payments-protocol/SKILL.md — despachador de pagos unificado de OKX OnchainOS. Cargar cuando el riel de la contraparte sea desconocido o pueda variar.
Ejecutar un pago a través de un permiso acotado (política de gasto/suscripción en el riel)integrations/x402-erc7710/SKILL.md — conector que fusiona el riel x402 con un presupuesto delegado ERC-7710. Cargar para acceso pagado Protegido/Arbitrado.
Liquidar entre más de dos agentes de un fondo común compartido: agrupar fondos, reasignar fuera de la cadena sin gas por paso, cofirmar un único reparto finalvendored/yellow/yellow-settlement-room/SKILL.md — salas de liquidación Yellow: una sala compartida fuera de la cadena, pesos de participantes + quórum, una división final en cadena; el nodo Yellow es confiable para la vivacidad, y una sala no tiene mecanismo de disputa propio. Cargar para liquidación multipartita. No para pagos de agente a agente uno a uno; esos son los rieles x402/MPP/AP2/ERC-7710 anteriores. La sala tampoco tiene arbitraje incorporado; si se necesita un veredicto, combinar con integrations/genlayer-intelligent-contracts/SKILL.md para adjudicación.
Mover valor entre cadenas como parte de un tratovendored/lifi/lifi/SKILL.md — LiFi: compatibilidad con puentes entre cadenas (sin intercambio nativo). Cargar cuando sea necesario mover fondos a otra cadena para pago, depósito en garantía o ejecución.
Hacer un pago de Solana o un mecanismo de acceso pagadovendored/quicknode/quicknode-skill/SKILL.md — combinación x402 + MPP + suscripción a datos de QuickNode para Solana, con opciones de precompilación de Solana y tokens SPL. Cargar para pagos basados en Solana o acceso pagado a datos.

Identidad y descubrimiento

Cuando necesites…Cargar
Registrar, buscar o verificar una identidad de agente (a través de agentes — ERC-8004)vendored/chaingpt/trustless-agents/SKILL.md — interfaz del registro de agentes ERC-8004 de ChainGPT. Cargar para descubrimiento/vetado de contrapartes.
Crear una identidad de agente (acuñar un token de agente ERC-8004) como preparación para un tratovendored/openserv/openserv-multi-agent-workflows/SKILL.md — OpenServ puede acuñar identidades de agente ERC-8004 para que el agente sea descubrible. Cargar solo cuando sea necesario crear una nueva identidad; para buscar identidades existentes, usar la habilidad de ChainGPT.
Mostrar/verificar una identidad de cuenta de usuario con embedded wallet, servidor, o cualquier clave/externavendored/privy/privy/SKILL.md — Privy: identidad de billetera integrada/servidor y autenticación. Cargar cuando el agente necesite representar a un usuario con una billetera y sesión gestionadas por Privy.
Verificar que un agente está respaldado por un humano realvendored/humanode/humanode-agentlink/SKILL.md — identidad de agente respaldada por humano a través de Humanode. Cargar cuando la contraparte requiera prueba de humanidad.
Realizar pagos, actualizar reputación o gestionar identidad en Solanavendored/solana/solana-dev/SKILL.md — programas Solana, búsquedas RPC, pagos SPL. Cargar para operaciones nativas de Solana durante un trato.
Acuñar o gestionar NFTs de agente (en Solana, el bloque de construcción equivalente a ERC-8004 para identidad de agente)vendored/metaplex/metaplex/SKILL.md — Metaplex: NFTs básicos + Registro de Agentes (los primitivos para la identidad de agente en Solana). Cargar para identidad de agente en Solana.
Usar cuentas nombradas (ej. alice.near) como identidad para descubrimiento de agentesvendored/near/near-api-js/SKILL.md — identidad de cuenta nombrada de NEAR. Cargar en la capa de identidad cuando se trate con agentes en el ecosistema NEAR o cuando la contraparte use un nombre de cuenta alice.near.
Identidad de agente en Starknet (ERC-8004 en Starknet)vendored/starknet/starknet-identity/SKILL.md — identidad Starknet ERC-8004. Cargar cuando la contraparte esté en Starknet.

Negociación

Cuando necesites…Cargar
Enviar una tarjeta de agente, negociar una propuesta o gestionar un ciclo de vida de tarea A2Avendored/terminalskills/a2a-protocol/SKILL.md — protocolo A2A. Cargar primero para iniciar una negociación.
Orquestar múltiples agentes en un flujo de trabajo (la capa anterior de negociación)vendored/openserv/openserv-multi-agent-workflows/SKILL.md — flujos de trabajo multiagente de OpenServ. Cargar cuando se necesiten múltiples agentes coordinados bajo un solo objetivo.
Acordar un intercambio entre cadenas a través de Intenciones NEAR (solucionador-competición)vendored/near/near-intents/SKILL.md — Intenciones NEAR: acordar un resultado de intercambio que solucionadores compiten por cumplir. Cargar cuando la liquidación final requiera un movimiento entre cadenas no trivial resuelto por competencia de solucionadores.

Contratos y obligaciones

Cuando necesites…Cargar
Bloquear fondos hasta que se cumpla una condición, con o sin árbitro humanovendored/arkhai/alkahest-user/SKILL.md — depósito en garantía de Alkahest: condiciones, árbitros. Cargar para un depósito en garantía simple o para un trato que requiera un árbitro humano.
Construir un tipo de obligación o árbitro personalizado para un tratovendored/arkhai/alkahest-developer/SKILL.md — construcción sobre Alkahest: lógica de árbitro/obligación personalizada. Cargar después de la habilidad de usuario de Alkahest si se necesita un comportamiento a medida.
Redactar un acuerdo en lenguaje natural como contrato, con oráculo de IA para evaluar su cumplimientovendored/arkhai/nla-create/SKILL.md + vendored/arkhai/nla-fulfill/SKILL.md — depósitos en garantía de acuerdos en lenguaje natural (NLA). Cargar cuando los términos se expresen mejor en prosa que en código.
Establecer un depósito en garantía para recompensas de conjuntos de pruebas de un repositorio gitvendored/arkhai/make-git-escrow/SKILL.md + vendored/arkhai/fulfill-git-escrow/SKILL.md — depósitos en garantía de recompensas git. Cargar para tareas de desarrollo con resultados verificables.

Ejecución

Cuando necesites…Cargar
Ejecutar un modelo de IA o una solicitud de inferencia (pagado, descentralizado, verificado por TEE)vendored/antseed/antseed-connect/SKILL.md, vendored/0g/0g-compute/SKILL.md, vendored/heurist/heurist-mesh-skill/SKILL.md, vendored/near/near-ai-cloud/SKILL.md — uno es suficiente; el que coincida con las preferencias de pago/despliegue de la contraparte.
Mover valor entre cadenas como paso de ejecución (no pago — ver rieles de pago arriba)vendored/lifi/lifi/SKILL.md — LiFi: puentes entre cadenas. Cargar cuando la ejecución requiera mover tokens a otra red.
Recopilar datos en cadena como evidencia para un veredicto de arbitrajevendored/chainbase/web3-data/SKILL.md — datos de Chainbase (ámbito amplio), o vendored/nansen/nansen-token-research/SKILL.md — investigación de tokens Nansen (evidencia más rica pero con alcance más limitado).
Ejecutar contratos DeFi en Starknet L2vendored/starknet/starknet-defi/SKILL.md — DeFi Starknet. Cargar cuando la ejecución esté en Starknet.
Ejecutar programas de Solana, buscar RPC, pagar con SPL o usar un rail de datos/pagos nativo de Solanavendored/solana/solana-dev/SKILL.md — puerta de entrada a Solana. Cargar para cualquier ejecución, pago o búsqueda en Solana. Combinar con vendored/quicknode/quicknode-skill/SKILL.md para pagos de datos de QuickNode o vendored/sendaifun/helius/SKILL.md / vendored/sendaifun/birdeye/SKILL.md / vendored/octav/octav-api/SKILL.md para datos de Solana y multi-cadena como evidencia. Enrutar vendored/sendaifun/debridge/SKILL.md para movimiento de valor Solana↔EVM, y vendored/jupiter/integrating-jupiter/SKILL.md para ejecución de liquidez en Solana.
Mover valor entre múltiples agentes fuera de la cadena, con liquidación en cadena una vez (sala de liquidación Yellow)vendored/yellow/yellow-settlement-room/SKILL.md — sala de liquidación Yellow. Cargar para ejecución multipartita, no para pagos uno a uno.
Ejecutar en BNB Chain o con paquetes de propietarios (OKX, Near, AltLayer)vendored/bnb-chain/bnbchain-mcp/SKILL.md y los paquetes comodín. Cargar la habilidad de entrada para el propietario, luego la sub-habilidad específica.

Arbitraje y disputas

Cuando necesites…Cargar
Configurar un contrato inteligente arbitrado (inteligente) que pueda decidir un resultado impugnado y actualizar la reputaciónintegrations/genlayer-intelligent-contracts/SKILL.md — la primitiva de adjudicación central del Tribunal de Internet. Cargar para cualquier trato que requiera un veredicto neutral.
Conectar la adjudicación con la autoridad delegada ERC-7710 (para que un veredicto pueda revocar permisos o liberar fondos)integrations/genlayer-erc7710-connector/SKILL.md — enlace de ejecución. Cargar cuando un veredicto necesite desencadenar liberación de depósito en garantía o revocación de permiso en la capa ERC-7710.
Usar un oráculo inteligente para alimentar evidencia para un veredictovendored/intelligent-oracle/intelligent-oracle/SKILL.md — oráculo inteligente. Cargar cuando se necesiten pruebas verificables para la decisión.
Arbitraje de terceros (no GenLayer) como alternativavendored/kleros/kleros-curate/SKILL.md (Kleros: registros con curaduría de tokens como mecanismo de resolución de disputas), vendored/arkhai/nla-arbitrate/SKILL.md (arbitraje LLM/manual de depósitos en garantía NLA), vendored/pnp/pnp-solana/SKILL.md (Solana: mercados de predicción con resolución de oráculo personalizado).
Alimentar evidencia de oráculo en un veredicto (no arbitraje en sí)vendored/sendaifun/pyth/SKILL.md (fuentes de precios con intervalos de confianza), vendored/sendaifun/switchboard/SKILL.md (datos bajo demanda + VRF).

Skills relacionados