DigiRails is a family of application-layer specifications that operate entirely above the DigiByte blockchain. No consensus changes, no soft forks. A pure application-layer standard.
Three specifications share a common on-chain prefix (0x4452, ASCII "DR") and a sub-protocol byte that cleanly namespaces each spec.
Shared infrastructure. Agent identity declarations, key rotation, DNS-verified naming. Used by all DigiRails specifications.
Payment infrastructure. Invoice creation, payment verification, confirmation tiers, streaming escrow, service discovery. The core specification.
Reputation system. On-chain attestations backed by verifiable payments. Sybil resistance via rate limiting and cluster detection.
Every DigiRails transaction uses a standard DigiByte OP_RETURN output with a 5-byte header followed by message-specific payload.
| Byte(s) | Field | Description |
|---|---|---|
0–1 | Magic | 0x4452 (ASCII "DR") — identifies this as a DigiRails transaction |
2 | Version | Protocol version. MSB (bit 7) is the test flag: 0x01 = production, 0x81 = test |
3 | Sub-protocol | 0x00 = DR-Core, 0x01 = DR-Pay, 0x02 = DR-Rep |
4 | Message type | Varies by sub-protocol (e.g., 0x01 = Service Declaration for DR-Pay) |
5+ | Payload | Message-specific data (category, manifest hash, invoice ID, etc.) |
Maximum payload: 75 bytes (DigiByte's 80-byte OP_RETURN limit minus the 5-byte header).
DR-Pay defines a 4-message exchange between buyer and seller. The SDK handles all of this automatically.
Buyer discovers the seller's manifest and sends a request specifying the service, parameters, and maximum amount.
Seller responds with an invoice: the exact amount, a payment address, invoice ID, and required confirmation tier.
Buyer constructs, signs, and broadcasts a standard DigiByte transaction. Sends the raw transaction to the seller.
Seller verifies the payment on-chain (or from mempool for micropayments), executes the service, and returns the result.
Not every payment needs the same security. DR-Pay defines four tiers that map payment size to required block confirmations.
| Tier | Confirmations | Time | Use Case | Recommended Max |
|---|---|---|---|---|
mempool | 0 | Instant | Micropayments: API calls, data queries | < 1 DGB |
flash | 1 block | ~15s | Standard: inference, tool use, compute | < 100 DGB |
standard | 4 blocks | ~60s | Large: bulk data, training jobs | < 10,000 DGB |
secure | 10 blocks | ~2.5 min | High-value: licensing, contracts | Unlimited |
18 standard categories plus a custom range (0xFF00–0xFFFF) supporting thousands more. Declared on-chain in service declaration transactions.
| Code | Category |
|---|---|
0x0001 | LLM Inference |
0x0002 | Image Generation |
0x0003 | Code Execution |
0x0004 | Data Retrieval / Feeds |
0x0005 | Embedding / Vector Search |
0x0006 | Media Processing |
0x0007 | Translation / Localization |
0x0008 | General Compute |
0x0009 | Storage |
0x000A | Relay / Proxy |
0x000B | Web Search / Live Information |
0x000C | Web Scraping / Extraction |
0x000D | Document Parsing |
0x000E | Data Enrichment |
0x000F | Fact Verification |
0x0010 | Agent Task Delegation |
0x0011 | Knowledge Graph |
0x0012 | Compliance / Regulatory |
0xFF00–0xFFFF | Custom / Experimental |
Three mechanisms for agents to find services, from simplest to most comprehensive.
Sellers publish a capabilities manifest at /.well-known/digirails.json. Buyers fetch it directly if they know the seller's domain.
Service declarations are broadcast as DigiByte transactions with manifest hashes. Indexers scan the chain and build a searchable directory.
A standardized REST API that any indexer implements. Agents query by category, trust score, or address. No custom integration code needed.
For long-running services, agents use a streaming payment pattern. The buyer pre-funds a 2-of-2 multisig address (P2WSH or Taproot), and both parties cooperatively sign incremental payout updates as the service is consumed. Only the final settlement transaction hits the chain. If either party disappears, a timelock ensures funds are not locked indefinitely.
This pattern enables pay-as-you-go consumption for services like training jobs, data streams, or extended compute sessions — where the total cost is not known in advance.