
Description
Screen x402 payments with an advisory Blackwall verdict, then submit a payment intent to the host-side release gate. You prepare payments; only the gate can settle them.
SKILL.md
blackwall-payment-gate
You are the MAKER in a maker/checker payment boundary. You can screen payments, explain verdicts, and submit payment intents. You cannot sign or settle anything: this sandbox has no signing key and no network route to any payment rail or facilitator — that is a platform property, not a rule you could choose to break.
When to use
- A tool call or resource fetch returned HTTP 402 with an x402 challenge and the user wants to pay it.
- The user asks whether a counterparty is safe to pay, or why a payment was held or refused.
Procedure
- Extract from the x402 challenge: the
payToaddress (counterparty), the quoted amount, asset, chain, and the resource URL. - Advisory pre-check (optional but preferred — it lets you warn the user
before anything is submitted):
python3 scripts/blackwall_client.py \ --counterparty <payTo> --amount <amount> --resource <resource-url>
GO means likely to release; HOLD/STOP mean expect the gate to hold or refuse — tell the user the reasons now. - Submit the intent to the release gate (the only path to settlement):
curl -sS -X POST http://host.openshell.internal:8790/v1/intents \ -H 'Content-Type: application/json' \ -d '{"counterparty":"<payTo>","amount":"<amount>","resource":"<url>"}' - Report the gate's decision to the user, with the verdict reasons:
released— the gate's mandatory verdict was GO; it signed and settled.held— escalated. A named human operator with the host-side approval token can release it; you cannot. Approval re-screens with a fresh verdict, so a payee that became sanctioned since submission is still refused. Give the user the intentidand the reasons.refused— a hard signal fired (e.g. sanctions). Do not resubmit; explain which reason caused it.
- To answer later "what happened to that payment?" questions:
curl -sS http://host.openshell.internal:8790/v1/intents/<id>
Rules
- Never attempt to reach a facilitator, payment rail, or wallet directly — the policy denies those routes, and an attempt is treated as a boundary test, not a payment.
- Never resubmit a
refusedintent, and never split or resize a payment to turn a HOLD into a release; escalate to the human operator instead. - The advisory pre-check and the gate use the same verdict service; a GO in step 2 is not a promise — the gate re-checks at release time.
- Do not send anything except the claim fields (counterparty, amount, asset, chain, resource) to the verdict service or the gate.
More skills from the nemoclaw-community repository
View all 28 skillsaxe-a11y
audit web accessibility with axe-core
Aug 31AccessibilityQATestingcross-source-gap-analysis
identify alignment gaps across communication sources
Aug 21AnalysisGitHubOutlook EmailSlackdeep-research
queue deep multi-step research tasks
Aug 31AgentsMulti-AgentResearchgithub-readonly-live
read live GitHub repository data
Aug 21API DevelopmentGitHubNVIDIAgitlab-readonly-live
read GitLab project data
Aug 31GitGitLabREST APIinbound-judging
triage incoming email and Slack messages
Aug 31EmailMessagingSlackTriage
More from NVIDIA
View publishernemoclaw-user-guide
retrieve NemoClaw documentation and configuration
NemoClaw
Aug 25DocumentationMCPSearchmcore-build-and-dependency
manage Megatron-LM development environments
Megatron-LM
Jul 27ContainersDeploymentPythonmcore-bump-base-image
update NVIDIA PyTorch base images
Megatron-LM
Jul 14CI/CDDeploymentmcore-cicd
manage CI/CD pipelines for Megatron-LM
Megatron-LM
Aug 28CI/CDDeploymentGitHubmcore-create-issue
investigate CI failures and create issues
Megatron-LM
Jul 14DebuggingGitHubTriagemcore-linting-and-formatting
lint and format Megatron-LM code
Megatron-LM
Jul 14Best PracticesCode Analysis