[{"data":1,"prerenderedAt":5105},["ShallowReactive",2],{"docs-search-sections":3,"docs-last-updated":1015,"docs-toc":1020,"content-md-map":1137,"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments":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":240,"author":1022,"body":1181,"content":1022,"description":5100,"extension":1130,"layout":1131,"meta":5101,"navigation":1133,"outline":1022,"path":239,"robots":1022,"searchPriority":1022,"seo":5102,"stem":5103,"__hash__":5104},"docs\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments.md",{"type":1024,"value":1182,"toc":5086},[1183,1186,1189,1313,1984,2446,2452,2463,2466,2495,2788,2791,3038,3042,3105,3111,3424,3427,3729,3916,3919,3926,4067,4098,4408,4411,4414,4419,4424,4427,4452,4474,4481,4485,4717,4754,4757,4800,4858,4861,4969,4977,5025,5041,5044,5059,5062,5077,5082],[1027,1184,1185],{},"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.",[1066,1187,245],{"id":1188},"epochs",[1027,1190,1191,1192,1312],{},"Time is divided into epochs ",[1193,1194,1198],"mjx-container",{"className":1195,"jax":1197},[1196],"MathJax","SVG",[1199,1200,1209,1241],"svg",{"style":1201,"xmlns":1202,"width":1203,"height":1204,"role":1205,"focusable":1206,"viewBox":1207,"xmlnsXLink":1208},"vertical-align: -0.439ex;","http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg","12.897ex","1.946ex","img","false","0 -666 5700.6 860","http:\u002F\u002Fwww.w3.org\u002F1999\u002Fxlink",[1210,1211,1212,1217,1221,1225,1229,1233,1237],"defs",{},[1213,1214],"path",{"id":1215,"d":1216},"MJX-1-TEX-I-1D461","M26 385Q19 392 19 395Q19 399 22 411T27 425Q29 430 36 430T87 431H140L159 511Q162 522 166 540T173 566T179 586T187 603T197 615T211 624T229 626Q247 625 254 615T261 596Q261 589 252 549T232 470L222 433Q222 431 272 431H323Q330 424 330 420Q330 398 317 385H210L174 240Q135 80 135 68Q135 26 162 26Q197 26 230 60T283 144Q285 150 288 151T303 153H307Q322 153 322 145Q322 142 319 133Q314 117 301 95T267 48T216 6T155 -11Q125 -11 98 4T59 56Q57 64 57 83V101L92 241Q127 382 128 383Q128 385 77 385H26Z",[1213,1218],{"id":1219,"d":1220},"MJX-1-TEX-N-3D","M56 347Q56 360 70 367H707Q722 359 722 347Q722 336 708 328L390 327H72Q56 332 56 347ZM56 153Q56 168 72 173H708Q722 163 722 153Q722 140 707 133H70Q56 140 56 153Z",[1213,1222],{"id":1223,"d":1224},"MJX-1-TEX-N-30","M96 585Q152 666 249 666Q297 666 345 640T423 548Q460 465 460 320Q460 165 417 83Q397 41 362 16T301 -15T250 -22Q224 -22 198 -16T137 16T82 83Q39 165 39 320Q39 494 96 585ZM321 597Q291 629 250 629Q208 629 178 597Q153 571 145 525T137 333Q137 175 145 125T181 46Q209 16 250 16Q290 16 318 46Q347 76 354 130T362 333Q362 478 354 524T321 597Z",[1213,1226],{"id":1227,"d":1228},"MJX-1-TEX-N-2C","M78 35T78 60T94 103T137 121Q165 121 187 96T210 8Q210 -27 201 -60T180 -117T154 -158T130 -185T117 -194Q113 -194 104 -185T95 -172Q95 -168 106 -156T131 -126T157 -76T173 -3V9L172 8Q170 7 167 6T161 3T152 1T140 0Q113 0 96 17Z",[1213,1230],{"id":1231,"d":1232},"MJX-1-TEX-N-31","M213 578L200 573Q186 568 160 563T102 556H83V602H102Q149 604 189 617T245 641T273 663Q275 666 285 666Q294 666 302 660V361L303 61Q310 54 315 52T339 48T401 46H427V0H416Q395 3 257 3Q121 3 100 0H88V46H114Q136 46 152 46T177 47T193 50T201 52T207 57T213 61V578Z",[1213,1234],{"id":1235,"d":1236},"MJX-1-TEX-N-32","M109 429Q82 429 66 447T50 491Q50 562 103 614T235 666Q326 666 387 610T449 465Q449 422 429 383T381 315T301 241Q265 210 201 149L142 93L218 92Q375 92 385 97Q392 99 409 186V189H449V186Q448 183 436 95T421 3V0H50V19V31Q50 38 56 46T86 81Q115 113 136 137Q145 147 170 174T204 211T233 244T261 278T284 308T305 340T320 369T333 401T340 431T343 464Q343 527 309 573T212 619Q179 619 154 602T119 569T109 550Q109 549 114 549Q132 549 151 535T170 489Q170 464 154 447T109 429Z",[1213,1238],{"id":1239,"d":1240},"MJX-1-TEX-N-2026","M78 60Q78 84 95 102T138 120Q162 120 180 104T199 61Q199 36 182 18T139 0T96 17T78 60ZM525 60Q525 84 542 102T585 120Q609 120 627 104T646 61Q646 36 629 18T586 0T543 17T525 60ZM972 60Q972 84 989 102T1032 120Q1056 120 1074 104T1093 61Q1093 36 1076 18T1033 0T990 17T972 60Z",[1242,1243,1247],"g",{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},"currentColor","0","scale(1,-1)",[1242,1248,1250,1258,1266,1274,1281,1288,1293,1300,1305],{"dataMmlNode":1249},"math",[1242,1251,1253],{"dataMmlNode":1252},"mi",[1254,1255],"use",{"dataC":1256,"xLinkHref":1257},"1D461","#MJX-1-TEX-I-1D461",[1242,1259,1262],{"dataMmlNode":1260,"transform":1261},"mo","translate(638.8,0)",[1254,1263],{"dataC":1264,"xLinkHref":1265},"3D","#MJX-1-TEX-N-3D",[1242,1267,1270],{"dataMmlNode":1268,"transform":1269},"mn","translate(1694.6,0)",[1254,1271],{"dataC":1272,"xLinkHref":1273},"30","#MJX-1-TEX-N-30",[1242,1275,1277],{"dataMmlNode":1260,"transform":1276},"translate(2194.6,0)",[1254,1278],{"dataC":1279,"xLinkHref":1280},"2C","#MJX-1-TEX-N-2C",[1242,1282,1284],{"dataMmlNode":1268,"transform":1283},"translate(2639.2,0)",[1254,1285],{"dataC":1286,"xLinkHref":1287},"31","#MJX-1-TEX-N-31",[1242,1289,1291],{"dataMmlNode":1260,"transform":1290},"translate(3139.2,0)",[1254,1292],{"dataC":1279,"xLinkHref":1280},[1242,1294,1296],{"dataMmlNode":1268,"transform":1295},"translate(3583.9,0)",[1254,1297],{"dataC":1298,"xLinkHref":1299},"32","#MJX-1-TEX-N-32",[1242,1301,1303],{"dataMmlNode":1260,"transform":1302},"translate(4083.9,0)",[1254,1304],{"dataC":1279,"xLinkHref":1280},[1242,1306,1308],{"dataMmlNode":1260,"transform":1307},"translate(4528.6,0)",[1254,1309],{"dataC":1310,"xLinkHref":1311},"2026","#MJX-1-TEX-N-2026",". Each epoch defines:",[1042,1314,1315,1425,1511,1572],{},[1045,1316,1317,1318],{},"a committed graph snapshot root ",[1193,1319,1321],{"className":1320,"jax":1197},[1196],[1199,1322,1327,1364],{"style":1323,"xmlns":1202,"width":1324,"height":1325,"role":1205,"focusable":1206,"viewBox":1326,"xmlnsXLink":1208},"vertical-align: -0.537ex;","11.016ex","2.129ex","0 -704 4869.3 941.1",[1210,1328,1329,1333,1337,1341,1345,1349,1353,1357,1361],{},[1213,1330],{"id":1331,"d":1332},"MJX-2-TEX-SS-1D5A6","M59 346Q59 499 157 601T384 704Q436 704 466 700T541 679Q551 674 560 670T575 664T583 660T588 658T590 656Q590 652 582 605T573 557L564 564Q489 626 392 626Q301 626 233 549T164 347T233 145T392 68Q441 68 506 84V223H388V299H599V38L588 33Q494 -11 393 -11Q296 -11 219 40T100 172T59 346Z",[1213,1334],{"id":1335,"d":1336},"MJX-2-TEX-SS-1D5CB","M171 389Q237 455 320 455H327V373H317Q262 369 220 336T167 248Q165 239 164 119V0H74V450H159V377L171 389Z",[1213,1338],{"id":1339,"d":1340},"MJX-2-TEX-SS-1D5BA","M236 387Q209 387 184 382T141 370T111 355T91 342T83 337L82 355Q80 373 79 393T77 417Q77 419 81 421Q86 423 91 426Q155 460 227 460H238Q319 460 368 400Q393 371 400 341T408 252Q408 240 408 207T407 152V0H317V39L306 32Q244 -10 159 -10H152Q109 -10 77 22Q38 61 38 126Q38 142 39 146Q55 199 130 223T295 252H314V277Q314 305 313 310Q308 342 287 364T236 387ZM303 186Q124 180 124 126Q124 105 144 86T208 66Q284 66 309 124Q314 137 314 166V186H303Z",[1213,1342],{"id":1343,"d":1344},"MJX-2-TEX-SS-1D5C9","M166 404Q194 424 241 439T337 455H341Q410 455 451 370Q483 307 483 222Q483 128 433 59T306 -10Q282 -10 260 -5T222 7T194 21T176 33T168 38V-194H75V444H165V424L166 404ZM390 222Q390 287 354 331T266 376T177 340L168 332V118Q200 66 257 66Q313 66 351 112T390 222Z",[1213,1346],{"id":1347,"d":1348},"MJX-2-TEX-SS-1D5C1","M163 395Q223 455 307 455Q417 455 438 354Q442 331 443 164V0H350V157Q349 315 348 320Q334 378 259 378H253Q224 378 204 358Q180 334 173 301T165 209Q165 198 165 172T166 129V0H73V694H163V395Z",[1213,1350],{"id":1351,"d":1352},"MJX-2-TEX-SS-1D5B1","M88 0V694H227H259H302Q365 694 399 689T474 663Q528 637 558 595T589 504Q589 482 584 462T569 426T547 396T522 372T495 353T470 338T449 328T434 322L429 320L440 300Q452 280 477 238T523 160L617 1L565 0Q513 0 512 1Q512 2 424 156L337 309H189V0H88ZM492 504Q492 600 367 620Q354 622 271 623H189V385H271Q363 386 388 392Q432 402 462 430T492 504Z",[1213,1354],{"id":1355,"d":1356},"MJX-2-TEX-SS-1D5C8","M28 222Q28 323 95 391T244 460Q275 460 281 459Q364 445 417 377T471 219Q471 124 408 57T250 -10Q158 -10 93 57T28 222ZM377 230Q377 277 364 310T328 358T287 379T248 385Q233 385 219 382T186 369T155 342T132 297T122 230Q122 146 159 108T250 69H253Q263 69 274 70T305 81T339 106T365 154T377 230Z",[1213,1358],{"id":1359,"d":1360},"MJX-2-TEX-SS-1D5CD","M333 27Q333 24 314 16T257 -1T184 -10H172Q146 -10 128 14T105 58T99 91Q95 113 95 251V371H18V444H98V571H182V444H316V371H182V253Q183 128 189 104Q199 68 234 68Q277 72 314 98Q315 93 323 61T333 27Z",[1213,1362],{"id":1363,"d":1216},"MJX-2-TEX-I-1D461",[1242,1365,1366],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,1367,1368],{"dataMmlNode":1249},[1242,1369,1371,1419],{"dataMmlNode":1370},"msub",[1242,1372,1375],{"dataMmlNode":1373,"dataMjxTexclass":1374},"TeXAtom","ORD",[1242,1376,1377,1381,1386,1391,1396,1401,1406,1411,1414],{"dataMmlNode":1252},[1254,1378],{"dataC":1379,"xLinkHref":1380},"1D5A6","#MJX-2-TEX-SS-1D5A6",[1254,1382],{"dataC":1383,"xLinkHref":1384,"transform":1385},"1D5CB","#MJX-2-TEX-SS-1D5CB","translate(667,0)",[1254,1387],{"dataC":1388,"xLinkHref":1389,"transform":1390},"1D5BA","#MJX-2-TEX-SS-1D5BA","translate(1009,0)",[1254,1392],{"dataC":1393,"xLinkHref":1394,"transform":1395},"1D5C9","#MJX-2-TEX-SS-1D5C9","translate(1490,0)",[1254,1397],{"dataC":1398,"xLinkHref":1399,"transform":1400},"1D5C1","#MJX-2-TEX-SS-1D5C1","translate(2007,0)",[1254,1402],{"dataC":1403,"xLinkHref":1404,"transform":1405},"1D5B1","#MJX-2-TEX-SS-1D5B1","translate(2524,0)",[1254,1407],{"dataC":1408,"xLinkHref":1409,"transform":1410},"1D5C8","#MJX-2-TEX-SS-1D5C8","translate(3170,0)",[1254,1412],{"dataC":1408,"xLinkHref":1409,"transform":1413},"translate(3670,0)",[1254,1415],{"dataC":1416,"xLinkHref":1417,"transform":1418},"1D5CD","#MJX-2-TEX-SS-1D5CD","translate(4170,0)",[1242,1420,1422],{"dataMmlNode":1252,"transform":1421},"translate(4564,-229.4) scale(0.707)",[1254,1423],{"dataC":1256,"xLinkHref":1424},"#MJX-2-TEX-I-1D461",[1045,1426,1427,1428],{},"a committed teleport\u002Fseed root ",[1193,1429,1431],{"className":1430,"jax":1197},[1196],[1199,1432,1437,1463],{"style":1433,"xmlns":1202,"width":1434,"height":1435,"role":1205,"focusable":1206,"viewBox":1436,"xmlnsXLink":1208},"vertical-align: -0.357ex;","9.743ex","1.977ex","0 -716 4306.3 873.8",[1210,1438,1439,1443,1447,1451,1454,1457,1460],{},[1213,1440],{"id":1441,"d":1442},"MJX-3-TEX-SS-1D5B2","M55 514Q55 589 115 652T283 716Q315 716 345 711T396 699T432 685T457 672T467 667Q467 666 459 618T449 568Q383 634 282 634Q214 634 182 600T150 525Q150 507 155 492T172 465T194 446T222 432T247 423T272 416T289 412Q353 396 378 384Q432 358 466 307T500 194Q500 110 438 44T272 -22Q215 -22 159 -5T73 28T44 50Q45 51 49 75T57 122T62 146L65 143Q68 140 74 136T88 125T107 111T131 98T160 85T194 74T232 66T274 63H286Q327 63 366 96T406 182Q406 245 352 280Q329 296 265 310T173 339Q124 363 90 409T55 514Z",[1213,1444],{"id":1445,"d":1446},"MJX-3-TEX-SS-1D5BE","M28 226Q28 329 91 395T235 461Q258 461 279 456T325 436T368 397T399 332T415 238V219H113V215Q113 163 151 114T248 65Q273 65 298 70T341 82T373 96T396 108L403 113Q403 106 406 76T409 38Q409 34 408 33T393 24Q325 -10 252 -10Q155 -10 92 59T28 226ZM340 289L338 297Q335 305 333 310T327 326T317 343T304 358T286 372T263 381T233 385Q212 385 193 376T162 353T140 325T127 301T123 289H340Z",[1213,1448],{"id":1449,"d":1450},"MJX-3-TEX-SS-1D5BD","M33 224Q33 321 81 388T197 455Q277 455 342 414L351 408V694H441V0H348V44L338 37Q278 -10 198 -10Q177 -10 168 -8Q99 11 62 90Q33 148 33 224ZM348 337Q307 378 263 378Q260 378 256 378T251 379Q239 379 223 374T182 355T142 305T126 220Q126 90 225 67Q231 66 250 66H255Q306 66 342 115L348 124V337Z",[1213,1452],{"id":1453,"d":1352},"MJX-3-TEX-SS-1D5B1",[1213,1455],{"id":1456,"d":1356},"MJX-3-TEX-SS-1D5C8",[1213,1458],{"id":1459,"d":1360},"MJX-3-TEX-SS-1D5CD",[1213,1461],{"id":1462,"d":1216},"MJX-3-TEX-I-1D461",[1242,1464,1465],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,1466,1467],{"dataMmlNode":1249},[1242,1468,1469,1505],{"dataMmlNode":1370},[1242,1470,1471],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,1472,1473,1477,1482,1485,1490,1494,1498,1501],{"dataMmlNode":1252},[1254,1474],{"dataC":1475,"xLinkHref":1476},"1D5B2","#MJX-3-TEX-SS-1D5B2",[1254,1478],{"dataC":1479,"xLinkHref":1480,"transform":1481},"1D5BE","#MJX-3-TEX-SS-1D5BE","translate(556,0)",[1254,1483],{"dataC":1479,"xLinkHref":1480,"transform":1484},"translate(1000,0)",[1254,1486],{"dataC":1487,"xLinkHref":1488,"transform":1489},"1D5BD","#MJX-3-TEX-SS-1D5BD","translate(1444,0)",[1254,1491],{"dataC":1403,"xLinkHref":1492,"transform":1493},"#MJX-3-TEX-SS-1D5B1","translate(1961,0)",[1254,1495],{"dataC":1408,"xLinkHref":1496,"transform":1497},"#MJX-3-TEX-SS-1D5C8","translate(2607,0)",[1254,1499],{"dataC":1408,"xLinkHref":1496,"transform":1500},"translate(3107,0)",[1254,1502],{"dataC":1416,"xLinkHref":1503,"transform":1504},"#MJX-3-TEX-SS-1D5CD","translate(3607,0)",[1242,1506,1508],{"dataMmlNode":1252,"transform":1507},"translate(4001,-150) scale(0.707)",[1254,1509],{"dataC":1256,"xLinkHref":1510},"#MJX-3-TEX-I-1D461",[1045,1512,1513,1514],{},"a canonical randomness beacon ",[1193,1515,1517],{"className":1516,"jax":1197},[1196],[1199,1518,1522,1540],{"style":1433,"xmlns":1202,"width":1519,"height":1520,"role":1205,"focusable":1206,"viewBox":1521,"xmlnsXLink":1208},"5.654ex","1.927ex","0 -694 2499.3 851.8",[1210,1523,1524,1527,1530,1534,1537],{},[1213,1525],{"id":1526,"d":1352},"MJX-4-TEX-SS-1D5B1",[1213,1528],{"id":1529,"d":1340},"MJX-4-TEX-SS-1D5BA",[1213,1531],{"id":1532,"d":1533},"MJX-4-TEX-SS-1D5C7","M160 392Q214 446 283 454Q285 454 292 454T303 455H306Q417 455 438 354Q442 331 443 164V0H350V157Q349 315 348 320Q334 378 259 378H253Q224 378 204 358Q180 334 173 301T165 209Q165 198 165 172T166 129V0H73V450H160V392Z",[1213,1535],{"id":1536,"d":1450},"MJX-4-TEX-SS-1D5BD",[1213,1538],{"id":1539,"d":1216},"MJX-4-TEX-I-1D461",[1242,1541,1542],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,1543,1544],{"dataMmlNode":1249},[1242,1545,1546,1566],{"dataMmlNode":1370},[1242,1547,1548],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,1549,1550,1553,1557,1562],{"dataMmlNode":1252},[1254,1551],{"dataC":1403,"xLinkHref":1552},"#MJX-4-TEX-SS-1D5B1",[1254,1554],{"dataC":1388,"xLinkHref":1555,"transform":1556},"#MJX-4-TEX-SS-1D5BA","translate(646,0)",[1254,1558],{"dataC":1559,"xLinkHref":1560,"transform":1561},"1D5C7","#MJX-4-TEX-SS-1D5C7","translate(1127,0)",[1254,1563],{"dataC":1487,"xLinkHref":1564,"transform":1565},"#MJX-4-TEX-SS-1D5BD","translate(1644,0)",[1242,1567,1569],{"dataMmlNode":1252,"transform":1568},"translate(2194,-150) scale(0.707)",[1254,1570],{"dataC":1256,"xLinkHref":1571},"#MJX-4-TEX-I-1D461",[1045,1573,1574,1575],{},"protocol parameters ",[1193,1576,1578],{"className":1577,"jax":1197},[1196],[1199,1579,1584,1675],{"style":1580,"xmlns":1202,"width":1581,"height":1582,"role":1205,"focusable":1206,"viewBox":1583,"xmlnsXLink":1208},"vertical-align: -1.028ex;","35.154ex","3.266ex","0 -989.3 15538.1 1443.6",[1210,1585,1586,1590,1594,1597,1601,1604,1608,1612,1616,1620,1624,1628,1632,1636,1640,1644,1648,1652,1656,1660,1664,1668,1671],{},[1213,1587],{"id":1588,"d":1589},"MJX-5-TEX-N-28","M94 250Q94 319 104 381T127 488T164 576T202 643T244 695T277 729T302 750H315H319Q333 750 333 741Q333 738 316 720T275 667T226 581T184 443T167 250T184 58T225 -81T274 -167T316 -220T333 -241Q333 -250 318 -250H315H302L274 -226Q180 -141 137 -14T94 250Z",[1213,1591],{"id":1592,"d":1593},"MJX-5-TEX-I-1D6FC","M34 156Q34 270 120 356T309 442Q379 442 421 402T478 304Q484 275 485 237V208Q534 282 560 374Q564 388 566 390T582 393Q603 393 603 385Q603 376 594 346T558 261T497 161L486 147L487 123Q489 67 495 47T514 26Q528 28 540 37T557 60Q559 67 562 68T577 70Q597 70 597 62Q597 56 591 43Q579 19 556 5T512 -10H505Q438 -10 414 62L411 69L400 61Q390 53 370 41T325 18T267 -2T203 -11Q124 -11 79 39T34 156ZM208 26Q257 26 306 47T379 90L403 112Q401 255 396 290Q382 405 304 405Q235 405 183 332Q156 292 139 224T121 120Q121 71 146 49T208 26Z",[1213,1595],{"id":1596,"d":1228},"MJX-5-TEX-N-2C",[1213,1598],{"id":1599,"d":1600},"MJX-5-TEX-I-1D6FF","M195 609Q195 656 227 686T302 717Q319 716 351 709T407 697T433 690Q451 682 451 662Q451 644 438 628T403 612Q382 612 348 641T288 671T249 657T235 628Q235 584 334 463Q401 379 401 292Q401 169 340 80T205 -10H198Q127 -10 83 36T36 153Q36 286 151 382Q191 413 252 434Q252 435 245 449T230 481T214 521T201 566T195 609ZM112 130Q112 83 136 55T204 27Q233 27 256 51T291 111T309 178T316 232Q316 267 309 298T295 344T269 400L259 396Q215 381 183 342T137 256T118 179T112 130Z",[1213,1602],{"id":1603,"d":1216},"MJX-5-TEX-I-1D461",[1213,1605],{"id":1606,"d":1607},"MJX-5-TEX-I-1D465","M52 289Q59 331 106 386T222 442Q257 442 286 424T329 379Q371 442 430 442Q467 442 494 420T522 361Q522 332 508 314T481 292T458 288Q439 288 427 299T415 328Q415 374 465 391Q454 404 425 404Q412 404 406 402Q368 386 350 336Q290 115 290 78Q290 50 306 38T341 26Q378 26 414 59T463 140Q466 150 469 151T485 153H489Q504 153 504 145Q504 144 502 134Q486 77 440 33T333 -11Q263 -11 227 52Q186 -10 133 -10H127Q78 -10 57 16T35 71Q35 103 54 123T99 143Q142 143 142 101Q142 81 130 66T107 46T94 41L91 40Q91 39 97 36T113 29T132 26Q168 26 194 71Q203 87 217 139T245 247T261 313Q266 340 266 352Q266 380 251 392T217 404Q177 404 142 372T93 290Q91 281 88 280T72 278H58Q52 284 52 289Z",[1213,1609],{"id":1610,"d":1611},"MJX-5-TEX-I-1D462","M21 287Q21 295 30 318T55 370T99 420T158 442Q204 442 227 417T250 358Q250 340 216 246T182 105Q182 62 196 45T238 27T291 44T328 78L339 95Q341 99 377 247Q407 367 413 387T427 416Q444 431 463 431Q480 431 488 421T496 402L420 84Q419 79 419 68Q419 43 426 35T447 26Q469 29 482 57T512 145Q514 153 532 153Q551 153 551 144Q550 139 549 130T540 98T523 55T498 17T462 -8Q454 -10 438 -10Q372 -10 347 46Q345 45 336 36T318 21T296 6T267 -6T233 -11Q189 -11 155 7Q103 38 103 113Q103 170 138 262T173 379Q173 380 173 381Q173 390 173 393T169 400T158 404H154Q131 404 112 385T82 344T65 302T57 280Q55 278 41 278H27Q21 284 21 287Z",[1213,1613],{"id":1614,"d":1615},"MJX-5-TEX-I-1D460","M131 289Q131 321 147 354T203 415T300 442Q362 442 390 415T419 355Q419 323 402 308T364 292Q351 292 340 300T328 326Q328 342 337 354T354 372T367 378Q368 378 368 379Q368 382 361 388T336 399T297 405Q249 405 227 379T204 326Q204 301 223 291T278 274T330 259Q396 230 396 163Q396 135 385 107T352 51T289 7T195 -10Q118 -10 86 19T53 87Q53 126 74 143T118 160Q133 160 146 151T160 120Q160 94 142 76T111 58Q109 57 108 57T107 55Q108 52 115 47T146 34T201 27Q237 27 263 38T301 66T318 97T323 122Q323 150 302 164T254 181T195 196T148 231Q131 256 131 289Z",[1213,1617],{"id":1618,"d":1619},"MJX-5-TEX-I-1D452","M39 168Q39 225 58 272T107 350T174 402T244 433T307 442H310Q355 442 388 420T421 355Q421 265 310 237Q261 224 176 223Q139 223 138 221Q138 219 132 186T125 128Q125 81 146 54T209 26T302 45T394 111Q403 121 406 121Q410 121 419 112T429 98T420 82T390 55T344 24T281 -1T205 -11Q126 -11 83 42T39 168ZM373 353Q367 405 305 405Q272 405 244 391T199 357T170 316T154 280T149 261Q149 260 169 260Q282 260 327 284T373 353Z",[1213,1621],{"id":1622,"d":1623},"MJX-5-TEX-I-1D45F","M21 287Q22 290 23 295T28 317T38 348T53 381T73 411T99 433T132 442Q161 442 183 430T214 408T225 388Q227 382 228 382T236 389Q284 441 347 441H350Q398 441 422 400Q430 381 430 363Q430 333 417 315T391 292T366 288Q346 288 334 299T322 328Q322 376 378 392Q356 405 342 405Q286 405 239 331Q229 315 224 298T190 165Q156 25 151 16Q138 -11 108 -11Q95 -11 87 -5T76 7T74 17Q74 30 114 189T154 366Q154 405 128 405Q107 405 92 377T68 316T57 280Q55 278 41 278H27Q21 284 21 287Z",[1213,1625],{"id":1626,"d":1627},"MJX-5-TEX-I-1D45D","M23 287Q24 290 25 295T30 317T40 348T55 381T75 411T101 433T134 442Q209 442 230 378L240 387Q302 442 358 442Q423 442 460 395T497 281Q497 173 421 82T249 -10Q227 -10 210 -4Q199 1 187 11T168 28L161 36Q160 35 139 -51T118 -138Q118 -144 126 -145T163 -148H188Q194 -155 194 -157T191 -175Q188 -187 185 -190T172 -194Q170 -194 161 -194T127 -193T65 -192Q-5 -192 -24 -194H-32Q-39 -187 -39 -183Q-37 -156 -26 -148H-6Q28 -147 33 -136Q36 -130 94 103T155 350Q156 355 156 364Q156 405 131 405Q109 405 94 377T71 316T59 280Q57 278 43 278H29Q23 284 23 287ZM178 102Q200 26 252 26Q282 26 310 49T356 107Q374 141 392 215T411 325V331Q411 405 350 405Q339 405 328 402T306 393T286 380T269 365T254 350T243 336T235 326L232 322Q232 321 229 308T218 264T204 212Q178 106 178 102Z",[1213,1629],{"id":1630,"d":1631},"MJX-5-TEX-I-1D45C","M201 -11Q126 -11 80 38T34 156Q34 221 64 279T146 380Q222 441 301 441Q333 441 341 440Q354 437 367 433T402 417T438 387T464 338T476 268Q476 161 390 75T201 -11ZM121 120Q121 70 147 48T206 26Q250 26 289 58T351 142Q360 163 374 216T388 308Q388 352 370 375Q346 405 306 405Q243 405 195 347Q158 303 140 230T121 120Z",[1213,1633],{"id":1634,"d":1635},"MJX-5-TEX-I-1D450","M34 159Q34 268 120 355T306 442Q362 442 394 418T427 355Q427 326 408 306T360 285Q341 285 330 295T319 325T330 359T352 380T366 386H367Q367 388 361 392T340 400T306 404Q276 404 249 390Q228 381 206 359Q162 315 142 235T121 119Q121 73 147 50Q169 26 205 26H209Q321 26 394 111Q403 121 406 121Q410 121 419 112T429 98T420 83T391 55T346 25T282 0T202 -11Q127 -11 81 37T34 159Z",[1213,1637],{"id":1638,"d":1639},"MJX-5-TEX-I-210E","M137 683Q138 683 209 688T282 694Q294 694 294 685Q294 674 258 534Q220 386 220 383Q220 381 227 388Q288 442 357 442Q411 442 444 415T478 336Q478 285 440 178T402 50Q403 36 407 31T422 26Q450 26 474 56T513 138Q516 149 519 151T535 153Q555 153 555 145Q555 144 551 130Q535 71 500 33Q466 -10 419 -10H414Q367 -10 346 17T325 74Q325 90 361 192T398 345Q398 404 354 404H349Q266 404 205 306L198 293L164 158Q132 28 127 16Q114 -11 83 -11Q69 -11 59 -2T48 16Q48 30 121 320L195 616Q195 629 188 632T149 637H128Q122 643 122 645T124 664Q129 683 137 683Z",[1213,1641],{"id":1642,"d":1643},"MJX-5-TEX-I-1D45A","M21 287Q22 293 24 303T36 341T56 388T88 425T132 442T175 435T205 417T221 395T229 376L231 369Q231 367 232 367L243 378Q303 442 384 442Q401 442 415 440T441 433T460 423T475 411T485 398T493 385T497 373T500 364T502 357L510 367Q573 442 659 442Q713 442 746 415T780 336Q780 285 742 178T704 50Q705 36 709 31T724 26Q752 26 776 56T815 138Q818 149 821 151T837 153Q857 153 857 145Q857 144 853 130Q845 101 831 73T785 17T716 -10Q669 -10 648 17T627 73Q627 92 663 193T700 345Q700 404 656 404H651Q565 404 506 303L499 291L466 157Q433 26 428 16Q415 -11 385 -11Q372 -11 364 -4T353 8T350 18Q350 29 384 161L420 307Q423 322 423 345Q423 404 379 404H374Q288 404 229 303L222 291L189 157Q156 26 151 16Q138 -11 108 -11Q95 -11 87 -5T76 7T74 17Q74 30 112 181Q151 335 151 342Q154 357 154 369Q154 405 129 405Q107 405 92 377T69 316T57 280Q55 278 41 278H27Q21 284 21 287Z",[1213,1645],{"id":1646,"d":1647},"MJX-5-TEX-I-1D44E","M33 157Q33 258 109 349T280 441Q331 441 370 392Q386 422 416 422Q429 422 439 414T449 394Q449 381 412 234T374 68Q374 43 381 35T402 26Q411 27 422 35Q443 55 463 131Q469 151 473 152Q475 153 483 153H487Q506 153 506 144Q506 138 501 117T481 63T449 13Q436 0 417 -8Q409 -10 393 -10Q359 -10 336 5T306 36L300 51Q299 52 296 50Q294 48 292 46Q233 -10 172 -10Q117 -10 75 30T33 157ZM351 328Q351 334 346 350T323 385T277 405Q242 405 210 374T160 293Q131 214 119 129Q119 126 119 118T118 106Q118 61 136 44T179 26Q217 26 254 59T298 110Q300 114 325 217T351 328Z",[1213,1649],{"id":1650,"d":1651},"MJX-5-TEX-I-1D458","M121 647Q121 657 125 670T137 683Q138 683 209 688T282 694Q294 694 294 686Q294 679 244 477Q194 279 194 272Q213 282 223 291Q247 309 292 354T362 415Q402 442 438 442Q468 442 485 423T503 369Q503 344 496 327T477 302T456 291T438 288Q418 288 406 299T394 328Q394 353 410 369T442 390L458 393Q446 405 434 405H430Q398 402 367 380T294 316T228 255Q230 254 243 252T267 246T293 238T320 224T342 206T359 180T365 147Q365 130 360 106T354 66Q354 26 381 26Q429 26 459 145Q461 153 479 153H483Q499 153 499 144Q499 139 496 130Q455 -11 378 -11Q333 -11 305 15T277 90Q277 108 280 121T283 145Q283 167 269 183T234 206T200 217T182 220H180Q168 178 159 139T145 81T136 44T129 20T122 7T111 -2Q98 -11 83 -11Q66 -11 57 -1T48 16Q48 26 85 176T158 471L195 616Q196 629 188 632T149 637H144Q134 637 131 637T124 640T121 647Z",[1213,1653],{"id":1654,"d":1655},"MJX-5-TEX-I-1D454","M311 43Q296 30 267 15T206 0Q143 0 105 45T66 160Q66 265 143 353T314 442Q361 442 401 394L404 398Q406 401 409 404T418 412T431 419T447 422Q461 422 470 413T480 394Q480 379 423 152T363 -80Q345 -134 286 -169T151 -205Q10 -205 10 -137Q10 -111 28 -91T74 -71Q89 -71 102 -80T116 -111Q116 -121 114 -130T107 -144T99 -154T92 -162L90 -164H91Q101 -167 151 -167Q189 -167 211 -155Q234 -144 254 -122T282 -75Q288 -56 298 -13Q311 35 311 43ZM384 328L380 339Q377 350 375 354T369 368T359 382T346 393T328 402T306 405Q262 405 221 352Q191 313 171 233T151 117Q151 38 213 38Q269 38 323 108L331 118L384 328Z",[1213,1657],{"id":1658,"d":1659},"MJX-5-TEX-I-1D459","M117 59Q117 26 142 26Q179 26 205 131Q211 151 215 152Q217 153 225 153H229Q238 153 241 153T246 151T248 144Q247 138 245 128T234 90T214 43T183 6T137 -11Q101 -11 70 11T38 85Q38 97 39 102L104 360Q167 615 167 623Q167 626 166 628T162 632T157 634T149 635T141 636T132 637T122 637Q112 637 109 637T101 638T95 641T94 647Q94 649 96 661Q101 680 107 682T179 688Q194 689 213 690T243 693T254 694Q266 694 266 686Q266 675 193 386T118 83Q118 81 118 75T117 65V59Z",[1213,1661],{"id":1662,"d":1663},"MJX-5-TEX-I-1D44F","M73 647Q73 657 77 670T89 683Q90 683 161 688T234 694Q246 694 246 685T212 542Q204 508 195 472T180 418L176 399Q176 396 182 402Q231 442 283 442Q345 442 383 396T422 280Q422 169 343 79T173 -11Q123 -11 82 27T40 150V159Q40 180 48 217T97 414Q147 611 147 623T109 637Q104 637 101 637H96Q86 637 83 637T76 640T73 647ZM336 325V331Q336 405 275 405Q258 405 240 397T207 376T181 352T163 330L157 322L136 236Q114 150 114 114Q114 66 138 42Q154 26 178 26Q211 26 245 58Q270 81 285 114T318 219Q336 291 336 325Z",[1213,1665],{"id":1666,"d":1667},"MJX-5-TEX-I-1D435","M231 637Q204 637 199 638T194 649Q194 676 205 682Q206 683 335 683Q594 683 608 681Q671 671 713 636T756 544Q756 480 698 429T565 360L555 357Q619 348 660 311T702 219Q702 146 630 78T453 1Q446 0 242 0Q42 0 39 2Q35 5 35 10Q35 17 37 24Q42 43 47 45Q51 46 62 46H68Q95 46 128 49Q142 52 147 61Q150 65 219 339T288 628Q288 635 231 637ZM649 544Q649 574 634 600T585 634Q578 636 493 637Q473 637 451 637T416 636H403Q388 635 384 626Q382 622 352 506Q352 503 351 500L320 374H401Q482 374 494 376Q554 386 601 434T649 544ZM595 229Q595 273 572 302T512 336Q506 337 429 337Q311 337 310 336Q310 334 293 263T258 122L240 52Q240 48 252 48T333 46Q422 46 429 47Q491 54 543 105T595 229Z",[1213,1669],{"id":1670,"d":1240},"MJX-5-TEX-N-2026",[1213,1672],{"id":1673,"d":1674},"MJX-5-TEX-N-29","M60 749L64 750Q69 750 74 750H86L114 726Q208 641 251 514T294 250Q294 182 284 119T261 12T224 -76T186 -143T145 -194T113 -227T90 -246Q87 -249 86 -250H74Q66 -250 63 -250T58 -247T55 -238Q56 -237 66 -225Q221 -64 221 250T66 725Q56 737 55 738Q55 746 60 749Z",[1242,1676,1677],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,1678,1679,1685,1692,1698,1722,1727,1800,1805,1871,1876,1944,1949,1954,1959,1966,1971,1977],{"dataMmlNode":1249},[1242,1680,1681],{"dataMmlNode":1260},[1254,1682],{"dataC":1683,"xLinkHref":1684},"28","#MJX-5-TEX-N-28",[1242,1686,1688],{"dataMmlNode":1252,"transform":1687},"translate(389,0)",[1254,1689],{"dataC":1690,"xLinkHref":1691},"1D6FC","#MJX-5-TEX-I-1D6FC",[1242,1693,1695],{"dataMmlNode":1260,"transform":1694},"translate(1029,0)",[1254,1696],{"dataC":1279,"xLinkHref":1697},"#MJX-5-TEX-N-2C",[1242,1699,1701,1707],{"dataMmlNode":1370,"transform":1700},"translate(1473.7,0)",[1242,1702,1703],{"dataMmlNode":1252},[1254,1704],{"dataC":1705,"xLinkHref":1706},"1D6FF","#MJX-5-TEX-I-1D6FF",[1242,1708,1710,1715],{"dataMmlNode":1373,"transform":1709,"dataMjxTexclass":1374},"translate(477,-150) scale(0.707)",[1242,1711,1712],{"dataMmlNode":1252},[1254,1713],{"dataC":1256,"xLinkHref":1714},"#MJX-5-TEX-I-1D461",[1242,1716,1718],{"dataMmlNode":1252,"transform":1717},"translate(361,0)",[1254,1719],{"dataC":1720,"xLinkHref":1721},"1D465","#MJX-5-TEX-I-1D465",[1242,1723,1725],{"dataMmlNode":1260,"transform":1724},"translate(2660.4,0)",[1254,1726],{"dataC":1279,"xLinkHref":1697},[1242,1728,1731,1735,1765],{"dataMmlNode":1729,"transform":1730},"msubsup","translate(3105.1,0)",[1242,1732,1733],{"dataMmlNode":1252},[1254,1734],{"dataC":1705,"xLinkHref":1706},[1242,1736,1738,1744,1751,1758],{"dataMmlNode":1373,"transform":1737,"dataMjxTexclass":1374},"translate(477,363) scale(0.707)",[1242,1739,1740],{"dataMmlNode":1252},[1254,1741],{"dataC":1742,"xLinkHref":1743},"1D462","#MJX-5-TEX-I-1D462",[1242,1745,1747],{"dataMmlNode":1252,"transform":1746},"translate(572,0)",[1254,1748],{"dataC":1749,"xLinkHref":1750},"1D460","#MJX-5-TEX-I-1D460",[1242,1752,1754],{"dataMmlNode":1252,"transform":1753},"translate(1041,0)",[1254,1755],{"dataC":1756,"xLinkHref":1757},"1D452","#MJX-5-TEX-I-1D452",[1242,1759,1761],{"dataMmlNode":1252,"transform":1760},"translate(1507,0)",[1254,1762],{"dataC":1763,"xLinkHref":1764},"1D45F","#MJX-5-TEX-I-1D45F",[1242,1766,1768,1772,1779,1786,1793],{"dataMmlNode":1373,"transform":1767,"dataMjxTexclass":1374},"translate(477,-315.5) scale(0.707)",[1242,1769,1770],{"dataMmlNode":1252},[1254,1771],{"dataC":1756,"xLinkHref":1757},[1242,1773,1775],{"dataMmlNode":1252,"transform":1774},"translate(466,0)",[1254,1776],{"dataC":1777,"xLinkHref":1778},"1D45D","#MJX-5-TEX-I-1D45D",[1242,1780,1782],{"dataMmlNode":1252,"transform":1781},"translate(969,0)",[1254,1783],{"dataC":1784,"xLinkHref":1785},"1D45C","#MJX-5-TEX-I-1D45C",[1242,1787,1789],{"dataMmlNode":1252,"transform":1788},"translate(1454,0)",[1254,1790],{"dataC":1791,"xLinkHref":1792},"1D450","#MJX-5-TEX-I-1D450",[1242,1794,1796],{"dataMmlNode":1252,"transform":1795},"translate(1887,0)",[1254,1797],{"dataC":1798,"xLinkHref":1799},"210E","#MJX-5-TEX-I-210E",[1242,1801,1803],{"dataMmlNode":1260,"transform":1802},"translate(5373.7,0)",[1254,1804],{"dataC":1279,"xLinkHref":1697},[1242,1806,1808,1812,1849],{"dataMmlNode":1729,"transform":1807},"translate(5818.3,0)",[1242,1809,1810],{"dataMmlNode":1252},[1254,1811],{"dataC":1705,"xLinkHref":1706},[1242,1813,1814,1820,1827,1832,1839,1844],{"dataMmlNode":1373,"transform":1737,"dataMjxTexclass":1374},[1242,1815,1816],{"dataMmlNode":1252},[1254,1817],{"dataC":1818,"xLinkHref":1819},"1D45A","#MJX-5-TEX-I-1D45A",[1242,1821,1823],{"dataMmlNode":1252,"transform":1822},"translate(878,0)",[1254,1824],{"dataC":1825,"xLinkHref":1826},"1D44E","#MJX-5-TEX-I-1D44E",[1242,1828,1830],{"dataMmlNode":1252,"transform":1829},"translate(1407,0)",[1254,1831],{"dataC":1763,"xLinkHref":1764},[1242,1833,1835],{"dataMmlNode":1252,"transform":1834},"translate(1858,0)",[1254,1836],{"dataC":1837,"xLinkHref":1838},"1D458","#MJX-5-TEX-I-1D458",[1242,1840,1842],{"dataMmlNode":1252,"transform":1841},"translate(2379,0)",[1254,1843],{"dataC":1756,"xLinkHref":1757},[1242,1845,1847],{"dataMmlNode":1252,"transform":1846},"translate(2845,0)",[1254,1848],{"dataC":1256,"xLinkHref":1714},[1242,1850,1851,1855,1859,1863,1867],{"dataMmlNode":1373,"transform":1767,"dataMjxTexclass":1374},[1242,1852,1853],{"dataMmlNode":1252},[1254,1854],{"dataC":1756,"xLinkHref":1757},[1242,1856,1857],{"dataMmlNode":1252,"transform":1774},[1254,1858],{"dataC":1777,"xLinkHref":1778},[1242,1860,1861],{"dataMmlNode":1252,"transform":1781},[1254,1862],{"dataC":1784,"xLinkHref":1785},[1242,1864,1865],{"dataMmlNode":1252,"transform":1788},[1254,1866],{"dataC":1791,"xLinkHref":1792},[1242,1868,1869],{"dataMmlNode":1252,"transform":1795},[1254,1870],{"dataC":1798,"xLinkHref":1799},[1242,1872,1874],{"dataMmlNode":1260,"transform":1873},"translate(8612.3,0)",[1254,1875],{"dataC":1279,"xLinkHref":1697},[1242,1877,1879,1883,1921],{"dataMmlNode":1729,"transform":1878},"translate(9057,0)",[1242,1880,1881],{"dataMmlNode":1252},[1254,1882],{"dataC":1705,"xLinkHref":1706},[1242,1884,1886,1892,1899,1904,1911,1916],{"dataMmlNode":1373,"transform":1885,"dataMjxTexclass":1374},"translate(477,498.6) scale(0.707)",[1242,1887,1888],{"dataMmlNode":1252},[1254,1889],{"dataC":1890,"xLinkHref":1891},"1D454","#MJX-5-TEX-I-1D454",[1242,1893,1895],{"dataMmlNode":1252,"transform":1894},"translate(477,0)",[1254,1896],{"dataC":1897,"xLinkHref":1898},"1D459","#MJX-5-TEX-I-1D459",[1242,1900,1902],{"dataMmlNode":1252,"transform":1901},"translate(775,0)",[1254,1903],{"dataC":1784,"xLinkHref":1785},[1242,1905,1907],{"dataMmlNode":1252,"transform":1906},"translate(1260,0)",[1254,1908],{"dataC":1909,"xLinkHref":1910},"1D44F","#MJX-5-TEX-I-1D44F",[1242,1912,1914],{"dataMmlNode":1252,"transform":1913},"translate(1689,0)",[1254,1915],{"dataC":1825,"xLinkHref":1826},[1242,1917,1919],{"dataMmlNode":1252,"transform":1918},"translate(2218,0)",[1254,1920],{"dataC":1897,"xLinkHref":1898},[1242,1922,1924,1928,1932,1936,1940],{"dataMmlNode":1373,"transform":1923,"dataMjxTexclass":1374},"translate(477,-317.1) scale(0.707)",[1242,1925,1926],{"dataMmlNode":1252},[1254,1927],{"dataC":1756,"xLinkHref":1757},[1242,1929,1930],{"dataMmlNode":1252,"transform":1774},[1254,1931],{"dataC":1777,"xLinkHref":1778},[1242,1933,1934],{"dataMmlNode":1252,"transform":1781},[1254,1935],{"dataC":1784,"xLinkHref":1785},[1242,1937,1938],{"dataMmlNode":1252,"transform":1788},[1254,1939],{"dataC":1791,"xLinkHref":1792},[1242,1941,1942],{"dataMmlNode":1252,"transform":1795},[1254,1943],{"dataC":1798,"xLinkHref":1799},[1242,1945,1947],{"dataMmlNode":1260,"transform":1946},"translate(11363.1,0)",[1254,1948],{"dataC":1279,"xLinkHref":1697},[1242,1950,1952],{"dataMmlNode":1252,"transform":1951},"translate(11807.7,0)",[1254,1953],{"dataC":1837,"xLinkHref":1838},[1242,1955,1957],{"dataMmlNode":1260,"transform":1956},"translate(12328.7,0)",[1254,1958],{"dataC":1279,"xLinkHref":1697},[1242,1960,1962],{"dataMmlNode":1252,"transform":1961},"translate(12773.4,0)",[1254,1963],{"dataC":1964,"xLinkHref":1965},"1D435","#MJX-5-TEX-I-1D435",[1242,1967,1969],{"dataMmlNode":1260,"transform":1968},"translate(13532.4,0)",[1254,1970],{"dataC":1279,"xLinkHref":1697},[1242,1972,1974],{"dataMmlNode":1260,"transform":1973},"translate(13977.1,0)",[1254,1975],{"dataC":1310,"xLinkHref":1976},"#MJX-5-TEX-N-2026",[1242,1978,1980],{"dataMmlNode":1260,"transform":1979},"translate(15149.1,0)",[1254,1981],{"dataC":1982,"xLinkHref":1983},"29","#MJX-5-TEX-N-29",[1985,1986,1989,2064,2443],"callout",{"title":1987,"type":1988},"Cap vector semantics","note",[1027,1990,1991,1992,2059,2060,2063],{},"The epoch cap ",[1193,1993,1995],{"className":1994,"jax":1197},[1196],[1199,1996,2001,2021],{"style":1997,"xmlns":1202,"width":1998,"height":1999,"role":1205,"focusable":1206,"viewBox":2000,"xmlnsXLink":1208},"vertical-align: -0.65ex;","5.133ex","2.272ex","0 -717 2268.6 1004.2",[1210,2002,2003,2006,2009,2012,2015,2018],{},[1213,2004],{"id":2005,"d":1600},"MJX-6-TEX-I-1D6FF",[1213,2007],{"id":2008,"d":1619},"MJX-6-TEX-I-1D452",[1213,2010],{"id":2011,"d":1627},"MJX-6-TEX-I-1D45D",[1213,2013],{"id":2014,"d":1631},"MJX-6-TEX-I-1D45C",[1213,2016],{"id":2017,"d":1635},"MJX-6-TEX-I-1D450",[1213,2019],{"id":2020,"d":1639},"MJX-6-TEX-I-210E",[1242,2022,2023],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2024,2025],{"dataMmlNode":1249},[1242,2026,2027,2032],{"dataMmlNode":1370},[1242,2028,2029],{"dataMmlNode":1252},[1254,2030],{"dataC":1705,"xLinkHref":2031},"#MJX-6-TEX-I-1D6FF",[1242,2033,2034,2039,2044,2049,2054],{"dataMmlNode":1373,"transform":1709,"dataMjxTexclass":1374},[1242,2035,2036],{"dataMmlNode":1252},[1254,2037],{"dataC":1756,"xLinkHref":2038},"#MJX-6-TEX-I-1D452",[1242,2040,2041],{"dataMmlNode":1252,"transform":1774},[1254,2042],{"dataC":1777,"xLinkHref":2043},"#MJX-6-TEX-I-1D45D",[1242,2045,2046],{"dataMmlNode":1252,"transform":1781},[1254,2047],{"dataC":1784,"xLinkHref":2048},"#MJX-6-TEX-I-1D45C",[1242,2050,2051],{"dataMmlNode":1252,"transform":1788},[1254,2052],{"dataC":1791,"xLinkHref":2053},"#MJX-6-TEX-I-1D450",[1242,2055,2056],{"dataMmlNode":1252,"transform":1795},[1254,2057],{"dataC":1798,"xLinkHref":2058},"#MJX-6-TEX-I-210E"," is not a single number. It’s a ",[1073,2061,2062],{},"cap vector",":",[1042,2065,2066,2195,2333],{},[1045,2067,2068,2194],{},[1193,2069,2071],{"className":2070,"jax":1197},[1196],[1199,2072,2077,2116],{"style":2073,"xmlns":1202,"width":2074,"height":2075,"role":1205,"focusable":1206,"viewBox":2076,"xmlnsXLink":1208},"vertical-align: -1.024ex;","7.673ex","2.721ex","0 -750 3391.6 1202.7",[1210,2078,2079,2082,2085,2088,2091,2094,2097,2100,2103,2106,2109,2113],{},[1213,2080],{"id":2081,"d":1600},"MJX-7-TEX-I-1D6FF",[1213,2083],{"id":2084,"d":1611},"MJX-7-TEX-I-1D462",[1213,2086],{"id":2087,"d":1615},"MJX-7-TEX-I-1D460",[1213,2089],{"id":2090,"d":1619},"MJX-7-TEX-I-1D452",[1213,2092],{"id":2093,"d":1623},"MJX-7-TEX-I-1D45F",[1213,2095],{"id":2096,"d":1627},"MJX-7-TEX-I-1D45D",[1213,2098],{"id":2099,"d":1631},"MJX-7-TEX-I-1D45C",[1213,2101],{"id":2102,"d":1635},"MJX-7-TEX-I-1D450",[1213,2104],{"id":2105,"d":1639},"MJX-7-TEX-I-210E",[1213,2107],{"id":2108,"d":1589},"MJX-7-TEX-N-28",[1213,2110],{"id":2111,"d":2112},"MJX-7-TEX-I-1D456","M184 600Q184 624 203 642T247 661Q265 661 277 649T290 619Q290 596 270 577T226 557Q211 557 198 567T184 600ZM21 287Q21 295 30 318T54 369T98 420T158 442Q197 442 223 419T250 357Q250 340 236 301T196 196T154 83Q149 61 149 51Q149 26 166 26Q175 26 185 29T208 43T235 78T260 137Q263 149 265 151T282 153Q302 153 302 143Q302 135 293 112T268 61T223 11T161 -11Q129 -11 102 10T74 74Q74 91 79 106T122 220Q160 321 166 341T173 380Q173 404 156 404H154Q124 404 99 371T61 287Q60 286 59 284T58 281T56 279T53 278T49 278T41 278H27Q21 284 21 287Z",[1213,2114],{"id":2115,"d":1674},"MJX-7-TEX-N-29",[1242,2117,2118],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2119,2120,2175,2181,2188],{"dataMmlNode":1249},[1242,2121,2122,2127,2149],{"dataMmlNode":1729},[1242,2123,2124],{"dataMmlNode":1252},[1254,2125],{"dataC":1705,"xLinkHref":2126},"#MJX-7-TEX-I-1D6FF",[1242,2128,2129,2134,2139,2144],{"dataMmlNode":1373,"transform":1737,"dataMjxTexclass":1374},[1242,2130,2131],{"dataMmlNode":1252},[1254,2132],{"dataC":1742,"xLinkHref":2133},"#MJX-7-TEX-I-1D462",[1242,2135,2136],{"dataMmlNode":1252,"transform":1746},[1254,2137],{"dataC":1749,"xLinkHref":2138},"#MJX-7-TEX-I-1D460",[1242,2140,2141],{"dataMmlNode":1252,"transform":1753},[1254,2142],{"dataC":1756,"xLinkHref":2143},"#MJX-7-TEX-I-1D452",[1242,2145,2146],{"dataMmlNode":1252,"transform":1760},[1254,2147],{"dataC":1763,"xLinkHref":2148},"#MJX-7-TEX-I-1D45F",[1242,2150,2151,2155,2160,2165,2170],{"dataMmlNode":1373,"transform":1767,"dataMjxTexclass":1374},[1242,2152,2153],{"dataMmlNode":1252},[1254,2154],{"dataC":1756,"xLinkHref":2143},[1242,2156,2157],{"dataMmlNode":1252,"transform":1774},[1254,2158],{"dataC":1777,"xLinkHref":2159},"#MJX-7-TEX-I-1D45D",[1242,2161,2162],{"dataMmlNode":1252,"transform":1781},[1254,2163],{"dataC":1784,"xLinkHref":2164},"#MJX-7-TEX-I-1D45C",[1242,2166,2167],{"dataMmlNode":1252,"transform":1788},[1254,2168],{"dataC":1791,"xLinkHref":2169},"#MJX-7-TEX-I-1D450",[1242,2171,2172],{"dataMmlNode":1252,"transform":1795},[1254,2173],{"dataC":1798,"xLinkHref":2174},"#MJX-7-TEX-I-210E",[1242,2176,2178],{"dataMmlNode":1260,"transform":2177},"translate(2268.6,0)",[1254,2179],{"dataC":1683,"xLinkHref":2180},"#MJX-7-TEX-N-28",[1242,2182,2184],{"dataMmlNode":1252,"transform":2183},"translate(2657.6,0)",[1254,2185],{"dataC":2186,"xLinkHref":2187},"1D456","#MJX-7-TEX-I-1D456",[1242,2189,2191],{"dataMmlNode":1260,"transform":2190},"translate(3002.6,0)",[1254,2192],{"dataC":1982,"xLinkHref":2193},"#MJX-7-TEX-N-29",": max claimable output per user\u002Fidentity per epoch",[1045,2196,2197,2332],{},[1193,2198,2200],{"className":2199,"jax":1197},[1196],[1199,2201,2205,2246],{"style":2073,"xmlns":1202,"width":2202,"height":2203,"role":1205,"focusable":1206,"viewBox":2204,"xmlnsXLink":1208},"10.068ex","2.956ex","0 -853.7 4450 1306.4",[1210,2206,2207,2210,2213,2216,2219,2222,2225,2228,2231,2234,2237,2240,2243],{},[1213,2208],{"id":2209,"d":1600},"MJX-8-TEX-I-1D6FF",[1213,2211],{"id":2212,"d":1643},"MJX-8-TEX-I-1D45A",[1213,2214],{"id":2215,"d":1647},"MJX-8-TEX-I-1D44E",[1213,2217],{"id":2218,"d":1623},"MJX-8-TEX-I-1D45F",[1213,2220],{"id":2221,"d":1651},"MJX-8-TEX-I-1D458",[1213,2223],{"id":2224,"d":1619},"MJX-8-TEX-I-1D452",[1213,2226],{"id":2227,"d":1216},"MJX-8-TEX-I-1D461",[1213,2229],{"id":2230,"d":1627},"MJX-8-TEX-I-1D45D",[1213,2232],{"id":2233,"d":1631},"MJX-8-TEX-I-1D45C",[1213,2235],{"id":2236,"d":1635},"MJX-8-TEX-I-1D450",[1213,2238],{"id":2239,"d":1639},"MJX-8-TEX-I-210E",[1213,2241],{"id":2242,"d":1589},"MJX-8-TEX-N-28",[1213,2244],{"id":2245,"d":1674},"MJX-8-TEX-N-29",[1242,2247,2248],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2249,2250,2315,2321,2326],{"dataMmlNode":1249},[1242,2251,2252,2257,2289],{"dataMmlNode":1729},[1242,2253,2254],{"dataMmlNode":1252},[1254,2255],{"dataC":1705,"xLinkHref":2256},"#MJX-8-TEX-I-1D6FF",[1242,2258,2259,2264,2269,2274,2279,2284],{"dataMmlNode":1373,"transform":1737,"dataMjxTexclass":1374},[1242,2260,2261],{"dataMmlNode":1252},[1254,2262],{"dataC":1818,"xLinkHref":2263},"#MJX-8-TEX-I-1D45A",[1242,2265,2266],{"dataMmlNode":1252,"transform":1822},[1254,2267],{"dataC":1825,"xLinkHref":2268},"#MJX-8-TEX-I-1D44E",[1242,2270,2271],{"dataMmlNode":1252,"transform":1829},[1254,2272],{"dataC":1763,"xLinkHref":2273},"#MJX-8-TEX-I-1D45F",[1242,2275,2276],{"dataMmlNode":1252,"transform":1834},[1254,2277],{"dataC":1837,"xLinkHref":2278},"#MJX-8-TEX-I-1D458",[1242,2280,2281],{"dataMmlNode":1252,"transform":1841},[1254,2282],{"dataC":1756,"xLinkHref":2283},"#MJX-8-TEX-I-1D452",[1242,2285,2286],{"dataMmlNode":1252,"transform":1846},[1254,2287],{"dataC":1256,"xLinkHref":2288},"#MJX-8-TEX-I-1D461",[1242,2290,2291,2295,2300,2305,2310],{"dataMmlNode":1373,"transform":1767,"dataMjxTexclass":1374},[1242,2292,2293],{"dataMmlNode":1252},[1254,2294],{"dataC":1756,"xLinkHref":2283},[1242,2296,2297],{"dataMmlNode":1252,"transform":1774},[1254,2298],{"dataC":1777,"xLinkHref":2299},"#MJX-8-TEX-I-1D45D",[1242,2301,2302],{"dataMmlNode":1252,"transform":1781},[1254,2303],{"dataC":1784,"xLinkHref":2304},"#MJX-8-TEX-I-1D45C",[1242,2306,2307],{"dataMmlNode":1252,"transform":1788},[1254,2308],{"dataC":1791,"xLinkHref":2309},"#MJX-8-TEX-I-1D450",[1242,2311,2312],{"dataMmlNode":1252,"transform":1795},[1254,2313],{"dataC":1798,"xLinkHref":2314},"#MJX-8-TEX-I-210E",[1242,2316,2318],{"dataMmlNode":1260,"transform":2317},"translate(2794,0)",[1254,2319],{"dataC":1683,"xLinkHref":2320},"#MJX-8-TEX-N-28",[1242,2322,2324],{"dataMmlNode":1252,"transform":2323},"translate(3183,0)",[1254,2325],{"dataC":1818,"xLinkHref":2263},[1242,2327,2329],{"dataMmlNode":1260,"transform":2328},"translate(4061,0)",[1254,2330],{"dataC":1982,"xLinkHref":2331},"#MJX-8-TEX-N-29",": max claimable output per market\u002Fdomain per epoch",[1045,2334,2335,2442],{},[1193,2336,2338],{"className":2337,"jax":1197},[1196],[1199,2339,2342,2374],{"style":1580,"xmlns":1202,"width":2340,"height":1582,"role":1205,"focusable":1206,"viewBox":2341,"xmlnsXLink":1208},"5.217ex","0 -989.3 2306.1 1443.6",[1210,2343,2344,2347,2350,2353,2356,2359,2362,2365,2368,2371],{},[1213,2345],{"id":2346,"d":1600},"MJX-9-TEX-I-1D6FF",[1213,2348],{"id":2349,"d":1655},"MJX-9-TEX-I-1D454",[1213,2351],{"id":2352,"d":1659},"MJX-9-TEX-I-1D459",[1213,2354],{"id":2355,"d":1631},"MJX-9-TEX-I-1D45C",[1213,2357],{"id":2358,"d":1663},"MJX-9-TEX-I-1D44F",[1213,2360],{"id":2361,"d":1647},"MJX-9-TEX-I-1D44E",[1213,2363],{"id":2364,"d":1619},"MJX-9-TEX-I-1D452",[1213,2366],{"id":2367,"d":1627},"MJX-9-TEX-I-1D45D",[1213,2369],{"id":2370,"d":1635},"MJX-9-TEX-I-1D450",[1213,2372],{"id":2373,"d":1639},"MJX-9-TEX-I-210E",[1242,2375,2376],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2377,2378],{"dataMmlNode":1249},[1242,2379,2380,2385,2416],{"dataMmlNode":1729},[1242,2381,2382],{"dataMmlNode":1252},[1254,2383],{"dataC":1705,"xLinkHref":2384},"#MJX-9-TEX-I-1D6FF",[1242,2386,2387,2392,2397,2402,2407,2412],{"dataMmlNode":1373,"transform":1885,"dataMjxTexclass":1374},[1242,2388,2389],{"dataMmlNode":1252},[1254,2390],{"dataC":1890,"xLinkHref":2391},"#MJX-9-TEX-I-1D454",[1242,2393,2394],{"dataMmlNode":1252,"transform":1894},[1254,2395],{"dataC":1897,"xLinkHref":2396},"#MJX-9-TEX-I-1D459",[1242,2398,2399],{"dataMmlNode":1252,"transform":1901},[1254,2400],{"dataC":1784,"xLinkHref":2401},"#MJX-9-TEX-I-1D45C",[1242,2403,2404],{"dataMmlNode":1252,"transform":1906},[1254,2405],{"dataC":1909,"xLinkHref":2406},"#MJX-9-TEX-I-1D44F",[1242,2408,2409],{"dataMmlNode":1252,"transform":1913},[1254,2410],{"dataC":1825,"xLinkHref":2411},"#MJX-9-TEX-I-1D44E",[1242,2413,2414],{"dataMmlNode":1252,"transform":1918},[1254,2415],{"dataC":1897,"xLinkHref":2396},[1242,2417,2418,2423,2428,2432,2437],{"dataMmlNode":1373,"transform":1923,"dataMjxTexclass":1374},[1242,2419,2420],{"dataMmlNode":1252},[1254,2421],{"dataC":1756,"xLinkHref":2422},"#MJX-9-TEX-I-1D452",[1242,2424,2425],{"dataMmlNode":1252,"transform":1774},[1254,2426],{"dataC":1777,"xLinkHref":2427},"#MJX-9-TEX-I-1D45D",[1242,2429,2430],{"dataMmlNode":1252,"transform":1781},[1254,2431],{"dataC":1784,"xLinkHref":2401},[1242,2433,2434],{"dataMmlNode":1252,"transform":1788},[1254,2435],{"dataC":1791,"xLinkHref":2436},"#MJX-9-TEX-I-1D450",[1242,2438,2439],{"dataMmlNode":1252,"transform":1795},[1254,2440],{"dataC":1798,"xLinkHref":2441},"#MJX-9-TEX-I-210E",": optional protocol-wide backstop (“fuse”)",[1027,2444,2445],{},"These caps are deterministic safety rails: even if audits miss something briefly, total extractable value is bounded per user and per market.",[1985,2447,2449],{"title":2448,"type":1988},"Intuition",[1027,2450,2451],{},"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.",[1985,2453,2455],{"title":2454,"type":1988},"Related work",[1027,2456,2457,2458,1064],{},"Commitment trees \u002F authenticated datasets via ",[1031,2459,2462],{"href":2460,"rel":2461},"https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~raluca\u002Fcs261-f15\u002Freadings\u002Fmerkle.pdf",[1035],"Merkle trees",[1066,2464,250],{"id":2465},"commitment-structure",[1027,2467,2468,2469,2494],{},"Partition nodes into shards ",[1193,2470,2472],{"className":2471,"jax":1197},[1196],[1199,2473,2478,2484],{"style":2474,"xmlns":1202,"width":2475,"height":2476,"role":1205,"focusable":1206,"viewBox":2477,"xmlnsXLink":1208},"vertical-align: -0.462ex;","0.932ex","1.957ex","0 -661 412 865",[1210,2479,2480],{},[1213,2481],{"id":2482,"d":2483},"MJX-10-TEX-I-1D457","M297 596Q297 627 318 644T361 661Q378 661 389 651T403 623Q403 595 384 576T340 557Q322 557 310 567T297 596ZM288 376Q288 405 262 405Q240 405 220 393T185 362T161 325T144 293L137 279Q135 278 121 278H107Q101 284 101 286T105 299Q126 348 164 391T252 441Q253 441 260 441T272 442Q296 441 316 432Q341 418 354 401T367 348V332L318 133Q267 -67 264 -75Q246 -125 194 -164T75 -204Q25 -204 7 -183T-12 -137Q-12 -110 7 -91T53 -71Q70 -71 82 -81T95 -112Q95 -148 63 -167Q69 -168 77 -168Q111 -168 139 -140T182 -74L193 -32Q204 11 219 72T251 197T278 308T289 365Q289 372 288 376Z",[1242,2485,2486],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2487,2488],{"dataMmlNode":1249},[1242,2489,2490],{"dataMmlNode":1252},[1254,2491],{"dataC":2492,"xLinkHref":2493},"1D457","#MJX-10-TEX-I-1D457",". Each shard publishes:",[1193,2496,2499],{"className":2497,"jax":1197,"display":2498},[1196],"true",[1199,2500,2505,2597],{"style":2501,"xmlns":1202,"width":2502,"height":2503,"role":1205,"focusable":1206,"viewBox":2504,"xmlnsXLink":1208},"vertical-align: -0.666ex;","43.05ex","2.363ex","0 -750 19027.9 1044.2",[1210,2506,2507,2510,2513,2516,2519,2522,2525,2528,2531,2534,2537,2540,2543,2547,2551,2555,2559,2563,2567,2571,2575,2578,2582,2586,2590,2594],{},[1213,2508],{"id":2509,"d":1442},"MJX-11-TEX-SS-1D5B2",[1213,2511],{"id":2512,"d":1348},"MJX-11-TEX-SS-1D5C1",[1213,2514],{"id":2515,"d":1340},"MJX-11-TEX-SS-1D5BA",[1213,2517],{"id":2518,"d":1336},"MJX-11-TEX-SS-1D5CB",[1213,2520],{"id":2521,"d":1450},"MJX-11-TEX-SS-1D5BD",[1213,2523],{"id":2524,"d":1352},"MJX-11-TEX-SS-1D5B1",[1213,2526],{"id":2527,"d":1356},"MJX-11-TEX-SS-1D5C8",[1213,2529],{"id":2530,"d":1360},"MJX-11-TEX-SS-1D5CD",[1213,2532],{"id":2533,"d":1216},"MJX-11-TEX-I-1D461",[1213,2535],{"id":2536,"d":1228},"MJX-11-TEX-N-2C",[1213,2538],{"id":2539,"d":2483},"MJX-11-TEX-I-1D457",[1213,2541],{"id":2542,"d":1220},"MJX-11-TEX-N-3D",[1213,2544],{"id":2545,"d":2546},"MJX-11-TEX-N-4D","M132 622Q125 629 121 631T105 634T62 637H29V683H135Q221 683 232 682T249 675Q250 674 354 398L458 124L562 398Q666 674 668 675Q671 681 683 682T781 683H887V637H854Q814 636 803 634T785 622V61Q791 51 802 49T854 46H887V0H876Q855 3 736 3Q605 3 596 0H585V46H618Q660 47 669 49T688 61V347Q688 424 688 461T688 546T688 613L687 632Q454 14 450 7Q446 1 430 1T410 7Q409 9 292 316L176 624V606Q175 588 175 543T175 463T175 356L176 86Q187 50 261 46H278V0H269Q254 3 154 3Q52 3 37 0H29V46H46Q78 48 98 56T122 69T132 86V622Z",[1213,2548],{"id":2549,"d":2550},"MJX-11-TEX-N-65","M28 218Q28 273 48 318T98 391T163 433T229 448Q282 448 320 430T378 380T406 316T415 245Q415 238 408 231H126V216Q126 68 226 36Q246 30 270 30Q312 30 342 62Q359 79 369 104L379 128Q382 131 395 131H398Q415 131 415 121Q415 117 412 108Q393 53 349 21T250 -11Q155 -11 92 58T28 218ZM333 275Q322 403 238 411H236Q228 411 220 410T195 402T166 381T143 340T127 274V267H333V275Z",[1213,2552],{"id":2553,"d":2554},"MJX-11-TEX-N-72","M36 46H50Q89 46 97 60V68Q97 77 97 91T98 122T98 161T98 203Q98 234 98 269T98 328L97 351Q94 370 83 376T38 385H20V408Q20 431 22 431L32 432Q42 433 60 434T96 436Q112 437 131 438T160 441T171 442H174V373Q213 441 271 441H277Q322 441 343 419T364 373Q364 352 351 337T313 322Q288 322 276 338T263 372Q263 381 265 388T270 400T273 405Q271 407 250 401Q234 393 226 386Q179 341 179 207V154Q179 141 179 127T179 101T180 81T180 66V61Q181 59 183 57T188 54T193 51T200 49T207 48T216 47T225 47T235 46T245 46H276V0H267Q249 3 140 3Q37 3 28 0H20V46H36Z",[1213,2556],{"id":2557,"d":2558},"MJX-11-TEX-N-6B","M36 46H50Q89 46 97 60V68Q97 77 97 91T97 124T98 167T98 217T98 272T98 329Q98 366 98 407T98 482T98 542T97 586T97 603Q94 622 83 628T38 637H20V660Q20 683 22 683L32 684Q42 685 61 686T98 688Q115 689 135 690T165 693T176 694H179V463L180 233L240 287Q300 341 304 347Q310 356 310 364Q310 383 289 385H284V431H293Q308 428 412 428Q475 428 484 431H489V385H476Q407 380 360 341Q286 278 286 274Q286 273 349 181T420 79Q434 60 451 53T500 46H511V0H505Q496 3 418 3Q322 3 307 0H299V46H306Q330 48 330 65Q330 72 326 79Q323 84 276 153T228 222L176 176V120V84Q176 65 178 59T189 49Q210 46 238 46H254V0H246Q231 3 137 3T28 0H20V46H36Z",[1213,2560],{"id":2561,"d":2562},"MJX-11-TEX-N-6C","M42 46H56Q95 46 103 60V68Q103 77 103 91T103 124T104 167T104 217T104 272T104 329Q104 366 104 407T104 482T104 542T103 586T103 603Q100 622 89 628T44 637H26V660Q26 683 28 683L38 684Q48 685 67 686T104 688Q121 689 141 690T171 693T182 694H185V379Q185 62 186 60Q190 52 198 49Q219 46 247 46H263V0H255L232 1Q209 2 183 2T145 3T107 3T57 1L34 0H26V46H42Z",[1213,2564],{"id":2565,"d":2566},"MJX-11-TEX-N-52","M130 622Q123 629 119 631T103 634T60 637H27V683H202H236H300Q376 683 417 677T500 648Q595 600 609 517Q610 512 610 501Q610 468 594 439T556 392T511 361T472 343L456 338Q459 335 467 332Q497 316 516 298T545 254T559 211T568 155T578 94Q588 46 602 31T640 16H645Q660 16 674 32T692 87Q692 98 696 101T712 105T728 103T732 90Q732 59 716 27T672 -16Q656 -22 630 -22Q481 -16 458 90Q456 101 456 163T449 246Q430 304 373 320L363 322L297 323H231V192L232 61Q238 51 249 49T301 46H334V0H323Q302 3 181 3Q59 3 38 0H27V46H60Q102 47 111 49T130 61V622ZM491 499V509Q491 527 490 539T481 570T462 601T424 623T362 636Q360 636 340 636T304 637H283Q238 637 234 628Q231 624 231 492V360H289Q390 360 434 378T489 456Q491 467 491 499Z",[1213,2568],{"id":2569,"d":2570},"MJX-11-TEX-N-6F","M28 214Q28 309 93 378T250 448Q340 448 405 380T471 215Q471 120 407 55T250 -10Q153 -10 91 57T28 214ZM250 30Q372 30 372 193V225V250Q372 272 371 288T364 326T348 362T317 390T268 410Q263 411 252 411Q222 411 195 399Q152 377 139 338T126 246V226Q126 130 145 91Q177 30 250 30Z",[1213,2572],{"id":2573,"d":2574},"MJX-11-TEX-N-74","M27 422Q80 426 109 478T141 600V615H181V431H316V385H181V241Q182 116 182 100T189 68Q203 29 238 29Q282 29 292 100Q293 108 293 146V181H333V146V134Q333 57 291 17Q264 -10 221 -10Q187 -10 162 2T124 33T105 68T98 100Q97 107 97 248V385H18V422H27Z",[1213,2576],{"id":2577,"d":1589},"MJX-11-TEX-N-28",[1213,2579],{"id":2580,"d":2581},"MJX-11-TEX-N-4E","M42 46Q74 48 94 56T118 69T128 86V634H124Q114 637 52 637H25V683H232L235 680Q237 679 322 554T493 303L578 178V598Q572 608 568 613T544 627T492 637H475V683H483Q498 680 600 680Q706 680 715 683H724V637H707Q634 633 622 598L621 302V6L614 0H600Q585 0 582 3T481 150T282 443T171 605V345L172 86Q183 50 257 46H274V0H265Q250 3 150 3Q48 3 33 0H25V46H42Z",[1213,2583],{"id":2584,"d":2585},"MJX-11-TEX-N-64","M376 495Q376 511 376 535T377 568Q377 613 367 624T316 637H298V660Q298 683 300 683L310 684Q320 685 339 686T376 688Q393 689 413 690T443 693T454 694H457V390Q457 84 458 81Q461 61 472 55T517 46H535V0Q533 0 459 -5T380 -11H373V44L365 37Q307 -11 235 -11Q158 -11 96 50T34 215Q34 315 97 378T244 442Q319 442 376 393V495ZM373 342Q328 405 260 405Q211 405 173 369Q146 341 139 305T131 211Q131 155 138 120T173 59Q203 26 251 26Q322 26 373 103V342Z",[1213,2587],{"id":2588,"d":2589},"MJX-11-TEX-N-63","M370 305T349 305T313 320T297 358Q297 381 312 396Q317 401 317 402T307 404Q281 408 258 408Q209 408 178 376Q131 329 131 219Q131 137 162 90Q203 29 272 29Q313 29 338 55T374 117Q376 125 379 127T395 129H409Q415 123 415 120Q415 116 411 104T395 71T366 33T318 2T249 -11Q163 -11 99 53T34 214Q34 318 99 383T250 448T370 421T404 357Q404 334 387 320Z",[1213,2591],{"id":2592,"d":2593},"MJX-11-TEX-N-73","M295 316Q295 356 268 385T190 414Q154 414 128 401Q98 382 98 349Q97 344 98 336T114 312T157 287Q175 282 201 278T245 269T277 256Q294 248 310 236T342 195T359 133Q359 71 321 31T198 -10H190Q138 -10 94 26L86 19L77 10Q71 4 65 -1L54 -11H46H42Q39 -11 33 -5V74V132Q33 153 35 157T45 162H54Q66 162 70 158T75 146T82 119T101 77Q136 26 198 26Q295 26 295 104Q295 133 277 151Q257 175 194 187T111 210Q75 227 54 256T33 318Q33 357 50 384T93 424T143 442T187 447H198Q238 447 268 432L283 424L292 431Q302 440 314 448H322H326Q329 448 335 442V310L329 304H301Q295 310 295 316Z",[1213,2595],{"id":2596,"d":1674},"MJX-11-TEX-N-29",[1242,2598,2599],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2600,2601,2659,2665,2715,2721,2782],{"dataMmlNode":1249},[1242,2602,2603,2640],{"dataMmlNode":1370},[1242,2604,2605],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,2606,2607,2610,2613,2617,2621,2625,2629,2633,2636],{"dataMmlNode":1252},[1254,2608],{"dataC":1475,"xLinkHref":2609},"#MJX-11-TEX-SS-1D5B2",[1254,2611],{"dataC":1398,"xLinkHref":2612,"transform":1481},"#MJX-11-TEX-SS-1D5C1",[1254,2614],{"dataC":1388,"xLinkHref":2615,"transform":2616},"#MJX-11-TEX-SS-1D5BA","translate(1073,0)",[1254,2618],{"dataC":1383,"xLinkHref":2619,"transform":2620},"#MJX-11-TEX-SS-1D5CB","translate(1554,0)",[1254,2622],{"dataC":1487,"xLinkHref":2623,"transform":2624},"#MJX-11-TEX-SS-1D5BD","translate(1896,0)",[1254,2626],{"dataC":1403,"xLinkHref":2627,"transform":2628},"#MJX-11-TEX-SS-1D5B1","translate(2413,0)",[1254,2630],{"dataC":1408,"xLinkHref":2631,"transform":2632},"#MJX-11-TEX-SS-1D5C8","translate(3059,0)",[1254,2634],{"dataC":1408,"xLinkHref":2631,"transform":2635},"translate(3559,0)",[1254,2637],{"dataC":1416,"xLinkHref":2638,"transform":2639},"#MJX-11-TEX-SS-1D5CD","translate(4059,0)",[1242,2641,2643,2648,2653],{"dataMmlNode":1373,"transform":2642,"dataMjxTexclass":1374},"translate(4453,-150) scale(0.707)",[1242,2644,2645],{"dataMmlNode":1252},[1254,2646],{"dataC":1256,"xLinkHref":2647},"#MJX-11-TEX-I-1D461",[1242,2649,2650],{"dataMmlNode":1260,"transform":1717},[1254,2651],{"dataC":1279,"xLinkHref":2652},"#MJX-11-TEX-N-2C",[1242,2654,2656],{"dataMmlNode":1252,"transform":2655},"translate(639,0)",[1254,2657],{"dataC":2492,"xLinkHref":2658},"#MJX-11-TEX-I-1D457",[1242,2660,2662],{"dataMmlNode":1260,"transform":2661},"translate(5523.9,0)",[1254,2663],{"dataC":1264,"xLinkHref":2664},"#MJX-11-TEX-N-3D",[1242,2666,2668],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":2667},"translate(6579.7,0)",[1242,2669,2670,2674,2679,2684,2689,2694,2697,2702,2707,2710],{"dataMmlNode":1252},[1254,2671],{"dataC":2672,"xLinkHref":2673},"4D","#MJX-11-TEX-N-4D",[1254,2675],{"dataC":2676,"xLinkHref":2677,"transform":2678},"65","#MJX-11-TEX-N-65","translate(917,0)",[1254,2680],{"dataC":2681,"xLinkHref":2682,"transform":2683},"72","#MJX-11-TEX-N-72","translate(1361,0)",[1254,2685],{"dataC":2686,"xLinkHref":2687,"transform":2688},"6B","#MJX-11-TEX-N-6B","translate(1753,0)",[1254,2690],{"dataC":2691,"xLinkHref":2692,"transform":2693},"6C","#MJX-11-TEX-N-6C","translate(2281,0)",[1254,2695],{"dataC":2676,"xLinkHref":2677,"transform":2696},"translate(2559,0)",[1254,2698],{"dataC":2699,"xLinkHref":2700,"transform":2701},"52","#MJX-11-TEX-N-52","translate(3003,0)",[1254,2703],{"dataC":2704,"xLinkHref":2705,"transform":2706},"6F","#MJX-11-TEX-N-6F","translate(3739,0)",[1254,2708],{"dataC":2704,"xLinkHref":2705,"transform":2709},"translate(4239,0)",[1254,2711],{"dataC":2712,"xLinkHref":2713,"transform":2714},"74","#MJX-11-TEX-N-74","translate(4739,0)",[1242,2716,2718],{"dataMmlNode":1260,"transform":2717},"translate(11707.7,0)",[1254,2719],{"dataC":1683,"xLinkHref":2720},"#MJX-11-TEX-N-28",[1242,2722,2724,2767],{"dataMmlNode":1370,"transform":2723},"translate(12096.7,0)",[1242,2725,2727,2731,2734,2739,2742,2745,2748,2753,2756,2759,2762],{"dataMmlNode":2726},"mtext",[1254,2728],{"dataC":2729,"xLinkHref":2730},"4E","#MJX-11-TEX-N-4E",[1254,2732],{"dataC":2704,"xLinkHref":2705,"transform":2733},"translate(750,0)",[1254,2735],{"dataC":2736,"xLinkHref":2737,"transform":2738},"64","#MJX-11-TEX-N-64","translate(1250,0)",[1254,2740],{"dataC":2676,"xLinkHref":2677,"transform":2741},"translate(1806,0)",[1254,2743],{"dataC":2699,"xLinkHref":2700,"transform":2744},"translate(2250,0)",[1254,2746],{"dataC":2676,"xLinkHref":2677,"transform":2747},"translate(2986,0)",[1254,2749],{"dataC":2750,"xLinkHref":2751,"transform":2752},"63","#MJX-11-TEX-N-63","translate(3430,0)",[1254,2754],{"dataC":2704,"xLinkHref":2705,"transform":2755},"translate(3874,0)",[1254,2757],{"dataC":2681,"xLinkHref":2682,"transform":2758},"translate(4374,0)",[1254,2760],{"dataC":2736,"xLinkHref":2737,"transform":2761},"translate(4766,0)",[1254,2763],{"dataC":2764,"xLinkHref":2765,"transform":2766},"73","#MJX-11-TEX-N-73","translate(5322,0)",[1242,2768,2770,2774,2778],{"dataMmlNode":1373,"transform":2769,"dataMjxTexclass":1374},"translate(5749,-150) scale(0.707)",[1242,2771,2772],{"dataMmlNode":1252},[1254,2773],{"dataC":1256,"xLinkHref":2647},[1242,2775,2776],{"dataMmlNode":1260,"transform":1717},[1254,2777],{"dataC":1279,"xLinkHref":2652},[1242,2779,2780],{"dataMmlNode":1252,"transform":2655},[1254,2781],{"dataC":2492,"xLinkHref":2658},[1242,2783,2785],{"dataMmlNode":1260,"transform":2784},"translate(18638.9,0)",[1254,2786],{"dataC":1982,"xLinkHref":2787},"#MJX-11-TEX-N-29",[1027,2789,2790],{},"The global graph root is:",[1193,2792,2794],{"className":2793,"jax":1197,"display":2498},[1196],[1199,2795,2798,2880],{"style":2501,"xmlns":1202,"width":2796,"height":2503,"role":1205,"focusable":1206,"viewBox":2797,"xmlnsXLink":1208},"42.751ex","0 -750 18896 1044.2",[1210,2799,2800,2803,2806,2809,2812,2815,2818,2821,2824,2827,2830,2833,2836,2839,2842,2845,2848,2851,2854,2857,2861,2864,2867,2870,2873,2877],{},[1213,2801],{"id":2802,"d":1332},"MJX-12-TEX-SS-1D5A6",[1213,2804],{"id":2805,"d":1336},"MJX-12-TEX-SS-1D5CB",[1213,2807],{"id":2808,"d":1340},"MJX-12-TEX-SS-1D5BA",[1213,2810],{"id":2811,"d":1344},"MJX-12-TEX-SS-1D5C9",[1213,2813],{"id":2814,"d":1348},"MJX-12-TEX-SS-1D5C1",[1213,2816],{"id":2817,"d":1352},"MJX-12-TEX-SS-1D5B1",[1213,2819],{"id":2820,"d":1356},"MJX-12-TEX-SS-1D5C8",[1213,2822],{"id":2823,"d":1360},"MJX-12-TEX-SS-1D5CD",[1213,2825],{"id":2826,"d":1216},"MJX-12-TEX-I-1D461",[1213,2828],{"id":2829,"d":1220},"MJX-12-TEX-N-3D",[1213,2831],{"id":2832,"d":2546},"MJX-12-TEX-N-4D",[1213,2834],{"id":2835,"d":2550},"MJX-12-TEX-N-65",[1213,2837],{"id":2838,"d":2554},"MJX-12-TEX-N-72",[1213,2840],{"id":2841,"d":2558},"MJX-12-TEX-N-6B",[1213,2843],{"id":2844,"d":2562},"MJX-12-TEX-N-6C",[1213,2846],{"id":2847,"d":2566},"MJX-12-TEX-N-52",[1213,2849],{"id":2850,"d":2570},"MJX-12-TEX-N-6F",[1213,2852],{"id":2853,"d":2574},"MJX-12-TEX-N-74",[1213,2855],{"id":2856,"d":1589},"MJX-12-TEX-N-28",[1213,2858],{"id":2859,"d":2860},"MJX-12-TEX-N-7B","M434 -231Q434 -244 428 -250H410Q281 -250 230 -184Q225 -177 222 -172T217 -161T213 -148T211 -133T210 -111T209 -84T209 -47T209 0Q209 21 209 53Q208 142 204 153Q203 154 203 155Q189 191 153 211T82 231Q71 231 68 234T65 250T68 266T82 269Q116 269 152 289T203 345Q208 356 208 377T209 529V579Q209 634 215 656T244 698Q270 724 324 740Q361 748 377 749Q379 749 390 749T408 750H428Q434 744 434 732Q434 719 431 716Q429 713 415 713Q362 710 332 689T296 647Q291 634 291 499V417Q291 370 288 353T271 314Q240 271 184 255L170 250L184 245Q202 239 220 230T262 196T290 137Q291 131 291 1Q291 -134 296 -147Q306 -174 339 -192T415 -213Q429 -213 431 -216Q434 -219 434 -231Z",[1213,2862],{"id":2863,"d":1442},"MJX-12-TEX-SS-1D5B2",[1213,2865],{"id":2866,"d":1450},"MJX-12-TEX-SS-1D5BD",[1213,2868],{"id":2869,"d":1228},"MJX-12-TEX-N-2C",[1213,2871],{"id":2872,"d":2483},"MJX-12-TEX-I-1D457",[1213,2874],{"id":2875,"d":2876},"MJX-12-TEX-N-7D","M65 731Q65 745 68 747T88 750Q171 750 216 725T279 670Q288 649 289 635T291 501Q292 362 293 357Q306 312 345 291T417 269Q428 269 431 266T434 250T431 234T417 231Q380 231 345 210T298 157Q293 143 292 121T291 -28V-79Q291 -134 285 -156T256 -198Q202 -250 89 -250Q71 -250 68 -247T65 -230Q65 -224 65 -223T66 -218T69 -214T77 -213Q91 -213 108 -210T146 -200T183 -177T207 -139Q208 -134 209 3L210 139Q223 196 280 230Q315 247 330 250Q305 257 280 270Q225 304 212 352L210 362L209 498Q208 635 207 640Q195 680 154 696T77 713Q68 713 67 716T65 731Z",[1213,2878],{"id":2879,"d":1674},"MJX-12-TEX-N-29",[1242,2881,2882],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,2883,2884,2921,2927,2960],{"dataMmlNode":1249},[1242,2885,2886,2916],{"dataMmlNode":1370},[1242,2887,2888],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,2889,2890,2893,2896,2899,2902,2905,2908,2911,2913],{"dataMmlNode":1252},[1254,2891],{"dataC":1379,"xLinkHref":2892},"#MJX-12-TEX-SS-1D5A6",[1254,2894],{"dataC":1383,"xLinkHref":2895,"transform":1385},"#MJX-12-TEX-SS-1D5CB",[1254,2897],{"dataC":1388,"xLinkHref":2898,"transform":1390},"#MJX-12-TEX-SS-1D5BA",[1254,2900],{"dataC":1393,"xLinkHref":2901,"transform":1395},"#MJX-12-TEX-SS-1D5C9",[1254,2903],{"dataC":1398,"xLinkHref":2904,"transform":1400},"#MJX-12-TEX-SS-1D5C1",[1254,2906],{"dataC":1403,"xLinkHref":2907,"transform":1405},"#MJX-12-TEX-SS-1D5B1",[1254,2909],{"dataC":1408,"xLinkHref":2910,"transform":1410},"#MJX-12-TEX-SS-1D5C8",[1254,2912],{"dataC":1408,"xLinkHref":2910,"transform":1413},[1254,2914],{"dataC":1416,"xLinkHref":2915,"transform":1418},"#MJX-12-TEX-SS-1D5CD",[1242,2917,2918],{"dataMmlNode":1252,"transform":1421},[1254,2919],{"dataC":1256,"xLinkHref":2920},"#MJX-12-TEX-I-1D461",[1242,2922,2924],{"dataMmlNode":1260,"transform":2923},"translate(5147,0)",[1254,2925],{"dataC":1264,"xLinkHref":2926},"#MJX-12-TEX-N-3D",[1242,2928,2930],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":2929},"translate(6202.8,0)",[1242,2931,2932,2935,2938,2941,2944,2947,2949,2952,2955,2957],{"dataMmlNode":1252},[1254,2933],{"dataC":2672,"xLinkHref":2934},"#MJX-12-TEX-N-4D",[1254,2936],{"dataC":2676,"xLinkHref":2937,"transform":2678},"#MJX-12-TEX-N-65",[1254,2939],{"dataC":2681,"xLinkHref":2940,"transform":2683},"#MJX-12-TEX-N-72",[1254,2942],{"dataC":2686,"xLinkHref":2943,"transform":2688},"#MJX-12-TEX-N-6B",[1254,2945],{"dataC":2691,"xLinkHref":2946,"transform":2693},"#MJX-12-TEX-N-6C",[1254,2948],{"dataC":2676,"xLinkHref":2937,"transform":2696},[1254,2950],{"dataC":2699,"xLinkHref":2951,"transform":2701},"#MJX-12-TEX-N-52",[1254,2953],{"dataC":2704,"xLinkHref":2954,"transform":2706},"#MJX-12-TEX-N-6F",[1254,2956],{"dataC":2704,"xLinkHref":2954,"transform":2709},[1254,2958],{"dataC":2712,"xLinkHref":2959,"transform":2714},"#MJX-12-TEX-N-74",[1242,2961,2964,2969,2975,3018,3032],{"dataMmlNode":2962,"transform":2963},"mrow","translate(11497.5,0)",[1242,2965,2966],{"dataMmlNode":1260},[1254,2967],{"dataC":1683,"xLinkHref":2968},"#MJX-12-TEX-N-28",[1242,2970,2971],{"dataMmlNode":1260,"transform":1687},[1254,2972],{"dataC":2973,"xLinkHref":2974},"7B","#MJX-12-TEX-N-7B",[1242,2976,2978,3002],{"dataMmlNode":1370,"transform":2977},"translate(889,0)",[1242,2979,2980],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,2981,2982,2985,2987,2989,2991,2994,2996,2998,3000],{"dataMmlNode":1252},[1254,2983],{"dataC":1475,"xLinkHref":2984},"#MJX-12-TEX-SS-1D5B2",[1254,2986],{"dataC":1398,"xLinkHref":2904,"transform":1481},[1254,2988],{"dataC":1388,"xLinkHref":2898,"transform":2616},[1254,2990],{"dataC":1383,"xLinkHref":2895,"transform":2620},[1254,2992],{"dataC":1487,"xLinkHref":2993,"transform":2624},"#MJX-12-TEX-SS-1D5BD",[1254,2995],{"dataC":1403,"xLinkHref":2907,"transform":2628},[1254,2997],{"dataC":1408,"xLinkHref":2910,"transform":2632},[1254,2999],{"dataC":1408,"xLinkHref":2910,"transform":2635},[1254,3001],{"dataC":1416,"xLinkHref":2915,"transform":2639},[1242,3003,3004,3008,3013],{"dataMmlNode":1373,"transform":2642,"dataMjxTexclass":1374},[1242,3005,3006],{"dataMmlNode":1252},[1254,3007],{"dataC":1256,"xLinkHref":2920},[1242,3009,3010],{"dataMmlNode":1260,"transform":1717},[1254,3011],{"dataC":1279,"xLinkHref":3012},"#MJX-12-TEX-N-2C",[1242,3014,3015],{"dataMmlNode":1252,"transform":2655},[1254,3016],{"dataC":2492,"xLinkHref":3017},"#MJX-12-TEX-I-1D457",[1242,3019,3021,3027],{"dataMmlNode":1370,"transform":3020},"translate(6135.2,0)",[1242,3022,3023],{"dataMmlNode":1260},[1254,3024],{"dataC":3025,"xLinkHref":3026},"7D","#MJX-12-TEX-N-7D",[1242,3028,3030],{"dataMmlNode":1252,"transform":3029},"translate(533,-150) scale(0.707)",[1254,3031],{"dataC":2492,"xLinkHref":3017},[1242,3033,3035],{"dataMmlNode":1260,"transform":3034},"translate(7009.5,0)",[1254,3036],{"dataC":1982,"xLinkHref":3037},"#MJX-12-TEX-N-29",[3039,3040,255],"h3",{"id":3041},"seed-commitments-market-relative-teleport",[1027,3043,3044,3045,3048,3049,3053,3054,1064],{},"Teleport is ",[1073,3046,3047],{},"market-relative",": each market ",[3050,3051,3052],"code",{},"marketId = m"," has its own protocol-committed teleport distribution ",[1193,3055,3057],{"className":3056,"jax":1197},[1196],[1199,3058,3062,3076],{"style":1997,"xmlns":1202,"width":3059,"height":3060,"role":1205,"focusable":1206,"viewBox":3061,"xmlnsXLink":1208},"3.676ex","1.65ex","0 -442 1624.7 729.2",[1210,3063,3064,3067,3070,3073],{},[1213,3065],{"id":3066,"d":1615},"MJX-13-TEX-I-1D460",[1213,3068],{"id":3069,"d":1216},"MJX-13-TEX-I-1D461",[1213,3071],{"id":3072,"d":1228},"MJX-13-TEX-N-2C",[1213,3074],{"id":3075,"d":1643},"MJX-13-TEX-I-1D45A",[1242,3077,3078],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,3079,3080],{"dataMmlNode":1249},[1242,3081,3082,3087],{"dataMmlNode":1370},[1242,3083,3084],{"dataMmlNode":1252},[1254,3085],{"dataC":1749,"xLinkHref":3086},"#MJX-13-TEX-I-1D460",[1242,3088,3090,3095,3100],{"dataMmlNode":1373,"transform":3089,"dataMjxTexclass":1374},"translate(502,-150) scale(0.707)",[1242,3091,3092],{"dataMmlNode":1252},[1254,3093],{"dataC":1256,"xLinkHref":3094},"#MJX-13-TEX-I-1D461",[1242,3096,3097],{"dataMmlNode":1260,"transform":1717},[1254,3098],{"dataC":1279,"xLinkHref":3099},"#MJX-13-TEX-N-2C",[1242,3101,3102],{"dataMmlNode":1252,"transform":2655},[1254,3103],{"dataC":1818,"xLinkHref":3104},"#MJX-13-TEX-I-1D45A",[1027,3106,3107,3108,2063],{},"To keep the fact layer compact while supporting many markets, the snapshot commits a ",[1073,3109,3110],{},"root of roots",[1193,3112,3114],{"className":3113,"jax":1197,"display":2498},[1196],[1199,3115,3120,3213],{"style":3116,"xmlns":1202,"width":3117,"height":3118,"role":1205,"focusable":1206,"viewBox":3119,"xmlnsXLink":1208},"vertical-align: -0.791ex;","53.968ex","2.713ex","0 -849.5 23854 1199",[1210,3121,3122,3125,3128,3131,3134,3137,3140,3143,3146,3149,3152,3155,3158,3161,3164,3167,3170,3174,3177,3180,3183,3186,3189,3193,3196,3199,3203,3206,3209],{},[1213,3123],{"id":3124,"d":1442},"MJX-14-TEX-SS-1D5B2",[1213,3126],{"id":3127,"d":1446},"MJX-14-TEX-SS-1D5BE",[1213,3129],{"id":3130,"d":1450},"MJX-14-TEX-SS-1D5BD",[1213,3132],{"id":3133,"d":1352},"MJX-14-TEX-SS-1D5B1",[1213,3135],{"id":3136,"d":1356},"MJX-14-TEX-SS-1D5C8",[1213,3138],{"id":3139,"d":1360},"MJX-14-TEX-SS-1D5CD",[1213,3141],{"id":3142,"d":1216},"MJX-14-TEX-I-1D461",[1213,3144],{"id":3145,"d":1220},"MJX-14-TEX-N-3D",[1213,3147],{"id":3148,"d":2546},"MJX-14-TEX-N-4D",[1213,3150],{"id":3151,"d":2550},"MJX-14-TEX-N-65",[1213,3153],{"id":3154,"d":2554},"MJX-14-TEX-N-72",[1213,3156],{"id":3157,"d":2558},"MJX-14-TEX-N-6B",[1213,3159],{"id":3160,"d":2562},"MJX-14-TEX-N-6C",[1213,3162],{"id":3163,"d":2566},"MJX-14-TEX-N-52",[1213,3165],{"id":3166,"d":2570},"MJX-14-TEX-N-6F",[1213,3168],{"id":3169,"d":2574},"MJX-14-TEX-N-74",[1213,3171],{"id":3172,"d":3173},"MJX-14-TEX-SO-28","M152 251Q152 646 388 850H416Q422 844 422 841Q422 837 403 816T357 753T302 649T255 482T236 250Q236 124 255 19T301 -147T356 -251T403 -315T422 -340Q422 -343 416 -349H388Q359 -325 332 -296T271 -213T212 -97T170 56T152 251Z",[1213,3175],{"id":3176,"d":2860},"MJX-14-TEX-N-7B",[1213,3178],{"id":3179,"d":1589},"MJX-14-TEX-N-28",[1213,3181],{"id":3182,"d":1643},"MJX-14-TEX-I-1D45A",[1213,3184],{"id":3185,"d":1228},"MJX-14-TEX-N-2C",[1213,3187],{"id":3188,"d":161},"MJX-14-TEX-N-A0",[1213,3190],{"id":3191,"d":3192},"MJX-14-TEX-SS-1D5AC","M92 0V694H228L233 680Q236 675 284 547T382 275T436 106Q446 149 497 292T594 558L640 680L645 694H782V0H689V305L688 606Q688 577 500 78L479 23H392L364 96Q364 97 342 156T296 280T246 418T203 544T186 609V588Q185 568 185 517T185 427T185 305V0H92Z",[1213,3194],{"id":3195,"d":1340},"MJX-14-TEX-SS-1D5BA",[1213,3197],{"id":3198,"d":1336},"MJX-14-TEX-SS-1D5CB",[1213,3200],{"id":3201,"d":3202},"MJX-14-TEX-SS-1D5C4","M76 0V694H163V257L340 444H449L286 272L292 263Q296 259 378 138T463 12L471 0H372L309 92Q294 114 277 139T250 179T237 198L228 211L160 139V0H76Z",[1213,3204],{"id":3205,"d":1674},"MJX-14-TEX-N-29",[1213,3207],{"id":3208,"d":2876},"MJX-14-TEX-N-7D",[1213,3210],{"id":3211,"d":3212},"MJX-14-TEX-SO-29","M305 251Q305 -145 69 -349H56Q43 -349 39 -347T35 -338Q37 -333 60 -307T108 -239T160 -136T204 27T221 250T204 473T160 636T108 740T60 807T35 839Q35 850 50 850H56H69Q197 743 256 566Q305 425 305 251Z",[1242,3214,3215],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,3216,3217,3250,3256,3289,3298,3304,3310,3316,3322,3329,3398,3404,3416],{"dataMmlNode":1249},[1242,3218,3219,3245],{"dataMmlNode":1370},[1242,3220,3221],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,3222,3223,3226,3229,3231,3234,3237,3240,3242],{"dataMmlNode":1252},[1254,3224],{"dataC":1475,"xLinkHref":3225},"#MJX-14-TEX-SS-1D5B2",[1254,3227],{"dataC":1479,"xLinkHref":3228,"transform":1481},"#MJX-14-TEX-SS-1D5BE",[1254,3230],{"dataC":1479,"xLinkHref":3228,"transform":1484},[1254,3232],{"dataC":1487,"xLinkHref":3233,"transform":1489},"#MJX-14-TEX-SS-1D5BD",[1254,3235],{"dataC":1403,"xLinkHref":3236,"transform":1493},"#MJX-14-TEX-SS-1D5B1",[1254,3238],{"dataC":1408,"xLinkHref":3239,"transform":1497},"#MJX-14-TEX-SS-1D5C8",[1254,3241],{"dataC":1408,"xLinkHref":3239,"transform":1500},[1254,3243],{"dataC":1416,"xLinkHref":3244,"transform":1504},"#MJX-14-TEX-SS-1D5CD",[1242,3246,3247],{"dataMmlNode":1252,"transform":1507},[1254,3248],{"dataC":1256,"xLinkHref":3249},"#MJX-14-TEX-I-1D461",[1242,3251,3253],{"dataMmlNode":1260,"transform":3252},"translate(4584,0)",[1254,3254],{"dataC":1264,"xLinkHref":3255},"#MJX-14-TEX-N-3D",[1242,3257,3259],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":3258},"translate(5639.8,0)",[1242,3260,3261,3264,3267,3270,3273,3276,3278,3281,3284,3286],{"dataMmlNode":1252},[1254,3262],{"dataC":2672,"xLinkHref":3263},"#MJX-14-TEX-N-4D",[1254,3265],{"dataC":2676,"xLinkHref":3266,"transform":2678},"#MJX-14-TEX-N-65",[1254,3268],{"dataC":2681,"xLinkHref":3269,"transform":2683},"#MJX-14-TEX-N-72",[1254,3271],{"dataC":2686,"xLinkHref":3272,"transform":2688},"#MJX-14-TEX-N-6B",[1254,3274],{"dataC":2691,"xLinkHref":3275,"transform":2693},"#MJX-14-TEX-N-6C",[1254,3277],{"dataC":2676,"xLinkHref":3266,"transform":2696},[1254,3279],{"dataC":2699,"xLinkHref":3280,"transform":2701},"#MJX-14-TEX-N-52",[1254,3282],{"dataC":2704,"xLinkHref":3283,"transform":2706},"#MJX-14-TEX-N-6F",[1254,3285],{"dataC":2704,"xLinkHref":3283,"transform":2709},[1254,3287],{"dataC":2712,"xLinkHref":3288,"transform":2714},"#MJX-14-TEX-N-74",[1242,3290,3292],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":3291},"translate(10767.8,0)",[1242,3293,3295],{"dataMmlNode":1260,"transform":3294},"translate(0 -0.5)",[1254,3296],{"dataC":1683,"xLinkHref":3297},"#MJX-14-TEX-SO-28",[1242,3299,3301],{"dataMmlNode":1260,"transform":3300},"translate(11225.8,0)",[1254,3302],{"dataC":2973,"xLinkHref":3303},"#MJX-14-TEX-N-7B",[1242,3305,3307],{"dataMmlNode":1260,"transform":3306},"translate(11725.8,0)",[1254,3308],{"dataC":1683,"xLinkHref":3309},"#MJX-14-TEX-N-28",[1242,3311,3313],{"dataMmlNode":1252,"transform":3312},"translate(12114.8,0)",[1254,3314],{"dataC":1818,"xLinkHref":3315},"#MJX-14-TEX-I-1D45A",[1242,3317,3319],{"dataMmlNode":1260,"transform":3318},"translate(12992.8,0)",[1254,3320],{"dataC":1279,"xLinkHref":3321},"#MJX-14-TEX-N-2C",[1242,3323,3325],{"dataMmlNode":2726,"transform":3324},"translate(13437.5,0)",[1254,3326],{"dataC":3327,"xLinkHref":3328},"A0","#MJX-14-TEX-N-A0",[1242,3330,3332,3383],{"dataMmlNode":1370,"transform":3331},"translate(13687.5,0)",[1242,3333,3334],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,3335,3336,3340,3344,3348,3353,3356,3359,3362,3365,3368,3371,3374,3377,3380],{"dataMmlNode":1252},[1254,3337],{"dataC":3338,"xLinkHref":3339},"1D5AC","#MJX-14-TEX-SS-1D5AC",[1254,3341],{"dataC":1388,"xLinkHref":3342,"transform":3343},"#MJX-14-TEX-SS-1D5BA","translate(875,0)",[1254,3345],{"dataC":1383,"xLinkHref":3346,"transform":3347},"#MJX-14-TEX-SS-1D5CB","translate(1356,0)",[1254,3349],{"dataC":3350,"xLinkHref":3351,"transform":3352},"1D5C4","#MJX-14-TEX-SS-1D5C4","translate(1698,0)",[1254,3354],{"dataC":1479,"xLinkHref":3228,"transform":3355},"translate(2187,0)",[1254,3357],{"dataC":1416,"xLinkHref":3244,"transform":3358},"translate(2631,0)",[1254,3360],{"dataC":1475,"xLinkHref":3225,"transform":3361},"translate(2992,0)",[1254,3363],{"dataC":1479,"xLinkHref":3228,"transform":3364},"translate(3548,0)",[1254,3366],{"dataC":1479,"xLinkHref":3228,"transform":3367},"translate(3992,0)",[1254,3369],{"dataC":1487,"xLinkHref":3233,"transform":3370},"translate(4436,0)",[1254,3372],{"dataC":1403,"xLinkHref":3236,"transform":3373},"translate(4953,0)",[1254,3375],{"dataC":1408,"xLinkHref":3239,"transform":3376},"translate(5599,0)",[1254,3378],{"dataC":1408,"xLinkHref":3239,"transform":3379},"translate(6099,0)",[1254,3381],{"dataC":1416,"xLinkHref":3244,"transform":3382},"translate(6599,0)",[1242,3384,3386,3390,3394],{"dataMmlNode":1373,"transform":3385,"dataMjxTexclass":1374},"translate(6993,-150) scale(0.707)",[1242,3387,3388],{"dataMmlNode":1252},[1254,3389],{"dataC":1256,"xLinkHref":3249},[1242,3391,3392],{"dataMmlNode":1260,"transform":1717},[1254,3393],{"dataC":1279,"xLinkHref":3321},[1242,3395,3396],{"dataMmlNode":1252,"transform":2655},[1254,3397],{"dataC":1818,"xLinkHref":3315},[1242,3399,3401],{"dataMmlNode":1260,"transform":3400},"translate(21803.2,0)",[1254,3402],{"dataC":1982,"xLinkHref":3403},"#MJX-14-TEX-N-29",[1242,3405,3407,3412],{"dataMmlNode":1370,"transform":3406},"translate(22192.2,0)",[1242,3408,3409],{"dataMmlNode":1260},[1254,3410],{"dataC":3025,"xLinkHref":3411},"#MJX-14-TEX-N-7D",[1242,3413,3414],{"dataMmlNode":1252,"transform":3029},[1254,3415],{"dataC":1818,"xLinkHref":3315},[1242,3417,3419],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":3418},"translate(23396,0)",[1242,3420,3421],{"dataMmlNode":1260,"transform":3294},[1254,3422],{"dataC":1982,"xLinkHref":3423},"#MJX-14-TEX-SO-29",[1027,3425,3426],{},"Each per-market seed root commits to the seed-weight table for that market:",[1193,3428,3430],{"className":3429,"jax":1197,"display":2498},[1196],[1199,3431,3434,3530],{"style":3116,"xmlns":1202,"width":3432,"height":3118,"role":1205,"focusable":1206,"viewBox":3433,"xmlnsXLink":1208},"48.277ex","0 -849.5 21338.6 1199",[1210,3435,3436,3439,3442,3445,3448,3451,3454,3457,3460,3463,3466,3469,3472,3475,3478,3481,3484,3487,3490,3493,3496,3499,3502,3505,3508,3511,3515,3518,3521,3524,3527],{},[1213,3437],{"id":3438,"d":3192},"MJX-15-TEX-SS-1D5AC",[1213,3440],{"id":3441,"d":1340},"MJX-15-TEX-SS-1D5BA",[1213,3443],{"id":3444,"d":1336},"MJX-15-TEX-SS-1D5CB",[1213,3446],{"id":3447,"d":3202},"MJX-15-TEX-SS-1D5C4",[1213,3449],{"id":3450,"d":1446},"MJX-15-TEX-SS-1D5BE",[1213,3452],{"id":3453,"d":1360},"MJX-15-TEX-SS-1D5CD",[1213,3455],{"id":3456,"d":1442},"MJX-15-TEX-SS-1D5B2",[1213,3458],{"id":3459,"d":1450},"MJX-15-TEX-SS-1D5BD",[1213,3461],{"id":3462,"d":1352},"MJX-15-TEX-SS-1D5B1",[1213,3464],{"id":3465,"d":1356},"MJX-15-TEX-SS-1D5C8",[1213,3467],{"id":3468,"d":1216},"MJX-15-TEX-I-1D461",[1213,3470],{"id":3471,"d":1228},"MJX-15-TEX-N-2C",[1213,3473],{"id":3474,"d":1643},"MJX-15-TEX-I-1D45A",[1213,3476],{"id":3477,"d":1220},"MJX-15-TEX-N-3D",[1213,3479],{"id":3480,"d":2546},"MJX-15-TEX-N-4D",[1213,3482],{"id":3483,"d":2550},"MJX-15-TEX-N-65",[1213,3485],{"id":3486,"d":2554},"MJX-15-TEX-N-72",[1213,3488],{"id":3489,"d":2558},"MJX-15-TEX-N-6B",[1213,3491],{"id":3492,"d":2562},"MJX-15-TEX-N-6C",[1213,3494],{"id":3495,"d":2566},"MJX-15-TEX-N-52",[1213,3497],{"id":3498,"d":2570},"MJX-15-TEX-N-6F",[1213,3500],{"id":3501,"d":2574},"MJX-15-TEX-N-74",[1213,3503],{"id":3504,"d":3173},"MJX-15-TEX-SO-28",[1213,3506],{"id":3507,"d":2860},"MJX-15-TEX-N-7B",[1213,3509],{"id":3510,"d":1589},"MJX-15-TEX-N-28",[1213,3512],{"id":3513,"d":3514},"MJX-15-TEX-I-1D463","M173 380Q173 405 154 405Q130 405 104 376T61 287Q60 286 59 284T58 281T56 279T53 278T49 278T41 278H27Q21 284 21 287Q21 294 29 316T53 368T97 419T160 441Q202 441 225 417T249 361Q249 344 246 335Q246 329 231 291T200 202T182 113Q182 86 187 69Q200 26 250 26Q287 26 319 60T369 139T398 222T409 277Q409 300 401 317T383 343T365 361T357 383Q357 405 376 424T417 443Q436 443 451 425T467 367Q467 340 455 284T418 159T347 40T241 -11Q177 -11 139 22Q102 54 102 117Q102 148 110 181T151 298Q173 362 173 380Z",[1213,3516],{"id":3517,"d":161},"MJX-15-TEX-N-A0",[1213,3519],{"id":3520,"d":1615},"MJX-15-TEX-I-1D460",[1213,3522],{"id":3523,"d":1674},"MJX-15-TEX-N-29",[1213,3525],{"id":3526,"d":2876},"MJX-15-TEX-N-7D",[1213,3528],{"id":3529,"d":3212},"MJX-15-TEX-SO-29",[1242,3531,3532],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,3533,3534,3595,3601,3634,3642,3648,3654,3661,3666,3672,3694,3699,3704,3710,3715,3721],{"dataMmlNode":1249},[1242,3535,3536,3578],{"dataMmlNode":1370},[1242,3537,3538],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,3539,3540,3543,3546,3549,3552,3555,3558,3561,3563,3565,3568,3571,3574,3576],{"dataMmlNode":1252},[1254,3541],{"dataC":3338,"xLinkHref":3542},"#MJX-15-TEX-SS-1D5AC",[1254,3544],{"dataC":1388,"xLinkHref":3545,"transform":3343},"#MJX-15-TEX-SS-1D5BA",[1254,3547],{"dataC":1383,"xLinkHref":3548,"transform":3347},"#MJX-15-TEX-SS-1D5CB",[1254,3550],{"dataC":3350,"xLinkHref":3551,"transform":3352},"#MJX-15-TEX-SS-1D5C4",[1254,3553],{"dataC":1479,"xLinkHref":3554,"transform":3355},"#MJX-15-TEX-SS-1D5BE",[1254,3556],{"dataC":1416,"xLinkHref":3557,"transform":3358},"#MJX-15-TEX-SS-1D5CD",[1254,3559],{"dataC":1475,"xLinkHref":3560,"transform":3361},"#MJX-15-TEX-SS-1D5B2",[1254,3562],{"dataC":1479,"xLinkHref":3554,"transform":3364},[1254,3564],{"dataC":1479,"xLinkHref":3554,"transform":3367},[1254,3566],{"dataC":1487,"xLinkHref":3567,"transform":3370},"#MJX-15-TEX-SS-1D5BD",[1254,3569],{"dataC":1403,"xLinkHref":3570,"transform":3373},"#MJX-15-TEX-SS-1D5B1",[1254,3572],{"dataC":1408,"xLinkHref":3573,"transform":3376},"#MJX-15-TEX-SS-1D5C8",[1254,3575],{"dataC":1408,"xLinkHref":3573,"transform":3379},[1254,3577],{"dataC":1416,"xLinkHref":3557,"transform":3382},[1242,3579,3580,3585,3590],{"dataMmlNode":1373,"transform":3385,"dataMjxTexclass":1374},[1242,3581,3582],{"dataMmlNode":1252},[1254,3583],{"dataC":1256,"xLinkHref":3584},"#MJX-15-TEX-I-1D461",[1242,3586,3587],{"dataMmlNode":1260,"transform":1717},[1254,3588],{"dataC":1279,"xLinkHref":3589},"#MJX-15-TEX-N-2C",[1242,3591,3592],{"dataMmlNode":1252,"transform":2655},[1254,3593],{"dataC":1818,"xLinkHref":3594},"#MJX-15-TEX-I-1D45A",[1242,3596,3598],{"dataMmlNode":1260,"transform":3597},"translate(8393.5,0)",[1254,3599],{"dataC":1264,"xLinkHref":3600},"#MJX-15-TEX-N-3D",[1242,3602,3604],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":3603},"translate(9449.2,0)",[1242,3605,3606,3609,3612,3615,3618,3621,3623,3626,3629,3631],{"dataMmlNode":1252},[1254,3607],{"dataC":2672,"xLinkHref":3608},"#MJX-15-TEX-N-4D",[1254,3610],{"dataC":2676,"xLinkHref":3611,"transform":2678},"#MJX-15-TEX-N-65",[1254,3613],{"dataC":2681,"xLinkHref":3614,"transform":2683},"#MJX-15-TEX-N-72",[1254,3616],{"dataC":2686,"xLinkHref":3617,"transform":2688},"#MJX-15-TEX-N-6B",[1254,3619],{"dataC":2691,"xLinkHref":3620,"transform":2693},"#MJX-15-TEX-N-6C",[1254,3622],{"dataC":2676,"xLinkHref":3611,"transform":2696},[1254,3624],{"dataC":2699,"xLinkHref":3625,"transform":2701},"#MJX-15-TEX-N-52",[1254,3627],{"dataC":2704,"xLinkHref":3628,"transform":2706},"#MJX-15-TEX-N-6F",[1254,3630],{"dataC":2704,"xLinkHref":3628,"transform":2709},[1254,3632],{"dataC":2712,"xLinkHref":3633,"transform":2714},"#MJX-15-TEX-N-74",[1242,3635,3637],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":3636},"translate(14577.2,0)",[1242,3638,3639],{"dataMmlNode":1260,"transform":3294},[1254,3640],{"dataC":1683,"xLinkHref":3641},"#MJX-15-TEX-SO-28",[1242,3643,3645],{"dataMmlNode":1260,"transform":3644},"translate(15035.2,0)",[1254,3646],{"dataC":2973,"xLinkHref":3647},"#MJX-15-TEX-N-7B",[1242,3649,3651],{"dataMmlNode":1260,"transform":3650},"translate(15535.2,0)",[1254,3652],{"dataC":1683,"xLinkHref":3653},"#MJX-15-TEX-N-28",[1242,3655,3657],{"dataMmlNode":1252,"transform":3656},"translate(15924.2,0)",[1254,3658],{"dataC":3659,"xLinkHref":3660},"1D463","#MJX-15-TEX-I-1D463",[1242,3662,3664],{"dataMmlNode":1260,"transform":3663},"translate(16409.2,0)",[1254,3665],{"dataC":1279,"xLinkHref":3589},[1242,3667,3669],{"dataMmlNode":2726,"transform":3668},"translate(16853.9,0)",[1254,3670],{"dataC":3327,"xLinkHref":3671},"#MJX-15-TEX-N-A0",[1242,3673,3675,3680],{"dataMmlNode":1370,"transform":3674},"translate(17103.9,0)",[1242,3676,3677],{"dataMmlNode":1252},[1254,3678],{"dataC":1749,"xLinkHref":3679},"#MJX-15-TEX-I-1D460",[1242,3681,3682,3686,3690],{"dataMmlNode":1373,"transform":3089,"dataMjxTexclass":1374},[1242,3683,3684],{"dataMmlNode":1252},[1254,3685],{"dataC":1256,"xLinkHref":3584},[1242,3687,3688],{"dataMmlNode":1260,"transform":1717},[1254,3689],{"dataC":1279,"xLinkHref":3589},[1242,3691,3692],{"dataMmlNode":1252,"transform":2655},[1254,3693],{"dataC":1818,"xLinkHref":3594},[1242,3695,3697],{"dataMmlNode":1260,"transform":3696},"translate(18728.6,0)",[1254,3698],{"dataC":1683,"xLinkHref":3653},[1242,3700,3702],{"dataMmlNode":1252,"transform":3701},"translate(19117.6,0)",[1254,3703],{"dataC":3659,"xLinkHref":3660},[1242,3705,3707],{"dataMmlNode":1260,"transform":3706},"translate(19602.6,0)",[1254,3708],{"dataC":1982,"xLinkHref":3709},"#MJX-15-TEX-N-29",[1242,3711,3713],{"dataMmlNode":1260,"transform":3712},"translate(19991.6,0)",[1254,3714],{"dataC":1982,"xLinkHref":3709},[1242,3716,3718],{"dataMmlNode":1260,"transform":3717},"translate(20380.6,0)",[1254,3719],{"dataC":3025,"xLinkHref":3720},"#MJX-15-TEX-N-7D",[1242,3722,3724],{"dataMmlNode":1373,"dataMjxTexclass":1374,"transform":3723},"translate(20880.6,0)",[1242,3725,3726],{"dataMmlNode":1260,"transform":3294},[1254,3727],{"dataC":1982,"xLinkHref":3728},"#MJX-15-TEX-SO-29",[1985,3730,3732],{"title":3731,"type":1988},"Proof-friendly teleport sampling (optional)",[1027,3733,3734,3735,3868,3869,1064],{},"For O(1) verifiable teleport sampling in transcripts, the snapshot artifact can also include a per-market alias table commitment (e.g., ",[1193,3736,3738],{"className":3737,"jax":1197},[1196],[1199,3739,3743,3791],{"style":1997,"xmlns":1202,"width":3740,"height":3741,"role":1205,"focusable":1206,"viewBox":3742,"xmlnsXLink":1208},"16.137ex","2.27ex","0 -716 7132.7 1003.2",[1210,3744,3745,3748,3751,3754,3758,3762,3766,3769,3773,3776,3779,3782,3785,3788],{},[1213,3746],{"id":3747,"d":1442},"MJX-16-TEX-SS-1D5B2",[1213,3749],{"id":3750,"d":1446},"MJX-16-TEX-SS-1D5BE",[1213,3752],{"id":3753,"d":1450},"MJX-16-TEX-SS-1D5BD",[1213,3755],{"id":3756,"d":3757},"MJX-16-TEX-SS-1D5A0","M183 181Q183 179 152 91T118 0H28L154 346L280 693Q281 694 333 694H385L511 349Q636 4 638 2Q638 0 584 0H530L464 183H184L183 181ZM324 606Q319 578 292 492T238 332T210 256Q210 254 324 254T438 255L429 281L419 308Q409 336 395 378T365 465T339 551T324 611V606Z",[1213,3759],{"id":3760,"d":3761},"MJX-16-TEX-SS-1D5C5","M74 0V694H164V0H74Z",[1213,3763],{"id":3764,"d":3765},"MJX-16-TEX-SS-1D5C2","M67 576V680H171V576H67ZM74 0V444H164V0H74Z",[1213,3767],{"id":3768,"d":1340},"MJX-16-TEX-SS-1D5BA",[1213,3770],{"id":3771,"d":3772},"MJX-16-TEX-SS-1D5CC","M33 326Q33 376 60 408T117 450T175 460H190Q245 460 272 454T345 429Q345 428 338 388L331 349Q278 386 188 386H183Q119 386 119 336Q119 307 142 295T210 276T278 256Q360 213 360 130Q360 108 354 88T332 43T281 5T195 -10Q152 -10 111 1T49 22T28 35Q29 36 32 56T39 95T43 115T51 110T72 99T102 85T143 73T193 68Q274 68 274 123Q274 152 248 167Q234 178 187 186T115 207Q66 229 46 273Q33 298 33 326Z",[1213,3774],{"id":3775,"d":1352},"MJX-16-TEX-SS-1D5B1",[1213,3777],{"id":3778,"d":1356},"MJX-16-TEX-SS-1D5C8",[1213,3780],{"id":3781,"d":1360},"MJX-16-TEX-SS-1D5CD",[1213,3783],{"id":3784,"d":1216},"MJX-16-TEX-I-1D461",[1213,3786],{"id":3787,"d":1228},"MJX-16-TEX-N-2C",[1213,3789],{"id":3790,"d":1643},"MJX-16-TEX-I-1D45A",[1242,3792,3793],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,3794,3795],{"dataMmlNode":1249},[1242,3796,3797,3850],{"dataMmlNode":1370},[1242,3798,3799],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,3800,3801,3804,3807,3809,3812,3816,3821,3826,3830,3835,3839,3843,3846],{"dataMmlNode":1252},[1254,3802],{"dataC":1475,"xLinkHref":3803},"#MJX-16-TEX-SS-1D5B2",[1254,3805],{"dataC":1479,"xLinkHref":3806,"transform":1481},"#MJX-16-TEX-SS-1D5BE",[1254,3808],{"dataC":1479,"xLinkHref":3806,"transform":1484},[1254,3810],{"dataC":1487,"xLinkHref":3811,"transform":1489},"#MJX-16-TEX-SS-1D5BD",[1254,3813],{"dataC":3814,"xLinkHref":3815,"transform":1493},"1D5A0","#MJX-16-TEX-SS-1D5A0",[1254,3817],{"dataC":3818,"xLinkHref":3819,"transform":3820},"1D5C5","#MJX-16-TEX-SS-1D5C5","translate(2628,0)",[1254,3822],{"dataC":3823,"xLinkHref":3824,"transform":3825},"1D5C2","#MJX-16-TEX-SS-1D5C2","translate(2867,0)",[1254,3827],{"dataC":1388,"xLinkHref":3828,"transform":3829},"#MJX-16-TEX-SS-1D5BA","translate(3106,0)",[1254,3831],{"dataC":3832,"xLinkHref":3833,"transform":3834},"1D5CC","#MJX-16-TEX-SS-1D5CC","translate(3587,0)",[1254,3836],{"dataC":1403,"xLinkHref":3837,"transform":3838},"#MJX-16-TEX-SS-1D5B1","translate(3970,0)",[1254,3840],{"dataC":1408,"xLinkHref":3841,"transform":3842},"#MJX-16-TEX-SS-1D5C8","translate(4616,0)",[1254,3844],{"dataC":1408,"xLinkHref":3841,"transform":3845},"translate(5116,0)",[1254,3847],{"dataC":1416,"xLinkHref":3848,"transform":3849},"#MJX-16-TEX-SS-1D5CD","translate(5616,0)",[1242,3851,3853,3858,3863],{"dataMmlNode":1373,"transform":3852,"dataMjxTexclass":1374},"translate(6010,-150) scale(0.707)",[1242,3854,3855],{"dataMmlNode":1252},[1254,3856],{"dataC":1256,"xLinkHref":3857},"#MJX-16-TEX-I-1D461",[1242,3859,3860],{"dataMmlNode":1260,"transform":1717},[1254,3861],{"dataC":1279,"xLinkHref":3862},"#MJX-16-TEX-N-2C",[1242,3864,3865],{"dataMmlNode":1252,"transform":2655},[1254,3866],{"dataC":1818,"xLinkHref":3867},"#MJX-16-TEX-I-1D45A",") for sampling from ",[1193,3870,3872],{"className":3871,"jax":1197},[1196],[1199,3873,3874,3888],{"style":1997,"xmlns":1202,"width":3059,"height":3060,"role":1205,"focusable":1206,"viewBox":3061,"xmlnsXLink":1208},[1210,3875,3876,3879,3882,3885],{},[1213,3877],{"id":3878,"d":1615},"MJX-17-TEX-I-1D460",[1213,3880],{"id":3881,"d":1216},"MJX-17-TEX-I-1D461",[1213,3883],{"id":3884,"d":1228},"MJX-17-TEX-N-2C",[1213,3886],{"id":3887,"d":1643},"MJX-17-TEX-I-1D45A",[1242,3889,3890],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,3891,3892],{"dataMmlNode":1249},[1242,3893,3894,3899],{"dataMmlNode":1370},[1242,3895,3896],{"dataMmlNode":1252},[1254,3897],{"dataC":1749,"xLinkHref":3898},"#MJX-17-TEX-I-1D460",[1242,3900,3901,3906,3911],{"dataMmlNode":1373,"transform":3089,"dataMjxTexclass":1374},[1242,3902,3903],{"dataMmlNode":1252},[1254,3904],{"dataC":1256,"xLinkHref":3905},"#MJX-17-TEX-I-1D461",[1242,3907,3908],{"dataMmlNode":1260,"transform":1717},[1254,3909],{"dataC":1279,"xLinkHref":3910},"#MJX-17-TEX-N-2C",[1242,3912,3913],{"dataMmlNode":1252,"transform":2655},[1254,3914],{"dataC":1818,"xLinkHref":3915},"#MJX-17-TEX-I-1D45A",[1066,3917,260],{"id":3918},"snapshot-artifact-identifier-snapshotid",[1027,3920,3921,3922,3925],{},"Audits require authenticated access to snapshot data (NodeRecords \u002F EdgeRecords \u002F alias tables). Each epoch therefore finalizes a ",[1073,3923,3924],{},"Snapshot Artifact"," that is content-addressed and publicly retrievable.",[1985,3927,3930],{"title":3928,"type":3929},"MarketRegistry is part of the snapshot artifact (required)","warning",[1027,3931,3932,3933,3936,3937,3960,3961,3964,3965,4062,4063,4066],{},"To make market membership auditable, ",[3050,3934,3935],{},"SnapshotBlob_t"," must include the canonical MarketRegistry table for epoch ",[1193,3938,3940],{"className":3939,"jax":1197},[1196],[1199,3941,3946,3951],{"style":3942,"xmlns":1202,"width":3943,"height":3944,"role":1205,"focusable":1206,"viewBox":3945,"xmlnsXLink":1208},"vertical-align: -0.025ex;","0.817ex","1.441ex","0 -626 361 637",[1210,3947,3948],{},[1213,3949],{"id":3950,"d":1216},"MJX-18-TEX-I-1D461",[1242,3952,3953],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,3954,3955],{"dataMmlNode":1249},[1242,3956,3957],{"dataMmlNode":1252},[1254,3958],{"dataC":1256,"xLinkHref":3959},"#MJX-18-TEX-I-1D461",":\n",[3050,3962,3963],{},"marketContext → (marketId, vault, feeRouter, flags)",".\nBecause ",[1193,3966,3968],{"className":3967,"jax":1197},[1196],[1199,3969,3973,4009],{"style":1323,"xmlns":1202,"width":3970,"height":3971,"role":1205,"focusable":1206,"viewBox":3972,"xmlnsXLink":1208},"11.234ex","2.156ex","0 -716 4965.3 953.1",[1210,3974,3975,3978,3981,3984,3987,3990,3993,3996,3999,4003,4006],{},[1213,3976],{"id":3977,"d":1442},"MJX-19-TEX-SS-1D5B2",[1213,3979],{"id":3980,"d":1533},"MJX-19-TEX-SS-1D5C7",[1213,3982],{"id":3983,"d":1340},"MJX-19-TEX-SS-1D5BA",[1213,3985],{"id":3986,"d":1344},"MJX-19-TEX-SS-1D5C9",[1213,3988],{"id":3989,"d":3772},"MJX-19-TEX-SS-1D5CC",[1213,3991],{"id":3992,"d":1348},"MJX-19-TEX-SS-1D5C1",[1213,3994],{"id":3995,"d":1356},"MJX-19-TEX-SS-1D5C8",[1213,3997],{"id":3998,"d":1360},"MJX-19-TEX-SS-1D5CD",[1213,4000],{"id":4001,"d":4002},"MJX-19-TEX-SS-1D5A8","M87 0V694H191V0H87Z",[1213,4004],{"id":4005,"d":1450},"MJX-19-TEX-SS-1D5BD",[1213,4007],{"id":4008,"d":1216},"MJX-19-TEX-I-1D461",[1242,4010,4011],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4012,4013],{"dataMmlNode":1249},[1242,4014,4015,4056],{"dataMmlNode":1370},[1242,4016,4017],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,4018,4019,4022,4025,4028,4031,4035,4039,4043,4047,4052],{"dataMmlNode":1252},[1254,4020],{"dataC":1475,"xLinkHref":4021},"#MJX-19-TEX-SS-1D5B2",[1254,4023],{"dataC":1559,"xLinkHref":4024,"transform":1481},"#MJX-19-TEX-SS-1D5C7",[1254,4026],{"dataC":1388,"xLinkHref":4027,"transform":2616},"#MJX-19-TEX-SS-1D5BA",[1254,4029],{"dataC":1393,"xLinkHref":4030,"transform":2620},"#MJX-19-TEX-SS-1D5C9",[1254,4032],{"dataC":3832,"xLinkHref":4033,"transform":4034},"#MJX-19-TEX-SS-1D5CC","translate(2071,0)",[1254,4036],{"dataC":1398,"xLinkHref":4037,"transform":4038},"#MJX-19-TEX-SS-1D5C1","translate(2454,0)",[1254,4040],{"dataC":1408,"xLinkHref":4041,"transform":4042},"#MJX-19-TEX-SS-1D5C8","translate(2971,0)",[1254,4044],{"dataC":1416,"xLinkHref":4045,"transform":4046},"#MJX-19-TEX-SS-1D5CD","translate(3471,0)",[1254,4048],{"dataC":4049,"xLinkHref":4050,"transform":4051},"1D5A8","#MJX-19-TEX-SS-1D5A8","translate(3832,0)",[1254,4053],{"dataC":1487,"xLinkHref":4054,"transform":4055},"#MJX-19-TEX-SS-1D5BD","translate(4110,0)",[1242,4057,4059],{"dataMmlNode":1252,"transform":4058},"translate(4660,-229.4) scale(0.707)",[1254,4060],{"dataC":1256,"xLinkHref":4061},"#MJX-19-TEX-I-1D461"," binds ",[3050,4064,4065],{},"SnapshotBlobHash_t",", auditors can verify MarketRegistry lookups against the same snapshot commitments used for graph and seed verification.",[1027,4068,4069,4070,4089,4090,4092,4093,4097],{},"At epoch ",[1193,4071,4073],{"className":4072,"jax":1197},[1196],[1199,4074,4075,4080],{"style":3942,"xmlns":1202,"width":3943,"height":3944,"role":1205,"focusable":1206,"viewBox":3945,"xmlnsXLink":1208},[1210,4076,4077],{},[1213,4078],{"id":4079,"d":1216},"MJX-20-TEX-I-1D461",[1242,4081,4082],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4083,4084],{"dataMmlNode":1249},[1242,4085,4086],{"dataMmlNode":1252},[1254,4087],{"dataC":1256,"xLinkHref":4088},"#MJX-20-TEX-I-1D461",", let ",[3050,4091,4065],{}," be the content hash of the snapshot artifact bytes in the data layer (see ",[1031,4094,4096],{"href":4095},"\u002Fdocs\u002Farchitecture\u002Fperformance-storage","Performance & Storage","). The chain commits:",[1193,4099,4101],{"className":4100,"jax":1197,"display":2498},[1196],[1199,4102,4107,4186],{"style":4103,"xmlns":1202,"width":4104,"height":4105,"role":1205,"focusable":1206,"viewBox":4106,"xmlnsXLink":1208},"vertical-align: -0.566ex;","61.065ex","2.262ex","0 -750 26990.6 1000",[1210,4108,4109,4112,4115,4118,4121,4124,4127,4130,4133,4136,4139,4142,4145,4149,4152,4155,4158,4161,4165,4168,4172,4175,4179,4183],{},[1213,4110],{"id":4111,"d":1442},"MJX-21-TEX-SS-1D5B2",[1213,4113],{"id":4114,"d":1533},"MJX-21-TEX-SS-1D5C7",[1213,4116],{"id":4117,"d":1340},"MJX-21-TEX-SS-1D5BA",[1213,4119],{"id":4120,"d":1344},"MJX-21-TEX-SS-1D5C9",[1213,4122],{"id":4123,"d":3772},"MJX-21-TEX-SS-1D5CC",[1213,4125],{"id":4126,"d":1348},"MJX-21-TEX-SS-1D5C1",[1213,4128],{"id":4129,"d":1356},"MJX-21-TEX-SS-1D5C8",[1213,4131],{"id":4132,"d":1360},"MJX-21-TEX-SS-1D5CD",[1213,4134],{"id":4135,"d":4002},"MJX-21-TEX-SS-1D5A8",[1213,4137],{"id":4138,"d":1450},"MJX-21-TEX-SS-1D5BD",[1213,4140],{"id":4141,"d":1216},"MJX-21-TEX-I-1D461",[1213,4143],{"id":4144,"d":1220},"MJX-21-TEX-N-3D",[1213,4146],{"id":4147,"d":4148},"MJX-21-TEX-I-1D43B","M228 637Q194 637 192 641Q191 643 191 649Q191 673 202 682Q204 683 219 683Q260 681 355 681Q389 681 418 681T463 682T483 682Q499 682 499 672Q499 670 497 658Q492 641 487 638H485Q483 638 480 638T473 638T464 637T455 637Q416 636 405 634T387 623Q384 619 355 500Q348 474 340 442T328 395L324 380Q324 378 469 378H614L615 381Q615 384 646 504Q674 619 674 627T617 637Q594 637 587 639T580 648Q580 650 582 660Q586 677 588 679T604 682Q609 682 646 681T740 680Q802 680 835 681T871 682Q888 682 888 672Q888 645 876 638H874Q872 638 869 638T862 638T853 637T844 637Q805 636 794 634T776 623Q773 618 704 340T634 58Q634 51 638 51Q646 48 692 46H723Q729 38 729 37T726 19Q722 6 716 0H701Q664 2 567 2Q533 2 504 2T458 2T437 1Q420 1 420 10Q420 15 423 24Q428 43 433 45Q437 46 448 46H454Q481 46 514 49Q520 50 522 50T528 55T534 64T540 82T547 110T558 153Q565 181 569 198Q602 330 602 331T457 332H312L279 197Q245 63 245 58Q245 51 253 49T303 46H334Q340 38 340 37T337 19Q333 6 327 0H312Q275 2 178 2Q144 2 115 2T69 2T48 1Q31 1 31 10Q31 12 34 24Q39 43 44 45Q48 46 59 46H65Q92 46 125 49Q139 52 144 61Q147 65 216 339T285 628Q285 635 228 637Z",[1213,4150],{"id":4151,"d":1589},"MJX-21-TEX-N-28",[1213,4153],{"id":4154,"d":1332},"MJX-21-TEX-SS-1D5A6",[1213,4156],{"id":4157,"d":1336},"MJX-21-TEX-SS-1D5CB",[1213,4159],{"id":4160,"d":1352},"MJX-21-TEX-SS-1D5B1",[1213,4162],{"id":4163,"d":4164},"MJX-21-TEX-N-2225","M133 736Q138 750 153 750Q164 750 170 739Q172 735 172 250T170 -239Q164 -250 152 -250Q144 -250 138 -244L137 -243Q133 -241 133 -179T132 250Q132 731 133 736ZM329 739Q334 750 346 750Q353 750 361 744L362 743Q366 741 366 679T367 250T367 -178T362 -243L361 -244Q355 -250 347 -250Q335 -250 329 -239Q327 -235 327 250T329 739Z",[1213,4166],{"id":4167,"d":1446},"MJX-21-TEX-SS-1D5BE",[1213,4169],{"id":4170,"d":4171},"MJX-21-TEX-SS-1D5A1","M425 363Q438 363 465 353T526 324T585 270T610 192Q610 132 561 78T426 7Q404 2 387 2T240 0H90V694H227Q373 693 396 689Q484 673 533 623T583 517Q583 494 574 473T551 437T520 409T487 388T456 374T433 366L425 363ZM490 516Q490 527 485 539T467 568T423 599T347 621Q340 622 262 623H188V399H261H286Q432 399 478 475Q490 496 490 516ZM514 190Q514 245 462 280T343 322Q336 323 259 323H188V71H274Q365 72 388 77Q445 88 479 121T514 190Z",[1213,4173],{"id":4174,"d":3761},"MJX-21-TEX-SS-1D5C5",[1213,4176],{"id":4177,"d":4178},"MJX-21-TEX-SS-1D5BB","M303 -11Q280 -11 259 -6T222 6T194 21T176 33T168 38V0H75V694H165V550L166 405Q247 455 336 455Q397 455 439 389T482 226Q482 115 428 52T303 -11ZM390 221Q390 283 361 331T265 379Q214 379 177 342L168 334V118Q203 66 258 66Q316 66 353 106T390 221Z",[1213,4180],{"id":4181,"d":4182},"MJX-21-TEX-SS-1D5A7","M86 0V694H190V399H517V694H621V0H517V323H190V0H86Z",[1213,4184],{"id":4185,"d":1674},"MJX-21-TEX-N-29",[1242,4187,4188],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4189,4190,4231,4237,4244,4250,4282,4289,4296,4301,4329,4334,4339,4344,4402],{"dataMmlNode":1249},[1242,4191,4192,4226],{"dataMmlNode":1370},[1242,4193,4194],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,4195,4196,4199,4202,4205,4208,4211,4214,4217,4220,4223],{"dataMmlNode":1252},[1254,4197],{"dataC":1475,"xLinkHref":4198},"#MJX-21-TEX-SS-1D5B2",[1254,4200],{"dataC":1559,"xLinkHref":4201,"transform":1481},"#MJX-21-TEX-SS-1D5C7",[1254,4203],{"dataC":1388,"xLinkHref":4204,"transform":2616},"#MJX-21-TEX-SS-1D5BA",[1254,4206],{"dataC":1393,"xLinkHref":4207,"transform":2620},"#MJX-21-TEX-SS-1D5C9",[1254,4209],{"dataC":3832,"xLinkHref":4210,"transform":4034},"#MJX-21-TEX-SS-1D5CC",[1254,4212],{"dataC":1398,"xLinkHref":4213,"transform":4038},"#MJX-21-TEX-SS-1D5C1",[1254,4215],{"dataC":1408,"xLinkHref":4216,"transform":4042},"#MJX-21-TEX-SS-1D5C8",[1254,4218],{"dataC":1416,"xLinkHref":4219,"transform":4046},"#MJX-21-TEX-SS-1D5CD",[1254,4221],{"dataC":4049,"xLinkHref":4222,"transform":4051},"#MJX-21-TEX-SS-1D5A8",[1254,4224],{"dataC":1487,"xLinkHref":4225,"transform":4055},"#MJX-21-TEX-SS-1D5BD",[1242,4227,4228],{"dataMmlNode":1252,"transform":4058},[1254,4229],{"dataC":1256,"xLinkHref":4230},"#MJX-21-TEX-I-1D461",[1242,4232,4234],{"dataMmlNode":1260,"transform":4233},"translate(5243,0)",[1254,4235],{"dataC":1264,"xLinkHref":4236},"#MJX-21-TEX-N-3D",[1242,4238,4240],{"dataMmlNode":1252,"transform":4239},"translate(6298.8,0)",[1254,4241],{"dataC":4242,"xLinkHref":4243},"1D43B","#MJX-21-TEX-I-1D43B",[1242,4245,4247],{"dataMmlNode":1260,"transform":4246},"translate(7186.8,0)",[1254,4248],{"dataC":1683,"xLinkHref":4249},"#MJX-21-TEX-N-28",[1242,4251,4253,4278],{"dataMmlNode":1370,"transform":4252},"translate(7575.8,0)",[1242,4254,4255],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,4256,4257,4260,4263,4265,4267,4269,4272,4274,4276],{"dataMmlNode":1252},[1254,4258],{"dataC":1379,"xLinkHref":4259},"#MJX-21-TEX-SS-1D5A6",[1254,4261],{"dataC":1383,"xLinkHref":4262,"transform":1385},"#MJX-21-TEX-SS-1D5CB",[1254,4264],{"dataC":1388,"xLinkHref":4204,"transform":1390},[1254,4266],{"dataC":1393,"xLinkHref":4207,"transform":1395},[1254,4268],{"dataC":1398,"xLinkHref":4213,"transform":1400},[1254,4270],{"dataC":1403,"xLinkHref":4271,"transform":1405},"#MJX-21-TEX-SS-1D5B1",[1254,4273],{"dataC":1408,"xLinkHref":4216,"transform":1410},[1254,4275],{"dataC":1408,"xLinkHref":4216,"transform":1413},[1254,4277],{"dataC":1416,"xLinkHref":4219,"transform":1418},[1242,4279,4280],{"dataMmlNode":1252,"transform":1421},[1254,4281],{"dataC":1256,"xLinkHref":4230},[1242,4283,4286],{"dataMmlNode":4284,"transform":4285},"mstyle","translate(12445.1,0)",[1242,4287],{"dataMmlNode":4288},"mspace",[1242,4290,4292],{"dataMmlNode":1260,"transform":4291},"translate(12612.1,0)",[1254,4293],{"dataC":4294,"xLinkHref":4295},"2225","#MJX-21-TEX-N-2225",[1242,4297,4299],{"dataMmlNode":4284,"transform":4298},"translate(13112.1,0)",[1242,4300],{"dataMmlNode":4288},[1242,4302,4304,4325],{"dataMmlNode":1370,"transform":4303},"translate(13279.1,0)",[1242,4305,4306],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,4307,4308,4310,4313,4315,4317,4319,4321,4323],{"dataMmlNode":1252},[1254,4309],{"dataC":1475,"xLinkHref":4198},[1254,4311],{"dataC":1479,"xLinkHref":4312,"transform":1481},"#MJX-21-TEX-SS-1D5BE",[1254,4314],{"dataC":1479,"xLinkHref":4312,"transform":1484},[1254,4316],{"dataC":1487,"xLinkHref":4225,"transform":1489},[1254,4318],{"dataC":1403,"xLinkHref":4271,"transform":1493},[1254,4320],{"dataC":1408,"xLinkHref":4216,"transform":1497},[1254,4322],{"dataC":1408,"xLinkHref":4216,"transform":1500},[1254,4324],{"dataC":1416,"xLinkHref":4219,"transform":1504},[1242,4326,4327],{"dataMmlNode":1252,"transform":1507},[1254,4328],{"dataC":1256,"xLinkHref":4230},[1242,4330,4332],{"dataMmlNode":4284,"transform":4331},"translate(17585.4,0)",[1242,4333],{"dataMmlNode":4288},[1242,4335,4337],{"dataMmlNode":1260,"transform":4336},"translate(17752.4,0)",[1254,4338],{"dataC":4294,"xLinkHref":4295},[1242,4340,4342],{"dataMmlNode":4284,"transform":4341},"translate(18252.4,0)",[1242,4343],{"dataMmlNode":4288},[1242,4345,4347,4397],{"dataMmlNode":1370,"transform":4346},"translate(18419.4,0)",[1242,4348,4349],{"dataMmlNode":1373,"dataMjxTexclass":1374},[1242,4350,4351,4353,4355,4357,4359,4361,4363,4365,4367,4371,4375,4378,4383,4388,4391,4394],{"dataMmlNode":1252},[1254,4352],{"dataC":1475,"xLinkHref":4198},[1254,4354],{"dataC":1559,"xLinkHref":4201,"transform":1481},[1254,4356],{"dataC":1388,"xLinkHref":4204,"transform":2616},[1254,4358],{"dataC":1393,"xLinkHref":4207,"transform":2620},[1254,4360],{"dataC":3832,"xLinkHref":4210,"transform":4034},[1254,4362],{"dataC":1398,"xLinkHref":4213,"transform":4038},[1254,4364],{"dataC":1408,"xLinkHref":4216,"transform":4042},[1254,4366],{"dataC":1416,"xLinkHref":4219,"transform":4046},[1254,4368],{"dataC":4369,"xLinkHref":4370,"transform":4051},"1D5A1","#MJX-21-TEX-SS-1D5A1",[1254,4372],{"dataC":3818,"xLinkHref":4373,"transform":4374},"#MJX-21-TEX-SS-1D5C5","translate(4499,0)",[1254,4376],{"dataC":1408,"xLinkHref":4216,"transform":4377},"translate(4738,0)",[1254,4379],{"dataC":4380,"xLinkHref":4381,"transform":4382},"1D5BB","#MJX-21-TEX-SS-1D5BB","translate(5238,0)",[1254,4384],{"dataC":4385,"xLinkHref":4386,"transform":4387},"1D5A7","#MJX-21-TEX-SS-1D5A7","translate(5755,0)",[1254,4389],{"dataC":1388,"xLinkHref":4204,"transform":4390},"translate(6463,0)",[1254,4392],{"dataC":3832,"xLinkHref":4210,"transform":4393},"translate(6944,0)",[1254,4395],{"dataC":1398,"xLinkHref":4213,"transform":4396},"translate(7327,0)",[1242,4398,4400],{"dataMmlNode":1252,"transform":4399},"translate(7877,-229.4) scale(0.707)",[1254,4401],{"dataC":1256,"xLinkHref":4230},[1242,4403,4405],{"dataMmlNode":1260,"transform":4404},"translate(26601.6,0)",[1254,4406],{"dataC":1982,"xLinkHref":4407},"#MJX-21-TEX-N-29",[1066,4409,265],{"id":4410},"proof-friendly-snapshot-packaging",[1027,4412,4413],{},"To support efficient verification (including random-walk transcript checks), the snapshot is packaged in structures that are easy to open with Merkle proofs.",[1985,4415,4416],{"title":2448,"type":1988},[1027,4417,4418],{},"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.",[1985,4420,4421],{"title":2454,"type":1988},[1027,4422,4423],{},"Authenticated data structures (Merkleized key–value stores and adjacency lists) used in light-client verification.",[3039,4425,270],{"id":4426},"noderecord",[1027,4428,4429,4430,2063],{},"For node ",[1193,4431,4433],{"className":4432,"jax":1197},[1196],[1199,4434,4438,4443],{"style":3942,"xmlns":1202,"width":4435,"height":4436,"role":1205,"focusable":1206,"viewBox":4437,"xmlnsXLink":1208},"1.294ex","1.025ex","0 -442 572 453",[1210,4439,4440],{},[1213,4441],{"id":4442,"d":1611},"MJX-22-TEX-I-1D462",[1242,4444,4445],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4446,4447],{"dataMmlNode":1249},[1242,4448,4449],{"dataMmlNode":1252},[1254,4450],{"dataC":1742,"xLinkHref":4451},"#MJX-22-TEX-I-1D462",[1042,4453,4454,4459,4468],{},[1045,4455,4456],{},[3050,4457,4458],{},"nodeId: Address",[1045,4460,4461,4464,4465],{},[3050,4462,4463],{},"marketOutIndexRoot: bytes32"," — Merkle root of per-market outgoing-index entries keyed by ",[3050,4466,4467],{},"marketId",[1045,4469,4470,4473],{},[3050,4471,4472],{},"nodeAttrRoot: bytes32"," — root of node attributes (identity proofs, reputation flags, maturity gates)",[1027,4475,4476,4477,4480],{},"Each per-market outgoing-index entry (opened by a Merkle proof from ",[3050,4478,4479],{},"marketOutIndexRoot",") is:",[4482,4483,275],"h4",{"id":4484},"outindexm",[1042,4486,4487,4492,4694,4703,4711],{},[1045,4488,4489],{},[3050,4490,4491],{},"marketId: uint32",[1045,4493,4494,4497,4498,4693],{},[3050,4495,4496],{},"outWeightSum: uint128"," — ",[1193,4499,4501],{"className":4500,"jax":1197},[1196],[1199,4502,4507,4557],{"style":4503,"xmlns":1202,"width":4504,"height":4505,"role":1205,"focusable":1206,"viewBox":4506,"xmlnsXLink":1208},"vertical-align: -1.105ex;","21.225ex","2.802ex","0 -750 9381.3 1238.4",[1210,4508,4509,4513,4516,4520,4523,4526,4529,4533,4536,4540,4544,4547,4550,4553],{},[1213,4510],{"id":4511,"d":4512},"MJX-23-TEX-SO-2211","M61 748Q64 750 489 750H913L954 640Q965 609 976 579T993 533T999 516H979L959 517Q936 579 886 621T777 682Q724 700 655 705T436 710H319Q183 710 183 709Q186 706 348 484T511 259Q517 250 513 244L490 216Q466 188 420 134T330 27L149 -187Q149 -188 362 -188Q388 -188 436 -188T506 -189Q679 -189 778 -162T936 -43Q946 -27 959 6H999L913 -249L489 -250Q65 -250 62 -248Q56 -246 56 -239Q56 -234 118 -161Q186 -81 245 -11L428 206Q428 207 242 462L57 717L56 728Q56 744 61 748Z",[1213,4514],{"id":4515,"d":1607},"MJX-23-TEX-I-1D465",[1213,4517],{"id":4518,"d":4519},"MJX-23-TEX-N-3A","M78 370Q78 394 95 412T138 430Q162 430 180 414T199 371Q199 346 182 328T139 310T96 327T78 370ZM78 60Q78 84 95 102T138 120Q162 120 180 104T199 61Q199 36 182 18T139 0T96 17T78 60Z",[1213,4521],{"id":4522,"d":161},"MJX-23-TEX-N-A0",[1213,4524],{"id":4525,"d":1589},"MJX-23-TEX-N-28",[1213,4527],{"id":4528,"d":1611},"MJX-23-TEX-I-1D462",[1213,4530],{"id":4531,"d":4532},"MJX-23-TEX-N-2192","M56 237T56 250T70 270H835Q719 357 692 493Q692 494 692 496T691 499Q691 511 708 511H711Q720 511 723 510T729 506T732 497T735 481T743 456Q765 389 816 336T935 261Q944 258 944 250Q944 244 939 241T915 231T877 212Q836 186 806 152T761 85T740 35T732 4Q730 -6 727 -8T711 -11Q691 -11 691 0Q691 7 696 25Q728 151 835 230H70Q56 237 56 250Z",[1213,4534],{"id":4535,"d":1674},"MJX-23-TEX-N-29",[1213,4537],{"id":4538,"d":4539},"MJX-23-TEX-N-2208","M84 250Q84 372 166 450T360 539Q361 539 377 539T419 540T469 540H568Q583 532 583 520Q583 511 570 501L466 500Q355 499 329 494Q280 482 242 458T183 409T147 354T129 306T124 272V270H568Q583 262 583 250T568 230H124V228Q124 207 134 177T167 112T231 48T328 7Q355 1 466 0H570Q583 -10 583 -20Q583 -32 568 -40H471Q464 -40 446 -40T417 -41Q262 -41 172 45Q84 127 84 250Z",[1213,4541],{"id":4542,"d":4543},"MJX-23-TEX-I-1D438","M492 213Q472 213 472 226Q472 230 477 250T482 285Q482 316 461 323T364 330H312Q311 328 277 192T243 52Q243 48 254 48T334 46Q428 46 458 48T518 61Q567 77 599 117T670 248Q680 270 683 272Q690 274 698 274Q718 274 718 261Q613 7 608 2Q605 0 322 0H133Q31 0 31 11Q31 13 34 25Q38 41 42 43T65 46Q92 46 125 49Q139 52 144 61Q146 66 215 342T285 622Q285 629 281 629Q273 632 228 634H197Q191 640 191 642T193 659Q197 676 203 680H757Q764 676 764 669Q764 664 751 557T737 447Q735 440 717 440H705Q698 445 698 453L701 476Q704 500 704 528Q704 558 697 578T678 609T643 625T596 632T532 634H485Q397 633 392 631Q388 629 386 622Q385 619 355 499T324 377Q347 376 372 376H398Q464 376 489 391T534 472Q538 488 540 490T557 493Q562 493 565 493T570 492T572 491T574 487T577 483L544 351Q511 218 508 216Q505 213 492 213Z",[1213,4545],{"id":4546,"d":1216},"MJX-23-TEX-I-1D461",[1213,4548],{"id":4549,"d":1228},"MJX-23-TEX-N-2C",[1213,4551],{"id":4552,"d":1643},"MJX-23-TEX-I-1D45A",[1213,4554],{"id":4555,"d":4556},"MJX-23-TEX-I-1D464","M580 385Q580 406 599 424T641 443Q659 443 674 425T690 368Q690 339 671 253Q656 197 644 161T609 80T554 12T482 -11Q438 -11 404 5T355 48Q354 47 352 44Q311 -11 252 -11Q226 -11 202 -5T155 14T118 53T104 116Q104 170 138 262T173 379Q173 380 173 381Q173 390 173 393T169 400T158 404H154Q131 404 112 385T82 344T65 302T57 280Q55 278 41 278H27Q21 284 21 287Q21 293 29 315T52 366T96 418T161 441Q204 441 227 416T250 358Q250 340 217 250T184 111Q184 65 205 46T258 26Q301 26 334 87L339 96V119Q339 122 339 128T340 136T341 143T342 152T345 165T348 182T354 206T362 238T373 281Q402 395 406 404Q419 431 449 431Q468 431 475 421T483 402Q483 389 454 274T422 142Q420 131 420 107V100Q420 85 423 71T442 42T487 26Q558 26 600 148Q609 171 620 213T632 273Q632 306 619 325T593 357T580 385Z",[1242,4558,4559],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4560,4561,4654,4668,4673,4678,4683,4688],{"dataMmlNode":1249},[1242,4562,4564,4570],{"dataMmlNode":4563},"munder",[1242,4565,4566],{"dataMmlNode":1260},[1254,4567],{"dataC":4568,"xLinkHref":4569},"2211","#MJX-23-TEX-SO-2211",[1242,4571,4573,4578,4584,4590,4596,4602,4609,4614,4620,4627],{"dataMmlNode":1373,"transform":4572,"dataMjxTexclass":1374},"translate(1089,-285.4) scale(0.707)",[1242,4574,4575],{"dataMmlNode":1252},[1254,4576],{"dataC":1720,"xLinkHref":4577},"#MJX-23-TEX-I-1D465",[1242,4579,4580],{"dataMmlNode":1260,"transform":1746},[1254,4581],{"dataC":4582,"xLinkHref":4583},"3A","#MJX-23-TEX-N-3A",[1242,4585,4587],{"dataMmlNode":2726,"transform":4586},"translate(850,0)",[1254,4588],{"dataC":3327,"xLinkHref":4589},"#MJX-23-TEX-N-A0",[1242,4591,4593],{"dataMmlNode":1260,"transform":4592},"translate(1100,0)",[1254,4594],{"dataC":1683,"xLinkHref":4595},"#MJX-23-TEX-N-28",[1242,4597,4599],{"dataMmlNode":1252,"transform":4598},"translate(1489,0)",[1254,4600],{"dataC":1742,"xLinkHref":4601},"#MJX-23-TEX-I-1D462",[1242,4603,4605],{"dataMmlNode":1260,"transform":4604},"translate(2061,0)",[1254,4606],{"dataC":4607,"xLinkHref":4608},"2192","#MJX-23-TEX-N-2192",[1242,4610,4612],{"dataMmlNode":1252,"transform":4611},"translate(3061,0)",[1254,4613],{"dataC":1720,"xLinkHref":4577},[1242,4615,4617],{"dataMmlNode":1260,"transform":4616},"translate(3633,0)",[1254,4618],{"dataC":1982,"xLinkHref":4619},"#MJX-23-TEX-N-29",[1242,4621,4623],{"dataMmlNode":1260,"transform":4622},"translate(4022,0)",[1254,4624],{"dataC":4625,"xLinkHref":4626},"2208","#MJX-23-TEX-N-2208",[1242,4628,4630,4636],{"dataMmlNode":1370,"transform":4629},"translate(4689,0)",[1242,4631,4632],{"dataMmlNode":1252},[1254,4633],{"dataC":4634,"xLinkHref":4635},"1D438","#MJX-23-TEX-I-1D438",[1242,4637,4639,4644,4649],{"dataMmlNode":1373,"transform":4638,"dataMjxTexclass":1374},"translate(771,-150) scale(0.707)",[1242,4640,4641],{"dataMmlNode":1252},[1254,4642],{"dataC":1256,"xLinkHref":4643},"#MJX-23-TEX-I-1D461",[1242,4645,4646],{"dataMmlNode":1260,"transform":1717},[1254,4647],{"dataC":1279,"xLinkHref":4648},"#MJX-23-TEX-N-2C",[1242,4650,4651],{"dataMmlNode":1252,"transform":2655},[1254,4652],{"dataC":1818,"xLinkHref":4653},"#MJX-23-TEX-I-1D45A",[1242,4655,4657,4663],{"dataMmlNode":1370,"transform":4656},"translate(5960.3,0)",[1242,4658,4659],{"dataMmlNode":1252},[1254,4660],{"dataC":4661,"xLinkHref":4662},"1D464","#MJX-23-TEX-I-1D464",[1242,4664,4666],{"dataMmlNode":1252,"transform":4665},"translate(749,-150) scale(0.707)",[1254,4667],{"dataC":1256,"xLinkHref":4643},[1242,4669,4671],{"dataMmlNode":1260,"transform":4670},"translate(7014.6,0)",[1254,4672],{"dataC":1683,"xLinkHref":4595},[1242,4674,4676],{"dataMmlNode":1252,"transform":4675},"translate(7403.6,0)",[1254,4677],{"dataC":1742,"xLinkHref":4601},[1242,4679,4681],{"dataMmlNode":1260,"transform":4680},"translate(7975.6,0)",[1254,4682],{"dataC":1279,"xLinkHref":4648},[1242,4684,4686],{"dataMmlNode":1252,"transform":4685},"translate(8420.3,0)",[1254,4687],{"dataC":1720,"xLinkHref":4577},[1242,4689,4691],{"dataMmlNode":1260,"transform":4690},"translate(8992.3,0)",[1254,4692],{"dataC":1982,"xLinkHref":4619}," for this market",[1045,4695,4696,4699,4700],{},[3050,4697,4698],{},"adjacencyRoot: bytes32"," — Merkle root of outgoing edges ",[1073,4701,4702],{},"in this market",[1045,4704,4705,4708,4709],{},[3050,4706,4707],{},"aliasRoot: bytes32"," — Merkle root of alias table for O(1) sampling of outgoing edges ",[1073,4710,4702],{},[1045,4712,4713,4716],{},[3050,4714,4715],{},"degree: uint32"," — number of outgoing edges in this market",[1985,4718,4719],{"title":2448,"type":1988},[1027,4720,4721,4722,4743,4744,4746,4747,4750,4751,1064],{},"A node’s outgoing edges are partitioned by market. When verifying a walk step for market ",[1193,4723,4725],{"className":4724,"jax":1197},[1196],[1199,4726,4729,4734],{"style":3942,"xmlns":1202,"width":4727,"height":4436,"role":1205,"focusable":1206,"viewBox":4728,"xmlnsXLink":1208},"1.986ex","0 -442 878 453",[1210,4730,4731],{},[1213,4732],{"id":4733,"d":1643},"MJX-24-TEX-I-1D45A",[1242,4735,4736],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4737,4738],{"dataMmlNode":1249},[1242,4739,4740],{"dataMmlNode":1252},[1254,4741],{"dataC":1818,"xLinkHref":4742},"#MJX-24-TEX-I-1D45A",", a verifier opens ",[3050,4745,275],{}," and then verifies the sampled neighbor using that market’s ",[3050,4748,4749],{},"aliasRoot"," + ",[3050,4752,4753],{},"adjacencyRoot",[3039,4755,281],{"id":4756},"edgerecord",[1027,4758,4759,4760,2063],{},"For an outgoing edge ",[1193,4761,4763],{"className":4762,"jax":1197},[1196],[1199,4764,4768,4779],{"style":3942,"xmlns":1202,"width":4765,"height":4766,"role":1205,"focusable":1206,"viewBox":4767,"xmlnsXLink":1208},"5.911ex","1.181ex","0 -511 2612.6 522",[1210,4769,4770,4773,4776],{},[1213,4771],{"id":4772,"d":1611},"MJX-25-TEX-I-1D462",[1213,4774],{"id":4775,"d":4532},"MJX-25-TEX-N-2192",[1213,4777],{"id":4778,"d":3514},"MJX-25-TEX-I-1D463",[1242,4780,4781],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4782,4783,4788,4794],{"dataMmlNode":1249},[1242,4784,4785],{"dataMmlNode":1252},[1254,4786],{"dataC":1742,"xLinkHref":4787},"#MJX-25-TEX-I-1D462",[1242,4789,4791],{"dataMmlNode":1260,"transform":4790},"translate(849.8,0)",[1254,4792],{"dataC":4607,"xLinkHref":4793},"#MJX-25-TEX-N-2192",[1242,4795,4797],{"dataMmlNode":1252,"transform":4796},"translate(2127.6,0)",[1254,4798],{"dataC":3659,"xLinkHref":4799},"#MJX-25-TEX-I-1D463",[1042,4801,4802,4807,4812,4818,4852],{},[1045,4803,4804],{},[3050,4805,4806],{},"dst: Address",[1045,4808,4809],{},[3050,4810,4811],{},"weight: uint128",[1045,4813,4814,4817],{},[3050,4815,4816],{},"edgeAttrRoot: bytes32"," — service proof \u002F dispute state commitments",[1045,4819,4820,4497,4822,4825,4826,4845,4846,4848,4849,4851],{},[3050,4821,4491],{},[1073,4823,4824],{},"required"," market tag for commerce edges (“this edge belongs to market ",[1193,4827,4829],{"className":4828,"jax":1197},[1196],[1199,4830,4831,4836],{"style":3942,"xmlns":1202,"width":4727,"height":4436,"role":1205,"focusable":1206,"viewBox":4728,"xmlnsXLink":1208},[1210,4832,4833],{},[1213,4834],{"id":4835,"d":1643},"MJX-26-TEX-I-1D45A",[1242,4837,4838],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4839,4840],{"dataMmlNode":1249},[1242,4841,4842],{"dataMmlNode":1252},[1254,4843],{"dataC":1818,"xLinkHref":4844},"#MJX-26-TEX-I-1D45A","”). ",[3050,4847,4467],{}," MUST match the registry-assigned ",[3050,4850,4467],{}," of the producing MarketContext at that block height.",[1045,4853,4854,4857],{},[3050,4855,4856],{},"flags: uint32"," — dispute outcomes, maturity gating, etc.",[3039,4859,286],{"id":4860},"alias-tables-recommended",[1027,4862,4863,4864,4960,4961,4964,4965,4968],{},"For efficient verifiable sampling from ",[1193,4865,4867],{"className":4866,"jax":1197},[1196],[1199,4868,4872,4900],{"style":1997,"xmlns":1202,"width":4869,"height":4870,"role":1205,"focusable":1206,"viewBox":4871,"xmlnsXLink":1208},"8.756ex","2.347ex","0 -750 3870.3 1037.2",[1210,4873,4874,4878,4881,4884,4887,4890,4893,4897],{},[1213,4875],{"id":4876,"d":4877},"MJX-27-TEX-I-1D443","M287 628Q287 635 230 637Q206 637 199 638T192 648Q192 649 194 659Q200 679 203 681T397 683Q587 682 600 680Q664 669 707 631T751 530Q751 453 685 389Q616 321 507 303Q500 302 402 301H307L277 182Q247 66 247 59Q247 55 248 54T255 50T272 48T305 46H336Q342 37 342 35Q342 19 335 5Q330 0 319 0Q316 0 282 1T182 2Q120 2 87 2T51 1Q33 1 33 11Q33 13 36 25Q40 41 44 43T67 46Q94 46 127 49Q141 52 146 61Q149 65 218 339T287 628ZM645 554Q645 567 643 575T634 597T609 619T560 635Q553 636 480 637Q463 637 445 637T416 636T404 636Q391 635 386 627Q384 621 367 550T332 412T314 344Q314 342 395 342H407H430Q542 342 590 392Q617 419 631 471T645 554Z",[1213,4879],{"id":4880,"d":1216},"MJX-27-TEX-I-1D461",[1213,4882],{"id":4883,"d":1228},"MJX-27-TEX-N-2C",[1213,4885],{"id":4886,"d":1643},"MJX-27-TEX-I-1D45A",[1213,4888],{"id":4889,"d":1589},"MJX-27-TEX-N-28",[1213,4891],{"id":4892,"d":1611},"MJX-27-TEX-I-1D462",[1213,4894],{"id":4895,"d":4896},"MJX-27-TEX-N-22C5","M78 250Q78 274 95 292T138 310Q162 310 180 294T199 251Q199 226 182 208T139 190T96 207T78 250Z",[1213,4898],{"id":4899,"d":1674},"MJX-27-TEX-N-29",[1242,4901,4902],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4903,4904,4930,4936,4942,4947,4954],{"dataMmlNode":1249},[1242,4905,4906,4912],{"dataMmlNode":1370},[1242,4907,4908],{"dataMmlNode":1252},[1254,4909],{"dataC":4910,"xLinkHref":4911},"1D443","#MJX-27-TEX-I-1D443",[1242,4913,4915,4920,4925],{"dataMmlNode":1373,"transform":4914,"dataMjxTexclass":1374},"translate(675,-150) scale(0.707)",[1242,4916,4917],{"dataMmlNode":1252},[1254,4918],{"dataC":1256,"xLinkHref":4919},"#MJX-27-TEX-I-1D461",[1242,4921,4922],{"dataMmlNode":1260,"transform":1717},[1254,4923],{"dataC":1279,"xLinkHref":4924},"#MJX-27-TEX-N-2C",[1242,4926,4927],{"dataMmlNode":1252,"transform":2655},[1254,4928],{"dataC":1818,"xLinkHref":4929},"#MJX-27-TEX-I-1D45A",[1242,4931,4933],{"dataMmlNode":1260,"transform":4932},"translate(1797.7,0)",[1254,4934],{"dataC":1683,"xLinkHref":4935},"#MJX-27-TEX-N-28",[1242,4937,4939],{"dataMmlNode":1252,"transform":4938},"translate(2186.7,0)",[1254,4940],{"dataC":1742,"xLinkHref":4941},"#MJX-27-TEX-I-1D462",[1242,4943,4945],{"dataMmlNode":1260,"transform":4944},"translate(2758.7,0)",[1254,4946],{"dataC":1279,"xLinkHref":4924},[1242,4948,4950],{"dataMmlNode":1260,"transform":4949},"translate(3203.3,0)",[1254,4951],{"dataC":4952,"xLinkHref":4953},"22C5","#MJX-27-TEX-N-22C5",[1242,4955,4957],{"dataMmlNode":1260,"transform":4956},"translate(3481.3,0)",[1254,4958],{"dataC":1982,"xLinkHref":4959},"#MJX-27-TEX-N-29",", the protocol supports per-node, ",[1073,4962,4963],{},"per-market"," alias tables (via ",[3050,4966,4967],{},"OutIndex(m).aliasRoot","):",[1042,4970,4971,4974],{},[1045,4972,4973],{},"alias entries deterministically derived from the market-scoped adjacency list",[1045,4975,4976],{},"the table commits to sampling structure enabling O(1) verification of a sampled neighbor within the market context",[1985,4978,4979],{"title":2448,"type":1988},[1027,4980,4981,4982,5001,5002,5024],{},"A random walk repeatedly asks: “from ",[1193,4983,4985],{"className":4984,"jax":1197},[1196],[1199,4986,4987,4992],{"style":3942,"xmlns":1202,"width":4435,"height":4436,"role":1205,"focusable":1206,"viewBox":4437,"xmlnsXLink":1208},[1210,4988,4989],{},[1213,4990],{"id":4991,"d":1611},"MJX-28-TEX-I-1D462",[1242,4993,4994],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,4995,4996],{"dataMmlNode":1249},[1242,4997,4998],{"dataMmlNode":1252},[1254,4999],{"dataC":1742,"xLinkHref":5000},"#MJX-28-TEX-I-1D462",", which neighbor ",[1193,5003,5005],{"className":5004,"jax":1197},[1196],[1199,5006,5010,5015],{"style":3942,"xmlns":1202,"width":5007,"height":5008,"role":1205,"focusable":1206,"viewBox":5009,"xmlnsXLink":1208},"1.097ex","1.027ex","0 -443 485 454",[1210,5011,5012],{},[1213,5013],{"id":5014,"d":3514},"MJX-29-TEX-I-1D463",[1242,5016,5017],{"stroke":1244,"fill":1244,"stroke-width":1245,"transform":1246},[1242,5018,5019],{"dataMmlNode":1249},[1242,5020,5021],{"dataMmlNode":1252},[1254,5022],{"dataC":3659,"xLinkHref":5023},"#MJX-29-TEX-I-1D463"," do I jump to next?” Alias tables are a standard trick to sample from a discrete distribution in O(1) time.",[1985,5026,5027],{"title":2454,"type":1988},[1027,5028,5029,5030,5035,5036,1064],{},"The alias method: ",[1031,5031,5034],{"href":5032,"rel":5033},"https:\u002F\u002Fdl.acm.org\u002Fdoi\u002Fpdf\u002F10.1145\u002F355744.355749",[1035],"Walker (1977)"," and ",[1031,5037,5040],{"href":5038,"rel":5039},"https:\u002F\u002Fdl.acm.org\u002Fdoi\u002F10.1109\u002F32.92917",[1035],"Vose (1991)",[1066,5042,70],{"id":5043},"related",[1042,5045,5046,5051,5055],{},[1045,5047,5048],{},[1031,5049,5050],{"href":74},"Snapshot-Relative Diffusion",[1045,5052,5053],{},[1031,5054,542],{"href":541},[1045,5056,5057],{},[1031,5058,193],{"href":192},[1066,5060,295],{"id":5061},"snapshot-artifacts-and-data-availability",[1027,5063,5064,5065,5070,5071,5076],{},"Nodes can check availability via probabilistic sampling (DAS-style checks), as in ",[1031,5066,5069],{"href":5067,"rel":5068},"https:\u002F\u002Farxiv.org\u002Fabs\u002F1905.09274",[1035],"LazyLedger"," and common DAS primers (e.g., Celestia’s ",[1031,5072,5075],{"href":5073,"rel":5074},"https:\u002F\u002Fcelestia.org\u002Fglossary\u002Fdata-availability-sampling\u002F",[1035],"Data Availability Sampling",").",[1027,5078,5079,5080],{},"See: ",[1031,5081,4096],{"href":4095},[5083,5084,5085],"style",{},"\nmjx-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}\n",{"title":161,"searchDepth":16,"depth":16,"links":5087},[5088,5089,5092,5093,5098,5099],{"id":1188,"depth":16,"text":245},{"id":2465,"depth":16,"text":250,"children":5090},[5091],{"id":3041,"depth":52,"text":255},{"id":3918,"depth":16,"text":260},{"id":4410,"depth":16,"text":265,"children":5094},[5095,5096,5097],{"id":4426,"depth":52,"text":270},{"id":4756,"depth":52,"text":281},{"id":4860,"depth":52,"text":286},{"id":5043,"depth":16,"text":70},{"id":5061,"depth":16,"text":295},"One canonical epoch snapshot commitment per epoch — graph, seed, and artifact roots that serve as the reference for diffusion-derived claims.",{},{"title":240,"description":5100},"docs\u002Fgames-and-graphs\u002Fsnapshot-commitments","K7AvNz0pb1abKmKLpyUoKOFT5--GHXdrd36-Hoh4qOg",1783724205057]