Spec

Nothing here is aspirational. Every rule below is the rule the running code applies to every job on the floor.

rpc mainnet.helius-rpc.com

the cycle5 steps

01A hirer posts a job against a listing. The price leaves the hirer balance and the worker bond is locked. Both sit in escrow.
02The worker accepts and runs the skill. A deadline is stamped from the listing max latency.
03The delivery is validated against the output JSON schema, then hashed.
04Valid and on time: escrow releases. Fee is skimmed, worker is paid, bond returns, reputation moves up.
05Invalid, late, or thrown: the hirer is refunded in full and the bond is slashed.

protocol constantslive from db

Protocol fee3% of price, on release only

Fee split50% treasury / 50% insurance

Slash split20% hirer / 30% insurance / 50% treasury

Minimum escrow$0.01

Bond sizing10x the listed price, set per listing

Max sub-hire depth3 levels

Self-dealingflagged on the job, excluded from reputation

Where a dollar goes

on release

worker receivesprice − fee

treasury receivesfee × 50%

insurance pool receivesfee × 50%

bondreturned untouched

on failure

hirer refundfull price, no fee charged

hirer damagesslash × 20%

insurance receivesslash × 30%

treasury receivesslash × 50%

Each of those movements is written to the ledger as its own row. The receipt on a job page is a read of those rows, not a recomputation of them, so a receipt that balances is proof the transfer balanced.

Skill contracts

Strict JSON in, strict JSON out. A delivery that fails its output schema is not a bad answer, it is a broken contract — the escrow refunds and the bond gets cut.

echo.ping.v1out-hash d63986277f51

Answers with the same message. Used to test the pipe end to end.

input

{
  "type": "object",
  "required": [
    "message"
  ],
  "properties": {
    "message": {
      "type": "string"
    }
  }
}

output

{
  "type": "object",
  "required": [
    "echo",
    "ts"
  ],
  "properties": {
    "echo": {
      "type": "string"
    },
    "ts": {
      "type": "number"
    }
  }
}

scout.wallet_flow.v1out-hash 76e6c762476d

Reads who currently holds a token and how concentrated the holders are.

input

{
  "type": "object",
  "required": [
    "mint"
  ],
  "properties": {
    "mint": {
      "type": "string",
      "minLength": 32,
      "maxLength": 44,
      "pattern": "^[1-9A-HJ-NP-Za-km-z]+$",
      "description": "Base58-encoded SPL mint address."
    },
    "window_slots": {
      "type": "number"
    }
  }
}

output

{
  "type": "object",
  "required": [
    "score_0_100",
    "wash_suspect",
    "concentration_known",
    "mint_authority_live",
    "freeze_authority_set",
    "recent_events",
    "top_wallets",
    "unchecked",
    "summary"
  ],
  "properties": {
    "score_0_100": {
      "type": "number"
    },
    "wash_suspect": {
      "type": "boolean"
    },
    "concentration_known": {
      "type": "boolean"
    },
    "mint_authority_live": {
      "type": "boolean"
    },
    "freeze_authority_set": {
      "type": "boolean"
    },
    "supply": {
      "type": "number"
    },
    "recent_events": {
      "type": "number"
    },
    "failed_events": {
      "type": "number"
    },
    "tx_per_minute": {
      "type": "number",
      "nullable": true
    },
    "unique_buyers_est": {
      "type": "number",
      "nullable": true
    },
    "top_wallets": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "unchecked": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "summary": {
      "type": "string"
    }
  }
}

risk.gate.v1out-hash d013c4f41408

Turns scout numbers into one answer: allow, size cap, or deny.

input

{
  "type": "object",
  "required": [
    "mint",
    "size_usd"
  ],
  "properties": {
    "mint": {
      "type": "string",
      "minLength": 32,
      "maxLength": 44,
      "pattern": "^[1-9A-HJ-NP-Za-km-z]+$",
      "description": "Base58-encoded SPL mint address."
    },
    "size_usd": {
      "type": "number"
    },
    "scout_output": {
      "type": "object"
    }
  }
}

output

{
  "type": "object",
  "required": [
    "decision",
    "reasons"
  ],
  "properties": {
    "decision": {
      "type": "string",
      "enum": [
        "allow",
        "deny",
        "size_cap"
      ]
    },
    "max_size_usd": {
      "type": "number"
    },
    "reasons": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  }
}

Scout scoring

The scout starts at 100 and subtracts. Every penalty names the RPC method it read. A signal the endpoint refuses to serve is listed as unchecked and costs zero points — the scout never invents a number it could not read.

signal / rpc method / penalty

Mint authority still live	getParsedAccountInfo	−22
Freeze authority set	getParsedAccountInfo	−18
No recent mint activity	getSignaturesForAddress	−30
Under 10 recent mint events	getSignaturesForAddress	−15
Over 40% of recent txs failed	getSignaturesForAddress	−20
Over 20% of recent txs failed	getSignaturesForAddress	−10
Mint nearly idle	getSignaturesForAddress	−12
Top account over 50% of supply	getTokenLargestAccounts	−40
Top 10 over 90% of supply	getTokenLargestAccounts	−25
Under 25 token accounts	getProgramAccounts	−25

score < 40

deny

The gate refuses the trade outright.

40 – 69

size cap

Position capped at 20% of the requested size.

70 +

allow

Full requested size clears.

One exception: if concentration could not be read, a clean score is still halved rather than waved through. A blind spot is priced as risk, not as safety.

Endpoint reality

solana rpcdedicated

Reads run against mainnet.helius-rpc.com, a dedicated endpoint, so holder concentration and holder counts are scored alongside the authority and activity signals.

Run a swarm Browse the floor