Merchants that rotate payTo on every 402 (Tavily, Browserbase)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- blockchain, typescript
- Área
- security
Línea de trabajo
Begin with the pinned-payTo invariant described in the issue and the existing registry and 402 payment flow; their file paths are not named in the payload. First write a design note in the issue, then assess how the design can be tested with mock merchants that rotate payTo, including a hostile merchant. Done means the owner remains in control of every authorized payee and both test cases are covered.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Why
Agent Safe pins each merchant's payTo in the owner's registry: a 402 asking to pay any other address is refused. That is the core protection against redirected payments.
While testing live x402 merchants on Base (2026-10-07) we found two that return a different payTo on every 402 (five probes, five addresses each): Tavily (x402.tavily.com/search) and Browserbase (x402.browserbase.com). A fixed allowlist can't pay them today.
What
Find a way to authorize a rotating payee without letting the server choose who gets paid. Options to discuss:
- The merchant publishes its payee set or a signing key at a well-known path on its own domain (e.g.
/.well-known/x402.json), fetched by the owner at setup time, not by the agent at pay time. - A merchant-signed payTo attestation inside the 402, verified against a key pinned in the registry.
- Per-merchant deposit/forwarder contracts.
Acceptance
- A design note in this issue first.
- Whatever ships keeps the invariant: nothing in a 402 can add a payee the owner didn't approve.
- Tests with a mock merchant that rotates payTo, plus a hostile one that rotates to an attacker.
- Lenguaje dominante
- TypeScript
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 3 h 51 min
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de DeepFirstHQ/deepfirstsearch
-
documentation good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
guard: a documented way to pin the payee for clients that expose only a custom fetch or walletAbiertoenhancement help wanted
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
-
good first issue integration
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
-
help wanted integration
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
-
enhancement good first issue
Dificultad 3/5 1-2 días Aptitud para principiantes 62/100
Todos los issues de DeepFirstHQ/deepfirstsearch
Issues similares
-
area:plugins enhancement platform:vscode
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
anthropics/claude-code#103166 ·
Los mantenedores suelen responder en 1 día
-
Add: Add pogo tv indiaAbiertocheck:failed streams:add
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
iptv-org/iptv#55744 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
jitsi/jitsi-meet#18021 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
spec: discovery input example can contain multiple aliases for one parameter, with no canonical oneAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
x402-foundation/x402#3841 ·
Los mantenedores suelen responder en 1 día