PATH primary sources

Reviewed: 2026-05-14 UTC

PATH overview / positioning

  • https://docs.pocket.network/path/
    • Best short source for the current official framing.
    • Used to confirm that PATH means Path API & Toolkit Harness, is an open-source Go gateway framework for Pocket Network’s decentralized supply network, and is the same software PNF uses to operate api.pocket.network.
    • Also the clearest source for the top-level component split across gateway, protocol, QoS, router, config, reputation, and metrics layers.

Routing, reputation, and service-quality mechanics

  • https://docs.pocket.network/path/architecture/
    • Best mechanism document in this pass.
    • Used to confirm the request data flow, reputation-score impacts, tiered endpoint selection, probation and recovery policy, chain-specific QoS modules, session-rollover handling, observation-pipeline sampling, and domain-level circuit breaker behavior.
    • This page is the strongest evidence that PATH is a genuine routing-and-quality control plane rather than a thin transport shim.

Configuration surfaces / operator policy levers

  • https://docs.pocket.network/path/configuration/
    • Best source for the operator-exposed control surface.
    • Used to confirm gateway modes (centralized, delegated, permissionless), required key material, Redis-backed shared state, retry and hedge policy, latency profiles, per-service overrides, RPC-type fallback handling, and operational endpoints.
    • Especially useful for showing where gateway operators can shape routing and reliability policy in practice.

Developer-facing architecture and adjacent components

  • https://docs.pocket.network/developers/building-with-path/
    • Best source for the higher-level product framing.
    • Used to confirm that PATH handles session management, QoS routing, relay forwarding, proof generation, multi-chain support, and archival detection, and that Pocket presents GUARD and WATCH as adjacent deployable components alongside PATH itself.
    • Helpful for explaining why PATH belongs in the corpus as a separate middleware/control-plane entry instead of being left implicit under Pocket Network.

Gateway economics and delegated authority

  • https://docs.pocket.network/gateways/staking/
    • Best source for the gateway-side economic role.
    • Used to confirm that applications delegate to gateways, gateways compete to attract many applications, and PATH is the off-chain engine that actually exercises that delegated routing/signing role after the on-chain gateway stake exists.
    • Important for grounding PATH in gateway-market structure rather than treating it as a neutral library.

Official repo framing

  • https://raw.githubusercontent.com/pokt-network/path/main/README.md
    • Useful concise repo-level source.
    • Used to confirm that the repository is maintained by the Pocket Network community, services the public RPC endpoints, and includes additional SaaS-oriented surfaces like the portal DB.
    • Helpful for tying the docs framing to the maintained upstream codebase.

Main takeaways from this pass

  • PATH clears the bar because it isolates the practical gateway layer inside Pocket Network: request admission, supplier scoring, routing, relay signing, proof-generation handshakes, and service-specific validation.
  • The most important analytical point is that gateway power does not stop at on-chain stake or supplier registration; it also sits in QoS rules, reputation thresholds, probation policy, circuit breakers, service overrides, and shared state choices like Redis.
  • PATH is therefore most useful in the corpus as a comparison point for decentralized RPC gateways, routing middleware, and any protocol that claims neutral open-data access while still depending on off-chain gateway software to decide where traffic actually goes.