[{"data":1,"prerenderedAt":1426},["ShallowReactive",2],{"docs-search-sections":3,"docs-last-updated":1015,"docs-toc":1020,"content-md-map":1137,"\u002Fdocs\u002Fmarkets\u002Fregistry":1179},[4,11,17,22,27,32,37,42,47,53,58,63,68,73,78,83,88,93,98,103,108,112,117,122,127,132,137,142,147,152,157,162,167,172,177,182,187,191,196,201,206,210,215,220,225,229,234,238,243,248,253,258,263,268,273,279,284,289,293,298,303,308,312,317,321,326,330,335,340,345,350,355,360,365,370,374,378,382,385,390,395,399,403,407,410,415,420,424,428,433,438,443,447,452,457,462,466,471,476,481,486,491,496,501,506,511,516,521,526,531,536,540,545,550,555,560,565,570,575,580,584,589,593,598,603,607,612,617,622,627,632,637,641,646,651,656,661,665,670,674,679,684,689,694,699,703,708,713,717,721,726,731,735,740,745,750,754,759,763,768,772,777,781,785,790,794,799,803,808,812,817,821,826,830,835,840,845,849,854,859,865,870,875,880,885,890,895,900,905,910,915,920,925,930,935,940,945,950,955,959,963,967,971,976,981,986,991,995,1000,1005,1010],{"id":5,"title":6,"titles":7,"content":8,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties","Validator Audits & Penalties",[],"Auditing as an obligated validator duty — random audit sampling, deterministic fraud proofs, and fact-layer penalties that feed back into diffusion policy. Optimistic diffusion claims shift heavy computation to provers, but the protocol still needs reliable verification at high volume. In mature markets, relying on a voluntary challenger ecosystem can suffer from free-riding (the “verifier’s dilemma”). Local Protocol addresses this by making auditing an obligated validator duty, enforced by standard consensus incentives (rewards + slashing). The chain checks: a protocol-chosen random subset of claims is mandatorily audited by assigned validators. The verifier’s dilemma is discussed in the Arbitrum paper (Kalodner et al., 2018). Slashing-backed enforcement is common in PoS finality designs (e.g., Casper FFG).",1,"Docs",{"id":12,"title":13,"titles":14,"content":15,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-sampling-unpredictable-canonical","Audit sampling (unpredictable, canonical)",[6],"At epoch boundary , the protocol derives an audit set using future randomness: : all diffusion claims included during epoch : audit budget (a fixed count or fraction per epoch) Using  ensures provers cannot predict which claims will be audited when committing transcripts.",2,{"id":18,"title":19,"titles":20,"content":21,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-assignment-obligations-not-volunteers","Audit assignment (obligations, not volunteers)",[6],"Each audited claim  is assigned to one or more validators deterministically: Assigned auditors must publish an AuditAttestation by a strict deadline, or be slashable.",{"id":23,"title":24,"titles":25,"content":26,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#what-auditors-verify-bounded-work","What auditors verify (bounded work)",[6],"Claims are market-relative: each claim is verified in a market context marketId = m, using the market’s committed teleport distribution  (opened via ) and market-scoped edge sampling commitments for that market. Auditors verify a bounded subset of transcript walks\u002Fsteps derived canonically, and check the opened transitions against the committed snapshot roots. The transcript format and commitment rules live in the claim protocol: Optimistic Diffusion ClaimsGraph Commitments & Epoch Snapshots Audits require authenticated snapshot data (NodeRecords, EdgeRecords, alias tables). Availability and retrieval live in the storage model. See: Performance & Storage",{"id":28,"title":29,"titles":30,"content":31,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-outcomes-and-accountability","Audit outcomes and accountability",[6],"Auditors publish one of: VALID: with transcript fragments sufficient for anyone to reproduce the checksINVALID: a concrete fraud proof (openings + proofs showing a violation)",{"id":33,"title":34,"titles":35,"content":36,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#fraud-proofs-are-deterministic","Fraud proofs are deterministic",[6],"A fraud proof is valid iff any full node can deterministically replay the sampled checks and obtain a mismatch. Concretely, a fraud proof includes: claimId, txid, epoch: t, , and the claim parameter commitment (e.g., ParamsHash)the sampled walk indices (or enough data to recompute them from )the opened transcript fragments (Merkle openings from TranscriptRoot)the Merkle\u002Falias openings required to verify market-scoped transitions against  and teleport sampling against the market seed root  (opened via ) This is the standard optimistic “fraud proof” pattern (e.g., Truebit, Arbitrum), specialized to sampled Monte Carlo transcripts rather than full VM traces.",{"id":38,"title":39,"titles":40,"content":41,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-deadline-and-claim-finality-fail-closed-for-audited-claims","Audit deadline and claim finality (fail-closed for audited claims)",[6],"Audited claims finalize under a fail-closed rule: rewards are escrowed at submission timeif a claim is in , it cannot finalize as VALID by timeout alonethe claim becomes:\nINVALID immediately upon inclusion of a valid fraud proofVALID once at least one assigned auditor posts a VALID attestation and the deadline passes without any valid fraud proofPENDING (locked) if the deadline passes with no VALID attestation (and no-show auditors are slashable) To prevent rubber-stamping: No-show: assigned auditor misses deadline → slashableFalse attestation: auditor attests VALID but a fraud proof is later posted → slashable",{"id":43,"title":44,"titles":45,"content":46,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#penalties-fact-layer-and-how-they-affect-future-trust","Penalties (fact-layer) and how they affect future trust",[6],"When an audited claim fails, the protocol applies objective penalties and then feeds them back into diffusion policy.",{"id":48,"title":49,"titles":50,"content":51,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_1-edge-slashing","1) Edge slashing",[6,44],"For a failed edge :",3,{"id":54,"title":55,"titles":56,"content":57,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_2-bond-slashing","2) Bond slashing",[6,44],"The claim bond  is slashed (policy-defined split between burn\u002Fsecurity pool\u002Fauditor rewards).",{"id":59,"title":60,"titles":61,"content":62,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_3-penalty-vector-ledger-fact","3) Penalty vector  (ledger fact)",[6,44],"Maintain a per-node penalty score , updated only by finalized audits: Penalty injection is a distrust \u002F negative-evidence propagation pattern in link analysis and trust systems. A representative example is distrust propagation in PageRank-style rankings (e.g., Wu et al., 2006). See also distrust demotion variants like Anti-TrustRank and early trust\u002Fdistrust graph models such as Guha et al., 2004. Optional bounded neighbor spillover:",{"id":64,"title":65,"titles":66,"content":67,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_4-how-penalties-modify-policy-inputs","4) How penalties modify policy inputs",[6,44],"Penalty-adjusted seed weights (before normalization): Risk-based claim constraints (examples):",{"id":69,"title":70,"titles":71,"content":72,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#related","Related",[6],"Optimistic Diffusion ClaimsConsensusSampling & Slashing mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":74,"title":75,"titles":76,"content":77,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion","Snapshot-Relative Diffusion (PageRank \u002F PPR)",[],"Influence defined as a PageRank\u002FPPR fixed point evaluated relative to a committed epoch snapshot, with protocol-defined market-relative teleport. Local Protocol defines influence using a diffusion score that is a fixed point over a committed epoch snapshot. Practically, this is PageRank \u002F Personalized PageRank (PPR) semantics, evaluated relative to the snapshot, not continuously recomputed as a global “ledger fact”.",{"id":79,"title":80,"titles":81,"content":82,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_1-transition-operator","1) Transition operator",[75],"Let the global transaction graph at epoch  be a weighted, directed graph: Define a row-stochastic transition matrix  derived from outgoing weights: For dangling nodes (no outgoing edges), the protocol redirects mass according to the teleport distribution (standard PageRank handling). You can read  as a “next hop” rule: if you are at , then  is the chance you move to  next. Rows sum to 1 because this is a Markov chain. Markov chains and stationary distributions are the standard lens for PageRank-style scores; see e.g. Levin–Peres–Wilmer.",{"id":84,"title":85,"titles":86,"content":87,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_2-teleport-distribution-protocol-defined","2) Teleport distribution (protocol-defined)",[75],"Local Protocol uses Personalized PageRank (PPR) to anchor diffusion to a protocol-defined set of trusted starting points (users do not get to choose personalization; that would be instantly gameable).",{"id":89,"title":90,"titles":91,"content":92,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#why-market-relative-teleport","Why market-relative teleport?",[75,85],"In real marketplaces, trust is often local to a market context (a naturally fragmented city \u002F vertical can be real yet weakly connected to global anchors). A single global seed set can accidentally treat a legitimate, fragmented market as “low influence” simply because diffusion cannot reach it. Market-relative teleport addresses this: diffusion (and claims derived from it) are evaluated in a market context marketId = m. Formally: teleport distribution per market: market-relative diffusion score: The protocol commits to  each epoch (users do not choose it). Teleport is the protocol’s “source of ground truth”: where trust starts. Market-relative teleport keeps that rule intact while preventing “fragmented-but-real” markets from being unfairly treated as low influence. Personalization vectors in Personalized PageRank, topic\u002Fcontext-sensitive ranking variants, and seed-set anchoring like TrustRank.",{"id":94,"title":95,"titles":96,"content":97,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_3-fixed-point-definition","3) Fixed point definition",[75],"For a given market context , the protocol defines a market-scoped transition operator  (outgoing edges filtered to marketId = m, plus any explicitly-global edges the protocol defines), and a market-relative teleport distribution . Claims are verified against market-scoped walks: the walk uses the market-scoped operator  and teleports according to the market’s committed seed table . This prevents reinterpreting the same transcript under a different market context. marketId is derived from execution: it must match the registered MarketContext that emitted the interaction record, and the market must be ACTIVE. See: Market Registry. The market-relative diffusion score  is defined as: Where  is the restart probability (teleport rate). This fixed point exists and is unique for .",{"id":99,"title":100,"titles":101,"content":102,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_4-random-walk-interpretation","4) Random-walk interpretation",[75],"Sample a random walk: start from a teleport sample at each step: with probability  restart from , otherwise follow a market-scoped outgoing edge proportional to weights Then  is the stationary probability of being at node  (in market context ).",{"id":104,"title":105,"titles":106,"content":107,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_5-why-snapshot-relative","5) Why snapshot-relative?",[75],"Diffusion is defined relative to a committed snapshot: the ledger commits to  via claims derived from diffusion must specify which snapshot they referenceeconomic outputs are computed with respect to that snapshot Diffusion is a global fixed point and is not composable by one-way merging of independently computed partition-local vectors.",{"id":109,"title":70,"titles":110,"content":111,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#related",[75],"Graph Commitments & Epoch SnapshotsMarketsOptimistic Diffusion Claims mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":113,"title":114,"titles":115,"content":116,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample","Basic Example Graph",[],"A tiny five-participant graph that builds intuition for snapshot-relative diffusion (PageRank \u002F PPR) and how claims reference it. This page builds intuition for snapshot-relative diffusion (PageRank \u002F PPR) and how it can be referenced by claims.",{"id":118,"title":119,"titles":120,"content":121,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#a-tiny-transaction-graph","A tiny transaction graph",[114],"Consider five participants: producers: P1, P2buyers: B1, B2, B3 Model interactions as a directed graph, where an edge buyer → producer has weight equal to completed transaction value (after any quality\u002Fproof factors).",{"id":123,"title":124,"titles":125,"content":126,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#personalized-pagerank-ppr-intuition","Personalized PageRank (PPR) intuition",[114],"In PPR, influence originates from a teleport distribution and diffuses through the graph. In Local Protocol, teleport is market-relative: for market marketId = m, influence originates from . If the protocol’s verified seed set for market  includes B1 and B2, a toy teleport distribution might be: The diffusion fixed point is: So nodes that are reachable via high-weight paths from the verified seed set accumulate more influence.",{"id":128,"title":129,"titles":130,"content":131,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#offchain-computation-demo-networkx","Offchain computation demo (NetworkX)",[114],"This is not a protocol algorithm; it’s just a quick way to visualize the fixed point on a small graph. import networkx as nx\n\n# Directed graph with edge weights (buyer -> producer)\nG = nx.DiGraph()\nG.add_edge(\"B1\", \"P1\", weight=2.0)\nG.add_edge(\"B2\", \"P2\", weight=3.0)\nG.add_edge(\"B3\", \"P2\", weight=1.0)\n\n# Teleport distribution (protocol-defined in production)\npersonalization = {\"B1\": 0.5, \"B2\": 0.5, \"B3\": 0.0, \"P1\": 0.0, \"P2\": 0.0}\n\n# alpha here is the restart probability (teleport rate)\nr = nx.pagerank(G, alpha=0.85, personalization=personalization, weight=\"weight\")\nprint(r)",{"id":133,"title":134,"titles":135,"content":136,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#how-this-maps-to-the-protocol","How this maps to the protocol",[114],"Diffusion  is defined on a committed snapshot  and a market-relative seed commitment:  is a root-of-roots that binds per-market seed tables.The protocol does not store  as a global vector.Instead, diffusion enters the system through bounded, challengeable claims with transcripts and slashing.",{"id":138,"title":139,"titles":140,"content":141,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#next-steps","Next steps",[114],"Snapshot-Relative DiffusionOptimistic Diffusion Claims mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n} html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}",{"id":143,"title":144,"titles":145,"content":146,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph","The Transaction Graph",[],"A weighted, directed graph capturing economic relationships, used via snapshot-relative diffusion to allocate incentives and resist Sybil attacks. The transaction graph is a weighted, directed graph that captures economic relationships between participants. Each completed interaction adds or updates an edge, and the protocol uses the resulting connectivity (via snapshot-relative diffusion) to allocate incentives and resist Sybil manipulation.",{"id":148,"title":149,"titles":150,"content":151,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#graph-structure","Graph Structure",[144],"Let the global transaction graph at epoch  be: : participants (buyers, producers, agents, domains, etc.): directed edges representing completed interactions: nonnegative edge weights In a marketplace setting: buyer  purchasing from producer  adds edge an optional reverse edge  can represent fulfillment confirmation, dispute outcomes, or service-proof acknowledgements Commerce edges are market-tagged. The market tag is not user-provided: it is derived from the MarketContext that emitted the interaction record and must match the canonical registry state. See: Market Registry. The graph is a ledger-friendly data structure: edges are “who paid whom for what,” and weights are “how much that interaction counts.” These are facts derived from transactions and dispute outcomes. Interaction graphs and reputation-as-edges, e.g. EigenTrust. Separating facts (edges\u002Fweights\u002Fproofs\u002Fdisputes) from interpretations (diffusion scores computed on snapshots) is what makes the protocol scalable and verifiable.",{"id":153,"title":154,"titles":155,"content":156,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#edge-weights","Edge weights",[144,149],"Each completed transaction produces an edge weight: Where: amount is the economic value (price, fee base, etc.)quality accounts for dispute outcomes, refunds, chargebacks, delivery SLAs, etc.proof_factor is derived from attached service proofs and identity proofs The protocol constrains weights to prevent pathological abuse (per-edge min\u002Fmax, per-transaction caps, epoch caps, and\u002For decay).",{"id":158,"title":159,"titles":160,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#key-features","Key Features",[144],"",{"id":163,"title":164,"titles":165,"content":166,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#_1-dynamic-adjustments","1. Dynamic Adjustments",[144,159],"The transaction graph dynamically adjusts based on participant interactions. As transactions occur, edge weights are updated, causing changes in connectivity and node influence. This creates a self-optimizing system where token distributions reflect the evolving state of the network.",{"id":168,"title":169,"titles":170,"content":171,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#_2-connectivity-as-a-measure-of-value","2. Connectivity as a Measure of Value",[144,159],"The graph not only captures transaction volume but also connectivity: Nodes with more connections to well-connected nodes are considered more influential.This approach ensures that participants contributing to network growth through broad connectivity earn higher rewards, not just participants with high transaction volumes with a single counterparty.",{"id":173,"title":174,"titles":175,"content":176,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#_3-sybil-resistance","3. Sybil Resistance",[144,159],"The graph’s structure inherently resists manipulation through Sybil attacks: Sybil nodes (fake users) typically form isolated clusters without strong connections to real nodes.The graph's weighting system prioritizes connections that enhance network-wide connectivity, making it difficult for isolated Sybil nodes to earn high rewards.",{"id":178,"title":179,"titles":180,"content":181,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#next-steps","Next Steps",[144],"The transaction graph sets the foundation for diffusion and verification: Snapshot-Relative DiffusionGraph Commitments & Epoch Snapshots mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":183,"title":184,"titles":185,"content":186,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs","Games & Graphs",[],"The protocol's graph-based mechanism stack — a transaction graph, snapshot-relative diffusion, and optimistic bounded claims. This chapter describes the protocol’s graph-based mechanism stack: ledger facts as a transaction graph,snapshot-relative diffusion (PPR) defined on committed epoch snapshots,optimistic, bounded claims verified by sampling and slashing. For markets (registry, commitments, and bootstrapping), see: Markets.",{"id":188,"title":179,"titles":189,"content":190,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs#next-steps",[184],"Start here: Transaction Graph ModelSnapshot-Relative Diffusion (PageRank \u002F PPR)MarketsGraph Commitments & Epoch SnapshotsOptimistic Diffusion Claims",{"id":192,"title":193,"titles":194,"content":195,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims","Optimistic Diffusion Claims",[],"Participants include diffusion-derived rewards as bounded, challengeable claims verified by sampling, caps, bonds, and slashing instead of global computation. Local Protocol allows participants to include diffusion-derived reward outputs inside their transaction SDLs without requiring validators to compute  as a global vector. This uses optimistic verification: claims are accepted subject to a challenge window; incorrect claims are deterred with bonds + slashing and are verifiable via sampling. A user can attach a “this is my bounded reward, relative to the last committed snapshot” claim. Validators don’t compute global diffusion; they enforce caps\u002Fbonds and audit a bounded subset. Optimistic verification and fraud-proof patterns: Truebit and verifier-incentive discussions like the Arbitrum paper (Kalodner et al., 2018). Diffusion is expensive globally, but individual claims can be checked with bounded audits. This keeps validator work predictable while shifting compute to provers.",{"id":197,"title":198,"titles":199,"content":200,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#what-a-user-is-allowed-to-claim","What a user is allowed to claim",[193],"A user submitting a transaction SDL may include a reward claim: The claim is a function of: committed snapshot roots the canonical snapshot artifact identifier  (to fetch authenticated snapshot data needed for audits, including MarketRegistry; see Graph Commitments & Epoch Snapshots and Performance & Storage)protocol parameters transaction contents (counterparty, amount, and market context)a protocol-defined estimator (random-walk \u002F Monte Carlo diffusion) Safety is achieved by combining: strict caps (deterministic safety rails):\nper-transaction: per-user per-epoch: per-market per-epoch: optional global backstop: canonical randomness (no grinding)priced verification (bounded work)bonds and slashing (negative EV for cheating)delayed sampling (prevents adaptive transcripts) Audits are probabilistic, but caps are deterministic. Even if audits miss something temporarily, total extractable value is bounded per user and per market. Claims are structured so audits have deterministic worst-case cost: protocol parameters bound maximum walk length, the number of sampled walks opened per audited claim, and the size of each opening (Merkle proofs + alias-table proofs). These bounds prevent “audit griefing” via oversized transcripts or huge openings.",{"id":202,"title":203,"titles":204,"content":205,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#canonical-randomness-kills-grinding","Canonical randomness (kills grinding)",[193],"Each epoch has a randomness beacon . For each transaction id txid, walk seeds are derived deterministically: This removes user choice and prevents seed grinding \u002F “variance extraction”. The prover doesn’t get to pick the dice rolls: walk randomness is derived from an epoch beacon, so users can’t retry until they get a lucky estimator outcome. Verifiable Random Functions: RFC 9381. Audit selection and transcript determinism rely on  being unpredictable at commit time and bias-resistant with respect to block proposers\u002Fvalidators. A common appchain design is a threshold BLS beacon in the style of drand (see also Cloudflare’s beacon background: Randomness Beacon).",{"id":207,"title":208,"titles":209,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#transcript-commitment-delayed-sampling-prevents-adaptive-cheating","Transcript commitment + delayed sampling (prevents adaptive cheating)",[193],{"id":211,"title":212,"titles":213,"content":214,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#commit-now-sample-later","Commit now, sample later",[193,208],"The prover: computes the claim and a transcript for  Monte Carlo walkscommits to a transcript root posts a commitment hash: Binding , , plus the market context  makes the transcript commitment deterministic: every verifier replays the same market-relative random-walk process on the same snapshot using the market’s committed teleport distribution .  ensures the replay also uses the same estimator settings (walk count, max steps, etc.). Binding  and  prevents replaying a valid transcript under a different snapshot. Binding  prevents reusing the transcript under a different market seed table. Users don’t get to pick a favorable marketId. In the fact layer, the transaction executes a MarketContext that emits an InteractionRecord, and the record’s marketId = m must match MarketRegistry[marketContext].marketId at that height.\nBecause MarketRegistry is included in SnapshotBlob_t and bound by , auditors can deterministically verify the market derivation while verifying the same claim’s transcript steps against  \u002F . Then sampling indices are derived from future randomness (e.g., ): Because  is unknown at commit time, the prover cannot craft a transcript that is only valid on the checked parts. First you lock in the transcript; later the protocol decides which parts must be opened. If you lied anywhere, there’s a good chance the opened part exposes it. Merkle commitments and delayed random challenges are standard in fraud-proof protocols.",{"id":216,"title":217,"titles":218,"content":219,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#transcript-contents-minimal-sketch","Transcript contents (minimal sketch)",[193],"For walk  (length ): starting node  (sampled from the market-relative teleport , with teleport sampling proofs against  and optionally a per-market seed alias commitment )visited nodes for each step :\nrestart decision correctnessmarket-scoped edge sampling proof:\nopen OutIndex(m) for the current node via Merkle proof from marketOutIndexRootprove the sampled outgoing edge index using a Merkle opening against the aliasRoot from OutIndex(m)open the selected edge entry via Merkle proof against the adjacencyRoot from OutIndex(m)final contribution to the estimator (e.g., terminal node count, hit counts, discounted hits)",{"id":221,"title":222,"titles":223,"content":224,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#verification-and-penalties-validator-audits","Verification and penalties (validator audits)",[193],"In high-volume markets, a protocol-chosen subset of claims is mandatorily audited by assigned validators, and failed audits finalize as fact-layer penalties. See: Validator Audits & Penalties",{"id":226,"title":70,"titles":227,"content":228,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#related",[193],"Snapshot-Relative DiffusionGraph Commitments & Epoch SnapshotsValidator Audits & PenaltiesState Model (SDLs) mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":230,"title":231,"titles":232,"content":233,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foverview","Incentives in Local Protocol",[],"Snapshot-relative diffusion on the transaction graph dynamically adjusts incentives while keeping validator work bounded and Sybil resistance strong. Local Protocol leverages snapshot-relative diffusion on the transaction graph to dynamically adjust incentives while maintaining strong Sybil resistance. Diffusion-derived outputs enter the system through bounded, challengeable claims, keeping validator work bounded and predictable. Diffusion answers: “if we start from verified activity and let trust spread, where does it end up?” Those scores then feed reward multipliers, risk limits, and market policy knobs. Graph diffusion for ranking\u002Ftrust: PageRank, Personalized PageRank, and seed-set anchoring like TrustRank. The protocol wants local actions (a completed delivery) to have non-local effects (your neighborhood becomes more trusted). Diffusion provides that spillover with clear semantics.",{"id":235,"title":179,"titles":236,"content":237,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Foverview#next-steps",[231],"In the following sections, we’ll build up the full model: The Transaction GraphSnapshot-Relative Diffusion (PageRank \u002F PPR)MarketsGraph Commitments & Epoch SnapshotsOptimistic Diffusion ClaimsBasic Example (PPR intuition)Insurance & Dispute Resolution After you’re comfortable with the transaction graph, you can dive into the other core protocol layers: SecurityProofsTrustArchitecture",{"id":239,"title":240,"titles":241,"content":242,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments","Graph Commitments & Epoch Snapshots",[],"One canonical epoch snapshot commitment per epoch — graph, seed, and artifact roots that serve as the reference for diffusion-derived claims. Local Protocol finalizes one canonical epoch snapshot commitment per epoch. The ledger commits to snapshot roots and uses them as the canonical reference for any diffusion-derived claims.",{"id":244,"title":245,"titles":246,"content":247,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#epochs","Epochs",[240],"Time is divided into epochs . Each epoch defines: a committed graph snapshot root a committed teleport\u002Fseed root a canonical randomness beacon protocol parameters The epoch cap  is not a single number. It’s a cap vector:: max claimable output per user\u002Fidentity per epoch: max claimable output per market\u002Fdomain per epoch: optional protocol-wide backstop (“fuse”)These caps are deterministic safety rails: even if audits miss something briefly, total extractable value is bounded per user and per market. A snapshot is like taking a photo of the graph once per epoch and publishing a hash of it. Later, anyone can prove facts about that “photo” (this edge existed, this node’s out-weight sum was X) using short inclusion proofs. Commitment trees \u002F authenticated datasets via Merkle trees.",{"id":249,"title":250,"titles":251,"content":252,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#commitment-structure","Commitment structure",[240],"Partition nodes into shards . Each shard publishes: The global graph root is:",{"id":254,"title":255,"titles":256,"content":257,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#seed-commitments-market-relative-teleport","Seed commitments (market-relative teleport)",[240,250],"Teleport is market-relative: each market marketId = m has its own protocol-committed teleport distribution . To keep the fact layer compact while supporting many markets, the snapshot commits a root of roots: Each per-market seed root commits to the seed-weight table for that market: For O(1) verifiable teleport sampling in transcripts, the snapshot artifact can also include a per-market alias table commitment (e.g., ) for sampling from .",{"id":259,"title":260,"titles":261,"content":262,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#snapshot-artifact-identifier-snapshotid","Snapshot artifact identifier (SnapshotId)",[240],"Audits require authenticated access to snapshot data (NodeRecords \u002F EdgeRecords \u002F alias tables). Each epoch therefore finalizes a Snapshot Artifact that is content-addressed and publicly retrievable. To make market membership auditable, SnapshotBlob_t must include the canonical MarketRegistry table for epoch :\nmarketContext → (marketId, vault, feeRouter, flags).\nBecause  binds SnapshotBlobHash_t, auditors can verify MarketRegistry lookups against the same snapshot commitments used for graph and seed verification. At epoch , let SnapshotBlobHash_t be the content hash of the snapshot artifact bytes in the data layer (see Performance & Storage). The chain commits:",{"id":264,"title":265,"titles":266,"content":267,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#proof-friendly-snapshot-packaging","Proof-friendly snapshot packaging",[240],"To support efficient verification (including random-walk transcript checks), the snapshot is packaged in structures that are easy to open with Merkle proofs. These records are the index that makes audits cheap: a verifier doesn’t need the whole graph—just a few Merkle openings for the edges touched by a sampled walk. Authenticated data structures (Merkleized key–value stores and adjacency lists) used in light-client verification.",{"id":269,"title":270,"titles":271,"content":272,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#noderecord","NodeRecord",[240,265],"For node : nodeId: AddressmarketOutIndexRoot: bytes32 — Merkle root of per-market outgoing-index entries keyed by marketIdnodeAttrRoot: bytes32 — root of node attributes (identity proofs, reputation flags, maturity gates) Each per-market outgoing-index entry (opened by a Merkle proof from marketOutIndexRoot) is:",{"id":274,"title":275,"titles":276,"content":277,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#outindexm","OutIndex(m)",[240,265,270],"marketId: uint32outWeightSum: uint128 —  for this marketadjacencyRoot: bytes32 — Merkle root of outgoing edges in this marketaliasRoot: bytes32 — Merkle root of alias table for O(1) sampling of outgoing edges in this marketdegree: uint32 — number of outgoing edges in this market A node’s outgoing edges are partitioned by market. When verifying a walk step for market , a verifier opens OutIndex(m) and then verifies the sampled neighbor using that market’s aliasRoot + adjacencyRoot.",4,{"id":280,"title":281,"titles":282,"content":283,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#edgerecord","EdgeRecord",[240,265],"For an outgoing edge : dst: Addressweight: uint128edgeAttrRoot: bytes32 — service proof \u002F dispute state commitmentsmarketId: uint32 — required market tag for commerce edges (“this edge belongs to market ”). marketId MUST match the registry-assigned marketId of the producing MarketContext at that block height.flags: uint32 — dispute outcomes, maturity gating, etc.",{"id":285,"title":286,"titles":287,"content":288,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#alias-tables-recommended","Alias tables (recommended)",[240,265],"For efficient verifiable sampling from , the protocol supports per-node, per-market alias tables (via OutIndex(m).aliasRoot): alias entries deterministically derived from the market-scoped adjacency listthe table commits to sampling structure enabling O(1) verification of a sampled neighbor within the market context A random walk repeatedly asks: “from , which neighbor  do I jump to next?” Alias tables are a standard trick to sample from a discrete distribution in O(1) time. The alias method: Walker (1977) and Vose (1991).",{"id":290,"title":70,"titles":291,"content":292,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#related",[240],"Snapshot-Relative DiffusionMarketsOptimistic Diffusion Claims",{"id":294,"title":295,"titles":296,"content":297,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#snapshot-artifacts-and-data-availability","Snapshot artifacts and data availability",[240],"Nodes can check availability via probabilistic sampling (DAS-style checks), as in LazyLedger and common DAS primers (e.g., Celestia’s Data Availability Sampling). See: Performance & Storage mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":299,"title":300,"titles":301,"content":302,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity","Identity",[],"Local Account contracts provide an ERC-4337 account abstraction using P256 and WebAuthn for secure, user-friendly identity management. The Local Account contracts provide an ERC-4337 compliant account abstraction for managing user identities within the Local network. These contracts leverage P256 elliptic curve cryptography and WebAuthn standards to offer secure, user-friendly authentication mechanisms. The primary goals of these contracts are to: Account Abstraction: Implement ERC-4337 account abstraction to enable advanced functionalities like batching transactions and key rotation.Key Management: Support multiple signing keys (1-of-n multisig) with the ability to add or remove keys.Usability: Provide a seamless user experience without compromising on security by using p256 keys compatible with WebAuthn, compatible with passkeys.Security: Ensure all cryptographic operations are secure.Compatibility: Align with existing and proposed standards like EIP-7212 for future-proofing.",{"id":304,"title":305,"titles":306,"content":307,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#components","Components",[300],"The Local Account system comprises the following on-chain elements: LocalAccount: The main contract representing a user's account.LocalAccountFactory: A factory contract for deploying LocalAccount instances using CREATE2 for deterministic addresses.LocalVerifier: A contract for verifying signatures using P256 elliptic curve operations.",{"id":309,"title":310,"titles":311,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#localaccount-contract","LocalAccount Contract",[300],{"id":313,"title":314,"titles":315,"content":316,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#overview","Overview",[300,310],"The LocalAccount contract implements an ERC-4337 compatible account abstraction. It allows users to: Execute multiple transactions atomically.Validate user operations via P256 signatures.Manage multiple signing keys with 1-of-n multisig support.Rotate keys securely.",{"id":318,"title":159,"titles":319,"content":320,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#key-features",[300,310],"ERC-4337 Compliance: Implements the IAccount interface for compatibility with account abstraction entry points.Multisig Support: Allows up to 20 active signing keys, enabling 1-of-n multisig functionality.Key Rotation: Supports adding and removing signing keys, enhancing security and flexibility.WebAuthn Integration: Uses P256 keys compatible with WebAuthn, facilitating passwordless authentication.Upgradeable: Utilizes the UUPS upgrade pattern for future enhancements.",{"id":322,"title":323,"titles":324,"content":325,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#state-variables","State Variables",[300,310],"numActiveKeys: Number of active signing keys.keys: Mapping from key slots to public keys.entryPoint: Reference to the ERC-4337 entry point contract.verifier: Instance of the LocalVerifier contract.maxKeys: Maximum number of signing keys (constant value of 20).",{"id":327,"title":328,"titles":329,"content":161,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#methods","Methods",[300,310],{"id":331,"title":332,"titles":333,"content":334,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#initialization","Initialization",[300,310,328],"function initialize(\n    uint8 slot,\n    bytes32[2] calldata key,\n    Call[] calldata initCalls\n) public virtual initializer Purpose: Initializes the account with an initial signing key and optional contract calls.Parameters:\nslot: Key slot to store the initial key.key: The P256 public key.initCalls: Array of contract calls to execute during initialization.",{"id":336,"title":337,"titles":338,"content":339,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#transaction-execution","Transaction Execution",[300,310,328],"function executeBatch(Call[] calldata calls) external onlyEntryPoint Purpose: Executes multiple transactions atomically.Parameters:\ncalls: An array of Call structs containing destination, value, and data.",{"id":341,"title":342,"titles":343,"content":344,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#user-operation-validation","User Operation Validation",[300,310,328],"function validateUserOp(\n    UserOperation calldata userOp,\n    bytes32 userOpHash,\n    uint256 missingAccountFunds\n) external override returns (uint256 validationData) Purpose: Validates a user operation by verifying a P256 signature.Parameters:\nuserOp: The user operation to validate.userOpHash: Hash of the user operation.missingAccountFunds: Amount of funds the account needs to cover transaction costs.",{"id":346,"title":347,"titles":348,"content":349,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#signature-validation","Signature Validation",[300,310,328],"function isValidSignature(\n    bytes32 message,\n    bytes calldata signature\n) external view override returns (bytes4 magicValue) Purpose: Validates signatures for ERC-1271 compliance.Parameters:\nmessage: The message hash that was signed.signature: The signature data.",{"id":351,"title":352,"titles":353,"content":354,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#key-management","Key Management",[300,310,328],"Add Signing Keyfunction addSigningKey(uint8 slot, bytes32[2] memory key) public onlySelf\nPurpose: Adds a new signing key to the account.Parameters:\nslot: The key slot to store the new key.key: The P256 public key.Remove Signing Keyfunction removeSigningKey(uint8 slot) public onlySelf\nPurpose: Removes an existing signing key from the account.Parameters:\nslot: The key slot of the key to remove.",{"id":356,"title":357,"titles":358,"content":359,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#utility-methods","Utility Methods",[300,310,328],"Get Active Signing Keysfunction getActiveSigningKeys()\n    public\n    view\n    returns (\n        bytes32[2][] memory activeSigningKeys,\n        uint8[] memory activeSigningKeySlots\n    )\nPurpose: Retrieves all active signing keys and their slots.",{"id":361,"title":362,"titles":363,"content":364,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#access-control","Access Control",[300,310],"onlySelf: Modifier to restrict functions to be called only by the contract itself.onlyEntryPoint: Modifier to restrict functions to be called only by the designated entry point.",{"id":366,"title":367,"titles":368,"content":369,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#events","Events",[300,310],"AccountInitialized: Emitted during initialization.SigningKeyAdded: Emitted when a new signing key is added.SigningKeyRemoved: Emitted when a signing key is removed.",{"id":371,"title":372,"titles":373,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#localaccountfactory-contract","LocalAccountFactory Contract",[300],{"id":375,"title":314,"titles":376,"content":377,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#overview-1",[300,372],"The LocalAccountFactory contract is responsible for deploying new LocalAccount instances using the CREATE2 opcode, allowing for deterministic contract addresses.",{"id":379,"title":159,"titles":380,"content":381,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#key-features-1",[300,372],"Deterministic Deployment: Uses CREATE2 for predictable account addresses.Prefunding: Allows prefunding of the account during creation.Singleton Implementation: Reuses a single LocalAccount implementation for all instances.",{"id":383,"title":328,"titles":384,"content":161,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#methods-1",[300,372],{"id":386,"title":387,"titles":388,"content":389,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#create-account","Create Account",[300,372,328],"function createAccount(\n    uint8 keySlot,\n    bytes32[2] memory key,\n    LocalAccount.Call[] calldata initCalls,\n    uint256 salt\n) public payable returns (LocalAccount ret) Purpose: Deploys a new LocalAccount contract or returns the address if it already exists.Parameters:\nkeySlot: Key slot for the initial key.key: The P256 public key.initCalls: Array of initialization calls.salt: Salt value for CREATE2.",{"id":391,"title":392,"titles":393,"content":394,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#get-address","Get Address",[300,372,328],"function getAddress(\n    uint8 keySlot,\n    bytes32[2] memory key,\n    LocalAccount.Call[] calldata initCalls,\n    uint256 salt\n) public view returns (address) Purpose: Computes the deterministic address of a LocalAccount contract based on input parameters.",{"id":396,"title":397,"titles":398,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#localverifier-contract","LocalVerifier Contract",[300],{"id":400,"title":314,"titles":401,"content":402,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#overview-2",[300,397],"The LocalVerifier contract provides signature verification functionality for P256 signatures, compatible with WebAuthn standards.",{"id":404,"title":159,"titles":405,"content":406,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#key-features-2",[300,397],"Signature Verification: Verifies P256 signatures for both user operations and ERC-1271 compliance.Upgradeable: Implements the UUPS upgrade pattern for future enhancements.Auditability: Designed with security and auditability in mind.",{"id":408,"title":328,"titles":409,"content":161,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#methods-2",[300,397],{"id":411,"title":412,"titles":413,"content":414,"level":278,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#verify-signature","Verify Signature",[300,397,328],"function verifySignature(\n    bytes memory message,\n    bytes calldata signature,\n    uint256 x,\n    uint256 y\n) public view returns (bool) Purpose: Verifies a P256 signature given the message, signature data, and public key coordinates.Parameters:\nmessage: The original message that was signed.signature: The signature data, including WebAuthn-related fields.x, y: Coordinates of the public key on the P256 curve.",{"id":416,"title":417,"titles":418,"content":419,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#signature-structure","Signature Structure",[300,397],"The signature used in the LocalAccount contract follows a specific structure: Signature Format:struct Signature {\n    bytes authenticatorData;\n    string clientDataJSON;\n    uint256 challengeLocation;\n    uint256 responseTypeLocation;\n    uint256 r;\n    uint256 s;\n}\nComponents:authenticatorData: Data from the authenticator device.clientDataJSON: JSON-encoded client data.challengeLocation: Offset of the challenge in clientDataJSON.responseTypeLocation: Offset of the response type in clientDataJSON.r, s: Signature components.",{"id":421,"title":362,"titles":422,"content":423,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#access-control-1",[300,397],"onlyOwner: Modifier restricting functions to the contract owner.Ownership Transfer: Ownership can be transferred to enable upgrades or burned to make the contract immutable.",{"id":425,"title":426,"titles":427,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#key-concepts","Key Concepts",[300],{"id":429,"title":430,"titles":431,"content":432,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#erc-4337-account-abstraction","ERC-4337 Account Abstraction",[300,426],"ERC-4337 introduces account abstraction, allowing smart contract accounts to manage their own authentication and transaction validation logic. The LocalAccount leverages this standard to provide flexible and secure account management.",{"id":434,"title":435,"titles":436,"content":437,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#p256-elliptic-curve-cryptography","P256 Elliptic Curve Cryptography",[300,426],"The contracts utilize the P256 elliptic curve for cryptographic operations, ensuring strong security guarantees. P256 is widely used in WebAuthn implementations, facilitating compatibility with modern authentication standards.",{"id":439,"title":440,"titles":441,"content":442,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#webauthn-integration","WebAuthn Integration",[300,426],"By integrating with WebAuthn, users can authenticate using hardware security modules, biometric sensors, or other secure methods without relying on traditional private keys or seed phrases.",{"id":444,"title":445,"titles":446,"content":161,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#additional-context","Additional Context",[300],{"id":448,"title":449,"titles":450,"content":451,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#gas-optimization","Gas Optimization",[300,445],"While smart contract-based signature verification is more gas-intensive than native precompiles, the LocalVerifier is optimized for efficiency: Strauss-Shamir Trick: Optimizes scalar multiplication in elliptic curve operations.Extended Jacobian Coordinates: Enhances efficiency in point addition and doubling.Progressive Precompiles: The design anticipates future EVM improvements, such as the proposed EIP-7212 precompile, which would significantly reduce gas costs.",{"id":453,"title":454,"titles":455,"content":456,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#future-enhancements","Future Enhancements",[300,445],"EIP-7212 Compatibility: The contracts are designed to be compatible with the proposed EIP-7212, allowing for potential gas cost reductions if the precompile is adopted.Key Rotation Replay Protection: Future versions may include cross-chain replay protection for key rotations.",{"id":458,"title":459,"titles":460,"content":461,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#references","References",[300],"EIP-4337: Account AbstractionEIP-7212: P256 Precompile ProposalWebAuthn SpecificationP256 Elliptic Curve DetailsWycheproof Test VectorsStrauss-Shamir TrickExtended Jacobian Coordinates",{"id":463,"title":179,"titles":464,"content":465,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fidentity#next-steps",[300],"That is all for identity. Next up, creating apps. html pre.shiki code .s5BVO, html code.shiki .s5BVO{--shiki-default:#F97583;--shiki-light:#CF222E}html pre.shiki code .sYIwp, html code.shiki .sYIwp{--shiki-default:#B392F0;--shiki-light:#8250DF}html pre.shiki code .sssk8, html code.shiki .sssk8{--shiki-default:#E1E4E8;--shiki-light:#1F2328}html pre.shiki code .sE5zC, html code.shiki .sE5zC{--shiki-default:#79B8FF;--shiki-light:#0550AE}html pre.shiki code .sdMFD, html code.shiki .sdMFD{--shiki-default:#FFAB70;--shiki-light:#953800}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html pre.shiki code .sPwVg, html code.shiki .sPwVg{--shiki-default:#B392F0;--shiki-light:#953800}",{"id":467,"title":468,"titles":469,"content":470,"level":9,"kind":10,"priority":9},"\u002Fdocs","Introduction",[],"Local Protocol unlocks decentralized applications that operate in uncertain, physical environments where service-proofs range from soft to hard. Blockchains use consensus algorithms and validity proofs to come to agreements on the state of digital transactions. However, most commercial transactions are not verifiable and still depend on trusted intermediaries. It is impossible, for example, for blockchains to reach consensus on the physical state of the world: the location of an entitythe completion of a servicethe condition of an asset The Local Blockchain is designed to unlock a new class of decentralized applications that can operate in these uncertain environments. Local introduces a graph-theoretic game that views proofs as probabilistic.",{"id":472,"title":473,"titles":474,"content":475,"level":16,"kind":10,"priority":9},"\u002Fdocs#who-should-use-local-protocol","Who should use Local Protocol",[468],"Local Protocol is for developers, businesses, and institutions seeking to build decentralized networks and is suitable for early-stage projects to large-scale networks. Local is uniquely suited to capture markets where strict, deterministic service-proofs are either not available, or are too expensive to produce. We view verifiability as a spectrum between soft proofs (probabilistic) and hard proofs (deterministic and cryptographically verifiable) and provide a path forward for applications along this spectrum to exist in a p2p and token-incentivized network. Below are some use cases that illustrate Local Protocol’s potential:",{"id":477,"title":478,"titles":479,"content":480,"level":16,"kind":10,"priority":9},"\u002Fdocs#who-is-this-documentation-for","Who is this documentation for",[468],"This documentation is for developers who wish to build services within the Local Proto ecosystem. It is structured to guide readers from basic to advanced concepts, providing practical examples and detailed explanations of how to use Local Protocol's features to build decentralized marketplace applications.",{"id":482,"title":483,"titles":484,"content":485,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping","Market Bootstrapping",[],"Market-relative teleport, endogenous and exogenous seeds, and per-market credit-line vaults that fund early rewards and repay from market fees. Market-relative diffusion avoids a core failure mode of “one global seed set”: fragmented-but-real markets. Early markets can also be sparse, so the protocol supports capital-backed bootstrapping without discretionary grants. This page defines: Market-relative teleport: a per-market, protocol-committed teleport distribution Endogenous market seeds: hard-to-fake “earned” anchors inside a marketMarket Anchors: capital-backed exogenous anchors that can seed markets earlyMarket Vaults: a per-market credit-line primitive that funds early rewards and gets repaid from future fees Think of diffusion as “trust spreading” through a market’s transaction history, but it needs a place to start. Seeds define that starting point. Market Vaults fund a market’s early incentive budget and are repaid from that market’s future fees if the market becomes real and active.",{"id":487,"title":488,"titles":489,"content":490,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#why-market-relative-teleport-exists","Why market-relative teleport exists",[483],"In marketplace networks, trust is often local to a market context: a courier can be highly trusted in one city\u002Fvertical even if the global network is fragmenteda new market can be economically real even if it’s weakly connected to global anchors If the protocol used one global seed set, naturally isolated markets would look “low influence” even when they are honest. To avoid that, diffusion (and claims derived from it) are evaluated relative to a market marketId = m, using the market’s committed teleport distribution . Teleport is the restart step in Personalized PageRank (PPR): with some probability, the walk jumps back to a protocol-defined distribution instead of following an edge. That restart distribution is what the protocol treats as its “trusted starting points”.See: Snapshot-Relative Diffusion. Personalized PageRank: Jeh & Widom, 2003Seed anchoring \u002F spam demotion (adjacent framing): TrustRank",{"id":492,"title":493,"titles":494,"content":495,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#per-market-seed-commitments-root-of-roots","Per-market seed commitments (root of roots)",[483],"Seeds are not user-chosen. The protocol commits to them each epoch so that claims and audits can be verified against a fixed reference. The chain commits to per-market seed tables via a root-of-roots: When verifying a claim in market , a verifier opens  from  and checks teleport sampling proofs against that market’s table. Without a commitment, a claimant could “move the goalposts” by choosing a convenient seed set that inflates their score. Committing seed tables makes market-relative diffusion reproducible: anyone can replay the same walk distribution for the same snapshot.",{"id":497,"title":498,"titles":499,"content":500,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#a-safety-tether-market-seeds-mixed-with-a-tiny-global-baseline","A safety tether: market seeds mixed with a tiny global baseline",[483],"Market-relative seeding fixes fragmented real clusters, but it introduces a risk: market capture (a cartel tries to become the market’s only “truth source”). To reduce capture risk without creating per-market governance, the teleport distribution can be defined as a fixed mixture:",{"id":502,"title":503,"titles":504,"content":505,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#recommended-seed-construction-rule-deterministic-low-governance","Recommended seed construction rule (deterministic, low-governance)",[483],"The protocol builds the market-local teleport mass  from a union of endogenous and exogenous anchors, then normalizes and clips.",{"id":507,"title":508,"titles":509,"content":510,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#_1-endogenous-anchors-earned-seeds-diversity-time-not-volume","1) Endogenous anchors (earned seeds): diversity + time, not volume",[483,503],"Let Window_t be the last  epochs (a global constant). A participant  is endo-eligible in market  iff: Verified(v)",{"id":512,"title":513,"titles":514,"content":515,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#_2-exogenous-anchors-market-anchors-concave-weight-from-locked-capital","2) Exogenous anchors (Market Anchors): concave weight from locked capital",[483,503],"Market Anchors are addresses that lock capital into the MarketVault for market  and opt into anchor status. Exogenous anchor weight is deliberately concave in capital:",{"id":517,"title":518,"titles":519,"content":520,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#_3-mixture-clipping","3) Mixture + clipping",[483,503],"Then apply a per-address cap (e.g., ) and renormalize.",{"id":522,"title":523,"titles":524,"content":525,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#market-vaults-a-startup-credit-line-primitive-for-a-market","Market Vaults: a “startup credit line” primitive for a market",[483],"Market Vaults are a mechanism for funding early incentives without ad-hoc grants. They work like a credit facility: capital is supplied up-front, and the market repays it with future fees if the market succeeds. Each market  can have a MarketVault contract that supports: Deposits (credit supply): anchors deposit capital into the vaultDraws (protocol borrows): the protocol can draw from the vault to fund early reward budgets under policy limitsRepayment (fees repay): as the market generates fees, a fixed share routes back to the vault until draws are repaid (plus a policy-defined yield to depositors) Credit delegation framing: Aave V3 Credit Delegation guidePolicy-driven liquidity facility (adjacent): Maker’s MIPs index (see D3M-style facilities): Maker MIPsBribing \u002F rent-to-control dynamics (adjacent risk surface): “Blockchain Bribing Attacks and Mitigations” (paper)",{"id":527,"title":528,"titles":529,"content":530,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#fee-attribution-is-ledger-defined","Fee attribution is ledger-defined",[483,523],"For a market  in epoch , define  as the realized protocol fee total attributed to market  during epoch . Mechanically,  is derived from finalized execution output: sum of fee over finalized InteractionRecords with marketId = m during epoch See: Market Registry",{"id":532,"title":533,"titles":534,"content":535,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#vault-invariants-mechanical-constraints","Vault invariants (mechanical constraints)",[483,523],"To avoid emissions-farming and rent-to-control dynamics, vault rules are mechanical and bounded. Common invariants include: Fee-first yield: yield is paid primarily from realized market fees.Draw limit: outstanding draws capped as a fraction of deposits: Risk haircut \u002F clawback: if dispute\u002Ffraud losses exceed thresholds, repayment\u002Fyield is haircutted under policy.Lockup for anchors: deposits that confer seed weight require a minimum lock duration.",{"id":537,"title":70,"titles":538,"content":539,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#related",[483],"Market RegistrySnapshot-Relative DiffusionGraph Commitments & Epoch SnapshotsOptimistic Diffusion Claims mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":541,"title":542,"titles":543,"content":544,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets","Markets",[],"Protocol-defined execution contexts with their own policy and accounting, derived from execution and verified against canonical registry state. Markets are protocol-defined execution contexts with their own policy and accounting. A market is not a user-chosen label; it is derived from what a transaction executed, and it is verified against canonical registry state. Markets also provide the protocol surface for bootstrapping: new markets can start sparse and fragmented yet still be scored and incentivized safely via market-relative teleport (seeds) and credit-like reward funding (MarketVaults) with repayment sourced from market fees.",{"id":546,"title":547,"titles":548,"content":549,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets#what-lives-here","What lives here",[542],"Market identity and enforcement: how a transaction’s market is derived from execution and verified against canonical registry state.Commitment hooks: how market tables and fee attribution are bound into epoch commitments.Bootstrapping and credit: how early markets can be seeded and funded, with repayment sourced from market fee cashflows.",{"id":551,"title":552,"titles":553,"content":554,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets#start-here","Start here",[542],"Market RegistryMarket Bootstrapping (Seeds + Vaults) Personalized PageRank (PPR): market-relative teleport is a protocol-fixed personalization distribution (Jeh & Widom, 2003).Seed-anchored filtering: anchoring trust to protocol-defined seeds is adjacent to ideas like TrustRank.Authenticated data \u002F commitments: MarketRegistry is made auditable by including it in snapshot artifacts bound by hash commitments (Merkle trees: Merkle, 1987).",{"id":556,"title":557,"titles":558,"content":559,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fregistry","Market Registry",[],"How a transaction’s market is derived from the executing MarketContext and canonicalized against the protocol MarketRegistry. Markets are defined as execution contexts. A transaction’s market is derived from the MarketContext contract\u002Frouter that emitted an InteractionRecord, not from user-provided metadata.",{"id":561,"title":562,"titles":563,"content":564,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fregistry#markets-are-derived-from-execution","Markets are derived from execution",[557],"MarketContext: an on-chain contract (or router) that emits canonical InteractionRecords for a commercial context.Market (m): a policy + accounting container bound to one MarketContext.marketId: a registry-assigned identifier derived from the executed MarketContext.",{"id":566,"title":567,"titles":568,"content":569,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fregistry#marketregistry-canonicalization","MarketRegistry (canonicalization)",[557],"The protocol maintains a canonical MarketRegistry: marketContext → (marketId, vault, feeRouter, flags) where: marketId: uint32: registry-assigned market identifier (unique; not user-chosen)vault: Address: MarketVault for this market (MAY be 0x0 if unused)feeRouter: Address: where protocol fees for this market are routedflags: uint32: e.g. ACTIVE \u002F DEPRECATED",{"id":571,"title":572,"titles":573,"content":574,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fregistry#interactionrecords","InteractionRecords",[557],"An InteractionRecord is emitted by a registered MarketContext during execution and is included in an SDL. Minimal sketch: marketId: uint32marketContext: Addressbuyer: Addressprovider: Addressamount: uint128fee: uint128edgeDelta and\u002For other protocol-defined graph\u002Fattribute deltasproofRefs: bytes32[]disputeRefs: bytes32[] (if applicable)",{"id":576,"title":577,"titles":578,"content":579,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fregistry#validity-rule-critical","Validity rule (critical)",[557,572],"An interaction record (and any resulting commerce edges) is valid only if: MarketRegistry[marketContext].marketId == marketId at that block heightthe market is ACTIVE The security-critical requirement is that users cannot choose a favorable market label. By deriving marketId from the executed marketContext via a canonical registry mapping, market-scoped caps, seeds, and accounting can be enforced deterministically. Authenticated commitments: binding MarketRegistry into a snapshot artifact so verifiers can check market attribution via short openings is a standard authenticated-data pattern (Merkle trees: Merkle, 1987).",{"id":581,"title":70,"titles":582,"content":583,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmarkets\u002Fregistry#related",[557],"Market BootstrappingGraph Commitments & Epoch Snapshots html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}",{"id":585,"title":586,"titles":587,"content":588,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fmore-resources","More Resources",[],"Lightweight supporting material for the Local Protocol documentation, including quick-reference pages and navigation aids. This section contains lightweight supporting material for the Local Protocol documentation, such as quick-reference pages and navigation aids.",{"id":590,"title":179,"titles":591,"content":592,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fmore-resources#next-steps",[586],"Read the whitepaper — the original Local Protocol whitepaper.Browse the code on GitHub — protocol implementations and tooling.",{"id":594,"title":595,"titles":596,"content":597,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fidentity-proofs","Identity Proofs as Node Attributes",[],"How identity proofs are committed as node attributes to boost trustworthiness, Sybil resistance, and incentives. Examples of identity proofs include: World IDzkPassportOpacity Network, or other zkTLS authentication with a relevant Web2 provider These proofs increase a node’s trustworthiness, which can translate into higher rewards and better economic terms. They enhance Sybil resistance by allowing the protocol to anchor diffusion in verified participants. See: Sybil Resistance and Snapshot-Relative Diffusion. These proofs can be assigned a score that unlocks a larger block rewards for both this node and any transacting counterparties. Specifically, we boost nodes that have evidence of realness because it provides the network with stronger sybil resistance.",{"id":599,"title":600,"titles":601,"content":602,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fidentity-proofs#how-identity-proofs-affect-diffusion-and-incentives","How identity proofs affect diffusion and incentives",[595],"In Local Protocol, identity proofs are committed as node attributes (via snapshot commitments) and can influence the system in protocol-defined ways: See: Graph Commitments & Epoch Snapshots. Teleport \u002F seed mass: identity-verified nodes can be included in the protocol-defined, market-relative teleport distribution , or receive higher  weights.Policy gating: identity attributes can raise per-tx caps, lower required bonds, or relax verification requirements (or the opposite), depending on market maturity and fraud risk. This framing keeps diffusion snapshot-relative (defined on committed roots) while allowing markets to bootstrap trust without hard proofs on every transaction.",{"id":604,"title":179,"titles":605,"content":606,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fidentity-proofs#next-steps",[595],"Next: Service Proofs, which strengthen the reliability of individual transactions in the network. mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":608,"title":609,"titles":610,"content":611,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs","Proofs in Local Protocol",[],"How Local Protocol treats verifiability as a spectrum and uses identity and service proofs as graph attributes to bootstrap trust. Local Protocol targets decentralized physical infrastructure networks (DePINs) where many valuable services lack cheap, deterministic proofs. The protocol treats verifiability as a spectrum and provides mechanisms that remain secure even when only probabilistic evidence is available. Our approach acknowledges a spectrum of verifiability and provides a path forward for networks that may not have access to hard or cost-effective service proofs. Local Protocol is an expressive architecture whose approach to verifiability is adaptable to a wide range of DePIN projects. In the root case, the protocol assumes that services do not have access to robust service-proofs.",{"id":613,"title":614,"titles":615,"content":616,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs#spectrum-of-verifiability","Spectrum of Verifiability",[609],"Verifiability is a spectrum between: Hard proofs: deterministic, cryptographically verifiable evidence (e.g., cryptographic attestations, signatures tied to objective system events).Soft proofs: probabilistic evidence (e.g., location signals, sensor readings, human attestations, reputation signals) that can be informative but not perfectly binding. Local Protocol is designed so soft proofs can still be useful without becoming a free attack surface: they feed into bounded weights, market-relative seeds, and claim verification (caps + audits + slashing).",{"id":618,"title":619,"titles":620,"content":621,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs#proofs-as-graph-attributes","Proofs as Graph Attributes",[609],"In graph theory, a node is a point representing an entity (buyer, seller), and an edge is a connection between two nodes (transactions). In Local protocol, we model identity-proofs (and other trust attributes for users) as node attributes and service-proofs as edge attributes. See: The Transaction Graph and Graph Commitments & Epoch Snapshots. Proofs are ledger facts attached to nodes\u002Fedges. The protocol consumes them in a few specific places (seed construction, edge-weight adjustment, risk\u002Fcap policy), and their effect propagates through the graph via snapshot-relative diffusion. You can think of both identity and service proofs as injecting trust into the network. As the network becomes more trustworthy, the protocol becomes more confident in distributing rewards that are greater than the fees collected for each transaction. This unlocks a rich surface area for capital formation to bootstrap new markets. New markets can inherit the security from existing markets providing the network with a strong cross-market network effect. For immature markets that want to prioritize bootstrapping trust, proofs can concentrate influence through the protocol-defined, market-relative teleport distribution  and through edge-weight adjustments (see Snapshot-Relative Diffusion and Market Bootstrapping). As the market matures, reliance on expensive proofs can be reduced via policy caps, decay schedules, and lower proof multipliers.",{"id":623,"title":624,"titles":625,"content":626,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs#trust-propagation-under-diffusion","Trust propagation under diffusion",[609,619],"Under snapshot-relative diffusion, proofs influence the walk in two protocol-defined ways: Seed mass (teleport) updates: stronger proofs can increase  (in market context ) or seed eligibility.Edge weight adjustments: service proofs\u002Fdisputes change proof_factor and quality in edge weights. See: Service Proofs and Dispute Resolution & Collateral. The effect naturally diminishes over distance: in a restarted random walk, influence along length- paths is damped by roughly .",{"id":628,"title":629,"titles":630,"content":631,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs#probabilistic-evidence-and-confidence","Probabilistic evidence and confidence",[609],"Many proofs are not binary. Local Protocol treats these as confidence-weighted signals and uses them only through protocol-defined, bounded interfaces. See: Proofs as Probabilities",{"id":633,"title":634,"titles":635,"content":636,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs#proof-attachments-in-state-diff-lists-sdls","Proof attachments in State Diff Lists (SDLs)",[609],"Proofs are committed to the canonical ledger as part of execution outputs. Concretely, proofs can be included as proof attachments inside a State Diff List (SDL)—the compact, verifiable bundle of ledger mutations that is produced by execution and finalized by the protocol. See State Model for the definition of SDLs and how they compose into a single canonical state.",{"id":638,"title":179,"titles":639,"content":640,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs#next-steps",[609],"Proofs OverviewIdentity ProofsService ProofsProofs as ProbabilitiesLocation Proofs mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":642,"title":643,"titles":644,"content":645,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Flocation-proofs","Location Proofs",[],"How probabilistic location signals are modeled as soft service proofs and combined with caps and slashing to bootstrap markets.",{"id":647,"title":648,"titles":649,"content":650,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#the-problem","The problem",[643],"Many physical services don’t have cheap, deterministic proofs. For example, “a driver arrived at the right doorstep” is hard to prove cryptographically at low cost. If every transaction required high-quality proofs, proof generation could break the unit economics of the underlying service.",{"id":652,"title":653,"titles":654,"content":655,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#proof-of-location-as-a-soft-proof","Proof-of-location as a soft proof",[643],"Location signals (GPS, cell triangulation, Wi-Fi, attestations) are often probabilistic. In Local Protocol, these are modeled as edge attributes (service proofs) that affect the transaction graph through: : higher confidence → higher effective edge weight: disputes\u002Fchargebacks → lower effective edge weight These adjustments feed into snapshot-relative diffusion on the committed graph snapshot.",{"id":657,"title":658,"titles":659,"content":660,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#why-this-helps-immature-markets","Why this helps immature markets",[643],"In small markets, collusion remains possible even with strong evidence. The protocol therefore combines proofs with: anchored diffusion (teleport mass from verified seeds)strict caps on claimable rewardschallengeable claims with bonds + slashing This allows bootstrapping while keeping dishonest inflation negative expected value.",{"id":662,"title":70,"titles":663,"content":664,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#related",[643],"Service ProofsSnapshot-Relative DiffusionOptimistic Diffusion Claims mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":666,"title":667,"titles":668,"content":669,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Foverview","Proofs Overview",[],"Proofs are committed as ledger facts and consumed as graph attributes for identity and service outcomes. Proofs are committed as ledger facts and consumed as graph attributes (node attributes for identity, edge attributes for service outcomes). See: Proofs in Local Protocol",{"id":671,"title":179,"titles":672,"content":673,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Foverview#next-steps",[667],"Identity ProofsService ProofsProofs as ProbabilitiesLocation Proofs",{"id":675,"title":676,"titles":677,"content":678,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fprobabilities","Proofs as Probabilities",[],"How Local Protocol models non-deterministic proofs as confidence-weighted evidence consumed through bounded interfaces. Many proofs are not deterministic. Location signals, sensor readings, and human attestations are often best modeled as probabilistic evidence with a confidence score. Local Protocol uses these signals only through protocol-defined, bounded interfaces so they can improve incentives without becoming an unbounded attack surface. See: Proofs in Local Protocol",{"id":680,"title":681,"titles":682,"content":683,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fprobabilities#confidence-weighted-evidence","Confidence-weighted evidence",[676],"Model a proof attachment as evidence with confidence , where  means “strong evidence” and  means “no evidence”. The protocol does not need to agree on a universal meaning of . It only requires: a deterministic rule for how  affects ledger-level policy inputs (weights, seed eligibility\u002Fweight, caps\u002Fbonds),and objective verification hooks where possible (e.g., by sampling proofs in audits or requiring stronger bonds for high-impact claims).",{"id":685,"title":686,"titles":687,"content":688,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fprobabilities#how-probabilistic-proofs-affect-the-graph","How probabilistic proofs affect the graph",[676],"Probabilistic proofs are consumed in two primary places: Edge weights (service proofs): adjust proof_factor (and sometimes quality) in: Seed mass (identity\u002Fservice baselines): affect seed eligibility and\u002For seed weight in the market-relative teleport distribution  used by diffusion. Because diffusion follows outgoing edges proportional to weights and restarts from , confidence-weighted evidence influences incentives by changing where influence can flow.",{"id":690,"title":691,"titles":692,"content":693,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fprobabilities#dampening-over-distance-and-time","Dampening over distance and time",[676],"Even strong evidence should not create permanent or global privilege. Distance dampening: in a restarted random walk, influence along length- paths is damped by roughly .Time decay: implementations can apply deterministic decay schedules to proof-derived boosts (edge-weight multipliers and\u002For seed weights) so old evidence fades unless refreshed.",{"id":695,"title":696,"titles":697,"content":698,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fprobabilities#practical-guidance-protocol-level","Practical guidance (protocol-level)",[676],"Bounded impact: clamp proof-derived multipliers and seed weights (caps prevent “proof = unlimited reward”).Risk coupling: require stronger bonds for claims that rely heavily on proof multipliers, and reduce future capacity via penalties when audits fail.Market-relative context: evaluate proof effects within a market context; bootstrapping mechanisms (seeds + vaults) can vary across markets while keeping the algorithm fixed. See: Market Bootstrapping",{"id":700,"title":179,"titles":701,"content":702,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fprobabilities#next-steps",[676],"Next, see an example of probabilistic evidence in action: Location Proofs mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":704,"title":705,"titles":706,"content":707,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fservice-proofs","Service Proofs as Edge Attributes",[],"How service proofs verify completed transactions and feed into edge weights through proof_factor and quality. Service proofs verify that a transaction has been successfully completed between a buyer and a provider. In the Local Protocol, these proofs can take the form of pin exchanges, location proofs, or other evidence of service completion. Service proofs enhance the reliability of the transaction graph, ensuring that rewards are allocated for users performing real transactions and not fake transactions. When available, service proofs can be integrated into the graph value calculation, increasing the weight of the corresponding edge for the transaction, making it more valuable to the network.",{"id":709,"title":710,"titles":711,"content":712,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fservice-proofs#how-service-proofs-affect-diffusion-and-incentives","How service proofs affect diffusion and incentives",[705],"Each directed edge  can have a weight: Service proofs primarily affect: : stronger evidence of completion increases the effective edge weight.: dispute outcomes, refunds, or chargebacks can decrease the effective weight. Because diffusion follows outgoing edges proportional to weights, increasing  (or ) increases how much trust\u002Finfluence can flow through that interaction in snapshot-relative diffusion.",{"id":714,"title":426,"titles":715,"content":716,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fservice-proofs#key-concepts",[705],"Transaction Verification: Confirms that services have been provided as agreed.Graph Integration: Boosts graph value, aligning rewards with verifiable transactions.",{"id":718,"title":179,"titles":719,"content":720,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fproofs\u002Fservice-proofs#next-steps",[705],"Next, see how the protocol models confidence-weighted evidence: Proofs as Probabilities mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":722,"title":723,"titles":724,"content":725,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value","Graph Value",[],"The protocol's epoch-based economic evaluation surface aggregating ledger facts and diffusion influence to drive incentives. Graph Value is the protocol’s epoch-based “economic evaluation surface.” It aggregates ledger facts (executed activity) and snapshot-relative interpretations (diffusion influence) to drive incentives.",{"id":727,"title":728,"titles":729,"content":730,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#introduction-to-graph-value","Introduction to Graph Value",[723],"In Local Protocol, Graph Value measures both economic activity and network influence for each participant, but it updates once per epoch (not continuously per transaction). Diffusion influence is defined over the committed snapshot for that epoch and can be consumed through bounded claims.",{"id":732,"title":305,"titles":733,"content":734,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#components",[723],"For participant  during epoch : : transaction volume (ledger fact; aggregated from executed edges): diffusion influence on snapshot  in market context  (snapshot-relative; not a ledger fact): reputation score (disputes, proofs, completion history)",{"id":736,"title":737,"titles":738,"content":739,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#epoch-update-rule","Epoch update rule",[723],"Graph Value is updated once per epoch: Where: is a smoothing factor are policy weightsnorm denotes protocol-defined normalization and clipping",{"id":741,"title":742,"titles":743,"content":744,"level":52,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#how-is-consumed","How  is consumed",[723,737],"The protocol consumes diffusion through accepted optimistic claims and bounded epoch-level accounting: diffusion appears in the system through accepted optimistic claims and bounded epoch-level accountinglarge or high-impact claims can be subjected to stronger sampling and higher bonds",{"id":746,"title":747,"titles":748,"content":749,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#per-transaction-reward-claim-sketch","Per-transaction reward claim (sketch)",[723],"For a transaction  with amount , define a base reward: and a diffusion-based multiplier: Then the user-claimed reward is: Where  and  are Monte Carlo estimators of market-relative diffusion scores on the committed snapshot. The estimator is protocol-defined and must be transcript-verifiable.",{"id":751,"title":70,"titles":752,"content":753,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#related",[723],"Snapshot-Relative DiffusionOptimistic Diffusion Claims mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":755,"title":756,"titles":757,"content":758,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity","Security in Local Protocol",[],"How Local Protocol achieves security through graph structure and cryptoeconomic incentives. Security within Local Protocol is achieved through a combination of graph structure and cryptoeconomic incentives: diffusion influence is anchored in protocol-defined verified seeds (Sybil isolation),diffusion-derived outputs are bounded and fraud-proofable (optimistic verification),dishonesty is deterred with bonds + slashing under canonical randomness. Local Protocol also accounts for incentive-system manipulation surfaces: rent-to-control market relevance: if influence or market budgets can be cheaply rented (via bribery\u002Fvote-buying or short-lived capital), actors may rationally purchase control rather than build real commerce. Mitigations include market caps, per-address seed caps, concave capital weighting, anchor lockups, delayed sampling, and mandatory audits with slashable attestations. See: Markets.",{"id":760,"title":179,"titles":761,"content":762,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity#next-steps",[756],"If you haven’t read the core model yet: Snapshot-Relative DiffusionGraph Commitments & Epoch SnapshotsOptimistic Diffusion Claims Then continue here: Graph ValueSybil Resistance",{"id":764,"title":765,"titles":766,"content":767,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Foverview","Security Overview",[],"Introduction to Local Protocol's security model, rooted in graph structure and cryptoeconomic incentives. Local Protocol’s security model is rooted in graph structure and cryptoeconomic incentives. This section introduces the core mechanisms and how they fit together.",{"id":769,"title":179,"titles":770,"content":771,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Foverview#next-steps",[765],"Graph ValueSybil Resistance",{"id":773,"title":774,"titles":775,"content":776,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance","Sybil Resistance",[],"How Local Protocol prevents fake-identity manipulation via snapshot-relative diffusion anchored in a verified teleport set. Sybil resistance is a core security goal: prevent an attacker from creating many fake identities to manipulate incentives. Local Protocol achieves this primarily through snapshot-relative diffusion anchored in a protocol-defined verified teleport set, and by constraining diffusion-derived rewards through bounded, challengeable claims.",{"id":778,"title":426,"titles":779,"content":780,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance#key-concepts",[774],"Anchored influence (market-relative): diffusion restarts from a protocol-defined, per-market teleport distribution  supported on verified anchors for market . Weakly connected Sybil regions receive little mass within that market context.Connectivity over volume: fake transactions tend to remain within the attacker’s region; without strong attachment to verified anchors, they don’t buy meaningful influence.Economic deterrence: diffusion-derived rewards are claimed under caps and can be challenged; dishonest inflation is deterred via bonds and slashing.",{"id":782,"title":179,"titles":783,"content":784,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance#next-steps",[774],"Snapshot-Relative DiffusionOptimistic Diffusion ClaimsArchitecture Overview mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":786,"title":787,"titles":788,"content":789,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust","Trust in Local Protocol",[],"An overview of how Local Protocol replaces intermediary trust with a crypto-economic game that propagates trust through local graphs. Local Protocol unlocks a new design space where peers across a variety of commercial settings can transact without the need to pay an intermediary. The network uses a crypto-economic game that replaces the trust one would otherwise place in an intermediary. Users are incentivized to complete transactions with a large number of counter-parties to maximize their block reward in their next transaction. The protocol propagates trust assumptions through local graphs where the strength of the trust assumptions diminish over longer paths from trusted centers. This mechanism creates a scalable network where self-interested actors participate in a complex multi-agent process to create the network's security guarantee.",{"id":791,"title":179,"titles":792,"content":793,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust#next-steps",[787],"In the following sections, we will explore how trust assumptions work, how trust propagates through networks, and how malicious actors can be slashed for failing to provide proofs in networks where proofs are expected.",{"id":795,"title":796,"titles":797,"content":798,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Foverview","Trust Overview",[],"Trust in Local Protocol is derived from transaction history and graph connectivity, with mechanisms to propagate and penalize trust assumptions over time. Trust in Local Protocol is derived from transaction history and graph connectivity, with mechanisms to propagate (and penalize) trust assumptions over time.",{"id":800,"title":179,"titles":801,"content":802,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Foverview#next-steps",[796],"Trust PropagationSampling & SlashingSelf-Policing",{"id":804,"title":805,"titles":806,"content":807,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fpropagation","Trust Propagation",[],"How trust spreads across the Local Protocol network based on transaction history and graph connectivity, diminishing over longer paths from trusted sources. Trust propagation in the Local Protocol allows trust to spread across the network based on transaction history and graph connectivity. The concept ensures that trust diminishes gradually as it travels further from a trusted source node, enabling the protocol to assess participant reliability over time. This mechanism helps the network establish broader trust networks, making it harder for malicious actors to gain undue influence without genuine connectivity. See: The Transaction Graph and Snapshot-Relative Diffusion.",{"id":809,"title":426,"titles":810,"content":811,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fpropagation#key-concepts",[805],"Decaying Trust: Trust assumptions weaken over longer paths from the source.Network-Wide Impact: Trust spreads through the transaction graph, enhancing overall reliability.",{"id":813,"title":814,"titles":815,"content":816,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fpropagation#trust-under-snapshot-relative-diffusion","Trust under snapshot-relative diffusion",[805],"Under diffusion, proofs inject trust in protocol-defined ways: Seed mass (teleport) updates: proofs can increase  (or inclusion in the seed set) for verified identities\u002Fdomains, in market context .Edge weight adjustments: service proofs and dispute outcomes modify edge weights via proof_factor and quality. See: Service Proofs and Dispute Resolution & Collateral. The effect of a proof naturally diminishes with path length: in a restarted random walk, influence along length- paths is damped by roughly . You can visualize the network as a series of concentric circles centered around the node or edge that incorporated a proof. The nodes directly connected form the first circle; these are the immediate neighbors who have direct interactions with the proof-bearing node or transaction. The second circle consists of nodes connected to those immediate neighbors, which are two steps away, and so on. The influence of the proof is strongest at the center and decreases as you move outward. Nodes that transact with those who submit strong proofs benefit more than they would have otherwise. This produces positive security externalities: when self-interested actors invest in verifiability, the network becomes more trustworthy and rewards become more robust.",{"id":818,"title":179,"titles":819,"content":820,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fpropagation#next-steps",[805],"In the next section, we will examine Sampling & Slashing, the mechanism used to verify bounded claims and penalize dishonest behavior. mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":822,"title":823,"titles":824,"content":825,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing","Sampling & Slashing",[],"How Local Protocol verifies diffusion-derived economic outputs through sampling and deters dishonesty through bond slashing. Local Protocol verifies diffusion-derived economic outputs through sampling and deters dishonesty through slashing. Participants submit bounded, optimistic claims with transcripts; verifiers check sampled openings against committed snapshot roots.",{"id":827,"title":426,"titles":828,"content":829,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#key-concepts",[823],"Probabilistic verification: only a bounded number of transcript walks are checked.Canonical randomness: removes prover choice (prevents grinding).Penalization: invalid openings cause bond slashing and claim rejection. In high-volume markets, audits are treated as an obligated validator duty (not a volunteer challenger market) to avoid audit starvation and free-riding.See: Validator Audits & Penalties",{"id":831,"title":832,"titles":833,"content":834,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#canonical-randomness-and-delayed-sampling","Canonical randomness and delayed sampling",[823],"For a transaction id txid in epoch , the prover’s transcript randomness is derived from . Sampling indices used for challenges are derived from future randomness (e.g., ) so the prover cannot adaptively craft transcripts that only satisfy the checked parts.",{"id":836,"title":837,"titles":838,"content":839,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#what-gets-slashed","What gets slashed",[823],"Claims include a bond . If any sampled transcript opening fails verification, the protocol: rejects or reverts the claim outputslashes the bond  (and any additional penalties defined by policy) This makes dishonest inflation negative expected value under appropriate parameter selection.",{"id":841,"title":842,"titles":843,"content":844,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#where-the-details-live","Where the details live",[823],"The precise transcript format and verifier checks are defined by the claim protocol: Optimistic Diffusion ClaimsGraph Commitments & Epoch Snapshots",{"id":846,"title":179,"titles":847,"content":848,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#next-steps",[823],"The next topic, Self-Policing, will explore how these incentives shape counterparty selection and discourage transacting with dishonest regions. mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":850,"title":851,"titles":852,"content":853,"level":9,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fself-policing","A Self-Policing Network",[],"How incentive alignment leads participants to avoid dishonest regions of the graph, creating a self-policing network. Participants prefer to transact with counterparties that are well connected to verified regions of the graph, because doing so increases their expected future rewards and reduces the risk of interacting with dishonest claimants. The crucial point is incentive alignment: transacting with dishonest regions tends to reduce your expected payouts (via reputation, dispute outcomes, and heightened verification\u002Fbond requirements), creating a self-policing network.",{"id":855,"title":856,"titles":857,"content":858,"level":16,"kind":10,"priority":9},"\u002Fdocs\u002Ftrust\u002Fself-policing#why-this-emerges-under-optimistic-claims","Why this emerges under optimistic claims",[851],"Under optimistic diffusion claims: dishonest inflation can be challenged and punished via bond slashingdisputed or low-quality interactions reduce edge weights () and future eligibilitypolicies can require higher bonds or stricter sampling for higher-risk regions As a consequence, honest users learn to avoid transacting with nodes that are weakly connected to verified anchors or that frequently trigger disputes\u002Fchallenges. This creates a self-reinforcing dynamic where honest regions deepen connectivity, while dishonest regions remain isolated and unprofitable. The self-policing nature of the network not only maintains security but also reduces the costs associated with identifying malicious actors. The possibility of being challenged (and losing a bond) discourages dishonest behavior, while honest behavior compounds through connectivity and reputation. mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":860,"title":861,"titles":862,"content":863,"level":9,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank","PageRank and Token Design",[],"Applying PageRank's eigenvector-centrality principles to token distribution — modeling commercial networks as bipartite graphs that align incentives with network growth. In this post, I propose a novel token design strategy that draws inspiration from one of the most successful algorithms in the history of the internet: PageRank. PageRank is an Eigenvector-based algorithm that focuses on centrality which is a fundamental measure in network theory that quantifies the importance or influence of a node within a network. Eigenvector-based algorithms are well-suited to capture the quality and impact of a node's position in a network's topology, and are therefore a great method to distribute tokens in complex networks.","Blog",{"id":866,"title":867,"titles":868,"content":869,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#intro-to-pagerank","Intro to PageRank",[861],"At its core, PageRank revolutionized the way we navigate the web by recognizing that not all links are created equal. A link from a highly influential page carries more weight than one from an obscure corner of the internet. This insight led to a recursive evaluation of importance, creating a robust ranking system that serves as the engine to perhaps the best business model in the last half-century. This same principle – the notion of recursive influence – holds the key to designing optimal token distributions in complex cryptonetworks. By using centrality ranks as a foundation for token allocations, we can create a dynamical, self-optimizing network that: Naturally aligns incentives with network growthResists manipulation and Sybil attacksDynamically adapts to evolving market conditionsImplicitly reward behaviors that strengthen network effects",{"id":871,"title":872,"titles":873,"content":874,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#the-basic-idea","The Basic Idea",[861],"Any commercial network can be modeled as a bipartite graph that captures the economic relationships between producers and buyers, with edge weights signifying the historical transactions between the two nodes. By modeling the network as a graph, we can design an economic system that dynamically adjusts token incentives based on the revealed preferences and pricing power of the participants. The token rewards can be determined using a modified eigenvector centrality measure, which takes into account both the revenue generated by each node and its centrality in the network. This technique quantifies an individual node's contribution to the current state of the network, considering its economic impact and its role in facilitating transactions between other nodes. The network can leverage the graph's structural properties to implement a token allocation mechanism that optimizes the distribution of rewards based on the temporal and economic characteristics of the transacting agents in the multi-sided market. A simple definition of the graph can be  representing producers  and buyers  as nodes, with weighted edges  capturing transactions between them. Edge weights  track the producer's  transactions with the buyer . With this graph we can optimize against a universal objective function: maximizing total number of transactionsmaximizing total fees transactedmaximizing connectivity of the entire network This single model contains the following properties: The network naturally evolves towards optimal structures for value creationEarly adopters and key contributors are rewarded proportional to their influence in sub-networksThe system becomes increasingly resistant to manipulation as it growsProvides the ability to propagate trust and reputationThe network can naturally adapt to optimize rewards across various stages of network maturityThe split between supply and demand can self-optimize as the network learns the pricing power of the transacting parties",{"id":876,"title":877,"titles":878,"content":879,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#beyond-simple-incentives","Beyond Simple Incentives",[861],"Traditional approaches to token design might allocate tokens based on transaction volume, geography, predefined roles within a network, referrals etc. While these methods do drive certain behaviors, they fall short in maximally aligning incentives within a complex, interconnected network. Centrality-based designs unlock a more nuanced, precise, and adaptive approach - recognizing that value in a network is not about individual actions, but a web of relationships and influence.",{"id":881,"title":882,"titles":883,"content":884,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#network-maturity-and-early-adopter-rewards","Network Maturity and Early Adopter Rewards",[861,877],"Many DePINs mint tokens based on a simple exponential decay model. Mining block rewards generates a large number of tokens per unit of work early as a bootstrapping incentive. Over time, rewards rapidly decrease. This design has been successful at bootstrapping supply but today's DePIN's have a huge demand problem, leading to imbalanced services, potential token supply issues, and ultimately supply-side churn due to diminishing returns as the network matures. By modeling a network as a graph, we can design incentives that are adaptive and dynamical such that we maximize the overall utility to all users across the network's adoption lifecycle. Token rewards can scale gracefully based on the state of the graph and can be recursively re-balanced with consumer demand, creating a system that successfully bootstraps the network without creating undue harm to the treasury or future earning potential of suppliers. By optimizing for connectivity in immature markets, EC maintains a healthy balance between growing supply and demand. A distribution mechanism can look like this: where the value created from a net new transaction creates a block reward that can be redistributed to any number of currently active nodes on either the demand or supply side of the network, depending on the economic properties of this graph.",{"id":886,"title":887,"titles":888,"content":889,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#sybil-resistance-verifiability-and-security","Sybil Resistance, Verifiability, and Security",[861,877],"As a network matures, connectivity becomes increasingly difficult and expensive to manufacture, making eigenvector-centrality an effective sybil resistance mechanism. Producers aiming to increase their influence must generate real transactions with genuine buyers who also interact with other producers. If PageRank views centrality as a measure of recursive influence, we can view it as a measure of recursive trust.",{"id":891,"title":892,"titles":893,"content":894,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#the-island-effect","The Island Effect",[861,877,887],"When a malicious actor attempts to create fake transactions, they form isolated clusters or \"islands\" within the network. \"Islands\" have limited connectivity to the rest of the network and are expensive to create. Legitimate users are unlikely to engage with them. Consequently, malicious nodes exhibit low EC scores, as they lack the strong, organic connections to the rest of the network. This island effect makes it difficult for attackers to artificially inflate their influence or rewards, as EC inherently favors nodes with high-quality, real connections.",{"id":896,"title":897,"titles":898,"content":899,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#propagation-of-trust","Propagation of Trust",[861,877,887],"In the absence of robust service-proofs to verify the legitimacy of transactions, a network becomes vulnerable to various game-theoretic challenges, including self-dealing and collusion risks. As we explored the design space for real-world service-proofs, we identified a number of possible verification strategies for last-mile delivery networks. Specifically, a combination of location-proofs, randomized pin exchanges with drivers, and random driver assignment together provide a robust proof-of-delivery mechanism for the current state of delivery networks. This double-blind system ensures that neither the provider nor the customer can confidently predict or influence the matching process. If the provider and customer are known to be unique, cannot systematically predict the assignment of the third colluding party, and all three parties require cooperation to submit a valid service-proof then there is extremely low collusion risk in mature markets. However, even in the case of mobile food ordering, the majority of all orders are still pick up orders. Pick-up orders and in-store dining are much more difficult to verify. Because restaurants do not sell a commodity, provider assignment cannot be randomized. This makes it easy for a set of two cooperating attackers to collude and earn a block reward without doing the work required to justify the reward (in this case producing the food for the buyer). We could use a similar location-proof to verify that both parties are in the same location at the time of the transaction, but even if the customer is in the store of the restaurant, it is impossible to have a robust proof-of-work mechanism that verifies (with high confidence) that the service was performed.",{"id":901,"title":902,"titles":903,"content":904,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#a-spectrum-of-verifiability","A Spectrum of Verifiability",[861,877,887],"As described above, in the context of a peer-to-peer restaurant food delivery network, there are varying levels of verifiability across the two primary supported transaction types (pickup and delivery). This spectrum of verifiability presents a significant hurdle for the mass adoption of decentralized physical infrastructure services. Typical work-arounds either require a trusted third-party, expensive service proofs, or strict permissions \u002F registration to participate. These restrictions are all limitations that limit the design space available to build truly robust, sustainable, and decentralized networks at a global scale. Quadrant I: Easy to Create (weak-guarantee) and Cheap\nSimple randomized pin exchanges: Users and drivers exchange simple PINs to verify or mutually attest to service completion. Quadrant II: Easy to Create (weak-guarantee) and Expensive\nBasic location sharing: Sharing the user's location through GPS, which can be easily manipulated but is straightforward to implement. Quadrant III: Hard to Create (strong-guarantee) and Cheap\nOn-chain Reputation-based systems: take a long time to develop but can be cheap and robust at scale. Quadrant IV: Hard to Create (strong-guarantee) and Expensive\nAdvanced location proofs: ZkTLS with cell tower or trusted hardware. Either computationally expensive or requires hardware. Networks trying to bootstrap adoption often face challenges when relying on verification methods that fall into Quadrant IV (Hard to Create and Expensive). These methods, while robust, can hinder growth due to their complexity and cost. Conversely, using methods from Quadrant I (Easy to Create and Cheap) may lead to increased vulnerability to attacks such as self-dealing and collusion. Eigenvector Centrality (EC) rankings can help mitigate issues in each of these networks by propagating trust assumptions through the graph. In networks with weak or expensive service proofs, EC rankings become particularly valuable. The underlying assumption is that collusion becomes increasingly difficult as the number of colluding nodes increases. For networks bootstrapping trust, EC rankings can help establish trust vectors for nodes through a combination of service proofs and identity sampling. As the network grows and trust is established, the reliance on expensive service-proofs can be gradually reduced with a dampening factor over time. By leveraging EC rankings, networks can strike a balance between security and costs depending on their needs. As trust propagates through the network, the need for expensive and complex verification methods decreases, enabling the network to scale more efficiently without compromising security.",{"id":906,"title":907,"titles":908,"content":909,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#sampling-trust","Sampling Trust",[861,877,887],"To ensure that the graph doesn't lose its security guarantees as new nodes enter the game, the network can randomly sample for service-proofs or service-approximations if proofs aren't available. If a node fails to provide their proofs, the network can slash the edge weights (tokens staked in the graph), along with those of their neighboring nodes. This localized penalty system encourages self-policing and reinforces the importance of maintaining genuine connections with real users. By creating a verification system that can adapt to the specific requirements and constraints of different DePIN projects, network designers can expand the range of services that can be decentralized. This approach acknowledges a spectrum of verifiability and provides a path forward for networks that may not have access to hard or cost-effective service proofs.",{"id":911,"title":912,"titles":913,"content":914,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#difficulty-in-manufacturing-connectivity","Difficulty in Manufacturing Connectivity",[861,877,887],"Achieving a high EC score requires not only a large number of connections but also connections to other well-connected nodes. This property makes it challenging for malicious actors to manufacture high connectivity rankings, as they would need to establish links with reputable, central nodes in the network. Legitimate, highly-connected nodes are more likely to scrutinize and avoid suspicious or low-quality nodes. As a result, attackers face significant hurdles to manipulate their EC scores. In this example, the block rewards produced from legitimate actors are reinforcing. Malicious actors are losing fees per transaction and shuffling around rewards to themselves, making self-dealing unprofitable. As the network expands, the computational cost and effort required to manipulate EC scores increases. Attackers would need to establish an ever-growing number of connections to keep pace with the network's organic growth, making it impractical and resource-intensive to maintain a significant influence to earn large rewards - making the entire network increasingly robust to attacks over time.",{"id":916,"title":917,"titles":918,"content":919,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#generalizing-to-various-networks","Generalizing to Various Networks",[861,877],"Adjustable fees allow markets to self-optimize token distributions across various commercial contexts. Nodes in the network can fine-tune to dynamically align incentives, eliminating the need for network designers to make naive assumptions about the unpredictable behavior of participants in different economic settings. Optimal token distributions are \"discovered\" based on the pricing power of producers in different sub-networks. This adaptive mechanism ensures that tokens are allocated in a way that reflects the true value of services provided, fostering a competitive and balanced network that reaches a comfortable equilibrium as the network matures. In markets with unique, high-demand producers, most of the reward for a given transaction is likely to accrue to the producer. Conversely, in markets where producers sell goods with many substitutes, the reward will be distributed in favor of the buyer (the producer will use their rewards as marketing capital). This adaptive incentive system ensures that the token economy remains responsive to changes in dynamic markets, and different networks automatically adapt without manual recalibration.",{"id":921,"title":922,"titles":923,"content":924,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#centrality-as-an-implicit-referral-mechanism","Centrality as an Implicit Referral Mechanism",[861,877],"Centrality rankings implicitly capture what other networks attempt to achieve through imprecise mechanisms like referral rewards or marketing incentives. For example, Braintrust's connector program. In a graph, \"referrals\" are not enshrined as a concept; they are just the optimal strategy to maximize personal rewards. Users are therefore unknowingly participating in a complex, multi-agent optimization process where the optimal strategy is: Contribute as much revenue as possibleRecruit your neighbors to contribute as much revenue as possible Connectivity allows us to align the incentives of the individual agents in the network with those of the network's objective function. In practice, this results in a more mathematically precise referral mechanism. The aggregated behavior of countless self-interested actions drives behaviors that tend towards maximizing total network value. We hypothesize that the collective action of self-interested agents, each seeking to maximize their individual utility, will develop more effective solution concepts to maximize network value compared to a single centralized actor. Through the alignment of incentives, we aim to create a system that encourages fast, self-reinforcing network growth. You can think of EC based networks as \"outsourcing acquisition and retention\".",{"id":926,"title":927,"titles":928,"content":929,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#what-are-the-risks","What are the Risks?",[861],"While centrality-based token economies offer an exciting new possibility for DePIN projects and cryptonetworks alike, there are a couple of risks to consider.",{"id":931,"title":932,"titles":933,"content":934,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#potential-for-centralization","Potential for Centralization",[861,927],"If the distribution mechanism heavily favors highly connected nodes, it could lead to a disproportionate accumulation of tokens in the hands of a few influential actors. This centralization of power could make the system vulnerable to manipulation by these entities. To mitigate this risk, it's crucial to carefully design the network's monetary policy, taking into account potential tradeoffs. If we over-emphasize connectivity, highly connected nodes can earn disproportionate rewards, which can lead to a concentration of power. One approach to address this issue is implementing an inflationary monetary policy. By gradually increasing the token supply over time, the relative influence of today's powerful nodes can be diluted. This allows new entrants to compete more effectively and helps prevent the entrenchment of dominant players. However, it's important to strike a balance, as excessive inflation can also devalue token holdings and disincentivize participation.",{"id":936,"title":937,"titles":938,"content":939,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#computational-complexity","Computational Complexity",[861,927],"Calculating eigenvector centrality involves diagonalizing a large matrix, which can become computationally demanding as the network grows and transaction volumes increase. The computational resources required to process these calculations may strain the network's capacity, potentially leading to slower transaction times and reduced efficiency. To address this challenge, we are exploring various optimization techniques. We are also exploring various sharding techniques, which involve partitioning the network into smaller, more manageable subgraphs. By dividing the computational workload across these shards, the network can process centrality calculations more efficiently, allowing for faster transaction processing and improved scalability. Luckily there is a tremendous amount of research in the literature about PageRank given it's importance in web2 contexts. As we make progress here, we will continue to share more here.",{"id":941,"title":942,"titles":943,"content":944,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fpage-rank#wrapping-up","Wrapping Up",[861],"Eigenvector-based cryptonetworks offer a unique set of generalizable properties that can be tuned to support a wide range of commercial networks. We think that this strategy captures the nuances of unpredictable economic behavior and could unlock a bunch of new cryptonetworks that either don't have verifiable service-proofs or have weak service-proofs. The set of techniques discussed in this article provide a rich set of new primitives that can overcome these restrictions across a spectrum of verifiability which can help unlock a tremendous number of new use cases and catalyze mass adoption for the next generation of the internet. Although there are some risks and serious research problems ahead, we think this proposal unlocks a rich new design space for DePIN and other applications. This research originated from the work of Matheus Venturyne Xavier Ferreira, with support from our friends at the CryptoEconLab. mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"id":946,"title":947,"titles":948,"content":949,"level":9,"kind":864,"priority":9},"\u002Fblog\u002Fproofs","Probabilistic Proofs in DePIN",[],"Modeling identity and service proofs as probabilistic graph attributes in Local Protocol, so trust propagates through the network without hard cryptographic proofs for every transaction. In my last post, I introduced the economic concepts underlying Local Protocol, a general decentralized marketplace protocol. Local protocol aims to address key challenges for decentralized physical infrastructure networks (DePINs) where services are limited by the availability or cost of proofs. We argue that the number of services that have hard cryptographic service-proofs is especially limited in physical networks, which has reduced the surface area and design space for DePIN in general. Local aims to expand this surface area for physical services that can be both peer-to-peer and token-incentivized. Our approach acknowledges a spectrum of verifiability and provides a path forward for networks that may not have access to hard or cost-effective service proofs. Local Protocol is an expressive architecture whose approach to verifiability is adaptable to a wide range of DePIN projects. In the root case, the protocol assumes that services do not have access to robust service-proofs. In this post, I discuss incorporating service-proofs and identity-proofs for network's that have access to such things. I'll share why modeling proofs in Local Protocol is more cost effective than opinionated or narrow DePIN architectures, and argue that DePIN requires Local Protocol to unlock new use cases that are limited by the availability or cost of proofs.",{"id":951,"title":952,"titles":953,"content":954,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#local-protocol-design-recap","Local Protocol Design Recap",[947],"Local Protocol is a cryptoeconomic game where buyers and sellers develop connectivity by fulfilling transactions. As users complete transactions, the protocol creates a trustless transaction graph. The block reward for the subsequent transaction is dictated by a relative connectivity ranking (more specifically, their eigenvector centrality (EC)). Self-interested actors aim to enhance their connectivity ranking which requires cooperation with transacting parties that are transacting with similar cohorts of the network. The network incentivizes users with a large reward for developing connectivity, providing the network with a strong bootstrapping and referral mechanism that doubles as the network's security guarantee.",{"id":956,"title":912,"titles":957,"content":958,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#difficulty-in-manufacturing-connectivity",[947,952],"Achieving a high EC score requires not only a large number of connections but also connections to other well-connected nodes. This property makes it challenging for malicious actors to manufacture high connectivity rankings, as they would need to establish links with reputable, central nodes in the network. Legitimate, highly-connected nodes are more likely to scrutinize and avoid suspicious or low-quality nodes. As a result, attackers face significant hurdles to manipulate their EC scores.",{"id":960,"title":619,"titles":961,"content":962,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#proofs-as-graph-attributes",[947],"In graph theory, a node is a point representing an entity (buyer, seller), and an edge is a connection between two nodes (transactions). In Local protocol, we model identity-proofs (and other trust attributes for users) as node attributes and service-proofs as edge attributes. We can assign a degree of confidence to such proofs and propagate the trust assumptions that we derive from each proof through the graph to neighboring nodes with a dampening factor over longer path lengths from the trusted node. This allows us to reduce the requirement of capturing potentially cost-prohibitive proofs for every transaction without sacrificing the security guarantee for the network. You can think of both identity and service proofs as injecting trust into the network. As the network becomes more trustworthy, the protocol becomes more confident in distributing rewards that are greater than the fees collected for each transaction. This unlocks a rich surface area for capital formation to bootstrap new markets. New markets can inherit the security from existing markets providing the network with a strong cross-market network effect. For immature local networks that want to prioritize bootstrapping trust, EC rankings can help establish trust vectors through a combination of service proofs and identity proofs. As the network grows and trust is established, the reliance on expensive service-proofs can be gradually reduced with a dampening factor over time.",{"id":964,"title":805,"titles":965,"content":966,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#trust-propagation",[947,619],"The boost in eigenvector centrality (EC) resulting from any proof—be it an identity proof or a service proof—doesn't just affect the individual node or transaction; it propagates through the network due to the recursive nature of the EC calculation. Nodes directly connected to the node or edge associated with the proof will also see an increase in their EC because their centrality depends on the centrality of their neighbors. The effect of any proof diminishes exponentially over longer paths in the graph. The modified EC calculation naturally captures this phenomenon, as the solution to the inhomogeneous eigenvalue problem (more on this later) accounts for the additional trust introduced by the proofs (the doping vector for nodes or adjusted weights for edges). You can visualize the network as a series of concentric circles centered around the node or edge that has incorporated a proof. The nodes directly connected form the first circle; these are the immediate neighbors who have direct interactions with the proof-bearing node or transaction. The second circle consists of nodes connected to those immediate neighbors, which are two steps away, and so on for subsequent circles. The influence of the proof's boost in eigenvector centrality is strongest at the center and decreases exponentially as you move outward. Nodes that transact with those who have submitted proofs benefit more than they would have without the proofs. This results in higher rewards for both parties and increases their attractiveness as transaction partners in the network. In this way, nodes in the network might view the submission of proofs, and thus the increase in security for the network, as an investment in their EC. When self-interested actors perform actions that have positive security externalities, we achieve strong design properties.",{"id":968,"title":595,"titles":969,"content":970,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#identity-proofs-as-node-attributes",[947],"Examples of identity proofs include World ID, zkPassport, or a zkTLS authentication with a relevant Web2 provider using Opacity Network. These proofs can be assigned a score that unlocks a larger block rewards for both this node and any transacting counterparties. Specifically, we boost nodes that have evidence of realness because it provides the network with stronger sybil resistance.",{"id":972,"title":973,"titles":974,"content":975,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#incorporating-identity-proofs-into-eigenvector-centrality","Incorporating Identity Proofs into Eigenvector Centrality",[947,595],"We represent the network as a bipartite graph , where  and  are disjoint sets of nodes representing producers (sellers) and buyers, respectively, and  is the set of edges representing transactions between them. The eigenvector centrality (EC)  of the nodes in the graph is calculated by solving the eigenvalue problem: where  is the adjacency matrix of the graph, and  is the largest eigenvalue. When a user provides an identity proof, we model this as adding a doping vector  to the eigenvalue equation. This can be captured by modifying the EC formula to become an inhomogeneous eigenvalue problem. Suppose user  submits an identity proof that translates into a boost of  in eigenvector centrality. We then define a \"doping vector\" , where the nonzero element  appears in the -th position. The inhomogeneous eigenvalue problem to solve is then:",{"id":977,"title":978,"titles":979,"content":980,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#service-proofs","Service Proofs",[947],"While identity proofs enhance trust in individual nodes, service proofs strengthen the reliability of specific transactions (edges) between nodes. Some existing examples in the wild: Wireless NetworksProof of Coverage (PoC)Mobility and LogisticsProof of Route ComplianceEnergyProof of Green Energy Generation (PoGG)Compute and StorageProof of SpacetimeProof of ReplicationProof of Useful WorkDomain AgnosticProof of LocationProof of PresenceProof of Time",{"id":982,"title":983,"titles":984,"content":985,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#service-proofs-in-the-adjacency-matrix","Service Proofs in the Adjacency Matrix",[947,978],"Each edge  in the graph has a weight  representing the cumulative fees or value from transactions between producer  and buyer . When a service proof is available, we adjust the edge weight to reflect the increased confidence in that transaction: where  is the boost provided by the service proof. Alternatively, in terms of the adjacency matrix , we update the entry: This adjustment increases the significance of the edge  in the calculation of EC.",{"id":987,"title":988,"titles":989,"content":990,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#impact-on-eigenvector-centrality-and-rewards","Impact on Eigenvector Centrality and Rewards",[947,978,983],"By increasing the weight of the edge , both nodes  and  receive a higher EC score due to their strengthened connection. This boost is again propagated through the network. Higher EC scores translate into increased graph values  and , which are used to calculate block rewards. Therefore, providing service proofs directly benefits the involved parties and indirectly enhances the trustworthiness of their neighbors. In the next EC calculation, both  and  will increase more than they would have without the proof. This results in higher rewards for both parties and increases their attractiveness as transaction partners in the network; transacting with high EC nodes boosts ones own EC.",{"id":992,"title":676,"titles":993,"content":994,"level":278,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#proofs-as-probabilities",[947,978,983],"Modeling proofs as increments in edge weights allows us to treat proofs as probabilistic assessments, rather than binary evidence of service. This approach acknowledges that proofs for physical services can vary in strength and reliability which is particularly useful for networks that lack hard cryptographic proofs-of-service. By quantifying the confidence level , we can proportionally adjust the influence of each proof in the network, unlocking a wider range of evidence and increasing the applicability for networks that do not have deterministic proofs or where capturing \u002F computing proofs is cost-prohibitive (which could break the unit economics of the service in question). Said another way, physical networks have a spectrum of proofs. Local Protocol reduces the reliance on absolute measures of trust, which may be impractical or costly, and instead uses the aggregate trust derived from various proofs and interactions within the network. Example: RidesharingFor example, in a mobility network, a ridesharing application may contain two nodes who submit evidence of their service using a location-proof and time-proof. However, we may not have assurances that these nodes are discrete individuals; it could be a single person acting as both the driver and the rider. In such a case, these rideshare \"proofs\" are not robust like validity proofs are in other blockchain networks.The graph is robust to such attacks because colluding nodes will form isolated subgraphs, disconnected from the broader network of honest participants. Nodes with low connectivity will inherently have low Eigenvector Centrality (EC). This ensures that the weight boost for a given transaction is contained to the colluding actor, is unprofitable, and a self-destructive strategy. As edge weights update dynamically, nodes that are disconnected from the main graph (or have limited interactions with genuinely trusted nodes) will find it increasingly costly to maintain their position.",{"id":996,"title":997,"titles":998,"content":999,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#random-sampling-and-slashing","Random Sampling and Slashing",[947],"To ensure that the graph doesn't lose its security guarantees as new nodes enter the game, the network can randomly sample for service-proofs or service-approximations if proofs aren't available. If a node fails to provide their proofs, the network can slash the edge weights (tokens staked in the graph), and add a inverse doping vector to the nodes that fail to provide their proofs. This localized penalty system encourages self-policing and allows the network to remain secure without necessitating costly proofs for every transaction.",{"id":1001,"title":1002,"titles":1003,"content":1004,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#inverse-doping-vector","Inverse Doping Vector",[947,997],"When the network randomly samples a transaction and requests a service proof, the involved nodes must submit the required proof. If they fail to do so, we model this as an inverse doping vector in the eigenvector centrality (EC) calculation. Specifically, we decrease the EC scores of the nodes in question and remove the edge representing the fake transaction. This slashing not only impacts the penalized nodes but also affects their neighboring nodes, with the effect diminishing exponentially over longer paths in the graph. where  is a vector with positive entries corresponding to the penalized nodes, effectively reducing their EC scores. For example, if node  fails to submit a proof, the inverse doping vector  has a positive value  at position  and zeros elsewhere: The impact of this penalty propagates through the network due to the nature of the EC calculation and the edge weights  associated with the failed transaction are also decreased or set to zero:",{"id":1006,"title":1007,"titles":1008,"content":1009,"level":52,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#slashing-neighbors","Slashing Neighbors",[947,997],"To further encourage self-policing, we can extend the penalty to nodes directly connected to the penalized node. This is modeled by adjusting the inverse doping vector to include these neighboring nodes with scaled penalties. Let  denote the set of nodes directly connected to node . We define the inverse doping vector  as: where  is the decay factor representing the reduced penalty on neighboring nodes. For each node , we can adjust the edge weights  associated with the neighboring node where  is a smaller slashing factor for the connected edges. The effect of the penalty diminishes exponentially over longer paths in the network. Mathematically, this is inherent in the properties of the EC calculation. The further a node is from the penalized node, the less impact the inverse doping vector has on its EC score. This decay can be adjusted through the choice of decay factor  and slashing factors  and , allowing network designers to balance between strictness and leniency based on the desired security level. This slashing mechanism encourages nodes to maintain genuine connections and discourages malicious behavior.",{"id":1011,"title":1012,"titles":1013,"content":1014,"level":16,"kind":864,"priority":9},"\u002Fblog\u002Fproofs#conclusion","Conclusion",[947],"Incorporating identity proofs and service proofs into the Local Protocol graph enhances the network's ability to verify users and transactions without relying solely on network connectivity. By modeling proofs as probabilistic boosts in eigenvector centrality (EC), we allow trust to propagate organically through the network. This approach balances the need for security with the practical limitations of obtaining proofs in various markets. By integrating proofs into the mathematical framework of the graph, we create a system where security (trust) is directly linked to economic rewards. Nodes are incentivized to provide proofs, not just for their own benefit, but also to enhance the trustworthiness of transacting partners in their Local network. Local Protocol supports a wide range of decentralized services, even those without hard cryptographic proofs, expanding the design space for DePIN projects. This enables more services to be both peer-to-peer and token-incentivized. mjx-container[jax=\"SVG\"] {\n  direction: ltr;\n}\n\nmjx-container[jax=\"SVG\"] > svg {\n  overflow: visible;\n  min-height: 1px;\n  min-width: 1px;\n}\n\nmjx-container[jax=\"SVG\"] > svg a {\n  fill: blue;\n  stroke: blue;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"] {\n  display: block;\n  text-align: center;\n  margin: 1em 0;\n}\n\nmjx-container[jax=\"SVG\"][display=\"true\"][width=\"full\"] {\n  display: flex;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"left\"] {\n  text-align: left;\n}\n\nmjx-container[jax=\"SVG\"][justify=\"right\"] {\n  text-align: right;\n}\n\ng[data-mml-node=\"merror\"] > g {\n  fill: red;\n  stroke: red;\n}\n\ng[data-mml-node=\"merror\"] > rect[data-background] {\n  fill: yellow;\n  stroke: none;\n}\n\ng[data-mml-node=\"mtable\"] > line[data-line], svg[data-table] > g > line[data-line] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > rect[data-frame], svg[data-table] > g > rect[data-frame] {\n  stroke-width: 70px;\n  fill: none;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dashed, svg[data-table] > g > .mjx-dashed {\n  stroke-dasharray: 140;\n}\n\ng[data-mml-node=\"mtable\"] > .mjx-dotted, svg[data-table] > g > .mjx-dotted {\n  stroke-linecap: round;\n  stroke-dasharray: 0,140;\n}\n\ng[data-mml-node=\"mtable\"] > g > svg {\n  overflow: visible;\n}\n\n[jax=\"SVG\"] mjx-tool {\n  display: inline-block;\n  position: relative;\n  width: 0;\n  height: 0;\n}\n\n[jax=\"SVG\"] mjx-tool > mjx-tip {\n  position: absolute;\n  top: 0;\n  left: 0;\n}\n\nmjx-tool > mjx-tip {\n  display: inline-block;\n  padding: .2em;\n  border: 1px solid #888;\n  font-size: 70%;\n  background-color: #F8F8F8;\n  color: black;\n  box-shadow: 2px 2px 5px #AAAAAA;\n}\n\ng[data-mml-node=\"maction\"][data-toggle] {\n  cursor: pointer;\n}\n\nmjx-status {\n  display: block;\n  position: fixed;\n  left: 1em;\n  bottom: 1em;\n  min-width: 25%;\n  padding: .2em .4em;\n  border: 1px solid #888;\n  font-size: 90%;\n  background-color: #F8F8F8;\n  color: black;\n}\n\nforeignObject[data-mjx-xml] {\n  font-family: initial;\n  line-height: normal;\n  overflow: visible;\n}\n\nmjx-container[jax=\"SVG\"] path[data-c], mjx-container[jax=\"SVG\"] use[data-c] {\n  stroke-width: 3;\n}",{"\u002Fdocs\u002Farchitecture\u002Fconsensus":1016,"\u002Fdocs\u002Farchitecture":1016,"\u002Fdocs\u002Farchitecture\u002Foverview":1016,"\u002Fdocs\u002Farchitecture\u002Fperformance-storage":1016,"\u002Fdocs\u002Farchitecture\u002Fsettlement":1016,"\u002Fdocs\u002Farchitecture\u002Fsharding":1016,"\u002Fdocs\u002Farchitecture\u002Fstate-model":1016,"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties":1017,"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion":1017,"\u002Fdocs\u002Fgames-and-graphs\u002Fexample":1017,"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph":1017,"\u002Fdocs\u002Fgames-and-graphs":1017,"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims":1017,"\u002Fdocs\u002Fgames-and-graphs\u002Foverview":1017,"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments":1017,"\u002Fdocs\u002Fidentity":1017,"\u002Fdocs":1018,"\u002Fdocs\u002Finsurance\u002Fdispute-resolution":1016,"\u002Fdocs\u002Finsurance":1016,"\u002Fdocs\u002Finsurance\u002Finsurance-amm":1016,"\u002Fdocs\u002Fmarkets\u002Fbootstrapping":1018,"\u002Fdocs\u002Fmarkets":1017,"\u002Fdocs\u002Fmarkets\u002Fregistry":1017,"\u002Fdocs\u002Fmore-resources":1016,"\u002Fdocs\u002Fproofs\u002Fidentity-proofs":1017,"\u002Fdocs\u002Fproofs":1017,"\u002Fdocs\u002Fproofs\u002Flocation-proofs":1017,"\u002Fdocs\u002Fproofs\u002Foverview":1017,"\u002Fdocs\u002Fproofs\u002Fprobabilities":1017,"\u002Fdocs\u002Fproofs\u002Fservice-proofs":1017,"\u002Fdocs\u002Fsecurity\u002Fgraph-value":1017,"\u002Fdocs\u002Fsecurity":1017,"\u002Fdocs\u002Fsecurity\u002Foverview":1017,"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance":1017,"\u002Fdocs\u002Ftrust":1017,"\u002Fdocs\u002Ftrust\u002Foverview":1017,"\u002Fdocs\u002Ftrust\u002Fpropagation":1017,"\u002Fdocs\u002Ftrust\u002Fsampling-slashing":1017,"\u002Fdocs\u002Ftrust\u002Fself-policing":1017,"\u002Fblog\u002Fpage-rank":1019,"\u002Fblog\u002Fproofs":1019},"2026-07-10T17:57:56-04:00","2026-06-27T10:18:06-04:00","2026-07-10T15:52:15-04:00","2026-07-10T17:07:49-04:00",{"id":1021,"title":468,"author":1022,"body":1023,"content":1022,"description":1129,"extension":1130,"layout":1131,"meta":1132,"navigation":1133,"outline":1022,"path":467,"robots":1022,"searchPriority":1022,"seo":1134,"stem":1135,"__hash__":1136},"docs\u002Fdocs\u002Findex.md",null,{"type":1024,"value":1025,"toc":1125},"minimark",[1026,1038,1041,1054,1065,1069,1080,1091,1094,1117,1120,1123],[1027,1028,1029,1030,1037],"p",{},"Blockchains use ",[1031,1032,1036],"a",{"href":1033,"rel":1034},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FConsensus_(computer_science)",[1035],"nofollow","consensus algorithms"," and validity proofs to come to agreements on the state of digital transactions.",[1027,1039,1040],{},"However, most commercial transactions are not verifiable and still depend on trusted intermediaries. It is impossible, for example, for blockchains to reach consensus on the physical state of the world:",[1042,1043,1044,1048,1051],"ul",{},[1045,1046,1047],"li",{},"the location of an entity",[1045,1049,1050],{},"the completion of a service",[1045,1052,1053],{},"the condition of an asset",[1027,1055,1056,1057,1060,1061,1064],{},"The Local Blockchain is designed to unlock a new class of decentralized applications that can operate in these uncertain environments. Local introduces a ",[1031,1058,1059],{"href":183},"graph-theoretic"," game that views ",[1031,1062,1063],{"href":608},"proofs as probabilistic",".",[1066,1067,473],"h2",{"id":1068},"who-should-use-local-protocol",[1027,1070,1071,1072,1076,1077,1064],{},"Local Protocol is for developers, businesses, and institutions seeking to build decentralized networks and is suitable for ",[1073,1074,1075],"strong",{},"early-stage projects"," to ",[1073,1078,1079],{},"large-scale networks",[1027,1081,1082,1083,1086,1087,1090],{},"Local is uniquely suited to capture markets where strict, deterministic service-proofs are either not available, or are too expensive to produce. We view verifiability as a spectrum between ",[1073,1084,1085],{},"soft proofs"," (probabilistic) and ",[1073,1088,1089],{},"hard proofs"," (deterministic and cryptographically verifiable) and provide a path forward for applications along this spectrum to exist in a p2p and token-incentivized network.",[1027,1092,1093],{},"Below are some use cases that illustrate Local Protocol’s potential:",[1095,1096,1097,1103,1108,1113],"cards",{},[1098,1099],"card",{"description":1100,"icon":1101,"title":1102},"Enabling decentralized delivery with dynamic routing and automated payments.","store","Use Case: Last Mile Delivery",[1098,1104],{"description":1105,"icon":1106,"title":1107},"Facilitating trustless transactions in logistics networks.","package","Use Case: Logistics",[1098,1109],{"description":1110,"icon":1111,"title":1112},"Ensuring transparency and trust in supply chain networks.","monitor","Use Case: Supply Chain",[1098,1114],{"description":1115,"icon":1111,"title":1116},"Managing a shared network of gig-workers to increase utilization.","Use Case: Gig-work",[1118,1119],"hr",{},[1066,1121,478],{"id":1122},"who-is-this-documentation-for",[1027,1124,480],{},{"title":161,"searchDepth":16,"depth":16,"links":1126},[1127,1128],{"id":1068,"depth":16,"text":473},{"id":1122,"depth":16,"text":478},"Local Protocol unlocks decentralized applications that operate in uncertain, physical environments where service-proofs range from soft to hard.","md","full",{},true,{"title":468,"description":1129},"docs\u002Findex","qQqETlfEy6Zr9toZQ9h0AEmhqHORv3-d--K_hhJUMfk",{"\u002Fdocs":1138,"\u002Fdocs\u002Farchitecture":1139,"\u002Fdocs\u002Farchitecture\u002Fconsensus":1140,"\u002Fdocs\u002Farchitecture\u002Foverview":1141,"\u002Fdocs\u002Farchitecture\u002Fperformance-storage":1142,"\u002Fdocs\u002Farchitecture\u002Fsettlement":1143,"\u002Fdocs\u002Farchitecture\u002Fsharding":1144,"\u002Fdocs\u002Farchitecture\u002Fstate-model":1145,"\u002Fdocs\u002Fgames-and-graphs":1146,"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties":1147,"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion":1148,"\u002Fdocs\u002Fgames-and-graphs\u002Fexample":1149,"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph":1150,"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims":1151,"\u002Fdocs\u002Fgames-and-graphs\u002Foverview":1152,"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments":1153,"\u002Fdocs\u002Fidentity":1154,"\u002Fdocs\u002Finsurance":1155,"\u002Fdocs\u002Finsurance\u002Fdispute-resolution":1156,"\u002Fdocs\u002Finsurance\u002Finsurance-amm":1157,"\u002Fdocs\u002Fmarkets":1158,"\u002Fdocs\u002Fmarkets\u002Fbootstrapping":1159,"\u002Fdocs\u002Fmarkets\u002Fregistry":1160,"\u002Fdocs\u002Fmore-resources":1161,"\u002Fdocs\u002Fproofs":1162,"\u002Fdocs\u002Fproofs\u002Fidentity-proofs":1163,"\u002Fdocs\u002Fproofs\u002Flocation-proofs":1164,"\u002Fdocs\u002Fproofs\u002Foverview":1165,"\u002Fdocs\u002Fproofs\u002Fprobabilities":1166,"\u002Fdocs\u002Fproofs\u002Fservice-proofs":1167,"\u002Fdocs\u002Fsecurity":1168,"\u002Fdocs\u002Fsecurity\u002Fgraph-value":1169,"\u002Fdocs\u002Fsecurity\u002Foverview":1170,"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance":1171,"\u002Fdocs\u002Ftrust":1172,"\u002Fdocs\u002Ftrust\u002Foverview":1173,"\u002Fdocs\u002Ftrust\u002Fpropagation":1174,"\u002Fdocs\u002Ftrust\u002Fsampling-slashing":1175,"\u002Fdocs\u002Ftrust\u002Fself-policing":1176,"\u002Fblog\u002Fproofs":1177,"\u002Fblog\u002Fpage-rank":1178},"# Introduction\n\nLocal Protocol unlocks decentralized applications that operate in uncertain, physical environments where service-proofs range from soft to hard.\n\nBlockchains use [consensus algorithms](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FConsensus_(computer_science)) and validity proofs to come to agreements on the state of digital transactions.\n\nHowever, most commercial transactions are not verifiable and still depend on trusted intermediaries. It is impossible, for example, for blockchains to reach consensus on the physical state of the world: \n- the location of an entity\n- the completion of a service\n- the condition of an asset\n\nThe Local Blockchain is designed to unlock a new class of decentralized applications that can operate in these uncertain environments. Local introduces a [graph-theoretic](\u002Fdocs\u002Fgames-and-graphs) game that views [proofs as probabilistic](\u002Fdocs\u002Fproofs). \n\n## Who should use Local Protocol\n\nLocal Protocol is for developers, businesses, and institutions seeking to build decentralized networks and is suitable for **early-stage projects** to **large-scale networks**. \n\nLocal is uniquely suited to capture markets where strict, deterministic service-proofs are either not available, or are too expensive to produce. We view verifiability as a spectrum between **soft proofs** (probabilistic) and **hard proofs** (deterministic and cryptographically verifiable) and provide a path forward for applications along this spectrum to exist in a p2p and token-incentivized network. \n\nBelow are some use cases that illustrate Local Protocol’s potential:\n\n::::cards\n:::card{title=\"Use Case: Last Mile Delivery\" description=\"Enabling decentralized delivery with dynamic routing and automated payments.\" icon=\"store\"}\n:::\n:::card{title=\"Use Case: Logistics\" description=\"Facilitating trustless transactions in logistics networks.\" icon=\"package\"}\n:::\n:::card{title=\"Use Case: Supply Chain\" description=\"Ensuring transparency and trust in supply chain networks.\" icon=\"monitor\"}\n:::\n:::card{title=\"Use Case: Gig-work\" description=\"Managing a shared network of gig-workers to increase utilization.\" icon=\"monitor\"}\n:::\n::::\n\n---\n\n## Who is this documentation for\n\nThis documentation is for developers who wish to build services within the Local Proto ecosystem. It is structured to guide readers from basic to advanced concepts, providing practical examples and detailed explanations of how to use Local Protocol's features to build decentralized marketplace applications.","# Architecture\n\nLocal Protocol separates where transactions execute from how their effects are finalized, enabling parallel execution with a single consistent ledger.\n\nScalable blockchains must support parallel transaction execution while maintaining a single, globally consistent ledger state. Achieving both requires separating where transactions execute from how their effects are finalized and shared across the network.\n\nThe Local Blockchain adopts this separation as a core architectural principle. Transactions execute locally within independently scalable environments, while their results are aggregated and finalized through a shared coordination layer. This enables high throughput and flexible execution models without fragmenting security, state consistency, or liquidity.","# Consensus\n\nLocal Protocol uses BFT Proof-of-Stake consensus to finalize blocks and epoch commitments, providing a canonical set of ledger facts.\n\nLocal Protocol uses standard **BFT Proof-of-Stake consensus** to finalize blocks and epoch commitments (snapshot roots and randomness). This provides a single, canonical set of ledger facts for claims and audits to reference.\n\nSee: [State Model](\u002Fdocs\u002Farchitecture\u002Fstate-model), [Settlement](\u002Fdocs\u002Farchitecture\u002Fsettlement), and [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments).\n\n::callout{type=\"success\" title=\"Quorum certificate (QC)\"}\nA QC is a supermajority signature (>$2\u002F3$ of stake) attesting to a finalized block (and, at epoch boundaries, the epoch header). If you have the QC, you know the network has finalized those ledger facts.\n::\n\n## What consensus finalizes (fact-layer)\n\nConsensus finalizes **ledger facts**:\n\n- which transactions and SDLs are included\n- which escrow\u002Fdispute outcomes are finalized\n- which graph deltas (edge\u002Fattribute updates) are applied\n- a canonical market label per commerce interaction: `marketId` derived from execution and registry state (see note below)\n- the canonical epoch snapshot roots $\\mathsf{GraphRoot}_t$ and $\\mathsf{SeedRoot}_t$\n- the canonical epoch randomness beacon $\\mathsf{Rand}_t$\n- a canonical snapshot artifact identifier $\\mathsf{SnapshotId}_t$ for authenticated snapshot data\n\nDiffusion values (PageRank\u002FPPR fixed points) are **snapshot-relative interpretations** and are not finalized as a global vector.\n\n::callout{type=\"note\" title=\"Consensus-critical label: canonical marketId (minimal registry)\"}\nWith market-scoped seeds and caps, `marketId` cannot be a soft\u002Fuser-chosen label. Otherwise, users could route interactions into whichever market has favorable teleport seeds or cap budgets.\n\nThe protocol therefore enforces one hard rule as a **ledger fact**:\n\n- `marketId` for an `InteractionRecord` (and the resulting commerce `EdgeRecord`s) must be **derivable from protocol facts**: it must match `MarketRegistry[marketContext].marketId` at that block height, and the market must be `ACTIVE`.\n\nAuditability: the epoch snapshot artifact `SnapshotBlob_t` includes the canonical MarketRegistry table for epoch $t$, and $\\mathsf{SnapshotId}_t$ binds `SnapshotBlobHash_t`, so verifiers can replay and check market attribution deterministically against the same snapshot commitments used for claims.\n::\n\n::callout{type=\"note\" title=\"Randomness and audit selection\"}\nAudit sampling depends on unpredictability at commit time. The randomness beacon used for $\\mathsf{Rand}_{t+1}$-derived sampling is designed to minimize bias (VRF-based or threshold designs), so no participant can systematically steer which claims are audited. A common appchain pattern is a threshold BLS beacon in the style of [drand](https:\u002F\u002Fdocs.drand.love\u002Fdocs\u002Fspecification\u002F).\n::\n\n## Claim-layer finality (optimistic diffusion claims)\n\nDiffusion-derived reward claims are finalized through optimistic verification with mandatory audits. Consensus finalizes the fact-layer roots and randomness; the claim protocol defines transcript commitments, sampling, and fraud proofs.\n\nSee: [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims) and [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties).\n\n```txt\nChain\n|\n|-- Validator Set (600 total stake)\n|   |-- V1 [stake: 100] [Block_t ✓]\n|   |-- V2 [stake: 150] [Block_t ✓]\n|   |-- V3 [stake: 200] [Block_t ✓]\n|   |-- V4 [stake: 150] [Block_t pending]\n|\n|-- Finalized Block_t: {\n|     SDLs: [...],\n|     graph_deltas: {...},\n|     epoch_roots: {GraphRoot_t, SeedRoot_t, Rand_t, SnapshotId_t},\n|     QC: {signatures: [...], total_stake: 450\u002F600}\n|   }\n```\n\n## Next Steps\nThis concludes the detailed breakdown of the Local Blockchain architecture. Explore further to understand how these concepts integrate with other features of the network.","# The Local Blockchain\n\nLocal Protocol separates execution from finality, enabling parallel execution across many environments while preserving a single canonical ledger.\n\nLocal Protocol separates **execution** (where transactions happen) from **finality** (what the network agrees on). This allows parallel execution across many environments while preserving a single canonical set of ledger facts and canonical snapshot roots for graph-based mechanisms.\n\n### Execution architecture\nLocal Protocol is specified as a **single-chain, EVM-compatible appchain** with **fast Byzantine finality**.\n\nScaling comes from:\n\n- implementation-level parallelism (multi-threaded execution, indexing, batching),\n- keeping diffusion computation off the validator critical path (see [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims) and [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties)),\n- committing canonical epoch snapshot roots so claims and audits share one reference frame (see [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)).\n\n### Markets as logical domains\nMarkets are policy + accounting domains derived from execution. A `marketId` (or `domainId`) is used for policy routing (maturity rules, caps, proof multipliers), accounting, and indexing, while consensus and asset state remain global so claims across markets reference the same canonical epoch commitments.\n\nSee: [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry)\n\n## Next Steps\nIn the next sections, we’ll cover:\n\n- [Execution Architecture](\u002Fdocs\u002Farchitecture\u002Fsharding)\n- [State Model](\u002Fdocs\u002Farchitecture\u002Fstate-model)\n- [Settlement](\u002Fdocs\u002Farchitecture\u002Fsettlement)\n- [Consensus](\u002Fdocs\u002Farchitecture\u002Fconsensus)","# Performance & Storage\n\nHow Local Protocol keeps consensus-critical state small while storing the full graph in large epochal snapshot artifacts.\n\nLocal Protocol is graph-heavy, but its **consensus-critical state** stays **small and bounded per transaction**. The system splits “graph state” into two layers:\n\n1. **Consensus state (small, frequently updated):** canonical ledger facts and compact indices.\n2. **Snapshot artifacts (large, epochal blobs):** the full adjacency + sampling structures used for diffusion claims and audits (see [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims) and [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties)).\n\n::callout{type=\"note\" title=\"Intuition\"}\nValidators finalize a *fingerprint* of the graph each epoch (snapshot roots + a blob hash). The full graph lives in a blob store that’s publicly retrievable and verifiable against those commitments.\n::\n\nSee: [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments).\n\nThis matches the broader “data-availability–first” pattern: the chain orders data and commits to it, while verifiers fetch only what they need (e.g., [LazyLedger](https:\u002F\u002Farxiv.org\u002Fabs\u002F1905.09274)).\n\n## 1) What lives in consensus state (small, bounded writes)\n\nConsensus state includes:\n\n- **Ledger facts**: balances, escrow\u002Fdispute state, finalized service outcomes\n- **Edge delta log (append-only)**: compact per-transaction deltas like `(src, dst, marketId, Δweight, flags)` plus proof\u002Fdispute references\n- **Compact per-node accumulators**: e.g. `outWeightSum[u] += Δ` and small penalty\u002Fstrike counters updated by finalized audits\n- **Claim metadata + bonds**: `commitHash`, `transcriptRoot`, `bond`, and claim status (pending\u002Fvalid\u002Finvalid)\n\n::callout{type=\"note\" title=\"Implementation nuance\"}\nStoring full adjacency lists inside Ethereum-style authenticated VM state creates heavy write amplification and makes throughput unpredictable (see **mLSM**: [Raju et al., 2018](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fhotstorage18\u002Fhotstorage18-paper-raju.pdf)). For background on authenticated state commitments, see the [Ethereum Yellow Paper](https:\u002F\u002Fethereum.github.io\u002Fyellowpaper\u002Fpaper.pdf).\n::\n\n## 2) What lives in the epoch snapshot artifact (large, blob-backed)\n\nThe epoch snapshot artifact `SnapshotBlob_t` contains the full data needed to replay diffusion walk steps and verify sampling:\n\n- `NodeRecord` table (including `marketOutIndexRoot` and `nodeAttrRoot`)\n- full adjacency lists as `EdgeRecord` arrays (Merkleized per node)\n- per-market per-node alias tables (via each node’s `OutIndex(m).aliasRoot`, or an equivalent O(1) sampling structure)\n- per-market teleport seed tables $\\{s_{t,m}\\}$ (or equivalent structures to sample from them, optionally via per-market seed alias tables)\n- epoch parameters needed for deterministic replay (e.g., claim\u002Faudit params, caps)\n- the canonical **MarketRegistry** table for epoch $t$: `marketContext → (marketId, vault, feeRouter, flags)` (so auditors can validate `marketId` derivation and market membership rules against snapshot commitments)\n\nThe chain commits to the snapshot artifact via:\n\n- $\\mathsf{GraphRoot}_t$ (Merkle commitment to graph records)\n- $\\mathsf{SeedRoot}_t$ (Merkle commitment to per-market teleport seed roots)\n- `SnapshotBlobHash_t` (content hash of the blob serialization)\n- $\\mathsf{SnapshotId}_t$ (an identifier binding the above)\n\n::callout{type=\"note\" title=\"Plain-language mental model\"}\nThe snapshot blob is “the big file.” The chain stores a hash of the file and Merkle roots that let anyone prove small parts of the file are correct.\n::\n\n## 3) How auditors fetch data without downloading the whole graph\n\nAuditors verifying a claim typically fetch only:\n\n- a small number of opened walk steps\n- the corresponding `NodeRecord` and a few `EdgeRecord` openings\n- alias-table openings (or equivalent) to prove correct neighbor sampling\n- Merkle proofs against $\\mathsf{GraphRoot}_t$ \u002F $\\mathsf{SeedRoot}_t$\n- the referenced snapshot blob bytes for those openings\n\nThis is the “download small pieces, verify against commitments” model used by authenticated data structures (Merkle trees: [Merkle, 1987](https:\u002F\u002Flink.springer.com\u002Fchapter\u002F10.1007\u002F3-540-48184-2_32)).\n\n## 4) Data availability requirements\n\nAudits depend on snapshot bytes being retrievable. Availability is therefore part of epoch finalization:\n\n- a snapshot finalizes only when `SnapshotBlob_t` is available in the data layer\n- nodes can check availability probabilistically with **Data Availability Sampling (DAS)** (e.g., [LazyLedger](https:\u002F\u002Farxiv.org\u002Fabs\u002F1905.09274))\n\n::callout{type=\"note\" title=\"Consensus rule\"}\nThe epoch-finalization block that sets $\\mathsf{SnapshotId}_t$ includes the protocol’s DA attestations \u002F sampling proofs for `SnapshotBlob_t` under its DAS parameters (LazyLedger-style).\n::\n\n## 5) Snapshot construction and correctness\n\nThe snapshot artifact must correspond to the fact-layer deltas finalized during the epoch.\n\nA concrete pattern:\n\n- **Deterministic build rule**: given the finalized edge delta log for epoch $t$ and the prior snapshot artifact, build the new `SnapshotBlob_t` by applying deltas in canonical order, then derive `NodeRecord`, adjacency structures, and alias tables deterministically.\n- **Builder\u002Fserving role**: anyone can build and serve `SnapshotBlob_t` (content-addressed by `SnapshotBlobHash_t`), while validators finalize $\\mathsf{SnapshotId}_t$ as the epoch’s canonical artifact identifier.\n- **Sampled verification**: a protocol-chosen sample of nodes\u002Fedges is checked each epoch by opening:\n  - a few `NodeRecord` \u002F adjacency roots from the blob\n  - corresponding Merkle proofs against $\\mathsf{GraphRoot}_t$\n  - and spot-checking that opened adjacency entries reflect finalized deltas.\n\nIf a sampled check fails, validators reject finalization of the artifact identifier and\u002For slash the responsible publisher(s) under policy.\n\n## 6) Practical guidance (implementers and simulators)\n\n- Keep consensus state writes small and append-only for graph deltas\n- Model `SnapshotBlob_t` as an external blob store keyed by `SnapshotBlobHash_t`\n- Ensure auditors can request and obtain Merkle openings into the snapshot blob\n- Prefer keeping full adjacency\u002Fsampling structures in the snapshot artifact layer, not in authenticated VM state","# Settlement\n\nSettlement packages execution outputs into State Diff Lists and finalizes snapshot commitments and randomness via consensus.\n\nSettlement is the process by which execution outputs are packaged into **State Diff Lists (SDLs)** and finalized by consensus. Settlement publishes **snapshot commitments and randomness**, not global diffusion vectors.\n\nSee: [State Model](\u002Fdocs\u002Farchitecture\u002Fstate-model), [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments), and [Consensus](\u002Fdocs\u002Farchitecture\u002Fconsensus).\n\n## What settles each epoch\n\nAt epoch $t$, blocks include SDLs containing:\n\n- executed transaction deltas and any escrow\u002Fdispute outcomes\n- **graph delta payloads** (edge adds\u002Fupdates, proof\u002Fattribute updates)\n- snapshot commitment references (for claims)\n\n## What the chain finalizes each epoch\n\nAt epoch boundaries, the chain finalizes:\n\n- $\\mathsf{GraphRoot}_t$ (commitment to the epoch graph snapshot)\n- $\\mathsf{SeedRoot}_t$ (commitment to per-market teleport seed roots; a root-of-roots)\n- $\\mathsf{Rand}_t$ (canonical randomness beacon)\n- a content-addressed snapshot artifact identifier $\\mathsf{SnapshotId}_t$ (so auditors can fetch authenticated snapshot data)\n\nDiffusion-derived outputs enter the system through **bounded, optimistic claims** that reference these commitments.\n\nSee: [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims) and [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties).\n\n::callout{type=\"note\" title=\"DA consensus rule\"}\nThe epoch-finalization block that sets $\\mathsf{SnapshotId}_t$ must include the protocol’s data-availability attestations \u002F sampling proofs for the snapshot artifact (DAS-style), as in [LazyLedger](https:\u002F\u002Farxiv.org\u002Fabs\u002F1905.09274).\n::\n\n## Next Steps\nNow that we have discussed settlement and epoch commitments, we will discuss consensus finality.","# Execution Architecture\n\nLocal Protocol is a single-chain EVM-compatible appchain that keeps global diffusion computation off the validator critical path.\n\nLocal Protocol is specified as a **single-chain, EVM-compatible appchain** with fast Byzantine finality. The core scaling strategy is to keep global diffusion computation off the validator critical path (claims + audits) and to rely on implementation-level parallelism for throughput.\n\n## One canonical reference frame per epoch\nAt epoch boundaries, the chain finalizes:\n\n- canonical snapshot roots (e.g., `GraphRoot_t`, `SeedRoot_t`),\n- a canonical randomness beacon (`Rand_t`),\n- and a canonical snapshot artifact identifier (e.g., `SnapshotId_t`) that auditors can fetch.\n\nThese commitments make diffusion claims deterministic to verify and keep audits objective.\n\n## Markets as logical domains\nMarkets are expressed as **logical domains** (e.g., `marketId`). `marketId` drives:\n\n- policy routing (maturity rules, caps, proof multipliers),\n- accounting (per-market cap vectors),\n- indexing and parallel execution hints.\n\nConsensus and asset state remain global, so claims across markets reference the same epoch snapshot roots.\n\n`marketId` is derived from execution: interaction records and commerce edges are valid only if their `(marketContext, marketId)` pair matches the canonical registry state and the market is ACTIVE.\n\nSee: [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry)\n\n## Snapshot artifacts and data availability\nAudits require authenticated access to snapshot data (NodeRecords \u002F EdgeRecords \u002F alias tables). Each epoch therefore finalizes a **Snapshot Artifact** that is content-addressed and publicly retrievable. Nodes can check availability via probabilistic sampling (DAS-style checks), as in systems like [LazyLedger](https:\u002F\u002Farxiv.org\u002Fabs\u002F1905.09274) and common DAS primers (e.g., Celestia’s [Data Availability Sampling](https:\u002F\u002Fcelestia.org\u002Fglossary\u002Fdata-availability-sampling\u002F)).\n\nAuditors fetch only the small Merkle openings needed to verify sampled walks.\n\nSee: [Performance & Storage](\u002Fdocs\u002Farchitecture\u002Fperformance-storage)\n\n## Next Steps\nNext, see how snapshot roots, randomness, and snapshot artifacts are finalized:\n\n- [Settlement](\u002Fdocs\u002Farchitecture\u002Fsettlement)\n- [Consensus](\u002Fdocs\u002Farchitecture\u002Fconsensus)","# State Model\n\nThe Local Blockchain maintains a single globally authoritative ledger state defined by finalized State Diff Lists committed by consensus.\n\nThe Local Blockchain maintains a single, globally authoritative ledger state defined by the ordered application of finalized **State Diff Lists (SDLs)** committed by consensus.\n\n## State Diff Lists (SDLs)\nAn SDL is a compact, verifiable description of ledger mutations produced by execution. It may include:\n- creation or update of transaction relationships\n- balance changes\n- [proofs](\u002Fdocs\u002Fproofs#proof-attachments-in-state-diff-lists-sdls)\n- graph delta payloads (edge\u002Fattribute updates)\n- optional diffusion-derived claim payloads (bounded, challengeable)\n\n### Commitment references (snapshot roots)\nSDLs can reference canonical epoch snapshot roots:\n- `epoch: t`\n- `graphRoot: GraphRoot_t`\n- `seedRoot: SeedRoot_t` (a root-of-roots that binds per-market seed tables)\n- `snapshotId: SnapshotId_t`\n- `paramsHash: H(alpha, δ_tx, δ_epoch_user, δ_epoch_market, δ_epoch_global, k, …)`\n\n::callout{type=\"note\" title=\"Market derivation (minimal registry)\"}\nIn an SDL, `marketId` is not trusted as user metadata. Market membership is derived from execution:\nan executed `MarketContext` emits an `InteractionRecord`, and `marketId` must match `MarketRegistry[marketContext].marketId` at that height.\n`MarketRegistry` is included in `SnapshotBlob_t` and is auditable because `snapshotId` binds `SnapshotBlobHash_t`.\n::\n\n### Optional diffusion claim payload (sketch)\nWhen included, a claim can carry:\n\n- `claimValue: uint128` (≤ δ_tx)\n- `transcriptRoot: bytes32`\n- `marketContext: Address` (the executed MarketContext that produced the interaction record)\n- `marketId: uint32`\n- `commitHash: bytes32` (= `H(ParamsHash || SnapshotId_t || marketId || txid || TranscriptRoot)`)\n- `bond: uint128`\n- `challengeWindow: uint32`\n\nExecution environments maintain **local execution state** used to process transactions and produce proposed state transitions. This local state may be partial, transient, or stale; the authoritative ledger state comes from finalized SDLs.\n\nThe canonical ledger state is obtained by applying accepted SDLs in consensus order. Execution environments derive local views from this canonical state for performance and parallelism; finality and reconciliation come from consensus ordering.\n\nThis separation allows execution to scale horizontally while preserving a single, consistent global ledger.\n\n## Related\n- [Execution Architecture](\u002Fdocs\u002Farchitecture\u002Fsharding) (where execution happens)\n- [Settlement](\u002Fdocs\u002Farchitecture\u002Fsettlement) (how SDLs are produced and finalized)\n- [Consensus](\u002Fdocs\u002Farchitecture\u002Fconsensus) (how accepted SDLs are ordered)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# Games & Graphs\n\nThe protocol's graph-based mechanism stack — a transaction graph, snapshot-relative diffusion, and optimistic bounded claims.\n\nThis chapter describes the protocol’s graph-based mechanism stack:\n\n- ledger facts as a transaction graph,\n- snapshot-relative diffusion (PPR) defined on committed epoch snapshots,\n- optimistic, bounded claims verified by sampling and slashing.\n\nFor markets (registry, commitments, and bootstrapping), see: [Markets](\u002Fdocs\u002Fmarkets).\n\n## Next Steps\n\nStart here:\n\n- [Transaction Graph Model](\u002Fdocs\u002Fgames-and-graphs\u002Fgraph)\n- [Snapshot-Relative Diffusion (PageRank \u002F PPR)](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Markets](\u002Fdocs\u002Fmarkets)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# Validator Audits & Penalties\n\nAuditing as an obligated validator duty — random audit sampling, deterministic fraud proofs, and fact-layer penalties that feed back into diffusion policy.\n\nOptimistic diffusion claims shift heavy computation to provers, but the protocol still needs **reliable verification** at high volume. In mature markets, relying on a voluntary challenger ecosystem can suffer from free-riding (the “verifier’s dilemma”).\n\nLocal Protocol addresses this by making auditing an **obligated validator duty**, enforced by standard consensus incentives (rewards + slashing).\n\n::callout{type=\"note\" title=\"Intuition\"}\nThe chain checks: a protocol-chosen random subset of claims is mandatorily audited by assigned validators.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nThe verifier’s dilemma is discussed in the Arbitrum paper ([Kalodner et al., 2018](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fusenixsecurity18\u002Fsec18-kalodner.pdf)). Slashing-backed enforcement is common in PoS finality designs (e.g., [Casper FFG](https:\u002F\u002Farxiv.org\u002Fabs\u002F1710.09437)).\n::\n\n## Audit sampling (unpredictable, canonical)\n\nAt epoch boundary $t \\to t+1$, the protocol derives an audit set using **future randomness**:\n\n$$\n\\mathsf{AuditSet}_t = \\textsf{Sample}(\\mathsf{Rand}_{t+1}, \\mathsf{Claims}_t; m)\n$$\n\n- $\\mathsf{Claims}_t$: all diffusion claims included during epoch $t$\n- $m$: audit budget (a fixed count or fraction per epoch)\n\nUsing $\\mathsf{Rand}_{t+1}$ ensures provers cannot predict which claims will be audited when committing transcripts.\n\n## Audit assignment (obligations, not volunteers)\n\nEach audited claim $c$ is assigned to one or more validators deterministically:\n\n$$\n\\mathsf{Auditors}(c) = \\textsf{Assign}(\\mathsf{Rand}_{t+1}, c, \\mathsf{ValidatorSet}_{t+1})\n$$\n\nAssigned auditors must publish an **AuditAttestation** by a strict deadline, or be slashable.\n\n## What auditors verify (bounded work)\n\nClaims are **market-relative**: each claim is verified in a market context `marketId = m`, using the market’s committed teleport distribution $s_{t,m}$ (opened via $\\mathsf{SeedRoot}_t$) and market-scoped edge sampling commitments for that market.\n\nAuditors verify a bounded subset of transcript walks\u002Fsteps derived canonically, and check the opened transitions against the committed snapshot roots. The transcript format and commitment rules live in the claim protocol:\n\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n\n::callout{type=\"note\" title=\"Snapshot artifacts and data availability\"}\nAudits require authenticated snapshot data (NodeRecords, EdgeRecords, alias tables). Availability and retrieval live in the storage model. See: [Performance & Storage](\u002Fdocs\u002Farchitecture\u002Fperformance-storage)\n::\n\n## Audit outcomes and accountability\n\nAuditors publish one of:\n\n- **VALID**: with transcript fragments sufficient for anyone to reproduce the checks\n- **INVALID**: a concrete fraud proof (openings + proofs showing a violation)\n\n## Fraud proofs are deterministic\n\nA fraud proof is valid iff any full node can deterministically replay the sampled checks and obtain a mismatch. Concretely, a fraud proof includes:\n\n- `claimId`, `txid`, `epoch: t`, $\\mathsf{SnapshotId}_t$, and the claim parameter commitment (e.g., `ParamsHash`)\n- the sampled walk indices (or enough data to recompute them from $\\mathsf{Rand}_{t+1}$)\n- the opened transcript fragments (Merkle openings from `TranscriptRoot`)\n- the Merkle\u002Falias openings required to verify market-scoped transitions against $\\mathsf{GraphRoot}_t$ and teleport sampling against the market seed root $\\mathsf{MarketSeedRoot}_{t,m}$ (opened via $\\mathsf{SeedRoot}_t$)\n\nThis is the standard optimistic “fraud proof” pattern (e.g., [Truebit](https:\u002F\u002Farxiv.org\u002Fabs\u002F1908.04756), [Arbitrum](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fusenixsecurity18\u002Fsec18-kalodner.pdf)), specialized to sampled Monte Carlo transcripts rather than full VM traces.\n\n## Audit deadline and claim finality (fail-closed for audited claims)\n\nAudited claims finalize under a fail-closed rule:\n\n- rewards are escrowed at submission time\n- if a claim is in $\\mathsf{AuditSet}_t$, it cannot finalize as VALID by timeout alone\n- the claim becomes:\n  - **INVALID immediately** upon inclusion of a valid fraud proof\n  - **VALID** once at least one assigned auditor posts a VALID attestation and the deadline passes without any valid fraud proof\n  - **PENDING (locked)** if the deadline passes with no VALID attestation (and no-show auditors are slashable)\n\nTo prevent rubber-stamping:\n\n- **No-show**: assigned auditor misses deadline → slashable\n- **False attestation**: auditor attests VALID but a fraud proof is later posted → slashable\n\n## Penalties (fact-layer) and how they affect future trust\n\nWhen an audited claim fails, the protocol applies objective penalties and then feeds them back into diffusion policy.\n\n### 1) Edge slashing\n\nFor a failed edge $(v \\to u)$:\n\n$$\nw_t(v,u) \\leftarrow w_t(v,u)\\cdot(1-\\gamma)\n\\quad \\text{or} \\quad\nw_t(v,u) \\leftarrow 0\n$$\n\n### 2) Bond slashing\n\nThe claim bond $B$ is slashed (policy-defined split between burn\u002Fsecurity pool\u002Fauditor rewards).\n\n### 3) Penalty vector $p_t$ (ledger fact)\n\nMaintain a per-node penalty score $p_t(i) \\ge 0$, updated only by finalized audits:\n\n::callout{type=\"note\" title=\"Related work\"}\nPenalty injection is a distrust \u002F negative-evidence propagation pattern in link analysis and trust systems. A representative example is distrust propagation in PageRank-style rankings (e.g., [Wu et al., 2006](https:\u002F\u002Fwww.cse.lehigh.edu\u002F~brian\u002Fpubs\u002F2006\u002FMTW\u002Fpropagating-trust.pdf)). See also distrust demotion variants like [Anti-TrustRank](https:\u002F\u002Fsnap.stanford.edu\u002Fmis2\u002Ffiles\u002FMIS2_paper_24.pdf) and early trust\u002Fdistrust graph models such as [Guha et al., 2004](https:\u002F\u002Fwww.ra.ethz.ch\u002Fcdstore\u002Fwww2004\u002Fdocs\u002F1p403.pdf).\n::\n\n$$\np_t(u) \\leftarrow p_t(u) + \\pi,\\qquad p_t(v) \\leftarrow p_t(v) + \\pi\n$$\n\nOptional bounded neighbor spillover:\n\n$$\np_t(j) \\leftarrow p_t(j) + \\alpha_N \\pi \\quad \\forall j \\in N(u)\\cup N(v)\n$$\n\n### 4) How penalties modify policy inputs\n\nPenalty-adjusted seed weights (before normalization):\n\n$$\ns_{t,m}'(i) \\propto s_{t,m}(i)\\cdot \\exp(-\\kappa\\, p_t(i))\n$$\n\nRisk-based claim constraints (examples):\n\n$$\n\\delta_{tx}(i) = \\delta_{tx,0}\\cdot \\exp(-\\kappa_\\delta\\, p_t(i))\n$$\n\n$$\nB(i) = B_0 \\cdot (1 + \\mu\\, p_t(i))\n$$\n\n## Related\n\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n- [Consensus](\u002Fdocs\u002Farchitecture\u002Fconsensus)\n- [Sampling & Slashing](\u002Fdocs\u002Ftrust\u002Fsampling-slashing)","# Snapshot-Relative Diffusion (PageRank \u002F PPR)\n\nInfluence defined as a PageRank\u002FPPR fixed point evaluated relative to a committed epoch snapshot, with protocol-defined market-relative teleport.\n\nLocal Protocol defines influence using a **diffusion score** that is a fixed point over a **committed epoch snapshot**. Practically, this is PageRank \u002F Personalized PageRank (PPR) semantics, evaluated relative to the snapshot, not continuously recomputed as a global “ledger fact”.\n\n## 1) Transition operator\n\nLet the global transaction graph at epoch $t$ be a weighted, directed graph:\n\n$$\nG_t = (V, E_t, w_t)\n$$\n\nDefine a row-stochastic transition matrix $P_t$ derived from outgoing weights:\n\n$$\nP_t(u \\to v) = \\frac{w_t(u,v)}{\\sum_{x} w_t(u,x)} \\quad \\text{if } \\sum_x w_t(u,x) > 0\n$$\n\nFor **dangling nodes** (no outgoing edges), the protocol redirects mass according to the teleport distribution (standard PageRank handling).\n\n::callout{type=\"note\" title=\"Intuition\"}\nYou can read $P_t$ as a “next hop” rule: if you are at $u$, then $P_t(u\\to v)$ is the chance you move to $v$ next. Rows sum to 1 because this is a Markov chain.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nMarkov chains and stationary distributions are the standard lens for PageRank-style scores; see e.g. [Levin–Peres–Wilmer](https:\u002F\u002Fpages.uoregon.edu\u002Fdlevin\u002FMARKOV\u002Fmcmt2e.pdf).\n::\n\n## 2) Teleport distribution (protocol-defined)\n\nLocal Protocol uses **Personalized PageRank (PPR)** to anchor diffusion to a *protocol-defined* set of trusted starting points (users do **not** get to choose personalization; that would be instantly gameable).\n\n### Why market-relative teleport?\nIn real marketplaces, trust is often **local to a market context** (a naturally fragmented city \u002F vertical can be real yet weakly connected to global anchors). A single global seed set can accidentally treat a legitimate, fragmented market as “low influence” simply because diffusion cannot reach it.\n\n**Market-relative teleport addresses this**: diffusion (and claims derived from it) are evaluated in a market context `marketId = m`.\n\nFormally:\n\n- teleport distribution per market: $s_{t,m} \\in \\Delta(V)$\n- market-relative diffusion score: $r_{t,m} \\in \\Delta(V)$\n\nThe protocol commits to $s_{t,m}$ each epoch (users do **not** choose it).\n\n::callout{type=\"note\" title=\"Intuition\"}\nTeleport is the protocol’s “source of ground truth”: where trust starts. Market-relative teleport keeps that rule intact while preventing “fragmented-but-real” markets from being unfairly treated as low influence.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nPersonalization vectors in [Personalized PageRank](https:\u002F\u002Finfolab.stanford.edu\u002F~glenj\u002Fspws.pdf), topic\u002Fcontext-sensitive ranking variants, and seed-set anchoring like [TrustRank](https:\u002F\u002Filpubs.stanford.edu\u002F638\u002F1\u002F2004-17.pdf).\n::\n\n## 3) Fixed point definition\n\nFor a given market context $m$, the protocol defines a **market-scoped** transition operator $P_{t,m}$ (outgoing edges filtered to `marketId = m`, plus any explicitly-global edges the protocol defines), and a market-relative teleport distribution $s_{t,m}$.\n\n::callout{type=\"warning\" title=\"Market-scoped walks (important)\"}\nClaims are verified against **market-scoped walks**: the walk uses the market-scoped operator $P_{t,m}$ and teleports according to the market’s committed seed table $s_{t,m}$. This prevents reinterpreting the same transcript under a different market context.\n::\n\n::callout{type=\"note\" title=\"Where marketId comes from\"}\n`marketId` is derived from execution: it must match the registered MarketContext that emitted the interaction record, and the market must be ACTIVE. See: [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry).\n::\n\nThe market-relative diffusion score $r_{t,m} \\in \\Delta(V)$ is defined as:\n\n$$\nr_{t,m} = \\alpha s_{t,m} + (1-\\alpha)P_{t,m}^\\top r_{t,m}\n$$\n\nWhere $\\alpha \\in (0,1)$ is the restart probability (teleport rate).\n\nThis fixed point exists and is unique for $\\alpha \\in (0,1)$.\n\n## 4) Random-walk interpretation\n\nSample a random walk:\n\n- start from a teleport sample $v_0 \\sim s_{t,m}$\n- at each step: with probability $\\alpha$ restart from $s_{t,m}$, otherwise follow a market-scoped outgoing edge proportional to weights\n\nThen $r_{t,m}(v)$ is the stationary probability of being at node $v$ (in market context $m$).\n\n## 5) Why snapshot-relative?\n\nDiffusion is defined **relative to a committed snapshot**:\n\n- the ledger commits to $G_t$ via $\\mathsf{GraphRoot}_t$\n- claims derived from diffusion must specify which snapshot they reference\n- economic outputs are computed *with respect to that snapshot*\n\nDiffusion is a global fixed point and is not composable by one-way merging of independently computed partition-local vectors.\n\n## Related\n\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n- [Markets](\u002Fdocs\u002Fmarkets)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# Basic Example Graph\n\nA tiny five-participant graph that builds intuition for snapshot-relative diffusion (PageRank \u002F PPR) and how claims reference it.\n\nThis page builds intuition for **snapshot-relative diffusion** (PageRank \u002F PPR) and how it can be referenced by claims.\n\n## A tiny transaction graph\n\nConsider five participants:\n\n- producers: `P1`, `P2`\n- buyers: `B1`, `B2`, `B3`\n\nModel interactions as a directed graph, where an edge `buyer → producer` has weight equal to completed transaction value (after any quality\u002Fproof factors).\n\n## Personalized PageRank (PPR) intuition\n\nIn PPR, influence originates from a **teleport distribution** and diffuses through the graph. In Local Protocol, teleport is **market-relative**: for market `marketId = m`, influence originates from $s_{t,m}$. If the protocol’s verified seed set for market $m$ includes `B1` and `B2`, a toy teleport distribution might be:\n\n$$\ns_{t,m}(B1)=0.5 \\\\\ns_{t,m}(B2)=0.5 \\\\\ns_{t,m}(\\text{else})=0\n$$\n\nThe diffusion fixed point is:\n\n$$\nr_{t,m} = \\alpha s_{t,m} + (1-\\alpha) P_{t,m}^\\top r_{t,m}\n$$\n\nSo nodes that are reachable via high-weight paths from the verified seed set accumulate more influence.\n\n## Offchain computation demo (NetworkX)\n\nThis is *not* a protocol algorithm; it’s just a quick way to visualize the fixed point on a small graph.\n\n```python\nimport networkx as nx\n\n# Directed graph with edge weights (buyer -> producer)\nG = nx.DiGraph()\nG.add_edge(\"B1\", \"P1\", weight=2.0)\nG.add_edge(\"B2\", \"P2\", weight=3.0)\nG.add_edge(\"B3\", \"P2\", weight=1.0)\n\n# Teleport distribution (protocol-defined in production)\npersonalization = {\"B1\": 0.5, \"B2\": 0.5, \"B3\": 0.0, \"P1\": 0.0, \"P2\": 0.0}\n\n# alpha here is the restart probability (teleport rate)\nr = nx.pagerank(G, alpha=0.85, personalization=personalization, weight=\"weight\")\nprint(r)\n```\n\n## How this maps to the protocol\n\n- Diffusion $r_{t,m}$ is defined **on a committed snapshot** $\\mathsf{GraphRoot}_t$ and a market-relative seed commitment: $\\mathsf{SeedRoot}_t$ is a root-of-roots that binds per-market seed tables.\n- The protocol does **not** store $r_{t,m}$ as a global vector.\n- Instead, diffusion enters the system through **bounded, challengeable claims** with transcripts and slashing.\n\n## Next steps\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# The Transaction Graph\n\nA weighted, directed graph capturing economic relationships, used via snapshot-relative diffusion to allocate incentives and resist Sybil attacks.\n\nThe transaction graph is a weighted, directed graph that captures economic relationships between participants. Each completed interaction adds or updates an edge, and the protocol uses the resulting connectivity (via snapshot-relative diffusion) to allocate incentives and resist Sybil manipulation.\n\n\n## Graph Structure\n\nLet the global transaction graph at epoch $t$ be:\n\n$$\nG_t = (V, E_t, w_t)\n$$\n\n- $V$: participants (buyers, producers, agents, domains, etc.)\n- $E_t \\subseteq V \\times V$: directed edges representing completed interactions\n- $w_t: E_t \\to \\mathbb{R}_{\\ge 0}$: nonnegative edge weights\n\nIn a marketplace setting:\n\n- buyer $v$ purchasing from producer $u$ adds edge $(v \\to u)$\n- an optional reverse edge $(u \\to v)$ can represent fulfillment confirmation, dispute outcomes, or service-proof acknowledgements\n\n::callout{type=\"note\" title=\"Market partitioning\"}\nCommerce edges are market-tagged. The market tag is **not user-provided**: it is derived from the MarketContext that emitted the interaction record and must match the canonical registry state. See: [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry).\n::\n\n::callout{type=\"note\" title=\"Intuition\"}\nThe graph is a ledger-friendly data structure: edges are “who paid whom for what,” and weights are “how much that interaction counts.” These are **facts** derived from transactions and dispute outcomes.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nInteraction graphs and reputation-as-edges, e.g. [EigenTrust](https:\u002F\u002Fwww.cs.stanford.edu\u002F~dkamvar\u002Fpapers\u002Feigentrust.pdf).\n::\n\n::callout{type=\"note\" title=\"Why it fits\"}\nSeparating **facts** (edges\u002Fweights\u002Fproofs\u002Fdisputes) from **interpretations** (diffusion scores computed on snapshots) is what makes the protocol scalable and verifiable.\n::\n\n### Edge weights\n\nEach completed transaction produces an edge weight:\n\n$$\nw_t(v,u) = \\mathrm{amount}(v,u)\\cdot \\mathrm{quality}(v,u)\\cdot \\mathrm{proof\\_factor}(v,u)\n$$\n\nWhere:\n\n- `amount` is the economic value (price, fee base, etc.)\n- `quality` accounts for dispute outcomes, refunds, chargebacks, delivery SLAs, etc.\n- `proof_factor` is derived from attached service proofs and identity proofs\n\nThe protocol constrains weights to prevent pathological abuse (per-edge min\u002Fmax, per-transaction caps, epoch caps, and\u002For decay).\n\n## Key Features\n\n### 1. **Dynamic Adjustments**\n\nThe transaction graph dynamically adjusts based on participant interactions. As transactions occur, edge weights are updated, causing changes in connectivity and node influence. This creates a **self-optimizing system** where token distributions reflect the evolving state of the network.\n\n### 2. **Connectivity as a Measure of Value**\n\nThe graph not only captures transaction volume but also **connectivity**:\n- Nodes with more connections to well-connected nodes are considered more influential.\n- This approach ensures that participants contributing to network growth through broad connectivity earn higher rewards, not just participants with high transaction volumes with a single counterparty.\n\n### 3. **Sybil Resistance**\n\nThe graph’s structure inherently resists manipulation through **Sybil attacks**:\n- Sybil nodes (fake users) typically form isolated clusters without strong connections to real nodes.\n- The graph's weighting system prioritizes connections that enhance network-wide connectivity, making it difficult for isolated Sybil nodes to earn high rewards.\n\n## Next Steps\n\nThe transaction graph sets the foundation for diffusion and verification:\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)","# Optimistic Diffusion Claims\n\nParticipants include diffusion-derived rewards as bounded, challengeable claims verified by sampling, caps, bonds, and slashing instead of global computation.\n\nLocal Protocol allows participants to include diffusion-derived reward outputs inside their transaction SDLs **without requiring validators to compute** $r_{t,m}$ as a global vector.\n\nThis uses **optimistic verification**: claims are accepted subject to a challenge window; incorrect claims are deterred with **bonds + slashing** and are verifiable via sampling.\n\n::callout{type=\"note\" title=\"Intuition\"}\nA user can attach a “this is my bounded reward, relative to the last committed snapshot” claim. Validators don’t compute global diffusion; they enforce caps\u002Fbonds and audit a bounded subset.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nOptimistic verification and fraud-proof patterns: [Truebit](https:\u002F\u002Farxiv.org\u002Fabs\u002F1908.04756) and verifier-incentive discussions like the Arbitrum paper ([Kalodner et al., 2018](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fusenixsecurity18\u002Fsec18-kalodner.pdf)).\n::\n\n::callout{type=\"note\" title=\"Why it fits\"}\nDiffusion is expensive globally, but individual claims can be checked with bounded audits. This keeps validator work predictable while shifting compute to provers.\n::\n\n## What a user is allowed to claim\n\nA user submitting a transaction SDL may include a reward claim:\n\n$$\n\\widehat{R}(\\mathrm{tx}) \\le \\delta_{tx}\n$$\n\nThe claim is a function of:\n\n- committed snapshot roots $(\\mathsf{GraphRoot}_t, \\mathsf{SeedRoot}_t)$\n- the canonical snapshot artifact identifier $\\mathsf{SnapshotId}_t$ (to fetch authenticated snapshot data needed for audits, including MarketRegistry; see [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments) and [Performance & Storage](\u002Fdocs\u002Farchitecture\u002Fperformance-storage))\n- protocol parameters $(\\alpha, \\dots)$\n- transaction contents (counterparty, amount, and market context)\n- a protocol-defined estimator (random-walk \u002F Monte Carlo diffusion)\n\n**Safety is achieved by combining**:\n\n- strict caps (deterministic safety rails):\n  - per-transaction: $\\delta_{tx}$\n  - per-user per-epoch: $\\delta^{user}_{epoch}(i)$\n  - per-market per-epoch: $\\delta^{market}_{epoch}(m)$\n  - optional global backstop: $\\delta^{global}_{epoch}$\n- canonical randomness (no grinding)\n- priced verification (bounded work)\n- bonds and slashing (negative EV for cheating)\n- delayed sampling (prevents adaptive transcripts)\n\n::callout{type=\"note\" title=\"Why caps matter even with audits\"}\nAudits are probabilistic, but caps are deterministic. Even if audits miss something temporarily, total extractable value is bounded per user and per market.\n::\n\n::callout{type=\"warning\" title=\"Bounded verification (anti-griefing)\"}\nClaims are structured so audits have deterministic worst-case cost: protocol parameters bound maximum walk length, the number of sampled walks opened per audited claim, and the size of each opening (Merkle proofs + alias-table proofs). These bounds prevent “audit griefing” via oversized transcripts or huge openings.\n::\n\n## Canonical randomness (kills grinding)\n\nEach epoch has a randomness beacon $\\mathsf{Rand}_t$. For each transaction id `txid`, walk seeds are derived deterministically:\n\n$$\n\\mathsf{seed}_{\\mathrm{tx},i} = \\mathrm{PRF}(\\mathsf{Rand}_t, \\mathrm{txid}\\,\\|\\,i)\n$$\n\nThis removes user choice and prevents seed grinding \u002F “variance extraction”.\n\n::callout{type=\"note\" title=\"Intuition\"}\nThe prover doesn’t get to pick the dice rolls: walk randomness is derived from an epoch beacon, so users can’t retry until they get a lucky estimator outcome.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nVerifiable Random Functions: [RFC 9381](https:\u002F\u002Fdatatracker.ietf.org\u002Fdoc\u002Frfc9381\u002F).\n::\n\n::callout{type=\"note\" title=\"Randomness beacon requirements\"}\nAudit selection and transcript determinism rely on $\\mathsf{Rand}_t$ being **unpredictable at commit time** and **bias-resistant** with respect to block proposers\u002Fvalidators. A common appchain design is a threshold BLS beacon in the style of [drand](https:\u002F\u002Fdocs.drand.love\u002Fdocs\u002Fspecification\u002F) (see also Cloudflare’s beacon background: [Randomness Beacon](https:\u002F\u002Fdevelopers.cloudflare.com\u002Frandomness-beacon\u002Fcryptographic-background\u002Frandomness-generation\u002F)).\n::\n\n## Transcript commitment + delayed sampling (prevents adaptive cheating)\n\n### Commit now, sample later\n\nThe prover:\n\n1. computes the claim and a transcript for $N$ Monte Carlo walks\n2. commits to a transcript root $\\mathsf{TranscriptRoot}$\n3. posts a commitment hash:\n\n$$\n\\mathsf{Commit} =\nH(\n\\mathsf{ParamsHash}\n\\,\\|\\, \\mathsf{GraphRoot}_t\n\\,\\|\\, \\mathsf{SeedRoot}_t\n\\,\\|\\, m\n\\,\\|\\, \\mathrm{txid}\n\\,\\|\\, \\mathsf{TranscriptRoot}\n)\n$$\n\n::callout{type=\"note\" title=\"Determinism\"}\nBinding $\\mathsf{GraphRoot}_t$, $\\mathsf{SeedRoot}_t$, plus the market context $m$ makes the transcript commitment deterministic: every verifier replays the *same* market-relative random-walk process on the *same* snapshot using the market’s committed teleport distribution $s_{t,m}$. $\\mathsf{ParamsHash}$ ensures the replay also uses the same estimator settings (walk count, max steps, etc.).\n::\n\n::callout{type=\"note\" title=\"Replay-safety\"}\nBinding $\\mathsf{GraphRoot}_t$ and $\\mathsf{SeedRoot}_t$ prevents replaying a valid transcript under a different snapshot. Binding $m$ prevents reusing the transcript under a different market seed table.\n::\n\n::callout{type=\"note\" title=\"Market derivation is auditable (minimal registry)\"}\nUsers don’t get to pick a favorable `marketId`. In the fact layer, the transaction executes a `MarketContext` that emits an `InteractionRecord`, and the record’s `marketId = m` must match `MarketRegistry[marketContext].marketId` at that height.\nBecause `MarketRegistry` is included in `SnapshotBlob_t` and bound by $\\mathsf{SnapshotId}_t$, auditors can deterministically verify the market derivation while verifying the same claim’s transcript steps against $\\mathsf{GraphRoot}_t$ \u002F $\\mathsf{SeedRoot}_t$.\n::\n\nThen sampling indices are derived from **future randomness** (e.g., $\\mathsf{Rand}_{t+1}$):\n\n$$\n\\mathsf{sampleIndex}_q = \\mathrm{PRF}(\\mathsf{Rand}_{t+1}, \\mathrm{txid}\\,\\|\\,q)\\bmod N\n$$\n\nBecause $\\mathsf{Rand}_{t+1}$ is unknown at commit time, the prover cannot craft a transcript that is only valid on the checked parts.\n\n::callout{type=\"note\" title=\"Intuition\"}\nFirst you lock in the transcript; later the protocol decides which parts must be opened. If you lied anywhere, there’s a good chance the opened part exposes it.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nMerkle commitments and delayed random challenges are standard in fraud-proof protocols.\n::\n\n## Transcript contents (minimal sketch)\n\nFor walk $i$ (length $L_i$):\n\n- starting node $v_{i,0}$ (sampled from the **market-relative** teleport $s_{t,m}$, with teleport sampling proofs against $\\mathsf{MarketSeedRoot}_{t,m}$ and optionally a per-market seed alias commitment $\\mathsf{SeedAliasRoot}_{t,m}$)\n- visited nodes $v_{i,1}, v_{i,2}, \\dots, v_{i,L_i}$\n- for each step $j$:\n  - restart decision correctness\n  - market-scoped edge sampling proof:\n    - open `OutIndex(m)` for the current node via Merkle proof from `marketOutIndexRoot`\n    - prove the sampled outgoing edge index using a Merkle opening against the `aliasRoot` from `OutIndex(m)`\n    - open the selected edge entry via Merkle proof against the `adjacencyRoot` from `OutIndex(m)`\n- final contribution to the estimator (e.g., terminal node count, hit counts, discounted hits)\n\n## Verification and penalties (validator audits)\n\nIn high-volume markets, a protocol-chosen subset of claims is **mandatorily audited by assigned validators**, and failed audits finalize as fact-layer penalties.\n\nSee: [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties)\n\n## Related\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n- [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties)\n- [State Model (SDLs)](\u002Fdocs\u002Farchitecture\u002Fstate-model)","# Incentives in Local Protocol\n\nSnapshot-relative diffusion on the transaction graph dynamically adjusts incentives while keeping validator work bounded and Sybil resistance strong.\n\nLocal Protocol leverages snapshot-relative diffusion on the transaction graph to dynamically adjust incentives while maintaining strong Sybil resistance. Diffusion-derived outputs enter the system through bounded, challengeable claims, keeping validator work bounded and predictable.\n\n::callout{type=\"note\" title=\"Intuition\"}\nDiffusion answers: “if we start from verified activity and let trust spread, where does it end up?” Those scores then feed reward multipliers, risk limits, and market policy knobs.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nGraph diffusion for ranking\u002Ftrust: [PageRank](https:\u002F\u002Fdoi.org\u002F10.1016\u002FS0169-7552(98)00110-X), [Personalized PageRank](https:\u002F\u002Finfolab.stanford.edu\u002F~glenj\u002Fspws.pdf), and seed-set anchoring like [TrustRank](https:\u002F\u002Filpubs.stanford.edu\u002F638\u002F1\u002F2004-17.pdf).\n::\n\n::callout{type=\"note\" title=\"Why it fits\"}\nThe protocol wants local actions (a completed delivery) to have non-local effects (your neighborhood becomes more trusted). Diffusion provides that spillover with clear semantics.\n::\n\n## Next Steps\n\nIn the following sections, we’ll build up the full model:\n\n- [The Transaction Graph](\u002Fdocs\u002Fgames-and-graphs\u002Fgraph)\n- [Snapshot-Relative Diffusion (PageRank \u002F PPR)](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Markets](\u002Fdocs\u002Fmarkets)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n- [Basic Example (PPR intuition)](\u002Fdocs\u002Fgames-and-graphs\u002Fexample)\n- [Insurance & Dispute Resolution](\u002Fdocs\u002Finsurance)\n\nAfter you’re comfortable with the transaction graph, you can dive into the other core protocol layers:\n\n- [Security](\u002Fdocs\u002Fsecurity)\n- [Proofs](\u002Fdocs\u002Fproofs)\n- [Trust](\u002Fdocs\u002Ftrust)\n- [Architecture](\u002Fdocs\u002Farchitecture)","# Graph Commitments & Epoch Snapshots\n\nOne canonical epoch snapshot commitment per epoch — graph, seed, and artifact roots that serve as the reference for diffusion-derived claims.\n\nLocal Protocol finalizes one canonical epoch snapshot commitment per epoch. The ledger commits to snapshot roots and uses them as the canonical reference for any diffusion-derived claims.\n\n## Epochs\n\nTime is divided into epochs $t = 0,1,2,\\dots$. Each epoch defines:\n\n- a committed graph snapshot root $\\mathsf{GraphRoot}_t$\n- a committed teleport\u002Fseed root $\\mathsf{SeedRoot}_t$\n- a canonical randomness beacon $\\mathsf{Rand}_t$\n- protocol parameters $(\\alpha, \\delta_{tx}, \\delta^{user}_{epoch}, \\delta^{market}_{epoch}, \\delta^{global}_{epoch}, k, B, \\dots)$\n\n::callout{type=\"note\" title=\"Cap vector semantics\"}\nThe epoch cap $\\delta_{epoch}$ is not a single number. It’s a **cap vector**:\n\n- $\\delta^{user}_{epoch}(i)$: max claimable output per user\u002Fidentity per epoch\n- $\\delta^{market}_{epoch}(m)$: max claimable output per market\u002Fdomain per epoch\n- $\\delta^{global}_{epoch}$: optional protocol-wide backstop (“fuse”)\n\nThese caps are deterministic safety rails: even if audits miss something briefly, total extractable value is bounded per user and per market.\n::\n\n::callout{type=\"note\" title=\"Intuition\"}\nA snapshot is like taking a photo of the graph once per epoch and publishing a hash of it. Later, anyone can prove facts about that “photo” (this edge existed, this node’s out-weight sum was X) using short inclusion proofs.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nCommitment trees \u002F authenticated datasets via [Merkle trees](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~raluca\u002Fcs261-f15\u002Freadings\u002Fmerkle.pdf).\n::\n\n## Commitment structure\n\nPartition nodes into shards $j$. Each shard publishes:\n\n$$\n\\mathsf{ShardRoot}_{t,j} = \\mathrm{MerkleRoot}(\\text{NodeRecords}_{t,j})\n$$\n\nThe global graph root is:\n\n$$\n\\mathsf{GraphRoot}_t = \\mathrm{MerkleRoot}\\left(\\{\\mathsf{ShardRoot}_{t,j}\\}_j\\right)\n$$\n\n### Seed commitments (market-relative teleport)\nTeleport is **market-relative**: each market `marketId = m` has its own protocol-committed teleport distribution $s_{t,m}$.\n\nTo keep the fact layer compact while supporting many markets, the snapshot commits a **root of roots**:\n\n$$\n\\mathsf{SeedRoot}_t = \\mathrm{MerkleRoot}\\big(\\{(m,\\ \\mathsf{MarketSeedRoot}_{t,m})\\}_m\\big)\n$$\n\nEach per-market seed root commits to the seed-weight table for that market:\n\n$$\n\\mathsf{MarketSeedRoot}_{t,m} = \\mathrm{MerkleRoot}\\big(\\{(v,\\ s_{t,m}(v))\\}\\big)\n$$\n\n::callout{type=\"note\" title=\"Proof-friendly teleport sampling (optional)\"}\nFor O(1) verifiable teleport sampling in transcripts, the snapshot artifact can also include a per-market alias table commitment (e.g., $\\mathsf{SeedAliasRoot}_{t,m}$) for sampling from $s_{t,m}$.\n::\n\n## Snapshot artifact identifier (SnapshotId)\nAudits require authenticated access to snapshot data (NodeRecords \u002F EdgeRecords \u002F alias tables). Each epoch therefore finalizes a **Snapshot Artifact** that is content-addressed and publicly retrievable.\n\n::callout{type=\"warning\" title=\"MarketRegistry is part of the snapshot artifact (required)\"}\nTo make market membership auditable, `SnapshotBlob_t` must include the canonical MarketRegistry table for epoch $t$:\n`marketContext → (marketId, vault, feeRouter, flags)`.\nBecause $\\mathsf{SnapshotId}_t$ binds `SnapshotBlobHash_t`, auditors can verify MarketRegistry lookups against the same snapshot commitments used for graph and seed verification.\n::\n\nAt epoch $t$, let `SnapshotBlobHash_t` be the content hash of the snapshot artifact bytes in the data layer (see [Performance & Storage](\u002Fdocs\u002Farchitecture\u002Fperformance-storage)). The chain commits:\n\n$$\n\\mathsf{SnapshotId}_t\n= H(\n\\mathsf{GraphRoot}_t\n\\,\\|\\, \\mathsf{SeedRoot}_t\n\\,\\|\\, \\mathsf{SnapshotBlobHash}_t\n)\n$$\n\n## Proof-friendly snapshot packaging\n\nTo support efficient verification (including random-walk transcript checks), the snapshot is packaged in structures that are easy to open with Merkle proofs.\n\n::callout{type=\"note\" title=\"Intuition\"}\nThese records are the index that makes audits cheap: a verifier doesn’t need the whole graph—just a few Merkle openings for the edges touched by a sampled walk.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nAuthenticated data structures (Merkleized key–value stores and adjacency lists) used in light-client verification.\n::\n\n### NodeRecord\n\nFor node $u$:\n\n- `nodeId: Address`\n- `marketOutIndexRoot: bytes32` — Merkle root of per-market outgoing-index entries keyed by `marketId`\n- `nodeAttrRoot: bytes32` — root of node attributes (identity proofs, reputation flags, maturity gates)\n\nEach per-market outgoing-index entry (opened by a Merkle proof from `marketOutIndexRoot`) is:\n\n#### OutIndex(m)\n\n- `marketId: uint32`\n- `outWeightSum: uint128` — $\\sum_{x:\\ (u\\to x)\\in E_{t,m}} w_t(u,x)$ for this market\n- `adjacencyRoot: bytes32` — Merkle root of outgoing edges **in this market**\n- `aliasRoot: bytes32` — Merkle root of alias table for O(1) sampling of outgoing edges **in this market**\n- `degree: uint32` — number of outgoing edges in this market\n\n::callout{type=\"note\" title=\"Intuition\"}\nA node’s outgoing edges are partitioned by market. When verifying a walk step for market $m$, a verifier opens `OutIndex(m)` and then verifies the sampled neighbor using that market’s `aliasRoot` + `adjacencyRoot`.\n::\n\n### EdgeRecord\n\nFor an outgoing edge $u \\to v$:\n\n- `dst: Address`\n- `weight: uint128`\n- `edgeAttrRoot: bytes32` — service proof \u002F dispute state commitments\n- `marketId: uint32` — **required** market tag for commerce edges (“this edge belongs to market $m$”). `marketId` MUST match the registry-assigned `marketId` of the producing MarketContext at that block height.\n- `flags: uint32` — dispute outcomes, maturity gating, etc.\n\n### Alias tables (recommended)\n\nFor efficient verifiable sampling from $P_{t,m}(u,\\cdot)$, the protocol supports per-node, **per-market** alias tables (via `OutIndex(m).aliasRoot`):\n\n- alias entries deterministically derived from the market-scoped adjacency list\n- the table commits to sampling structure enabling O(1) verification of a sampled neighbor within the market context\n\n::callout{type=\"note\" title=\"Intuition\"}\nA random walk repeatedly asks: “from $u$, which neighbor $v$ do I jump to next?” Alias tables are a standard trick to sample from a discrete distribution in O(1) time.\n::\n\n::callout{type=\"note\" title=\"Related work\"}\nThe alias method: [Walker (1977)](https:\u002F\u002Fdl.acm.org\u002Fdoi\u002Fpdf\u002F10.1145\u002F355744.355749) and [Vose (1991)](https:\u002F\u002Fdl.acm.org\u002Fdoi\u002F10.1109\u002F32.92917).\n::\n\n## Related\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Markets](\u002Fdocs\u002Fmarkets)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n\n## Snapshot artifacts and data availability\nNodes can check availability via probabilistic sampling (DAS-style checks), as in [LazyLedger](https:\u002F\u002Farxiv.org\u002Fabs\u002F1905.09274) and common DAS primers (e.g., Celestia’s [Data Availability Sampling](https:\u002F\u002Fcelestia.org\u002Fglossary\u002Fdata-availability-sampling\u002F)).\n\nSee: [Performance & Storage](\u002Fdocs\u002Farchitecture\u002Fperformance-storage)","# Identity\n\nLocal Account contracts provide an ERC-4337 account abstraction using P256 and WebAuthn for secure, user-friendly identity management.\n\nThe Local Account contracts provide an [ERC-4337](https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-4337) compliant account abstraction for managing user identities within the Local network. These contracts leverage [P256 elliptic curve cryptography](https:\u002F\u002Fcsrc.nist.gov\u002Fcsrc\u002Fmedia\u002Fevents\u002Fworkshop-on-elliptic-curve-cryptography-standards\u002Fdocuments\u002Fpapers\u002Fsession6-adalier-mehmet.pdf) and [WebAuthn](https:\u002F\u002Fwww.w3.org\u002FTR\u002Fwebauthn-2\u002F) standards to offer secure, user-friendly authentication mechanisms. The primary goals of these contracts are to:\n\n- **Account Abstraction**: Implement ERC-4337 account abstraction to enable advanced functionalities like batching transactions and key rotation.\n- **Key Management**: Support multiple signing keys (1-of-n multisig) with the ability to add or remove keys.\n- **Usability**: Provide a seamless user experience without compromising on security by using `p256` keys compatible with WebAuthn, compatible with passkeys.\n- **Security**: Ensure all cryptographic operations are secure.\n- **Compatibility**: Align with existing and proposed standards like [EIP-7212](https:\u002F\u002Fethereum-magicians.org\u002Ft\u002Feip-7212-precompiled-for-secp256r1-curve-support\u002F14789) for future-proofing.\n\n## Components\n\nThe Local Account system comprises the following on-chain elements:\n\n- **LocalAccount**: The main contract representing a user's account.\n- **LocalAccountFactory**: A factory contract for deploying LocalAccount instances using CREATE2 for deterministic addresses.\n- **LocalVerifier**: A contract for verifying signatures using P256 elliptic curve operations.\n\n```mermaid\nflowchart TD\n    LocalAccountFactory -- deploys --> LocalAccount\n    LocalAccount -- uses --> LocalVerifier\n    LocalAccount -- interacts_with --> IEntryPoint\n```\n\n## LocalAccount Contract\n\n### Overview\n\nThe `LocalAccount` contract implements an ERC-4337 compatible account abstraction. It allows users to:\n\n- Execute multiple transactions atomically.\n- Validate user operations via P256 signatures.\n- Manage multiple signing keys with 1-of-n multisig support.\n- Rotate keys securely.\n\n### Key Features\n\n- **ERC-4337 Compliance**: Implements the `IAccount` interface for compatibility with account abstraction entry points.\n- **Multisig Support**: Allows up to 20 active signing keys, enabling 1-of-n multisig functionality.\n- **Key Rotation**: Supports adding and removing signing keys, enhancing security and flexibility.\n- **WebAuthn Integration**: Uses P256 keys compatible with WebAuthn, facilitating passwordless authentication.\n- **Upgradeable**: Utilizes the UUPS upgrade pattern for future enhancements.\n\n### State Variables\n\n- `numActiveKeys`: Number of active signing keys.\n- `keys`: Mapping from key slots to public keys.\n- `entryPoint`: Reference to the ERC-4337 entry point contract.\n- `verifier`: Instance of the `LocalVerifier` contract.\n- `maxKeys`: Maximum number of signing keys (constant value of 20).\n\n### Methods\n\n#### Initialization\n\n```solidity\nfunction initialize(\n    uint8 slot,\n    bytes32[2] calldata key,\n    Call[] calldata initCalls\n) public virtual initializer\n```\n\n- **Purpose**: Initializes the account with an initial signing key and optional contract calls.\n- **Parameters**:\n  - `slot`: Key slot to store the initial key.\n  - `key`: The P256 public key.\n  - `initCalls`: Array of contract calls to execute during initialization.\n\n#### Transaction Execution\n\n```solidity\nfunction executeBatch(Call[] calldata calls) external onlyEntryPoint\n```\n\n- **Purpose**: Executes multiple transactions atomically.\n- **Parameters**:\n  - `calls`: An array of `Call` structs containing destination, value, and data.\n\n#### User Operation Validation\n\n```solidity\nfunction validateUserOp(\n    UserOperation calldata userOp,\n    bytes32 userOpHash,\n    uint256 missingAccountFunds\n) external override returns (uint256 validationData)\n```\n\n- **Purpose**: Validates a user operation by verifying a P256 signature.\n- **Parameters**:\n  - `userOp`: The user operation to validate.\n  - `userOpHash`: Hash of the user operation.\n  - `missingAccountFunds`: Amount of funds the account needs to cover transaction costs.\n\n#### Signature Validation\n\n```solidity\nfunction isValidSignature(\n    bytes32 message,\n    bytes calldata signature\n) external view override returns (bytes4 magicValue)\n```\n\n- **Purpose**: Validates signatures for ERC-1271 compliance.\n- **Parameters**:\n  - `message`: The message hash that was signed.\n  - `signature`: The signature data.\n\n#### Key Management\n\n- **Add Signing Key**\n\n  ```solidity\n  function addSigningKey(uint8 slot, bytes32[2] memory key) public onlySelf\n  ```\n\n  - **Purpose**: Adds a new signing key to the account.\n  - **Parameters**:\n    - `slot`: The key slot to store the new key.\n    - `key`: The P256 public key.\n\n- **Remove Signing Key**\n\n  ```solidity\n  function removeSigningKey(uint8 slot) public onlySelf\n  ```\n\n  - **Purpose**: Removes an existing signing key from the account.\n  - **Parameters**:\n    - `slot`: The key slot of the key to remove.\n\n#### Utility Methods\n\n- **Get Active Signing Keys**\n\n  ```solidity\n  function getActiveSigningKeys()\n      public\n      view\n      returns (\n          bytes32[2][] memory activeSigningKeys,\n          uint8[] memory activeSigningKeySlots\n      )\n  ```\n\n  - **Purpose**: Retrieves all active signing keys and their slots.\n\n### Access Control\n\n- `onlySelf`: Modifier to restrict functions to be called only by the contract itself.\n- `onlyEntryPoint`: Modifier to restrict functions to be called only by the designated entry point.\n\n### Events\n\n- `AccountInitialized`: Emitted during initialization.\n- `SigningKeyAdded`: Emitted when a new signing key is added.\n- `SigningKeyRemoved`: Emitted when a signing key is removed.\n\n## LocalAccountFactory Contract\n\n### Overview\n\nThe `LocalAccountFactory` contract is responsible for deploying new `LocalAccount` instances using the CREATE2 opcode, allowing for deterministic contract addresses.\n\n### Key Features\n\n- **Deterministic Deployment**: Uses CREATE2 for predictable account addresses.\n- **Prefunding**: Allows prefunding of the account during creation.\n- **Singleton Implementation**: Reuses a single `LocalAccount` implementation for all instances.\n\n### Methods\n\n#### Create Account\n\n```solidity\nfunction createAccount(\n    uint8 keySlot,\n    bytes32[2] memory key,\n    LocalAccount.Call[] calldata initCalls,\n    uint256 salt\n) public payable returns (LocalAccount ret)\n```\n\n- **Purpose**: Deploys a new `LocalAccount` contract or returns the address if it already exists.\n- **Parameters**:\n  - `keySlot`: Key slot for the initial key.\n  - `key`: The P256 public key.\n  - `initCalls`: Array of initialization calls.\n  - `salt`: Salt value for CREATE2.\n\n#### Get Address\n\n```solidity\nfunction getAddress(\n    uint8 keySlot,\n    bytes32[2] memory key,\n    LocalAccount.Call[] calldata initCalls,\n    uint256 salt\n) public view returns (address)\n```\n\n- **Purpose**: Computes the deterministic address of a `LocalAccount` contract based on input parameters.\n\n## LocalVerifier Contract\n\n### Overview\n\nThe `LocalVerifier` contract provides signature verification functionality for P256 signatures, compatible with WebAuthn standards.\n\n### Key Features\n\n- **Signature Verification**: Verifies P256 signatures for both user operations and ERC-1271 compliance.\n- **Upgradeable**: Implements the UUPS upgrade pattern for future enhancements.\n- **Auditability**: Designed with security and auditability in mind.\n\n### Methods\n\n#### Verify Signature\n\n```solidity\nfunction verifySignature(\n    bytes memory message,\n    bytes calldata signature,\n    uint256 x,\n    uint256 y\n) public view returns (bool)\n```\n\n- **Purpose**: Verifies a P256 signature given the message, signature data, and public key coordinates.\n- **Parameters**:\n  - `message`: The original message that was signed.\n  - `signature`: The signature data, including WebAuthn-related fields.\n  - `x`, `y`: Coordinates of the public key on the P256 curve.\n\n### Signature Structure\n\nThe signature used in the `LocalAccount` contract follows a specific structure:\n\n- **Signature Format**:\n\n  ```solidity\n  struct Signature {\n      bytes authenticatorData;\n      string clientDataJSON;\n      uint256 challengeLocation;\n      uint256 responseTypeLocation;\n      uint256 r;\n      uint256 s;\n  }\n  ```\n\n- **Components**:\n  - `authenticatorData`: Data from the authenticator device.\n  - `clientDataJSON`: JSON-encoded client data.\n  - `challengeLocation`: Offset of the challenge in `clientDataJSON`.\n  - `responseTypeLocation`: Offset of the response type in `clientDataJSON`.\n  - `r`, `s`: Signature components.\n\n### Access Control\n\n- `onlyOwner`: Modifier restricting functions to the contract owner.\n- **Ownership Transfer**: Ownership can be transferred to enable upgrades or burned to make the contract immutable.\n\n## Key Concepts\n\n### ERC-4337 Account Abstraction\n\nERC-4337 introduces account abstraction, allowing smart contract accounts to manage their own authentication and transaction validation logic. The `LocalAccount` leverages this standard to provide flexible and secure account management.\n\n### P256 Elliptic Curve Cryptography\n\nThe contracts utilize the P256 elliptic curve for cryptographic operations, ensuring strong security guarantees. P256 is widely used in WebAuthn implementations, facilitating compatibility with modern authentication standards.\n\n### WebAuthn Integration\n\nBy integrating with WebAuthn, users can authenticate using hardware security modules, biometric sensors, or other secure methods without relying on traditional private keys or seed phrases.\n\n## Additional Context\n\n### Gas Optimization\n\nWhile smart contract-based signature verification is more gas-intensive than native precompiles, the `LocalVerifier` is optimized for efficiency:\n\n- **Strauss-Shamir Trick**: Optimizes scalar multiplication in elliptic curve operations.\n- **Extended Jacobian Coordinates**: Enhances efficiency in point addition and doubling.\n- **Progressive Precompiles**: The design anticipates future EVM improvements, such as the proposed EIP-7212 precompile, which would significantly reduce gas costs.\n\n### Future Enhancements\n\n- **EIP-7212 Compatibility**: The contracts are designed to be compatible with the proposed EIP-7212, allowing for potential gas cost reductions if the precompile is adopted.\n- **Key Rotation Replay Protection**: Future versions may include cross-chain replay protection for key rotations.\n\n## References\n\n- [EIP-4337: Account Abstraction](https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-4337)\n- [EIP-7212: P256 Precompile Proposal](https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-7212)\n- [WebAuthn Specification](https:\u002F\u002Fwww.w3.org\u002FTR\u002Fwebauthn\u002F)\n- [P256 Elliptic Curve Details](https:\u002F\u002Fneuromancer.sk\u002Fstd\u002Fnist\u002FP-256)\n- [Wycheproof Test Vectors](https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fwycheproof)\n- [Strauss-Shamir Trick](https:\u002F\u002Fwww.jstor.org\u002Fstable\u002F10.2307\u002F2006182)\n- [Extended Jacobian Coordinates](https:\u002F\u002Fhyperelliptic.org\u002FEFD\u002Fg1p\u002Fauto-shortw-jacobian-0.html)\n\n---\n\n## Next Steps\n\nThat is all for identity. Next up, creating apps.","# Insurance\n\nHow Local Protocol supports insurance markets to manage dispute and slashing risk where proofs are weak or probabilistic.\n\nLocal Protocol can support insurance markets to manage dispute\u002Fslashing risk in settings where proofs are weak or probabilistic. This section is split into two parts:\n\n- [Dispute Resolution & Provider Collateral](\u002Fdocs\u002Finsurance\u002Fdispute-resolution)\n- [Insurance Market & Insurance AMM (IAMM)](\u002Fdocs\u002Finsurance\u002Finsurance-amm)","# Dispute Resolution & Provider Collateral\n\nHow Local Protocol uses provider collateral to provide service guarantees in markets where proofs are weak and disputes are possible.\n\nLocal Protocol’s core transaction flow can require **provider collateral** to provide **service guarantees** in markets where proofs are weak (e.g., PIN exchange) and disputes are possible.\n\n## Dispute Resolution via Provider Collateral\n\nConsider a transaction between provider $u$ and buyer $v$ with payment $p_{uv}$, network fee $w_{uv}$, and provider collateral $l_{uv}$.\n\nSee: [Sampling & Slashing](\u002Fdocs\u002Ftrust\u002Fsampling-slashing) and [Graph Value](\u002Fdocs\u002Fsecurity\u002Fgraph-value).\n\n### Transaction + collateral escrow\n\n- **Escrow setup**: buyer $v$ requests service from provider $u$. The protocol escrows $p_{uv}$ and locks provider collateral $l_{uv}$.\n- **Completion signal**: a proof of agreement (e.g., a PIN exchange) indicates both parties attest service completion.\n\n### Resolution outcomes\n\n- **No dispute (PIN exchanged)**: escrow releases and both $p_{uv}$ and $l_{uv}$ are paid out to the provider.\n- **Dispute (PIN withheld)**: the buyer refuses to exchange the PIN (claims service not provided). The protocol returns $p_{uv}$ to the buyer and **slashes** (burns) $l_{uv}$.\n\nThis mechanism provides a service guarantee to buyers without a trusted intermediary: providers face a direct economic penalty if they fail to complete service, and a dispute is resolved on-chain by the agreed completion signal.\n\n### Collateral sizing\n\nCollateral is modeled as a function:\n\n$$\nl_{uv} = l_{uv}(p_{uv}, G_u, r_u, G_v, r_v)\n$$\n\nwhere $G_u, G_v$ are graph values and $r_u, r_v$ are reputation scores. A common form is:\n\nSee: [Graph Value](\u002Fdocs\u002Fsecurity\u002Fgraph-value) and [Trust Propagation](\u002Fdocs\u002Ftrust\u002Fpropagation).\n\n$$\nl_{uv} = p_{uv} \\, f\\!\\left(\\frac{(r_v - r_{\\rm min}) G_v}{(r_u - r_{\\rm min}) G_u}\\right)\n$$\n\nwith $f(x)$ monotonically increasing, often constrained by $f(1)=1$, $f(0)=0$, and $\\lim_{x \\to \\infty} f(x)=f_{\\rm max}$.","# Insurance Market & Insurance AMM (IAMM)\n\nHow an emergent collateral insurance market and an insurance AMM let providers externalize slashing risk in exchange for a premium.\n\n## Collateral Insurance Market\n\nBecause providers must post $l_{uv}$, they are exposed to the risk that collateral is slashed in a dispute. A natural emergent market is **collateral insurance**, where a third party (or pool) accepts this risk in exchange for a premium.\n\nSee: [Dispute Resolution & Collateral](\u002Fdocs\u002Finsurance\u002Fdispute-resolution).\n\nLet $p_{\\rm slash}$ denote the probability collateral is slashed for a given transaction under an insurer’s risk model. The insurer’s expected cost per transaction is:\n\n$$\n{\\rm Cost} = l_{uv} \\, p_{\\rm slash}.\n$$\n\nTo be profitable, the insurer must charge a premium exceeding expected cost.\n\n## Example Insurance Market: Insurance AMM (IAMM)\n\nAn **insurance automatic market maker (IAMM)** can connect:\n\n- **Insurance liquidity providers**: token holders who stake liquidity into an insurance pool\n- **Providers**: users who pay a premium to externalize slashing risk for the collateral they would otherwise post\n\n### Simple single-price model\n\nLet $I$ be the set of insurance providers. Provider $i \\in I$ stakes $q_i$ tokens. Total pool liquidity is:\n\n$$\nQ = \\sum_{i \\in I} q_i.\n$$\n\nTime is split into epochs of duration $\\tau$, indexed by $t_n = n\\tau$. Pricing for epoch $t_n \\to t_{n+1}$ is determined from utilization in $t_{n-1} \\to t_n$.\n\nIf during epoch $t_{n-1} \\to t_n$, providers purchase insurance over collateral amounts $l_u^{n-1}$, define total insured collateral demand:\n\n$$\nL^{n-1} \\equiv \\sum_{u \\in U} l_u^{n-1}.\n$$\n\nFor a provider insuring collateral $l_u^n$ in epoch $t_n \\to t_{n+1}$, the premium is:\n\n$$\nF_u^n \\equiv \\hat F^n \\, l_u^n\n$$\n\nwhere the epoch pricing constant is:\n\n$$\n\\hat F^n = \\frac{L^{n-1}}{Q^{n-1}}.\n$$\n\nIntuition: price rises when demand $L$ is high relative to available liquidity $Q$, and falls when liquidity is abundant.\n\nAt settlement of epoch $t_n \\to t_{n+1}$, the pool’s realized PnL depends on whether collected premiums exceed realized slashing losses (payouts \u002F collateral covered).\n\n### Self-correcting dynamics\n\n- If the pool loses money, insurance is underpriced; liquidity exits, reducing $Q$, increasing $\\hat F$ until profitability returns.\n- If the pool earns excess profit, liquidity enters, increasing $Q$, reducing $\\hat F$ until the market price equilibrates.\n\n### Concentrated liquidity and granular pricing (risk “ticks”)\n\nRisk is not uniform across transactions. If slashing risk depends on quantities like $r_v G_v$ and $r_u G_u$, a single $\\hat F$ can be unfair. One approach is to price by discrete risk buckets (“ticks”), inspired by concentrated-liquidity AMMs.\n\nSee: [Graph Value](\u002Fdocs\u002Fsecurity\u002Fgraph-value).\n\nFor example, take a risk score proportional to $r_v r_u G_v G_u$. Partition the score range into $J$ ticks indexed by $j = 1, \\dots, J$. Each tick $j$ has pool liquidity $Q_j^n$ and insured collateral demand $L_{n-1}^j$.\n\nTick-level premiums are:\n\n$$\nF_j^n = \\frac{L_{n-1}^j}{Q_{n-1}^j}.\n$$\n\nLiquidity providers can allocate capital across ticks to express a risk view; prices per tick adjust as demand and liquidity shift, producing a more granular insurance curve.","# Markets\n\nProtocol-defined execution contexts with their own policy and accounting, derived from execution and verified against canonical registry state.\n\nMarkets are protocol-defined execution contexts with their own policy and accounting. A market is not a user-chosen label; it is derived from what a transaction executed, and it is verified against canonical registry state.\n\nMarkets also provide the protocol surface for **bootstrapping**: new markets can start sparse and fragmented yet still be scored and incentivized safely via market-relative teleport (seeds) and credit-like reward funding (MarketVaults) with repayment sourced from market fees.\n\n## What lives here\n\n- **Market identity and enforcement**: how a transaction’s market is derived from execution and verified against canonical registry state.\n- **Commitment hooks**: how market tables and fee attribution are bound into epoch commitments.\n- **Bootstrapping and credit**: how early markets can be seeded and funded, with repayment sourced from market fee cashflows.\n\n## Start here\n\n- [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry)\n- [Market Bootstrapping (Seeds + Vaults)](\u002Fdocs\u002Fmarkets\u002Fbootstrapping)\n\n::callout{title=\"Related work (context, not requirements)\"}\n- **Personalized PageRank (PPR)**: market-relative teleport is a protocol-fixed personalization distribution ([Jeh & Widom, 2003](https:\u002F\u002Finfolab.stanford.edu\u002F~glenj\u002Fspws.pdf)).\n- **Seed-anchored filtering**: anchoring trust to protocol-defined seeds is adjacent to ideas like [TrustRank](https:\u002F\u002Filpubs.stanford.edu\u002F638\u002F1\u002F2004-17.pdf).\n- **Authenticated data \u002F commitments**: MarketRegistry is made auditable by including it in snapshot artifacts bound by hash commitments (Merkle trees: [Merkle, 1987](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~raluca\u002Fcs261-f15\u002Freadings\u002Fmerkle.pdf)).\n::","# Market Bootstrapping\n\nMarket-relative teleport, endogenous and exogenous seeds, and per-market credit-line vaults that fund early rewards and repay from market fees.\n\nMarket-relative diffusion avoids a core failure mode of “one global seed set”: **fragmented-but-real markets**. Early markets can also be sparse, so the protocol supports **capital-backed bootstrapping** without discretionary grants.\n\nThis page defines:\n- **Market-relative teleport**: a per-market, protocol-committed teleport distribution $s_{t,m}$\n- **Endogenous market seeds**: hard-to-fake “earned” anchors inside a market\n- **Market Anchors**: capital-backed exogenous anchors that can seed markets early\n- **Market Vaults**: a per-market **credit-line primitive** that funds early rewards and gets repaid from future fees\n\n::callout{title=\"Intuition\"}\nThink of diffusion as “trust spreading” through a market’s transaction history, but it needs a place to start. Seeds define that starting point. Market Vaults fund a market’s early incentive budget and are repaid from that market’s future fees if the market becomes real and active.\n::\n\n---\n\n## Why market-relative teleport exists\nIn marketplace networks, trust is often local to a market context:\n\n- a courier can be highly trusted in one city\u002Fvertical even if the global network is fragmented\n- a new market can be economically real even if it’s weakly connected to global anchors\n\nIf the protocol used one global seed set, naturally isolated markets would look “low influence” even when they are honest. To avoid that, diffusion (and claims derived from it) are evaluated relative to a market `marketId = m`, using the market’s committed teleport distribution $s_{t,m}$.\n\n::callout{title=\"What “teleport” means\"}\nTeleport is the restart step in Personalized PageRank (PPR): with some probability, the walk jumps back to a protocol-defined distribution instead of following an edge. That restart distribution is what the protocol treats as its “trusted starting points”.\n\nSee: [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion).\n::\n\n::callout{title=\"Related work (teleport \u002F anchoring)\"}\n- **Personalized PageRank**: [Jeh & Widom, 2003](https:\u002F\u002Finfolab.stanford.edu\u002F~glenj\u002Fspws.pdf)\n- **Seed anchoring \u002F spam demotion** (adjacent framing): [TrustRank](https:\u002F\u002Filpubs.stanford.edu\u002F638\u002F1\u002F2004-17.pdf)\n::\n\n---\n\n## Per-market seed commitments (root of roots)\n\nSeeds are not user-chosen. The protocol commits to them each epoch so that claims and audits can be verified against a fixed reference.\n\nThe chain commits to per-market seed tables via a root-of-roots:\n\n$$\n\\mathsf{SeedRoot}_t = \\mathrm{MerkleRoot}\\big(\\{(m,\\ \\mathsf{MarketSeedRoot}_{t,m})\\}_m\\big)\n$$\n\n$$\n\\mathsf{MarketSeedRoot}_{t,m} = \\mathrm{MerkleRoot}\\big(\\{(v,\\ s_{t,m}(v))\\}\\big)\n$$\n\n::callout{title=\"Verifier view\"}\nWhen verifying a claim in market $m$, a verifier opens $\\mathsf{MarketSeedRoot}_{t,m}$ from $\\mathsf{SeedRoot}_t$ and checks teleport sampling proofs against that market’s table.\n::\n\n::callout{title=\"Why commit seeds at all?\"}\nWithout a commitment, a claimant could “move the goalposts” by choosing a convenient seed set that inflates their score. Committing seed tables makes market-relative diffusion reproducible: anyone can replay the same walk distribution for the same snapshot.\n::\n\n---\n\n## A safety tether: market seeds mixed with a tiny global baseline\n\nMarket-relative seeding fixes fragmented real clusters, but it introduces a risk: **market capture** (a cartel tries to become the market’s only “truth source”).\n\nTo reduce capture risk without creating per-market governance, the teleport distribution can be defined as a fixed mixture:\n\n$$\ns_{t,m} \\;=\\; (1-\\varepsilon)\\cdot s^{local}_{t,m} \\;+\\; \\varepsilon\\cdot s^{global}_{t}\n\\qquad \\text{with a small global constant } \\varepsilon \\in (0,1)\n$$\n\n---\n\n## Recommended seed construction rule (deterministic, low-governance)\n\nThe protocol builds the market-local teleport mass $s^{local}_{t,m}$ from a **union of endogenous and exogenous anchors**, then normalizes and clips.\n\n### 1) Endogenous anchors (earned seeds): diversity + time, not volume\n\nLet `Window_t` be the last $T$ epochs (a global constant). A participant $v$ is endo-eligible in market $m$ iff:\n\n- `Verified(v)`\n- $\\mathrm{UniqueCounterparties}_{\\mathrm{Window}_t,m}(v) \\ge K$\n- $\\mathrm{CompletionCount}_{\\mathrm{Window}_t,m}(v) \\ge C$\n- $\\mathrm{DisputeRate}_{\\mathrm{Window}_t,m}(v) \\le d_{\\max}$\n\n### 2) Exogenous anchors (Market Anchors): concave weight from locked capital\n\nMarket Anchors are addresses that lock capital into the MarketVault for market $m$ and opt into anchor status. Exogenous anchor weight is deliberately concave in capital:\n\n$$\n\\mathrm{ExoWeight}_{t,m}(v) \\;=\\; \\min\\{W_{\\max},\\ f(\\mathrm{Locked}_{t,m}(v))\\}\n\\quad \\text{where } f \\text{ is concave (e.g., } f(x)=\\sqrt{x}\\text{)}\n$$\n\n### 3) Mixture + clipping\n\n$$\ns^{local}_{t,m}(v) \\propto\n\\kappa_{\\mathrm{endo}}\\cdot \\mathrm{EndoWeight}_{t,m}(v)\n\\;+\\;\n\\kappa_{\\mathrm{exo}}\\cdot \\mathrm{ExoWeight}_{t,m}(v)\n$$\n\nThen apply a per-address cap (e.g., $s^{local}_{t,m}(v) \\le s_{\\max}$) and renormalize.\n\n---\n\n## Market Vaults: a “startup credit line” primitive for a market\n\nMarket Vaults are a mechanism for funding early incentives without ad-hoc grants. They work like a credit facility: capital is supplied up-front, and the market repays it with future fees if the market succeeds.\n\nEach market $m$ can have a MarketVault contract that supports:\n\n- **Deposits (credit supply)**: anchors deposit capital into the vault\n- **Draws (protocol borrows)**: the protocol can draw from the vault to fund early reward budgets under policy limits\n- **Repayment (fees repay)**: as the market generates fees, a fixed share routes back to the vault until draws are repaid (plus a policy-defined yield to depositors)\n\n::callout{title=\"Related work (credit-line framing and incentive risks)\"}\n- **Credit delegation framing**: [Aave V3 Credit Delegation guide](https:\u002F\u002Faave.com\u002Fdocs\u002Faave-v3\u002Fguides\u002Fcredit-delegation)\n- **Policy-driven liquidity facility (adjacent)**: Maker’s MIPs index (see D3M-style facilities): [Maker MIPs](https:\u002F\u002Fmips.makerdao.com\u002F)\n- **Bribing \u002F rent-to-control dynamics (adjacent risk surface)**: “Blockchain Bribing Attacks and Mitigations” ([paper](https:\u002F\u002Feprints.gla.ac.uk\u002F357388\u002F1\u002F357388.pdf))\n::\n\n### Fee attribution is ledger-defined\n\nFor a market $m$ in epoch $t$, define $F_{t,m}$ as the realized protocol fee total attributed to market $m$ during epoch $t$.\n\nMechanically, $F_{t,m}$ is derived from finalized execution output:\n\n- sum of `fee` over finalized `InteractionRecord`s with `marketId = m` during epoch $t$\n\nSee: [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry)\n\n### Vault invariants (mechanical constraints)\n\nTo avoid emissions-farming and rent-to-control dynamics, vault rules are mechanical and bounded. Common invariants include:\n\n1. **Fee-first yield**: yield is paid primarily from realized market fees.\n2. **Draw limit**: outstanding draws capped as a fraction of deposits:\n\n$$\n\\mathrm{OutstandingDraw}_{t,m} \\le \\phi \\cdot \\mathrm{TotalDeposits}_{t,m}\n\\quad \\text{(global constant } \\phi)\n$$\n\n3. **Risk haircut \u002F clawback**: if dispute\u002Ffraud losses exceed thresholds, repayment\u002Fyield is haircutted under policy.\n4. **Lockup for anchors**: deposits that confer seed weight require a minimum lock duration.\n\n---\n\n## Related\n\n- [Market Registry](\u002Fdocs\u002Fmarkets\u002Fregistry)\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# Market Registry\n\nHow a transaction’s market is derived from the executing MarketContext and canonicalized against the protocol MarketRegistry.\n\nMarkets are defined as **execution contexts**. A transaction’s market is derived from the MarketContext contract\u002Frouter that emitted an `InteractionRecord`, not from user-provided metadata.\n\n## Markets are derived from execution\n\n- **MarketContext**: an on-chain contract (or router) that emits canonical `InteractionRecord`s for a commercial context.\n- **Market (`m`)**: a policy + accounting container bound to one MarketContext.\n- **`marketId`**: a registry-assigned identifier derived from the executed MarketContext.\n\n## MarketRegistry (canonicalization)\n\nThe protocol maintains a canonical MarketRegistry:\n\n```txt\nmarketContext → (marketId, vault, feeRouter, flags)\n```\n\nwhere:\n\n- `marketId: uint32`: registry-assigned market identifier (unique; not user-chosen)\n- `vault: Address`: MarketVault for this market (MAY be `0x0` if unused)\n- `feeRouter: Address`: where protocol fees for this market are routed\n- `flags: uint32`: e.g. ACTIVE \u002F DEPRECATED\n\n## InteractionRecords\n\nAn `InteractionRecord` is emitted by a registered MarketContext during execution and is included in an SDL. Minimal sketch:\n\n- `marketId: uint32`\n- `marketContext: Address`\n- `buyer: Address`\n- `provider: Address`\n- `amount: uint128`\n- `fee: uint128`\n- `edgeDelta` and\u002For other protocol-defined graph\u002Fattribute deltas\n- `proofRefs: bytes32[]`\n- `disputeRefs: bytes32[]` (if applicable)\n\n### Validity rule (critical)\n\nAn interaction record (and any resulting commerce edges) is valid only if:\n\n- `MarketRegistry[marketContext].marketId == marketId` **at that block height**\n- the market is **ACTIVE**\n\n::callout{title=\"Security note\"}\nThe security-critical requirement is that **users cannot choose a favorable market label**. By deriving `marketId` from the executed `marketContext` via a canonical registry mapping, market-scoped caps, seeds, and accounting can be enforced deterministically.\n::\n\n::callout{title=\"Related work (context, not requirements)\"}\n- **Authenticated commitments**: binding MarketRegistry into a snapshot artifact so verifiers can check market attribution via short openings is a standard authenticated-data pattern (Merkle trees: [Merkle, 1987](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~raluca\u002Fcs261-f15\u002Freadings\u002Fmerkle.pdf)).\n::\n\n## Related\n\n- [Market Bootstrapping](\u002Fdocs\u002Fmarkets\u002Fbootstrapping)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)","# More Resources\n\nLightweight supporting material for the Local Protocol documentation, including quick-reference pages and navigation aids.\n\nThis section contains lightweight supporting material for the Local Protocol documentation, such as quick-reference pages and navigation aids.\n\n## Next Steps\n\n- :site-link{name=\"whitepaper\"}[Read the whitepaper] — the original Local Protocol whitepaper.\n- :site-link{name=\"github\"}[Browse the code on GitHub] — protocol implementations and tooling.","# Proofs in Local Protocol\n\nHow Local Protocol treats verifiability as a spectrum and uses identity and service proofs as graph attributes to bootstrap trust.\n\nLocal Protocol targets decentralized physical infrastructure networks (DePINs) where many valuable services lack cheap, deterministic proofs. The protocol treats verifiability as a spectrum and provides mechanisms that remain secure even when only probabilistic evidence is available.\n\nOur approach acknowledges a spectrum of verifiability and provides a path forward for networks that may not have access to hard or cost-effective service proofs.\n\nLocal Protocol is an expressive architecture whose approach to verifiability is adaptable to a wide range of DePIN projects. In the root case, the protocol assumes that services do not have access to robust service-proofs.\n\n## Spectrum of Verifiability\n\nVerifiability is a spectrum between:\n\n- **Hard proofs**: deterministic, cryptographically verifiable evidence (e.g., cryptographic attestations, signatures tied to objective system events).\n- **Soft proofs**: probabilistic evidence (e.g., location signals, sensor readings, human attestations, reputation signals) that can be informative but not perfectly binding.\n\nLocal Protocol is designed so **soft proofs can still be useful** without becoming a free attack surface: they feed into bounded weights, market-relative seeds, and claim verification (caps + audits + slashing).\n\n## Proofs as Graph Attributes\nIn graph theory, a node is a point representing an entity (buyer, seller), and an edge is a connection between two nodes (transactions). In Local protocol, we model identity-proofs (and other trust attributes for users) as node attributes and service-proofs as edge attributes. \n\nSee: [The Transaction Graph](\u002Fdocs\u002Fgames-and-graphs\u002Fgraph) and [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments).\n\nProofs are ledger facts attached to nodes\u002Fedges. The protocol consumes them in a few specific places (seed construction, edge-weight adjustment, risk\u002Fcap policy), and their effect propagates through the graph via snapshot-relative diffusion.\n\nYou can think of both identity and service proofs as injecting trust into the network. As the network becomes more trustworthy, the protocol becomes more confident in distributing rewards that are greater than the fees collected for each transaction. This unlocks a rich surface area for capital formation to bootstrap new markets. New markets can inherit the security from existing markets providing the network with a strong cross-market network effect. \n\nFor immature markets that want to prioritize bootstrapping trust, proofs can concentrate influence through the protocol-defined, market-relative teleport distribution $s_{t,m}$ and through edge-weight adjustments (see [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion) and [Market Bootstrapping](\u002Fdocs\u002Fmarkets\u002Fbootstrapping)). As the market matures, reliance on expensive proofs can be reduced via policy caps, decay schedules, and lower proof multipliers.\n\n### Trust propagation under diffusion\nUnder snapshot-relative diffusion, proofs influence the walk in two protocol-defined ways:\n\n- **Seed mass (teleport) updates**: stronger proofs can increase $s_{t,m}(v)$ (in market context $m$) or seed eligibility.\n- **Edge weight adjustments**: service proofs\u002Fdisputes change `proof_factor` and `quality` in edge weights.\n\nSee: [Service Proofs](\u002Fdocs\u002Fproofs\u002Fservice-proofs) and [Dispute Resolution & Collateral](\u002Fdocs\u002Finsurance\u002Fdispute-resolution).\n\nThe effect naturally diminishes over distance: in a restarted random walk, influence along length-$k$ paths is damped by roughly $(1-\\alpha)^k$.\n\n## Probabilistic evidence and confidence\nMany proofs are not binary. Local Protocol treats these as **confidence-weighted** signals and uses them only through protocol-defined, bounded interfaces.\n\nSee: [Proofs as Probabilities](\u002Fdocs\u002Fproofs\u002Fprobabilities)\n\n## Proof attachments in State Diff Lists (SDLs)\nProofs are committed to the canonical ledger as part of execution outputs. Concretely, proofs can be included as **proof attachments** inside a **State Diff List (SDL)**—the compact, verifiable bundle of ledger mutations that is produced by execution and finalized by the protocol.\n\nSee [State Model](\u002Fdocs\u002Farchitecture\u002Fstate-model) for the definition of SDLs and how they compose into a single canonical state.\n\n## Next Steps\n\n- [Proofs Overview](\u002Fdocs\u002Fproofs\u002Foverview)\n- [Identity Proofs](\u002Fdocs\u002Fproofs\u002Fidentity-proofs)\n- [Service Proofs](\u002Fdocs\u002Fproofs\u002Fservice-proofs)\n- [Proofs as Probabilities](\u002Fdocs\u002Fproofs\u002Fprobabilities)\n- [Location Proofs](\u002Fdocs\u002Fproofs\u002Flocation-proofs)","# Identity Proofs as Node Attributes\n\nHow identity proofs are committed as node attributes to boost trustworthiness, Sybil resistance, and incentives.\n\nExamples of identity proofs include:\n- [World ID](https:\u002F\u002Fworldcoin.org\u002Fworld-id)\n- [zkPassport](https:\u002F\u002Fzkpassport.app\u002F)\n- [Opacity Network](https:\u002F\u002Fwww.opacity.network\u002F#how-it-works), or other zkTLS authentication with a relevant Web2 provider\n\nThese proofs increase a node’s **trustworthiness**, which can translate into higher rewards and better economic terms. They enhance **Sybil resistance** by allowing the protocol to anchor diffusion in verified participants.\n\nSee: [Sybil Resistance](\u002Fdocs\u002Fsecurity\u002Fsybil-resistance) and [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion).\n\nThese proofs can be assigned a score that unlocks a larger block rewards for both this node and any transacting counterparties. Specifically, we boost nodes that have evidence of realness because it provides the network with stronger sybil resistance.\n\n## How identity proofs affect diffusion and incentives\nIn Local Protocol, identity proofs are committed as **node attributes** (via snapshot commitments) and can influence the system in protocol-defined ways:\n\nSee: [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments).\n\n- **Teleport \u002F seed mass**: identity-verified nodes can be included in the protocol-defined, market-relative teleport distribution $s_{t,m}$, or receive higher $s_{t,m}(v)$ weights.\n- **Policy gating**: identity attributes can raise per-tx caps, lower required bonds, or relax verification requirements (or the opposite), depending on market maturity and fraud risk.\n\nThis framing keeps diffusion **snapshot-relative** (defined on committed roots) while allowing markets to bootstrap trust without hard proofs on every transaction.\n\n## Next Steps\n\nNext: **Service Proofs**, which strengthen the reliability of individual transactions in the network.","# Location Proofs\n\nHow probabilistic location signals are modeled as soft service proofs and combined with caps and slashing to bootstrap markets.\n\n## The problem\nMany physical services don’t have cheap, deterministic proofs. For example, “a driver arrived at the right doorstep” is hard to prove cryptographically at low cost.\n\nIf every transaction required high-quality proofs, proof generation could break the unit economics of the underlying service.\n\n## Proof-of-location as a soft proof\nLocation signals (GPS, cell triangulation, Wi-Fi, attestations) are often **probabilistic**. In Local Protocol, these are modeled as **edge attributes** (service proofs) that affect the transaction graph through:\n\n- $\\mathrm{proof\\_factor}$: higher confidence → higher effective edge weight\n- $\\mathrm{quality}$: disputes\u002Fchargebacks → lower effective edge weight\n\nThese adjustments feed into snapshot-relative diffusion on the committed graph snapshot.\n\n## Why this helps immature markets\nIn small markets, collusion remains possible even with strong evidence. The protocol therefore combines proofs with:\n\n- anchored diffusion (teleport mass from verified seeds)\n- strict caps on claimable rewards\n- challengeable claims with bonds + slashing\n\nThis allows bootstrapping while keeping dishonest inflation negative expected value.\n\n## Related\n\n- [Service Proofs](\u002Fdocs\u002Fproofs\u002Fservice-proofs)\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# Proofs Overview\n\nProofs are committed as ledger facts and consumed as graph attributes for identity and service outcomes.\n\nProofs are committed as ledger facts and consumed as **graph attributes** (node attributes for identity, edge attributes for service outcomes).\n\nSee: [Proofs in Local Protocol](\u002Fdocs\u002Fproofs)\n\n## Next Steps\n\n- [Identity Proofs](\u002Fdocs\u002Fproofs\u002Fidentity-proofs)\n- [Service Proofs](\u002Fdocs\u002Fproofs\u002Fservice-proofs)\n- [Proofs as Probabilities](\u002Fdocs\u002Fproofs\u002Fprobabilities)\n- [Location Proofs](\u002Fdocs\u002Fproofs\u002Flocation-proofs)","# Proofs as Probabilities\n\nHow Local Protocol models non-deterministic proofs as confidence-weighted evidence consumed through bounded interfaces.\n\nMany proofs are not deterministic. Location signals, sensor readings, and human attestations are often best modeled as **probabilistic evidence** with a confidence score. Local Protocol uses these signals only through protocol-defined, bounded interfaces so they can improve incentives without becoming an unbounded attack surface.\n\nSee: [Proofs in Local Protocol](\u002Fdocs\u002Fproofs)\n\n## Confidence-weighted evidence\n\nModel a proof attachment as evidence with confidence $c \\in [0,1]$, where $c=1$ means “strong evidence” and $c=0$ means “no evidence”.\n\nThe protocol does not need to agree on a universal meaning of $c$. It only requires:\n\n- a deterministic rule for how $c$ affects ledger-level policy inputs (weights, seed eligibility\u002Fweight, caps\u002Fbonds),\n- and objective verification hooks where possible (e.g., by sampling proofs in audits or requiring stronger bonds for high-impact claims).\n\n## How probabilistic proofs affect the graph\n\nProbabilistic proofs are consumed in two primary places:\n\n- **Edge weights** (service proofs): adjust `proof_factor` (and sometimes `quality`) in:\n\n$$\nw_t(v,u) = \\mathrm{amount}(v,u)\\cdot \\mathrm{quality}(v,u)\\cdot \\mathrm{proof\\_factor}(v,u)\n$$\n\n- **Seed mass** (identity\u002Fservice baselines): affect seed eligibility and\u002For seed weight in the market-relative teleport distribution $s_{t,m}$ used by diffusion.\n\nBecause diffusion follows outgoing edges proportional to weights and restarts from $s_{t,m}$, confidence-weighted evidence influences incentives by changing where influence can flow.\n\n## Dampening over distance and time\n\nEven strong evidence should not create permanent or global privilege.\n\n- **Distance dampening**: in a restarted random walk, influence along length-$k$ paths is damped by roughly $(1-\\alpha)^k$.\n- **Time decay**: implementations can apply deterministic decay schedules to proof-derived boosts (edge-weight multipliers and\u002For seed weights) so old evidence fades unless refreshed.\n\n## Practical guidance (protocol-level)\n\n- **Bounded impact**: clamp proof-derived multipliers and seed weights (caps prevent “proof = unlimited reward”).\n- **Risk coupling**: require stronger bonds for claims that rely heavily on proof multipliers, and reduce future capacity via penalties when audits fail.\n- **Market-relative context**: evaluate proof effects within a market context; bootstrapping mechanisms (seeds + vaults) can vary across markets while keeping the algorithm fixed.\n\nSee: [Market Bootstrapping](\u002Fdocs\u002Fmarkets\u002Fbootstrapping)\n\n## Next Steps\nNext, see an example of probabilistic evidence in action:\n\n- [Location Proofs](\u002Fdocs\u002Fproofs\u002Flocation-proofs)","# Service Proofs as Edge Attributes\n\nHow service proofs verify completed transactions and feed into edge weights through proof_factor and quality.\n\nService proofs verify that a transaction has been successfully completed between a buyer and a provider. In the Local Protocol, these proofs can take the form of pin exchanges, location proofs, or other evidence of service completion. Service proofs enhance the reliability of the transaction graph, ensuring that rewards are allocated for users performing real transactions and not fake transactions.\n\nWhen available, service proofs can be integrated into the **graph value** calculation, increasing the weight of the corresponding edge for the transaction, making it more valuable to the network.\n\n## How service proofs affect diffusion and incentives\nEach directed edge $(v \\to u)$ can have a weight:\n\n$$\nw_t(v,u) = \\mathrm{amount}(v,u)\\cdot \\mathrm{quality}(v,u)\\cdot \\mathrm{proof\\_factor}(v,u)\n$$\n\nService proofs primarily affect:\n\n- **$\\mathrm{proof\\_factor}$**: stronger evidence of completion increases the effective edge weight.\n- **$\\mathrm{quality}$**: dispute outcomes, refunds, or chargebacks can decrease the effective weight.\n\nBecause diffusion follows outgoing edges proportional to weights, increasing $\\mathrm{proof\\_factor}$ (or $\\mathrm{quality}$) increases how much trust\u002Finfluence can flow through that interaction in snapshot-relative diffusion.\n\n## Key Concepts\n- **Transaction Verification**: Confirms that services have been provided as agreed.\n- **Graph Integration**: Boosts graph value, aligning rewards with verifiable transactions.\n\n## Next Steps\n\nNext, see how the protocol models confidence-weighted evidence:\n\n- [Proofs as Probabilities](\u002Fdocs\u002Fproofs\u002Fprobabilities)","# Security in Local Protocol\n\nHow Local Protocol achieves security through graph structure and cryptoeconomic incentives.\n\nSecurity within Local Protocol is achieved through a combination of **graph structure** and cryptoeconomic incentives:\n\n- diffusion influence is anchored in protocol-defined verified seeds (Sybil isolation),\n- diffusion-derived outputs are **bounded** and **fraud-proofable** (optimistic verification),\n- dishonesty is deterred with **bonds + slashing** under canonical randomness.\n\nLocal Protocol also accounts for incentive-system manipulation surfaces:\n\n- **rent-to-control market relevance**: if influence or market budgets can be cheaply rented (via bribery\u002Fvote-buying or short-lived capital), actors may rationally purchase control rather than build real commerce. Mitigations include market caps, per-address seed caps, concave capital weighting, anchor lockups, delayed sampling, and mandatory audits with slashable attestations.\n\nSee: [Markets](\u002Fdocs\u002Fmarkets).\n\n## Next Steps\n\nIf you haven’t read the core model yet:\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n\nThen continue here:\n\n- [Graph Value](\u002Fdocs\u002Fsecurity\u002Fgraph-value)\n- [Sybil Resistance](\u002Fdocs\u002Fsecurity\u002Fsybil-resistance)","# Graph Value\n\nThe protocol's epoch-based economic evaluation surface aggregating ledger facts and diffusion influence to drive incentives.\n\nGraph Value is the protocol’s epoch-based “economic evaluation surface.” It aggregates ledger facts (executed activity) and snapshot-relative interpretations (diffusion influence) to drive incentives.\n\n## Introduction to Graph Value\n\nIn Local Protocol, Graph Value measures both **economic activity** and **network influence** for each participant, but it updates **once per epoch** (not continuously per transaction). Diffusion influence is defined over the committed snapshot for that epoch and can be consumed through bounded claims.\n\n## Components\n\nFor participant $u$ during epoch $t$:\n\n- $W_{u,t}$: transaction volume (ledger fact; aggregated from executed edges)\n- $r_{u,t,m}$: diffusion influence on snapshot $G_t$ in market context $m$ (snapshot-relative; *not a ledger fact*)\n- $\\mathrm{Rep}_{u,t}$: reputation score (disputes, proofs, completion history)\n\n## Epoch update rule\n\nGraph Value is updated once per epoch:\n\n$$\nG_{u,t+1} = (1-\\beta)\\,G_{u,t} + \\beta\\cdot\n\\Big(\n\\lambda_W \\cdot \\mathrm{norm}(W_{u,t})\n+ \\lambda_r \\cdot \\mathrm{norm}(r_{u,t,m})\n+ \\lambda_{rep}\\cdot \\mathrm{norm}(\\mathrm{Rep}_{u,t})\n\\Big)\n$$\n\nWhere:\n- $\\beta \\in (0,1)$ is a smoothing factor\n- $\\lambda_W,\\lambda_r,\\lambda_{rep}$ are policy weights\n- `norm` denotes protocol-defined normalization and clipping\n\n### How $r_{u,t}$ is consumed\n\nThe protocol consumes diffusion through **accepted optimistic claims** and bounded epoch-level accounting:\n\n- diffusion appears in the system through **accepted optimistic claims** and bounded epoch-level accounting\n- large or high-impact claims can be subjected to stronger sampling and higher bonds\n\n## Per-transaction reward claim (sketch)\n\nFor a transaction $\\mathrm{tx} = (v \\to u)$ with amount $a$, define a base reward:\n\n$$\nR_{\\mathrm{base}}(\\mathrm{tx}) = \\rho \\cdot \\mathrm{fee}(\\mathrm{tx})\n$$\n\nand a diffusion-based multiplier:\n\n$$\nM_t(\\mathrm{tx}) =\n\\mathrm{clip}\\Big(\n1 + \\eta\\cdot \\mathrm{norm}(\\widehat r_{u,t,m}) + \\eta\\cdot \\mathrm{norm}(\\widehat r_{v,t,m})\n\\Big)\n$$\n\nThen the user-claimed reward is:\n\n$$\n\\widehat R(\\mathrm{tx}) = \\min\\{\\delta_{tx}, R_{\\mathrm{base}}(\\mathrm{tx})\\cdot M_t(\\mathrm{tx})\\}\n$$\n\nWhere $\\widehat r_{u,t,m}$ and $\\widehat r_{v,t,m}$ are Monte Carlo estimators of market-relative diffusion scores on the committed snapshot. The estimator is protocol-defined and must be transcript-verifiable.\n\n## Related\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)","# Security Overview\n\nIntroduction to Local Protocol's security model, rooted in graph structure and cryptoeconomic incentives.\n\nLocal Protocol’s security model is rooted in **graph structure** and cryptoeconomic incentives. This section introduces the core mechanisms and how they fit together.\n\n## Next Steps\n\n- [Graph Value](\u002Fdocs\u002Fsecurity\u002Fgraph-value)\n- [Sybil Resistance](\u002Fdocs\u002Fsecurity\u002Fsybil-resistance)","# Sybil Resistance\n\nHow Local Protocol prevents fake-identity manipulation via snapshot-relative diffusion anchored in a verified teleport set.\n\nSybil resistance is a core security goal: prevent an attacker from creating many fake identities to manipulate incentives. Local Protocol achieves this primarily through **snapshot-relative diffusion** anchored in a protocol-defined **verified teleport set**, and by constraining diffusion-derived rewards through **bounded, challengeable claims**.\n\n## Key Concepts\n\n- **Anchored influence (market-relative)**: diffusion restarts from a protocol-defined, per-market teleport distribution $s_{t,m}$ supported on verified anchors for market $m$. Weakly connected Sybil regions receive little mass within that market context.\n- **Connectivity over volume**: fake transactions tend to remain within the attacker’s region; without strong attachment to verified anchors, they don’t buy meaningful influence.\n- **Economic deterrence**: diffusion-derived rewards are claimed under caps and can be challenged; dishonest inflation is deterred via bonds and slashing.\n\n## Next Steps\n\n- [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion)\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n- [Architecture Overview](\u002Fdocs\u002Farchitecture\u002Foverview)","# Trust in Local Protocol\n\nAn overview of how Local Protocol replaces intermediary trust with a crypto-economic game that propagates trust through local graphs.\n\nLocal Protocol unlocks a new design space where peers across a variety of commercial settings can transact without the need to pay an intermediary. The network uses a crypto-economic game that replaces the trust one would otherwise place in an intermediary. Users are incentivized to complete transactions with a large number of counter-parties to maximize their block reward in their next transaction. \n\nThe protocol propagates trust assumptions through local graphs where the strength of the trust assumptions diminish over longer paths from trusted centers. This mechanism creates a scalable network where self-interested actors participate in a complex multi-agent process to create the network's security guarantee.\n\n## Next Steps\n\nIn the following sections, we will explore how trust assumptions work, how trust propagates through networks, and how malicious actors can be slashed for failing to provide proofs in networks where proofs are expected.","# Trust Overview\n\nTrust in Local Protocol is derived from transaction history and graph connectivity, with mechanisms to propagate and penalize trust assumptions over time.\n\nTrust in Local Protocol is derived from transaction history and graph connectivity, with mechanisms to propagate (and penalize) trust assumptions over time.\n\n## Next Steps\n\n- [Trust Propagation](\u002Fdocs\u002Ftrust\u002Fpropagation)\n- [Sampling & Slashing](\u002Fdocs\u002Ftrust\u002Fsampling-slashing)\n- [Self-Policing](\u002Fdocs\u002Ftrust\u002Fself-policing)","# Trust Propagation\n\nHow trust spreads across the Local Protocol network based on transaction history and graph connectivity, diminishing over longer paths from trusted sources.\n\nTrust propagation in the Local Protocol allows trust to spread across the network based on transaction history and graph connectivity. The concept ensures that trust diminishes gradually as it travels further from a **trusted source node**, enabling the protocol to assess participant reliability over time.\n\nThis mechanism helps the network establish broader trust networks, making it harder for malicious actors to gain undue influence without genuine connectivity.\n\nSee: [The Transaction Graph](\u002Fdocs\u002Fgames-and-graphs\u002Fgraph) and [Snapshot-Relative Diffusion](\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion).\n\n## Key Concepts\n- **Decaying Trust**: Trust assumptions weaken over longer paths from the source.\n- **Network-Wide Impact**: Trust spreads through the transaction graph, enhancing overall reliability.\n\n## Trust under snapshot-relative diffusion\nUnder diffusion, proofs inject trust in **protocol-defined ways**:\n\n- **Seed mass (teleport) updates**: proofs can increase $s_{t,m}(v)$ (or inclusion in the seed set) for verified identities\u002Fdomains, in market context $m$.\n- **Edge weight adjustments**: service proofs and dispute outcomes modify edge weights via `proof_factor` and `quality`.\n\nSee: [Service Proofs](\u002Fdocs\u002Fproofs\u002Fservice-proofs) and [Dispute Resolution & Collateral](\u002Fdocs\u002Finsurance\u002Fdispute-resolution).\n\nThe effect of a proof naturally diminishes with path length: in a restarted random walk, influence along length-$k$ paths is damped by roughly $(1-\\alpha)^k$.\n\nYou can visualize the network as a series of concentric circles centered around the node or edge that incorporated a proof. The nodes directly connected form the first circle; these are the immediate neighbors who have direct interactions with the proof-bearing node or transaction. The second circle consists of nodes connected to those immediate neighbors, which are two steps away, and so on. The influence of the proof is strongest at the center and decreases as you move outward.\n\nNodes that transact with those who submit strong proofs benefit more than they would have otherwise. This produces positive security externalities: when self-interested actors invest in verifiability, the network becomes more trustworthy and rewards become more robust.\n\n## Next Steps\n\nIn the next section, we will examine **Sampling & Slashing**, the mechanism used to verify bounded claims and penalize dishonest behavior.","# Sampling & Slashing\n\nHow Local Protocol verifies diffusion-derived economic outputs through sampling and deters dishonesty through bond slashing.\n\nLocal Protocol verifies diffusion-derived economic outputs through **sampling** and deters dishonesty through **slashing**. Participants submit bounded, optimistic claims with transcripts; verifiers check sampled openings against committed snapshot roots.\n\n## Key Concepts\n- **Probabilistic verification**: only a bounded number of transcript walks are checked.\n- **Canonical randomness**: removes prover choice (prevents grinding).\n- **Penalization**: invalid openings cause bond slashing and claim rejection.\n\n::callout{type=\"note\" title=\"Who verifies at scale\"}\nIn high-volume markets, audits are treated as an **obligated validator duty** (not a volunteer challenger market) to avoid audit starvation and free-riding.\n\nSee: [Validator Audits & Penalties](\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties)\n::\n\n## Canonical randomness and delayed sampling\nFor a transaction id `txid` in epoch $t$, the prover’s transcript randomness is derived from $\\mathsf{Rand}_t$. Sampling indices used for challenges are derived from **future randomness** (e.g., $\\mathsf{Rand}_{t+1}$) so the prover cannot adaptively craft transcripts that only satisfy the checked parts.\n\n## What gets slashed\nClaims include a bond $B$. If any sampled transcript opening fails verification, the protocol:\n\n- rejects or reverts the claim output\n- **slashes** the bond $B$ (and any additional penalties defined by policy)\n\nThis makes dishonest inflation negative expected value under appropriate parameter selection.\n\n## Where the details live\nThe precise transcript format and verifier checks are defined by the claim protocol:\n\n- [Optimistic Diffusion Claims](\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims)\n- [Graph Commitments & Epoch Snapshots](\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments)\n\n## Next Steps\n\nThe next topic, **Self-Policing**, will explore how these incentives shape counterparty selection and discourage transacting with dishonest regions.","# A Self-Policing Network\n\nHow incentive alignment leads participants to avoid dishonest regions of the graph, creating a self-policing network.\n\nParticipants prefer to transact with counterparties that are well connected to verified regions of the graph, because doing so increases their expected future rewards and reduces the risk of interacting with dishonest claimants.\n\n::callout{type=\"success\"}\nThe crucial point is incentive alignment: transacting with dishonest regions tends to reduce your expected payouts (via reputation, dispute outcomes, and heightened verification\u002Fbond requirements), creating a self-policing network.\n::\n\n## Why this emerges under optimistic claims\n\nUnder optimistic diffusion claims:\n\n- dishonest inflation can be challenged and punished via **bond slashing**\n- disputed or low-quality interactions reduce edge weights ($\\mathrm{quality}$) and future eligibility\n- policies can require **higher bonds** or stricter sampling for higher-risk regions\n\nAs a consequence, honest users learn to avoid transacting with nodes that are weakly connected to verified anchors or that frequently trigger disputes\u002Fchallenges. This creates a self-reinforcing dynamic where honest regions deepen connectivity, while dishonest regions remain isolated and unprofitable.\n\nThe self-policing nature of the network not only maintains security but also reduces the costs associated with identifying malicious actors. The possibility of being challenged (and losing a bond) discourages dishonest behavior, while honest behavior compounds through connectivity and reputation.","# Probabilistic Proofs in DePIN\n\nModeling identity and service proofs as probabilistic graph attributes in Local Protocol, so trust propagates through the network without hard cryptographic proofs for every transaction.\n\nIn my [last post](\u002Fblog\u002Fpage-rank), I introduced the economic concepts underlying [Local Protocol](\u002Fdocs), a general decentralized marketplace protocol.\n\nLocal protocol aims to address key challenges for decentralized physical infrastructure networks (DePINs) where services are [limited by the availability or cost of proofs](\u002Fblog\u002Fpage-rank#a-spectrum-of-verifiability). We argue that the number of services that have hard cryptographic service-proofs is especially limited in physical networks, which has reduced the surface area and design space for DePIN in general. Local aims to expand this surface area for physical services that can be both peer-to-peer and token-incentivized.\n\nOur approach acknowledges [a spectrum of verifiability](\u002Fblog\u002Fpage-rank#a-spectrum-of-verifiability) and provides a path forward for networks that may not have access to hard or cost-effective service proofs.\n\nLocal Protocol is an expressive architecture whose approach to verifiability is adaptable to a wide range of DePIN projects. In the root case, the protocol assumes that services do not have access to robust service-proofs.\n\nIn this post, I discuss incorporating service-proofs and identity-proofs for network's that have access to such things. I'll share why modeling proofs in Local Protocol is more cost effective than opinionated or narrow DePIN architectures, and argue that DePIN requires Local Protocol to unlock new use cases that are limited by the availability or cost of proofs.\n\n## Local Protocol Design Recap\n\nLocal Protocol is a cryptoeconomic game where buyers and sellers develop connectivity by fulfilling transactions. As users complete transactions, the protocol creates a trustless transaction graph. The block reward for the subsequent transaction is dictated by a relative connectivity ranking (more specifically, their eigenvector centrality (EC)). Self-interested actors aim to enhance their connectivity ranking which requires cooperation with transacting parties that are transacting with similar cohorts of the network. The network incentivizes users with a large reward for developing connectivity, providing the network with a strong bootstrapping and referral mechanism that doubles as the network's security guarantee.\n\n### Difficulty in Manufacturing Connectivity\n\nAchieving a high EC score requires not only a large number of connections but also connections to other well-connected nodes. This property makes it challenging for malicious actors to manufacture high connectivity rankings, as they would need to establish links with reputable, central nodes in the network.\n\nLegitimate, highly-connected nodes are more likely to scrutinize and avoid suspicious or low-quality nodes. As a result, attackers face significant hurdles to manipulate their EC scores.\n\n## Proofs as Graph Attributes\n\nIn graph theory, a node is a point representing an entity (buyer, seller), and an edge is a connection between two nodes (transactions). In Local protocol, we model identity-proofs (and other trust attributes for users) as node attributes and service-proofs as edge attributes.\n\nWe can assign a degree of confidence to such proofs and propagate the trust assumptions that we derive from each proof through the graph to neighboring nodes with a dampening factor over longer path lengths from the trusted node. This allows us to reduce the requirement of capturing potentially cost-prohibitive proofs for every transaction without sacrificing the security guarantee for the network.\n\nYou can think of both identity and service proofs as injecting trust into the network. As the network becomes more trustworthy, the protocol becomes more confident in distributing rewards that are greater than the fees collected for each transaction. This unlocks a rich surface area for capital formation to bootstrap new markets. New markets can inherit the security from existing markets providing the network with a strong cross-market network effect.\n\nFor immature local networks that want to prioritize bootstrapping trust, EC rankings can help establish trust vectors through a combination of service proofs and identity proofs. As the network grows and trust is established, the reliance on expensive service-proofs can be gradually reduced with a dampening factor over time.\n\n### Trust Propagation\n\nThe boost in eigenvector centrality (EC) resulting from any proof—be it an identity proof or a service proof—doesn't just affect the individual node or transaction; it **propagates through the network** due to the recursive nature of the EC calculation. Nodes directly connected to the node or edge associated with the proof will also see an increase in their EC because their centrality depends on the centrality of their neighbors.\n\nThe effect of any proof diminishes exponentially over longer paths in the graph. The modified EC calculation naturally captures this phenomenon, as the solution to the inhomogeneous eigenvalue problem (more on this later) accounts for the additional trust introduced by the proofs (the doping vector for nodes or adjusted weights for edges).\n\nYou can visualize the network as a series of concentric circles centered around the node or edge that has incorporated a proof. The nodes directly connected form the first circle; these are the immediate neighbors who have direct interactions with the proof-bearing node or transaction. The second circle consists of nodes connected to those immediate neighbors, which are two steps away, and so on for subsequent circles. The influence of the proof's boost in eigenvector centrality is strongest at the center and decreases exponentially as you move outward.\n\nNodes that transact with those who have submitted proofs benefit more than they would have without the proofs. This results in higher rewards for both parties and increases their attractiveness as transaction partners in the network. In this way, nodes in the network might view the submission of proofs, and thus the increase in security for the network, as an investment in their EC. When self-interested actors perform actions that have positive security externalities, we achieve strong design properties.\n\n## Identity Proofs as Node Attributes\n\nExamples of identity proofs include [World ID](https:\u002F\u002Fworldcoin.org\u002Fworld-id), [zkPassport](https:\u002F\u002Fzkpassport.app\u002F), or a zkTLS authentication with a relevant Web2 provider using [Opacity Network](https:\u002F\u002Fwww.opacity.network\u002F#how-it-works). These proofs can be assigned a score that unlocks a larger block rewards for both this node and any transacting counterparties. Specifically, we boost nodes that have evidence of realness because it provides the network with stronger sybil resistance.\n\n### Incorporating Identity Proofs into Eigenvector Centrality\n\nWe represent the network as a bipartite graph $G = (U, V, E)$, where $U$ and $V$ are disjoint sets of nodes representing producers (sellers) and buyers, respectively, and $E$ is the set of edges representing transactions between them.\n\nThe eigenvector centrality (EC) $x$ of the nodes in the graph is calculated by solving the eigenvalue problem:\n\n$$\\lambda_{\\text{max}} \\mathbf{x} = \\mathbf{A} \\mathbf{x}$$\n\nwhere $A$ is the adjacency matrix of the graph, and $\\lambda_{\\text{max}}$ is the largest eigenvalue.\n\nWhen a user provides an **identity proof**, we model this as adding a **doping vector** $b$ to the eigenvalue equation. This can be captured by modifying the EC formula to become an inhomogeneous eigenvalue problem. Suppose user $u$ submits an identity proof that translates into a boost of $b$ in eigenvector centrality. We then define a \"doping vector\" $\\vec{b}_u = (0,0,\\dots,0,b,0,\\dots,0)$, where the nonzero element $b$ appears in the $u$-th position. The inhomogeneous eigenvalue problem to solve is then:\n\n$$x = \\frac{1}{\\lambda_{\\rm max}} Ax + \\vec{b}$$\n\n## Service Proofs\n\nWhile identity proofs enhance trust in individual nodes, **service proofs** strengthen the reliability of specific transactions (edges) between nodes. Some existing examples in the wild:\n\n- **Wireless Networks**\n  - [Proof of Coverage (PoC)](https:\u002F\u002Fdocs.helium.com\u002Fblockchain\u002Fproof-of-coverage\u002F)\n- **Mobility and Logistics**\n  - [Proof of Route Compliance](https:\u002F\u002Fdimo.org\u002Fnews\u002Fdrive-to-earn-proof-of-movement)\n- **Energy**\n  - [Proof of Green Energy Generation (PoGG)](https:\u002F\u002Fdocs.arkreen.com\u002Ftechnical-details\u002Fproof-of-green-data\u002Foverview\u002F)\n- **Compute and Storage**\n  - [Proof of Spacetime](https:\u002F\u002Fdocs.filecoin.io\u002Freference\u002Fgeneral\u002Fglossary\u002F#proof-of-spacetime-post)\n  - [Proof of Replication](https:\u002F\u002Fdocs.filecoin.io\u002Freference\u002Fgeneral\u002Fglossary\u002F#proof-of-replication-porep)\n  - [Proof of Useful Work](https:\u002F\u002Fdocs.akash.network\u002Fother-resources\u002Fakash-network-glossary#proof-of-useful-work)\n- **Domain Agnostic**\n  - [Proof of Location](https:\u002F\u002Fdocs.witnesschain.com\u002Fdepin-coordination-layer\u002Fproof-of-location)\n  - [Proof of Presence](https:\u002F\u002Fcdn.prod.website-files.com\u002F65bb4a468049d4f4ebf2c321\u002F66061fd2b796461e9260b006_whitepaper-4.3.pdf)\n  - [Proof of Time](https:\u002F\u002Fdocs.presearch.io\u002Fnodes\u002Fproof-of-time)\n\n### Service Proofs in the Adjacency Matrix\n\nEach edge $(u, v) \\in E$ in the graph has a weight $w_{uv}$ representing the cumulative fees or value from transactions between producer $u$ and buyer $v$. When a service proof is available, we adjust the edge weight to reflect the increased confidence in that transaction:\n\n$$w_{uv} \\leftarrow w_{uv} + b$$\n\nwhere $b$ is the boost provided by the service proof.\n\nAlternatively, in terms of the adjacency matrix $\\mathbf{A}$, we update the entry:\n\n$$A_{uv} \\leftarrow A_{uv} + b$$\n\nThis adjustment increases the significance of the edge $(u, v)$ in the calculation of EC.\n\n#### Impact on Eigenvector Centrality and Rewards\n\nBy increasing the weight of the edge $(u, v)$, both nodes $u$ and $v$ receive a higher EC score due to their strengthened connection. This boost is again propagated through the network.\n\nHigher EC scores translate into increased graph values $G_u$ and $G_v$, which are used to calculate block rewards. Therefore, providing service proofs directly benefits the involved parties and indirectly enhances the trustworthiness of their neighbors.\n\nIn the next EC calculation, both $x_u$ and $x_v$ will increase more than they would have without the proof. This results in higher rewards for both parties and increases their attractiveness as transaction partners in the network; transacting with high EC nodes boosts ones own EC.\n\n#### Proofs as Probabilities\n\nModeling proofs as increments in edge weights allows us to treat proofs as **probabilistic assessments**, rather than binary evidence of service. This approach acknowledges that proofs for physical services can vary in strength and reliability which is particularly useful for networks that lack hard cryptographic proofs-of-service.\n\nBy quantifying the confidence level $b$, we can proportionally adjust the influence of each proof in the network, unlocking a wider range of evidence and increasing the applicability for networks that do not have deterministic proofs or where capturing \u002F computing proofs is cost-prohibitive (which could break the unit economics of the service in question).\n\nSaid another way, physical networks have a _spectrum of proofs_. Local Protocol reduces the reliance on absolute measures of trust, which may be impractical or costly, and instead uses the aggregate trust derived from various proofs and interactions within the network.\n\n> **Example: Ridesharing**\n>\n> For example, in a mobility network, a ridesharing application may contain two nodes who submit evidence of their service using a location-proof and time-proof. However, we may not have assurances that these nodes are discrete individuals; it could be a single person acting as both the driver and the rider. In such a case, these rideshare \"proofs\" are not robust like validity proofs are in other blockchain networks.\n>\n> The graph is robust to such attacks because colluding nodes will form isolated subgraphs, disconnected from the broader network of honest participants. Nodes with low connectivity will inherently have low Eigenvector Centrality (EC). This ensures that the weight boost for a given transaction is contained to the colluding actor, is unprofitable, and a self-destructive strategy. As edge weights update dynamically, nodes that are disconnected from the main graph (or have limited interactions with genuinely trusted nodes) will find it increasingly costly to maintain their position.\n\n## Random Sampling and Slashing\n\nTo ensure that the graph doesn't lose its security guarantees as new nodes enter the game, the network can randomly sample for service-proofs or service-approximations if proofs aren't available. If a node fails to provide their proofs, the network can slash the edge weights (tokens staked in the graph), and add a inverse doping vector to the nodes that fail to provide their proofs. This localized penalty system encourages self-policing and allows the network to remain secure without necessitating costly proofs for every transaction.\n\n### Inverse Doping Vector\n\nWhen the network randomly samples a transaction and requests a service proof, the involved nodes must submit the required proof. If they fail to do so, we model this as an **inverse doping vector** in the eigenvector centrality (EC) calculation. Specifically, we decrease the EC scores of the nodes in question and remove the edge representing the fake transaction. This slashing not only impacts the penalized nodes but also affects their neighboring nodes, with the effect diminishing exponentially over longer paths in the graph.\n\n$$\\mathbf{x} = \\frac{1}{\\lambda_{\\text{max}}} \\mathbf{A} \\mathbf{x} - \\vec{d}$$\n\nwhere $\\vec{d}$ is a vector with positive entries corresponding to the penalized nodes, effectively reducing their EC scores.\n\nFor example, if node $u$ fails to submit a proof, the inverse doping vector $\\vec{d}$ has a positive value $d_u$ at position $u$ and zeros elsewhere:\n\n$$\\vec{d} = (0, 0, \\dotsc, d_u, \\dotsc, 0)^{\\top}$$\n\nThe impact of this penalty propagates through the network due to the nature of the EC calculation and the edge weights $w_{uv}$ associated with the failed transaction are also decreased or set to zero:\n\n$$w_{uv} \\leftarrow w_{uv} \\times (1 - \\gamma)$$\n\n### Slashing Neighbors\n\nTo further encourage self-policing, we can extend the penalty to nodes directly connected to the penalized node. This is modeled by adjusting the inverse doping vector to include these neighboring nodes with scaled penalties.\n\nLet $N(u)$ denote the set of nodes directly connected to node $u$. We define the inverse doping vector $\\vec{d}$ as:\n\n$$d_i = \\begin{cases} d_u & \\text{if } i = u \\\\ \\alpha \\times d_u & \\text{if } i \\in N(u) \\\\ 0 & \\text{otherwise} \\end{cases}$$\n\nwhere $0 \u003C \\alpha \u003C 1$ is the decay factor representing the reduced penalty on neighboring nodes. For each node $i \\in N(u)$, we can adjust the edge weights $w_{ui}$ associated with the neighboring node where $0 \u003C \\beta \u003C \\gamma$ is a smaller slashing factor for the connected edges.\n\n$$w_{ui} \\leftarrow w_{ui} \\times (1 - \\beta)$$\n\nThe effect of the penalty diminishes exponentially over longer paths in the network. Mathematically, this is inherent in the properties of the EC calculation. The further a node is from the penalized node, the less impact the inverse doping vector has on its EC score.\n\nThis decay can be adjusted through the choice of decay factor $\\alpha$ and slashing factors $\\gamma$ and $\\beta$, allowing network designers to balance between strictness and leniency based on the desired security level.\n\nThis slashing mechanism encourages nodes to maintain genuine connections and discourages malicious behavior.\n\n## Conclusion\n\nIncorporating identity proofs and service proofs into the Local Protocol graph enhances the network's ability to verify users and transactions without relying solely on network connectivity. By modeling proofs as probabilistic boosts in eigenvector centrality (EC), we allow trust to propagate organically through the network. This approach balances the need for security with the practical limitations of obtaining proofs in various markets.\n\nBy integrating proofs into the mathematical framework of the graph, we create a system where security (trust) is directly linked to economic rewards. Nodes are incentivized to provide proofs, not just for their own benefit, but also to enhance the trustworthiness of transacting partners in their Local network.\n\nLocal Protocol supports a wide range of decentralized services, even those without hard cryptographic proofs, expanding the design space for DePIN projects. This enables more services to be both peer-to-peer and token-incentivized.","# PageRank and Token Design\n\nApplying PageRank's eigenvector-centrality principles to token distribution — modeling commercial networks as bipartite graphs that align incentives with network growth.\n\nIn this post, I propose a novel token design strategy that draws inspiration from one of the most successful algorithms in the history of the internet: PageRank.\n\nPageRank is an Eigenvector-based algorithm that focuses on *centrality* which is a fundamental measure in network theory that quantifies the importance or influence of a node within a network.\n\nEigenvector-based algorithms are well-suited to capture the quality and impact of a node's position in a network's topology, and are therefore a great method to distribute tokens in complex networks.\n\n## Intro to PageRank\n\nAt its core, PageRank revolutionized the way we navigate the web by recognizing that not all links are created equal. A link from a highly influential page carries more weight than one from an obscure corner of the internet. This insight led to a recursive evaluation of importance, creating a robust ranking system that serves as the engine to perhaps the best business model in the last half-century.\n\nThis same principle – the notion of recursive influence – holds the key to designing optimal token distributions in complex cryptonetworks. By using centrality ranks as a foundation for token allocations, we can create a dynamical, self-optimizing network that:\n\n1. Naturally aligns incentives with network growth\n2. Resists manipulation and Sybil attacks\n3. Dynamically adapts to evolving market conditions\n4. Implicitly reward behaviors that strengthen network effects\n\n## The Basic Idea\n\nAny commercial network can be modeled as a bipartite graph that captures the economic relationships between producers and buyers, with edge weights signifying the historical transactions between the two nodes.\n\nBy modeling the network as a graph, we can design an economic system that dynamically adjusts token incentives based on the revealed preferences and pricing power of the participants.\n\nThe token rewards can be determined using a modified eigenvector centrality measure, which takes into account both the revenue generated by each node and its centrality in the network. This technique quantifies an individual node's contribution to the current state of the network, considering its economic impact and its role in facilitating transactions between other nodes.\n\nThe network can leverage the graph's structural properties to implement a token allocation mechanism that optimizes the distribution of rewards based on the temporal and economic characteristics of the transacting agents in the multi-sided market.\n\nA simple definition of the graph can be $G = (U, V, E)$ representing producers $U$ and buyers $V$ as nodes, with weighted edges $E$ capturing transactions between them. Edge weights $w(u, v)$ track the producer's $u$ transactions with the buyer $v$.\n\nWith this graph we can optimize against a universal objective function:\n\n- maximizing total number of transactions\n- maximizing total fees transacted\n- maximizing connectivity of the entire network\n\n**This single model contains the following properties:**\n\n- The network naturally evolves towards optimal structures for value creation\n- Early adopters and key contributors are rewarded proportional to their *influence* in sub-networks\n- The system becomes increasingly resistant to manipulation as it grows\n- Provides the ability to *propagate trust* and *reputation*\n- The network can naturally adapt to optimize rewards across various stages of network maturity\n- The split between supply and demand can self-optimize as the network learns the pricing power of the transacting parties\n\n## Beyond Simple Incentives\n\nTraditional approaches to token design might allocate tokens based on transaction volume, geography, predefined roles within a network, referrals etc. While these methods do drive certain behaviors, they fall short in maximally aligning incentives within a complex, interconnected network.\n\nCentrality-based designs unlock a more nuanced, precise, and adaptive approach - recognizing that value in a network is not about individual actions, but a web of relationships and influence.\n\n### Network Maturity and Early Adopter Rewards\n\nMany DePINs mint tokens based on a simple exponential decay model. Mining block rewards generates a large number of tokens per unit of work early as a bootstrapping incentive. Over time, rewards rapidly decrease.\n\nThis design has been successful at bootstrapping supply but today's DePIN's have a huge demand problem, leading to imbalanced services, potential token supply issues, and ultimately supply-side churn due to diminishing returns as the network matures.\n\nBy modeling a network as a graph, we can design incentives that are adaptive and dynamical such that we maximize the overall utility to *all users* across the network's adoption lifecycle.\n\nToken rewards can scale gracefully based on the state of the graph and can be recursively re-balanced with consumer demand, creating a system that successfully bootstraps the network without creating undue harm to the treasury or future earning potential of suppliers.\n\nBy optimizing for connectivity in immature markets, EC maintains a healthy balance between growing supply and demand.\n\n**A distribution mechanism can look like this:**\n\nwhere the value created from a net new transaction creates a block reward that can be redistributed to any number of currently active nodes on either the demand or supply side of the network, depending on the economic properties of this graph.\n\n### Sybil Resistance, Verifiability, and Security\n\nAs a network matures, connectivity becomes increasingly difficult and expensive to manufacture, making eigenvector-centrality an effective sybil resistance mechanism.\n\nProducers aiming to increase their influence must generate real transactions with genuine buyers who also interact with other producers. If PageRank views centrality as a measure of recursive influence, we can view it as a measure of recursive trust.\n\n#### The Island Effect\n\nWhen a malicious actor attempts to create fake transactions, they form isolated clusters or \"islands\" within the network. \"Islands\" have limited connectivity to the rest of the network and are expensive to create.\n\nLegitimate users are unlikely to engage with them. Consequently, malicious nodes exhibit low EC scores, as they lack the strong, organic connections to the rest of the network.\n\nThis island effect makes it difficult for attackers to artificially inflate their influence or rewards, as EC inherently favors nodes with high-quality, real connections.\n\n#### Propagation of Trust\n\nIn the absence of robust service-proofs to verify the legitimacy of transactions, a network becomes vulnerable to various game-theoretic challenges, including self-dealing and collusion risks.\n\nAs we explored the design space for real-world service-proofs, we identified a number of possible verification strategies for last-mile delivery networks. Specifically, a combination of location-proofs, randomized pin exchanges with drivers, and random driver assignment together provide a robust proof-of-delivery mechanism for the current state of delivery networks. This double-blind system ensures that neither the provider nor the customer can confidently predict or influence the matching process. If the provider and customer are known to be unique, cannot systematically predict the assignment of the third colluding party, and all three parties require cooperation to submit a valid service-proof then there is extremely low collusion risk in mature markets.\n\nHowever, even in the case of mobile food ordering, the majority of all orders are still pick up orders. Pick-up orders and in-store dining are much more difficult to verify. Because restaurants do not sell a commodity, provider assignment cannot be randomized. This makes it easy for a set of two cooperating attackers to collude and earn a block reward without doing the work required to justify the reward (in this case producing the food for the buyer). We could use a similar location-proof to verify that both parties are in the same location at the time of the transaction, but even if the customer is in the store of the restaurant, it is impossible to have a robust proof-of-work mechanism that verifies (with high confidence) that the service was performed.\n\n#### A Spectrum of Verifiability\n\nAs described above, in the context of a peer-to-peer restaurant food delivery network, there are varying levels of verifiability across the two primary supported transaction types (pickup and delivery).\n\nThis spectrum of verifiability presents a significant hurdle for the mass adoption of decentralized physical infrastructure services. Typical work-arounds either require a trusted third-party, expensive service proofs, or strict permissions \u002F registration to participate. These restrictions are all limitations that limit the design space available to build truly robust, sustainable, and decentralized networks at a global scale.\n\n**Quadrant I: Easy to Create (weak-guarantee) and Cheap**\nSimple randomized pin exchanges: Users and drivers exchange simple PINs to verify or mutually attest to service completion.\n\n**Quadrant II: Easy to Create (weak-guarantee) and Expensive**\nBasic location sharing: Sharing the user's location through GPS, which can be easily manipulated but is straightforward to implement.\n\n**Quadrant III: Hard to Create (strong-guarantee) and Cheap**\nOn-chain Reputation-based systems: take a long time to develop but can be cheap and robust at scale.\n\n**Quadrant IV: Hard to Create (strong-guarantee) and Expensive**\nAdvanced location proofs: ZkTLS with cell tower or trusted hardware. Either computationally expensive or requires hardware.\n\nNetworks trying to bootstrap adoption often face challenges when relying on verification methods that fall into Quadrant IV (Hard to Create and Expensive). These methods, while robust, can hinder growth due to their complexity and cost. Conversely, using methods from Quadrant I (Easy to Create and Cheap) may lead to increased vulnerability to attacks such as self-dealing and collusion.\n\nEigenvector Centrality (EC) rankings can help mitigate issues in each of these networks by propagating trust assumptions through the graph. In networks with weak or expensive service proofs, EC rankings become particularly valuable. The underlying assumption is that collusion becomes increasingly difficult as the number of colluding nodes increases.\n\nFor networks bootstrapping trust, EC rankings can help establish trust vectors for nodes through a combination of service proofs and identity sampling. As the network grows and trust is established, the reliance on expensive service-proofs can be gradually reduced with a dampening factor over time.\n\nBy leveraging EC rankings, networks can strike a balance between security and costs depending on their needs. As trust propagates through the network, the need for expensive and complex verification methods decreases, enabling the network to scale more efficiently without compromising security.\n\n#### Sampling Trust\n\nTo ensure that the graph doesn't lose its security guarantees as new nodes enter the game, the network can randomly sample for service-proofs or service-approximations if proofs aren't available. If a node fails to provide their proofs, the network can slash the edge weights (tokens staked in the graph), along with those of their neighboring nodes. This localized penalty system encourages self-policing and reinforces the importance of maintaining genuine connections with real users.\n\nBy creating a verification system that can adapt to the specific requirements and constraints of different DePIN projects, network designers can expand the range of services that can be decentralized. This approach acknowledges a spectrum of verifiability and provides a path forward for networks that may not have access to hard or cost-effective service proofs.\n\n#### Difficulty in Manufacturing Connectivity\n\nAchieving a high EC score requires not only a large number of connections but also connections to other well-connected nodes. This property makes it challenging for malicious actors to manufacture high connectivity rankings, as they would need to establish links with reputable, central nodes in the network.\n\nLegitimate, highly-connected nodes are more likely to scrutinize and avoid suspicious or low-quality nodes. As a result, attackers face significant hurdles to manipulate their EC scores.\n\nIn this example, the block rewards produced from legitimate actors are reinforcing. Malicious actors are losing fees per transaction and shuffling around rewards to themselves, making self-dealing unprofitable.\n\nAs the network expands, the computational cost and effort required to manipulate EC scores increases. Attackers would need to establish an ever-growing number of connections to keep pace with the network's organic growth, making it impractical and resource-intensive to maintain a significant influence to earn large rewards - making the entire network increasingly robust to attacks over time.\n\n### Generalizing to Various Networks\n\nAdjustable fees allow markets to self-optimize token distributions across various commercial contexts. Nodes in the network can fine-tune to dynamically align incentives, eliminating the need for network designers to make naive assumptions about the unpredictable behavior of participants in different economic settings.\n\nOptimal token distributions are \"*discovered*\" based on the pricing power of producers in different sub-networks. This adaptive mechanism ensures that tokens are allocated in a way that reflects the true value of services provided, fostering a competitive and balanced network that reaches a comfortable equilibrium as the network matures.\n\nIn markets with unique, high-demand producers, most of the reward for a given transaction is likely to accrue to the producer. Conversely, in markets where producers sell goods with many substitutes, the reward will be distributed in favor of the buyer (the producer will use their rewards as marketing capital).\n\nThis adaptive incentive system ensures that the token economy remains responsive to changes in dynamic markets, and different networks automatically adapt without manual recalibration.\n\n### Centrality as an Implicit Referral Mechanism\n\nCentrality rankings implicitly capture what other networks attempt to achieve through imprecise mechanisms like referral rewards or marketing incentives. For example, Braintrust's connector program.\n\nIn a graph, \"referrals\" are not enshrined as a concept; they are just the optimal strategy to maximize personal rewards.\n\nUsers are therefore unknowingly participating in a complex, multi-agent optimization process where the optimal strategy is:\n\n- Contribute as much revenue as possible\n- Recruit your neighbors to contribute as much revenue as possible\n\nConnectivity allows us to align the incentives of the individual agents in the network with those of the network's objective function. In practice, this results in a more mathematically precise referral mechanism.\n\nThe aggregated behavior of countless self-interested actions drives behaviors that tend towards maximizing total network value.\n\nWe hypothesize that the collective action of self-interested agents, each seeking to maximize their individual utility, will develop more effective solution concepts to maximize network value compared to a single centralized actor. Through the alignment of incentives, we aim to create a system that encourages fast, self-reinforcing network growth.\n\nYou can think of EC based networks as \"outsourcing acquisition and retention\".\n\n## What are the Risks?\n\nWhile centrality-based token economies offer an exciting new possibility for DePIN projects and cryptonetworks alike, there are a couple of risks to consider.\n\n### Potential for Centralization\n\nIf the distribution mechanism heavily favors highly connected nodes, it could lead to a disproportionate accumulation of tokens in the hands of a few influential actors. This centralization of power could make the system vulnerable to manipulation by these entities. To mitigate this risk, it's crucial to carefully design the network's monetary policy, taking into account potential tradeoffs.\n\nIf we over-emphasize connectivity, highly connected nodes can earn disproportionate rewards, which can lead to a concentration of power.\n\nOne approach to address this issue is implementing an inflationary monetary policy. By gradually increasing the token supply over time, the relative influence of today's powerful nodes can be diluted. This allows new entrants to compete more effectively and helps prevent the entrenchment of dominant players. However, it's important to strike a balance, as excessive inflation can also devalue token holdings and disincentivize participation.\n\n### Computational Complexity\n\nCalculating eigenvector centrality involves diagonalizing a large matrix, which can become computationally demanding as the network grows and transaction volumes increase. The computational resources required to process these calculations may strain the network's capacity, potentially leading to slower transaction times and reduced efficiency.\n\nTo address this challenge, we are exploring various optimization techniques. We are also exploring various sharding techniques, which involve partitioning the network into smaller, more manageable subgraphs. By dividing the computational workload across these shards, the network can process centrality calculations more efficiently, allowing for faster transaction processing and improved scalability. Luckily there is a tremendous amount of research in the literature about PageRank given it's importance in web2 contexts. As we make progress here, we will continue to share more here.\n\n## Wrapping Up\n\nEigenvector-based cryptonetworks offer a unique set of generalizable properties that can be tuned to support a wide range of commercial networks. We think that this strategy captures the nuances of unpredictable economic behavior and could unlock a bunch of new cryptonetworks that either don't have verifiable service-proofs or have weak service-proofs.\n\nThe set of techniques discussed in this article provide a rich set of new primitives that can overcome these restrictions across a spectrum of verifiability which can help unlock a tremendous number of new use cases and catalyze mass adoption for the next generation of the internet.\n\nAlthough there are some risks and serious research problems ahead, we think this proposal unlocks a rich new design space for DePIN and other applications.\n\nThis research originated from the work of Matheus Venturyne Xavier Ferreira, with support from our friends at the CryptoEconLab.",{"id":1180,"title":557,"author":1022,"body":1181,"content":1022,"description":1421,"extension":1130,"layout":1131,"meta":1422,"navigation":1133,"outline":1022,"path":556,"robots":1022,"searchPriority":1022,"seo":1423,"stem":1424,"__hash__":1425},"docs\u002Fdocs\u002Fmarkets\u002Fregistry.md",{"type":1024,"value":1182,"toc":1413},[1183,1195,1198,1227,1230,1233,1247,1250,1280,1283,1289,1337,1341,1344,1361,1379,1396,1399,1409],[1027,1184,1185,1186,1189,1190,1194],{},"Markets are defined as ",[1073,1187,1188],{},"execution contexts",". A transaction’s market is derived from the MarketContext contract\u002Frouter that emitted an ",[1191,1192,1193],"code",{},"InteractionRecord",", not from user-provided metadata.",[1066,1196,562],{"id":1197},"markets-are-derived-from-execution",[1042,1199,1200,1209,1219],{},[1045,1201,1202,1205,1206,1208],{},[1073,1203,1204],{},"MarketContext",": an on-chain contract (or router) that emits canonical ",[1191,1207,1193],{},"s for a commercial context.",[1045,1210,1211,1218],{},[1073,1212,1213,1214,1217],{},"Market (",[1191,1215,1216],{},"m",")",": a policy + accounting container bound to one MarketContext.",[1045,1220,1221,1226],{},[1073,1222,1223],{},[1191,1224,1225],{},"marketId",": a registry-assigned identifier derived from the executed MarketContext.",[1066,1228,567],{"id":1229},"marketregistry-canonicalization",[1027,1231,1232],{},"The protocol maintains a canonical MarketRegistry:",[1234,1235,1239],"pre",{"className":1236,"code":1237,"language":1238,"meta":161,"style":161},"language-txt shiki shiki-themes github-dark github-light-default","marketContext → (marketId, vault, feeRouter, flags)\n","txt",[1191,1240,1241],{"__ignoreMap":161},[1242,1243,1245],"span",{"class":1244,"line":9},"line",[1242,1246,1237],{},[1027,1248,1249],{},"where:",[1042,1251,1252,1258,1268,1274],{},[1045,1253,1254,1257],{},[1191,1255,1256],{},"marketId: uint32",": registry-assigned market identifier (unique; not user-chosen)",[1045,1259,1260,1263,1264,1267],{},[1191,1261,1262],{},"vault: Address",": MarketVault for this market (MAY be ",[1191,1265,1266],{},"0x0"," if unused)",[1045,1269,1270,1273],{},[1191,1271,1272],{},"feeRouter: Address",": where protocol fees for this market are routed",[1045,1275,1276,1279],{},[1191,1277,1278],{},"flags: uint32",": e.g. ACTIVE \u002F DEPRECATED",[1066,1281,572],{"id":1282},"interactionrecords",[1027,1284,1285,1286,1288],{},"An ",[1191,1287,1193],{}," is emitted by a registered MarketContext during execution and is included in an SDL. Minimal sketch:",[1042,1290,1291,1295,1300,1305,1310,1315,1320,1326,1331],{},[1045,1292,1293],{},[1191,1294,1256],{},[1045,1296,1297],{},[1191,1298,1299],{},"marketContext: Address",[1045,1301,1302],{},[1191,1303,1304],{},"buyer: Address",[1045,1306,1307],{},[1191,1308,1309],{},"provider: Address",[1045,1311,1312],{},[1191,1313,1314],{},"amount: uint128",[1045,1316,1317],{},[1191,1318,1319],{},"fee: uint128",[1045,1321,1322,1325],{},[1191,1323,1324],{},"edgeDelta"," and\u002For other protocol-defined graph\u002Fattribute deltas",[1045,1327,1328],{},[1191,1329,1330],{},"proofRefs: bytes32[]",[1045,1332,1333,1336],{},[1191,1334,1335],{},"disputeRefs: bytes32[]"," (if applicable)",[1338,1339,577],"h3",{"id":1340},"validity-rule-critical",[1027,1342,1343],{},"An interaction record (and any resulting commerce edges) is valid only if:",[1042,1345,1346,1355],{},[1045,1347,1348,1351,1352],{},[1191,1349,1350],{},"MarketRegistry[marketContext].marketId == marketId"," ",[1073,1353,1354],{},"at that block height",[1045,1356,1357,1358],{},"the market is ",[1073,1359,1360],{},"ACTIVE",[1362,1363,1365],"callout",{"title":1364},"Security note",[1027,1366,1367,1368,1371,1372,1374,1375,1378],{},"The security-critical requirement is that ",[1073,1369,1370],{},"users cannot choose a favorable market label",". By deriving ",[1191,1373,1225],{}," from the executed ",[1191,1376,1377],{},"marketContext"," via a canonical registry mapping, market-scoped caps, seeds, and accounting can be enforced deterministically.",[1362,1380,1382],{"title":1381},"Related work (context, not requirements)",[1042,1383,1384],{},[1045,1385,1386,1389,1390,1395],{},[1073,1387,1388],{},"Authenticated commitments",": binding MarketRegistry into a snapshot artifact so verifiers can check market attribution via short openings is a standard authenticated-data pattern (Merkle trees: ",[1031,1391,1394],{"href":1392,"rel":1393},"https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~raluca\u002Fcs261-f15\u002Freadings\u002Fmerkle.pdf",[1035],"Merkle, 1987",").",[1066,1397,70],{"id":1398},"related",[1042,1400,1401,1405],{},[1045,1402,1403],{},[1031,1404,483],{"href":482},[1045,1406,1407],{},[1031,1408,240],{"href":239},[1410,1411,1412],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}",{"title":161,"searchDepth":16,"depth":16,"links":1414},[1415,1416,1417,1420],{"id":1197,"depth":16,"text":562},{"id":1229,"depth":16,"text":567},{"id":1282,"depth":16,"text":572,"children":1418},[1419],{"id":1340,"depth":52,"text":577},{"id":1398,"depth":16,"text":70},"How a transaction’s market is derived from the executing MarketContext and canonicalized against the protocol MarketRegistry.",{},{"title":557,"description":1421},"docs\u002Fmarkets\u002Fregistry","pA3Vutn3McM7ywrVnPpR5tM4IqY4U_JRBb17NVz6A0M",1783724204376]