Skip to content

Home

Jump to bottom
ClaraChengGo edited this page Jul 13, 2026 · 1 revision

Welcome to the RoboPay wiki!

RoboPay Bounty Success Criteria

The RoboPay Bounty rewards developers for connecting robots and simulators to Fabric through Zenoh and demonstrating that paid actions can be executed safely through the Fabric payment network.

All bounty submissions must satisfy the common success criteria described in this document.

In addition, submissions are classified into one of four difficulty tiers.

Bounty Tiers & Rewards

The total rewards is 1,000,000 ROBO for verified submission.

Tier 1 — Simulator Skill Execution

Reward: 14,000 ROBO

Objective:

Connect RoboPay with a robot in simulation and trigger the action by the policy

Requirements:

  • Code must be clean and easy to understand.
  • Simulator-only submission.
  • Must use Isaac Sim, Gazebo, MuJoCo, Webots, or another approved simulator.
  • Cannot simply replay a predefined animation or trajectory.
  • Cannot rely solely on built-in demo motions. Must be triggered by the policy, planner, controller or task model, and must provide simulator state metrics, such as changes in target pose, successful grasping, changes in door angle, completion of obstacle-avoidance paths, collision status, etc.
  • Must include Sim-to-Sim validation.

Examples:

  • Pick-and-place
  • Door opening
  • Obstacle navigation
  • Multi-step manipulation
  • Shelf inspection
  • Task-conditioned locomotion

Must be triggered by the policy, planner, controller or task model, and must provide simulator state metrics, such as changes in target pose, successful grasping, changes in door angle, completion of obstacle-avoidance paths, collision status, etc.

Tier 2 — Physical Robot Integration (Built-in Skills)

Reward: 14,000 ROBO

Objective:

Connect a real robot to RoboPay and expose existing vendor-provided actions as paid skills.

Requirements:

  • Code must be clean and easy to understand.
  • The integration should be generalized to simplify future maintenance such as adding new features.
  • Real robot hardware required.
  • Existing SDK actions are allowed.
  • Existing vendor APIs are allowed.
  • No policy training required.

Examples:

  • Wave
  • Stand
  • Sit
  • Turn
  • Salute
  • Dock

Tier 3 — Physical Robot Integration (Custom Skills)

Reward: 28,000 ROBO

Objective:

Expose a new robot capability that is not directly available as a built-in vendor action.

Requirements:

  • Code must be clean and easy to understand.
  • Real robot hardware required.
  • Must implement custom behavior logic.
  • Cannot simply invoke a single built-in SDK action.
  • Must combine planning, control, task orchestration, or behavior composition.

Examples:

  • Patrol workflow
  • Human-following
  • Autonomous inspection
  • Multi-stage manipulation
  • Navigate to target location
  • Composite robot workflows

Tier 4 — Physical Robot Skill Creation (Training Required)

Reward: 35,000 ROBO

Objective:

Create a new robot capability through training, adaptation, fine-tuning, imitation learning, reinforcement learning, or policy optimization.

Requirements:

  • Code must be clean and easy to understand.
  • Real robot hardware required.
  • Must involve training or policy adaptation.
  • Must demonstrate capability acquisition beyond vendor-provided functionality.
  • Must document training methodology and evaluation.

Examples:

  • Learned grasping
  • Pick-and-place from demonstrations
  • Learned manipulation policy
  • Learned navigation policy
  • Learned inspection policy

Tier 4 submissions may receive additional discretionary rewards for exceptional technical contributions.

Common Success Criteria

1. End-to-End Paid Action Flow

The submission must demonstrate the full flow:

  1. Robot bridge starts on or near the robot/simulator.
  2. Bridge connects outbound to the Fabric relay using robotsdk.
  3. Agent or test client sends a paid action request.
  4. Relay forwards the paid action through the robot tunnel.
  5. Bridge republishes the action onto a Zenoh topic.
  6. Robot control stack consumes the Zenoh message.
  7. Robot executes the action.
  8. Relay returns an immediate accepted / pending response to the payer.
  9. Robot execution result is produced asynchronously and correlated by actionId.
  10. Final success or failure must be verifiable through a status endpoint, result topic, logs, simulator metrics, or video evidence.

Minimum acceptable proof:

  • Terminal logs from relay / bridge / robot-side process.
  • Demo script or command to reproduce the flow.
  • Video proof for physical robot submissions.
  • Simulator recording for simulator-only submissions.

2. Zenoh Bridge Requirement

The bridge must use Zenoh as the local robot communication layer.

Required behavior:

  • Subscribe to incoming paid actions from the Fabric relay.
  • Republish each action to a documented Zenoh topic, for example:
robot/tunnel/action
  • Listen for robot execution results on a documented response topic, for example:
robot/tunnel/result
  • Return the result to Fabric in a structured format.

The README must document:

  • Zenoh topic names.
  • Message schema.
  • How to run the Zenoh router/session.
  • How the robot control process subscribes and responds.

3. Real Action Requirement

Please provide more robust acceptance evidence, such as:
1. unpaid request must return 402
2. paid request must include verified receipt / txHash
3. Zenoh payload must preserve actionId, robotId, skillId, idempotencyKey, paramsHash, payment
4. invalid/expired/replayed requests must not publish to Zenoh or actuate the robot

Tier 2 submissions may use vendor-provided predefined actions. Tier 3 and Tier 4 submissions must demonstrate capabilities beyond a single built-in SDK action.

Each submission must execute at least one real robot action.

For Tier 2 - 4 with physical robots:

  • Any clearly observable physical action is acceptable.
  • Examples include wave, stand, sit, move_to, turn, grasp, salute, nod, dock, or inspect.
  • The action does not need to be complex, but it must be visibly triggered by the paid Fabric request.

For Tier 1 in simulation:

  • Simple horizontal movement alone is not sufficient.
  • The simulated robot must perform a non-trivial embodied action beyond basic forward/backward motion.
  • Acceptable examples include:
    • waving
    • saluting
    • standing up
    • sitting down
    • grasping or manipulating an object
    • climbing stairs
    • opening a door
    • turning toward a target
    • following a multi-step motion sequence
    • navigating around an obstacle
  • The simulated action must be visually demonstrable in Gazebo, Isaac Sim, MuJoCo, or another approved robotics simulator.

Provide more robust acceptance evidence, such as:

  • 1. unpaid request must return 402
  • 2. paid request must include verified receipt / txHash
  • 3. Zenoh payload must preserve actionId, robotId, skillId, idempotencyKey, paramsHash, payment
  • 4. invalid/expired/replayed requests must not publish to Zenoh or actuate the robot

4. Skill Registration and Pricing

The robot must expose at least one priced skill.

Required skill metadata:

{
  "name": "wave",
  "description": "Robot waves its arm",
  "priceUSDC": "0.01",
  "paramsSchema": {},
  "robotId": "..."
}

The skill must be discoverable by the payer before execution.

The submitted demo must show:

  • Robot discovery.
  • Skill discovery.
  • Skill price.
  • Paid execution of the selected skill.

5. Success and Failure Semantics

The bridge must correctly return both success and failure.

Required success response:

{
  "status": "success",
  "skill": "wave",
  "result": {
    "message": "Action completed"
  }
}

Required failure response:

{
  "status": "error",
  "skill": "wave",
  "error": {
    "code": "ACTION_FAILED",
    "message": "Robot failed to complete action"
  }
}

Failure cases must be intentionally testable.

At minimum, the submission must include one of:

  • A deliberately failing skill.
  • An invalid parameter test.
  • A timeout test.
  • A robot unavailable test.
  • A simulator failure condition.

A failed action must not be reported as successful.

6. Submission Scope Classification

Each submission must clearly declare one of the following scopes:

  • Physical robot submission
  • Simulator-only submission
  • Hybrid submission: simulator proof with optional physical validation

The declared scope determines the required evidence and grant eligibility.

A simulator-only submission must not imply physical robot validation unless a physical robot video and corresponding Fabric-triggered logs are included.

A physical robot submission must identify the robot platform, control stack, and hardware setup used in the demo.

7. Payment Safety

The submission must preserve Fabric payment safety.

Acceptance requirement:

  • If the robot action succeeds, the relay may settle the payment.
  • If the robot action fails, times out, or returns an error, the relay must not settle the payment.
  • The demo must include logs or test output proving that failed execution does not settle.

Required evidence:

  • Successful action log showing settlement or settlement receipt.
  • Failed action log showing error response and no settlement.
  • Test case covering no-settle-on-failure behavior.

8. Robot Identity and Wallet Binding

The robot bridge must authenticate as a robot payee.

Required behavior:

  • Bridge signs the expected robot authentication handshake.
  • Robot identity binds to the payee wallet.
  • Private keys are loaded from environment variables or secret manager.
  • Private keys are never hardcoded, committed, or logged.

README must include:

  • Required environment variables.
  • Wallet setup instructions.
  • Testnet configuration.
  • Security warning for private keys.

9. Reproducibility

A reviewer must be able to reproduce the demo from a clean checkout.

Required documentation:

  • Hardware or simulator requirements.
  • Installation steps.
  • Environment variables.
  • Zenoh setup.
  • How to start the robot bridge.
  • How to start the robot control process.
  • How to send a paid action.
  • Expected success output.
  • Expected failure output.
  • Troubleshooting section.

Target standard:

  • A simulator submission should be reproducible in under 30 minutes.
  • A physical robot submission should be reproducible by someone with the same hardware and documented setup.

10. Demo Evidence

Physical robot submissions must include:

  • A short video showing the real robot executing the paid action.
  • The video should show or be paired with terminal logs proving the action was triggered by Fabric payment.
  • The action must be visibly attributable to the paid request.

Simulator-only submissions must include:

  • A screen recording of the simulated action.
  • Terminal logs showing paid request, Zenoh message, action execution, and returned result.
  • Clear labeling that the submission is simulator-only.

11. Code Quality

The implementation must be maintainable and merge-ready.

Required:

  • Clear module structure.
  • No hardcoded secrets.
  • Configurable relay URL.
  • Configurable robot ID.
  • Configurable Zenoh endpoints/topics.
  • Clear error messages.
  • Minimal unnecessary dependencies.
  • Basic tests for message parsing, action routing, success response, and failure response.

12. Scoring Rubric

Category Points
Full Fabric → Zenoh → robot/sim flow works 25
Real action executed and visually proven 20
Correct success/failure handling 15
Payment safety / no-settle-on-failure proven 15
Reproducible README and setup 10
Native robot-stack integration quality 10
Code quality and tests 5
Total 100

Minimum passing score: 75 / 100

13. Non-Acceptable Submissions

The following do not qualify:

  • A demo that only calls a mock function without Zenoh.
  • A robot video not connected to a Fabric paid request.
  • A simulator that only moves horizontally without any richer embodied action.
  • A hardcoded script that cannot be reused.
  • A success-only demo with no failure path.
  • Any submission that settles payment after failed execution.
  • Any submission that logs or commits private keys.

Robot Action Profile Contribution Guidelines

1. Purpose

Each downstream robot team should submit a package that allows upstream agents to understand:

  • What the robot is;
  • What the robot can do;
  • What parameters each action requires;
  • Which actions require payment;
  • How payment success is verified;
  • How the agent should call the robot action API;
  • How the action is mapped to downstream robot execution;
  • How the integration can be reviewed, reproduced, and validated.

2. Recommended Directory Structure

Each team should only add or modify files under its own vendor directory:

registry/ vendors/ <vendor>/ <robotModel>/ <profileId>/ robot.profile.yaml skills.yaml functions.yaml payment-policy.yaml execution-mapping.yaml examples/ action-envelope.move_forward.json action-envelope.stop.json tests/ skill-contract.test.yaml docs/ README.md validation-report.md

Example:

registry/ vendors/ unitree/ g1/ om1-sim-g1-v1/ robot.profile.yaml skills.yaml functions.yaml payment-policy.yaml execution-mapping.yaml examples/ docs/ validation-report.md

Recommended profileId format:

<vendor>.<robotModel>.<runtime-or-capability>.v1

3. Required Files

robot.profile.yaml

Describes the robot and runtime.

schemaVersion: robot-profile.v1vendor: unitreerobotModel: g1robotType: om1-sim-g1profileId: unitree.g1.om1-sim-g1.v1profileVersion: 1.0.0runtime: transport: zenoh actionTopic: robot/tunnel/action bridge: om1 ros2: cmdVelTopic: /cmd_velmaintainers: - github: example-maintainerstatus: experimental

skills.yaml

Describes what the robot can do.

schemaVersion: robot-skills.v1

profileId: unitree.g1.om1-sim-g1.v1skills: - skillId: move_forward description: Move the robot forward for a bounded duration. params: durationSec: type: number min: 0.1 max: 5 speed: type: number min: 0 max: 0.5 paymentRequired: true - skillId: stop description: Stop robot motion immediately. params: {} paymentRequired: false

functions.yaml

Describes how an agent should call the robot action API.

schemaVersion: agent-functions.v1functions: - name: list_robot_skills method: GET url: /v1/robots/{robotId}/skills - name: request_robot_action method: POST url: /v1/robots/{robotId}/actions body: skillId: string params: object idempotencyKey: string payment: unpaidStatus: 402 paymentRequiredHeader: payment-required - name: submit_paid_robot_action method: POST url: /v1/robots/{robotId}/actions headers: X-PAYMENT: string body: skillId: string params: object idempotencyKey: string

payment-policy.yaml

Describes payment requirements.

schemaVersion: payment-policy.v1provider: aeon-bnb-x402network: eip155:56asset: USDT_OR_USDC_CONTRACTamountUnit: smallestpolicies: - skillId: move_forward required: true amount: "10000" paymentHeader: X-PAYMENT - skillId: stop required: false amount: "0"

execution-mapping.yaml

Describes how actions are delivered to the robot runtime.

schemaVersion: execution-mapping.v1transport: type: zenoh topic: robot/tunnel/actionmappings: move_forward: output: ros2_twist topic: /cmd_vel linear.x: "$params.speed" angular.z: 0 durationSec: "$params.durationSec" stop: output: ros2_twist topic: /cmd_vel linear.x: 0 angular.z: 0 durationSec: 0

4. Examples

Each profile should include at least one example action envelope under:

examples/

Example:

{ "actionId": "act_example", "robotId": "g1-demo-001", "skillId": "move_forward", "params": { "durationSec": 3, "speed": 0.5 }, "idempotencyKey": "example-move-forward-001", "payment": { "provider": "aeon-bnb-x402", "amount": "10000", "asset": "USDT_OR_USDC_CONTRACT", "network": "eip155:56" }}

5. Validation Report

Each team should include:

docs/validation-report.md

Minimum content:

docs/validation-report.md:OS:ROS2:Zenoh:## Validated Skills- [ ] move_forward- [ ] stop## Validation Results- [ ] Skill catalog returns expected skills- [ ] Unpaid request returns 402 if payment is required- [ ] Paid request returns 200- [ ] Duplicate idempotency does not execute twice- [ ] Zenoh message received- [ ] Robot bridge received action- [ ] ROS2 output or robot movement observed## EvidenceCommands:Logs:Known limitations:

6. PR Rules

All submissions must go through pull requests.

PR title format:

Add robot profile: <vendor>/<robotModel>/<profileId>

Example:

Add robot profile: unitree/g1/unitree.g1.om1-sim-g1.v1

7. Review Checklist

  • ### Before submitting, make sure:

  • ### Required YAML files are included;

  • ### At least one example action envelope is included;

  • ### Validation report is included;

  • ### No private keys, API keys, .env, or secrets are committed;

  • ### No node_modules/, dist/, logs/, or *.pyc files are committed;

  • ### Movement actions include speed and duration limits;

  • ### Paid actions define payment requirements;

  • ### Emergency stop or safe stop behavior is described.

8. Important Principles

  • Agents should read skills.yaml and functions.yaml to understand what to call.

  • Payment requirements should be described in payment-policy.yaml.

  • Robot execution details should be described in execution-mapping.yaml.

  • Robot-side systems should not charge, verify, or settle payment a second time for the same authorized action.

  • Each profile should be small, reviewable, and specific to one robot model or runtime profile.

Clone this wiki locally