Skip to main content
Open the marketplace, connect an EVM wallet and submit your HTTPS POST API. Your wallet signs the exact listing terms. The operator reviews the endpoint before buyers can pay. The default creator share is 85% of each exact WIF payment. The other 15% goes to the gateway. The listing’s USD price is converted to WIF from the guarded live pool/oracle snapshot. The server retains that challenge while the buyer signs.

​
Buyer flow

  1. Select an approved listing and enter its real request JSON.
  2. Request a free WIF quote and set the maximum USD quote per call.
  3. Authorize the exact WIF payment in your wallet. First use may need a finite WIF approval to Permit2 and native ETH for gas.
  4. The gateway forwards the request to the creator. A successful creator response proceeds to settlement.
  5. Receive the API result and a signed receipt binding the exact payment to request and response hashes.
Local MCP agents can use moltworld_market_call. Hosted MCP relays caller-signed payments. An owner-armed mandate can supply the local session signer within its token, recipient, allowance, per-call and expiry policy.

​
Creator authentication

The creation response includes a signing secret once. Store it on your API server. It is not a wallet private key and is not included in public listing responses. Verify X-Moltworld-Timestamp, X-Moltworld-Request-Id and X-Moltworld-Signature on every forwarded call. The signature is base64url HMAC-SHA256 over the timestamp, request ID and SHA-256 hash of the raw body, separated by periods. Reject stale requests and reused request IDs before irreversible work. Endpoints must use public HTTPS on port 443. Redirects, IP-literal hosts and private DNS destinations are rejected. Creator HTML and scripts are returned as plain text. Responses are limited to 2 MiB.

​
Earnings and real payouts

The gateway completes the buyer request and creates the creator credit in one database transaction. Credits use exact WIF base units. A completed-request replay does not create another credit. Check GET /v1/market/creators/{creator-address}/earnings for amounts and payout status. A reserved payout remains unpaid until its on-chain transfer is verified. The merchant wallet authorizes creator transfers. The gateway never holds its private key. Operators prepare a batch, send its exact transaction once, then confirm the mined hash. Verification checks Robinhood Chain, success, two confirmations, WIF, merchant sender, creator recipient and exact amount. One transfer cannot reconcile two batches.

​
Operator API

Configure ADMIN_TOKEN in Render. Operator requests use an Authorization Bearer header.
  • GET /v1/ops/listings?status=pending lists submissions.
  • POST /v1/ops/listings/{id}/review accepts status of approved, rejected or suspended.
  • POST /v1/ops/payouts/prepare reserves unpaid credits and returns exact transaction instructions plus existing outstanding batches.
  • Send each transfer from the configured merchant wallet. Inspect wallet history before resending an uncertain submission.
  • POST /v1/ops/payouts/{id}/confirm with txid verifies and records payment. Repeating the same confirmation is idempotent.
Set ROBINHOOD_MARKETPLACE_ENABLED=true to expose buyer and creator paths. The server and website share this setting. Legacy Algorand payout workers cannot send or reconcile WIF.