chore(hermes): pin payments-enabled agent image

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.

[bussyjd]

Summary

Bump the default Hermes agent image used by both Obol-managed Hermes runtimes to a digest-pinned upstream image that contains the new optional payments skills:

• internal/hermes/hermes.go master agent default: nousresearch/hermes-agent:v2026.6.5 -> nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9
• internal/serviceoffercontroller/agent_render.go Agent CRD/sub-agent default: same pinned image ref

Why main@sha256: the latest dated Docker tag visible on Docker Hub is still v2026.6.5, published before Hermes commit 5bfed0fe0 (feat(skills): add optional payments skills (Stripe Link, MPP, Projects)). Docker Hub shows main/latest updated after that commit, and the current multi-arch manifest digest is pinned here:

nousresearch/hermes-agent:main@sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9

This keeps the train reproducible while we wait for Hermes to publish the next dated release tag containing the optional payments skills. Once that tag exists, replace this temporary digest pin with the release tag plus digest.

Compatibility Pass Map

flowchart TB
A["Hermes upstream main image pinned by digest"] --> B["Optional payments skills available in agent pod"]
B --> C["stripe-link-cli skill"]
B --> D["mpp-agent skill"]
C --> E["Stripe Link approval + Shared Payment Token"]
D --> F["MPP client probes HTTP 402 merchant"]
G["Obol seller card route"] --> H{"402 challenge wire"}
H -->|"current Obol"| I["PAYMENT-REQUIRED JSON + X-PAYMENT retry"]
H -->|"Hermes/Stripe MPP target"| J["WWW-Authenticate: Payment method=stripe"]
E --> K["Buyer retries with payment credential"]
F --> K
K --> L["x402-verifier card gate"]
L --> M["Stripe PaymentIntent authorize"]
M --> N["Proxy upstream"]
N --> O{"Upstream <400?"}
O -->|"yes"| P["Capture PaymentIntent + return receipt"]
O -->|"no"| Q["Cancel hold + return failure"]
I -.-> R["Follow-up: bridge/dual-advertise wire format"]
J -.-> R

Loading

Stripe / SPT Flow

sequenceDiagram
autonumber
participant Buyer as Hermes agent payment skill
participant StripeLink as Stripe Link CLI
participant Seller as Obol paid service
participant Verifier as x402-verifier card gate
participant Stripe as Stripe PaymentIntents
participant Upstream as Seller upstream
Buyer->>Seller: Request paid resource without credential
Seller-->>Buyer: 402 with Stripe MPP challenge
Buyer->>StripeLink: Create approved spend request for shared_payment_token
StripeLink-->>Buyer: SPT credential after user approval
Buyer->>Seller: Retry with payment credential
Seller->>Verifier: Route to card gate
Verifier->>Stripe: Authorize manual-capture PaymentIntent with SPT
Stripe-->>Verifier: requires_capture
Verifier->>Upstream: Proxy request
alt upstream succeeds
Upstream-->>Verifier: 2xx/3xx response
Verifier->>Stripe: Capture PaymentIntent
Stripe-->>Verifier: succeeded
Verifier-->>Buyer: Upstream response + payment receipt
else upstream fails
Upstream-->>Verifier: 4xx/5xx or no response
Verifier->>Stripe: Cancel PaymentIntent hold
Verifier-->>Buyer: Failure, buyer not charged
end

Loading

MPP / x402 Compatibility Work Remaining

flowchart LR
A["Current Obol card path"] --> B["Scheme card / network stripe in x402 PaymentRequired"]
A --> C["Credential read from X-PAYMENT"]
A --> D["Receipt in X-PAYMENT-RESPONSE"]
E["Hermes + Stripe MPP expectation"] --> F["WWW-Authenticate: Payment ... method=stripe"]
E --> G["Authorization: Payment ... credential"]
E --> H["Authentication-Info receipt"]
E --> I["networkId is Stripe profile_ / profile_test_ id"]
B --> J["Compatibility pass"]
C --> J
D --> J
F --> J
G --> J
H --> J
I --> J
J --> K["Emit MPP challenge alongside x402 challenge"]
J --> L["Accept MPP Authorization credential or translate to existing SPT payload"]
J --> M["Return MPP receipt while preserving x402 receipt for existing buyers"]
J --> N["Update CLI/docs from stripenet_* examples to profile_* / profile_test_*"]

Loading

Validation

• git diff --check
• go test ./internal/hermes ./internal/serviceoffercontroller ./internal/agentcrd -count=1
• docker buildx imagetools inspect nousresearch/hermes-agent:main
• Docker Hub tag listing checked: no dated tag newer than v2026.6.5 is currently published; main/latest resolve to sha256:e9f2892b626468d2a65abeae9f94ec0a71872d7d9643906b956ab29c9bf328a9.

Follow-up

• Replace this temporary main@sha256:... pin with the next dated Hermes release tag plus digest once available.
• Implement the MPP wire compatibility pass described above before declaring Obol card payments interoperable with Hermes/Stripe Link.

[bussyjd]

Closed after renaming the head branch off the codex/ prefix. Replacement PR with the corrected branch name and fixed Mermaid diagram: #649.