[{"data":1,"prerenderedAt":1036},["ShallowReactive",2],{"blog-list-1":3,"blog-count":23,"docs-search-sections":24,"docs-last-updated":1031},[4,15],{"path":5,"title":6,"description":7,"date":8,"tags":9,"author":14},"\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.","2024-10-26",[10,11,12,13],"research","proofs","depin","sybil-resistance","mike",{"path":16,"title":17,"description":18,"date":19,"tags":20,"author":14},"\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.","2024-06-23",[10,21,12,22],"token-design","pagerank",2,[25,32,37,42,47,52,57,62,67,73,78,83,88,93,98,103,108,113,118,123,128,132,137,142,147,152,157,162,167,172,177,182,187,192,197,202,207,211,216,221,226,230,235,240,245,249,254,258,263,268,273,278,283,288,293,299,304,309,313,318,323,328,332,337,341,346,350,355,360,365,370,375,380,385,390,394,398,402,405,410,415,419,423,427,430,435,440,444,448,453,458,463,467,472,477,482,486,491,496,501,506,511,516,521,526,531,536,541,546,551,556,560,565,570,575,580,585,590,595,600,604,609,613,618,623,627,632,637,642,647,652,657,661,666,671,676,681,685,690,694,699,704,709,714,719,723,728,733,737,741,746,751,755,760,765,770,774,779,783,788,792,797,801,805,810,814,819,823,828,832,837,841,846,850,855,860,865,869,874,879,883,888,893,898,903,908,913,918,923,928,933,938,943,948,953,958,963,966,971,975,979,983,987,992,997,1002,1007,1011,1016,1021,1026],{"id":26,"title":27,"titles":28,"content":29,"level":30,"kind":31,"priority":30},"\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":33,"title":34,"titles":35,"content":36,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-sampling-unpredictable-canonical","Audit sampling (unpredictable, canonical)",[27],"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.",{"id":38,"title":39,"titles":40,"content":41,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-assignment-obligations-not-volunteers","Audit assignment (obligations, not volunteers)",[27],"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":43,"title":44,"titles":45,"content":46,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#what-auditors-verify-bounded-work","What auditors verify (bounded work)",[27],"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":48,"title":49,"titles":50,"content":51,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#audit-outcomes-and-accountability","Audit outcomes and accountability",[27],"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":53,"title":54,"titles":55,"content":56,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#fraud-proofs-are-deterministic","Fraud proofs are deterministic",[27],"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":58,"title":59,"titles":60,"content":61,"level":23,"kind":31,"priority":30},"\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)",[27],"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":63,"title":64,"titles":65,"content":66,"level":23,"kind":31,"priority":30},"\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",[27],"When an audited claim fails, the protocol applies objective penalties and then feeds them back into diffusion policy.",{"id":68,"title":69,"titles":70,"content":71,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_1-edge-slashing","1) Edge slashing",[27,64],"For a failed edge :",3,{"id":74,"title":75,"titles":76,"content":77,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_2-bond-slashing","2) Bond slashing",[27,64],"The claim bond  is slashed (policy-defined split between burn\u002Fsecurity pool\u002Fauditor rewards).",{"id":79,"title":80,"titles":81,"content":82,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_3-penalty-vector-ledger-fact","3) Penalty vector  (ledger fact)",[27,64],"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":84,"title":85,"titles":86,"content":87,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#_4-how-penalties-modify-policy-inputs","4) How penalties modify policy inputs",[27,64],"Penalty-adjusted seed weights (before normalization): Risk-based claim constraints (examples):",{"id":89,"title":90,"titles":91,"content":92,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties#related","Related",[27],"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":94,"title":95,"titles":96,"content":97,"level":30,"kind":31,"priority":30},"\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":99,"title":100,"titles":101,"content":102,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_1-transition-operator","1) Transition operator",[95],"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":104,"title":105,"titles":106,"content":107,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_2-teleport-distribution-protocol-defined","2) Teleport distribution (protocol-defined)",[95],"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":109,"title":110,"titles":111,"content":112,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#why-market-relative-teleport","Why market-relative teleport?",[95,105],"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":114,"title":115,"titles":116,"content":117,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_3-fixed-point-definition","3) Fixed point definition",[95],"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":119,"title":120,"titles":121,"content":122,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_4-random-walk-interpretation","4) Random-walk interpretation",[95],"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":124,"title":125,"titles":126,"content":127,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#_5-why-snapshot-relative","5) Why snapshot-relative?",[95],"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":129,"title":90,"titles":130,"content":131,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion#related",[95],"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":133,"title":134,"titles":135,"content":136,"level":30,"kind":31,"priority":30},"\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":138,"title":139,"titles":140,"content":141,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#a-tiny-transaction-graph","A tiny transaction graph",[134],"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":143,"title":144,"titles":145,"content":146,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#personalized-pagerank-ppr-intuition","Personalized PageRank (PPR) intuition",[134],"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":148,"title":149,"titles":150,"content":151,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#offchain-computation-demo-networkx","Offchain computation demo (NetworkX)",[134],"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":153,"title":154,"titles":155,"content":156,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#how-this-maps-to-the-protocol","How this maps to the protocol",[134],"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":158,"title":159,"titles":160,"content":161,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fexample#next-steps","Next steps",[134],"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":163,"title":164,"titles":165,"content":166,"level":30,"kind":31,"priority":30},"\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":168,"title":169,"titles":170,"content":171,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#graph-structure","Graph Structure",[164],"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":173,"title":174,"titles":175,"content":176,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#edge-weights","Edge weights",[164,169],"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":178,"title":179,"titles":180,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#key-features","Key Features",[164],"",{"id":183,"title":184,"titles":185,"content":186,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#_1-dynamic-adjustments","1. Dynamic Adjustments",[164,179],"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":188,"title":189,"titles":190,"content":191,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#_2-connectivity-as-a-measure-of-value","2. Connectivity as a Measure of Value",[164,179],"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":193,"title":194,"titles":195,"content":196,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#_3-sybil-resistance","3. Sybil Resistance",[164,179],"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":198,"title":199,"titles":200,"content":201,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph#next-steps","Next Steps",[164],"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":203,"title":204,"titles":205,"content":206,"level":30,"kind":31,"priority":30},"\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":208,"title":199,"titles":209,"content":210,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs#next-steps",[204],"Start here: Transaction Graph ModelSnapshot-Relative Diffusion (PageRank \u002F PPR)MarketsGraph Commitments & Epoch SnapshotsOptimistic Diffusion Claims",{"id":212,"title":213,"titles":214,"content":215,"level":30,"kind":31,"priority":30},"\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":217,"title":218,"titles":219,"content":220,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#what-a-user-is-allowed-to-claim","What a user is allowed to claim",[213],"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":222,"title":223,"titles":224,"content":225,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#canonical-randomness-kills-grinding","Canonical randomness (kills grinding)",[213],"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":227,"title":228,"titles":229,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#transcript-commitment-delayed-sampling-prevents-adaptive-cheating","Transcript commitment + delayed sampling (prevents adaptive cheating)",[213],{"id":231,"title":232,"titles":233,"content":234,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#commit-now-sample-later","Commit now, sample later",[213,228],"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":236,"title":237,"titles":238,"content":239,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#transcript-contents-minimal-sketch","Transcript contents (minimal sketch)",[213],"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":241,"title":242,"titles":243,"content":244,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#verification-and-penalties-validator-audits","Verification and penalties (validator audits)",[213],"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":246,"title":90,"titles":247,"content":248,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims#related",[213],"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":250,"title":251,"titles":252,"content":253,"level":30,"kind":31,"priority":30},"\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":255,"title":199,"titles":256,"content":257,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Foverview#next-steps",[251],"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":259,"title":260,"titles":261,"content":262,"level":30,"kind":31,"priority":30},"\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":264,"title":265,"titles":266,"content":267,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#epochs","Epochs",[260],"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":269,"title":270,"titles":271,"content":272,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#commitment-structure","Commitment structure",[260],"Partition nodes into shards . Each shard publishes: The global graph root is:",{"id":274,"title":275,"titles":276,"content":277,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#seed-commitments-market-relative-teleport","Seed commitments (market-relative teleport)",[260,270],"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":279,"title":280,"titles":281,"content":282,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#snapshot-artifact-identifier-snapshotid","Snapshot artifact identifier (SnapshotId)",[260],"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":284,"title":285,"titles":286,"content":287,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#proof-friendly-snapshot-packaging","Proof-friendly snapshot packaging",[260],"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":289,"title":290,"titles":291,"content":292,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#noderecord","NodeRecord",[260,285],"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":294,"title":295,"titles":296,"content":297,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#outindexm","OutIndex(m)",[260,285,290],"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":300,"title":301,"titles":302,"content":303,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#edgerecord","EdgeRecord",[260,285],"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":305,"title":306,"titles":307,"content":308,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#alias-tables-recommended","Alias tables (recommended)",[260,285],"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":310,"title":90,"titles":311,"content":312,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#related",[260],"Snapshot-Relative DiffusionMarketsOptimistic Diffusion Claims",{"id":314,"title":315,"titles":316,"content":317,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments#snapshot-artifacts-and-data-availability","Snapshot artifacts and data availability",[260],"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":319,"title":320,"titles":321,"content":322,"level":30,"kind":31,"priority":30},"\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":324,"title":325,"titles":326,"content":327,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#components","Components",[320],"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":329,"title":330,"titles":331,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#localaccount-contract","LocalAccount Contract",[320],{"id":333,"title":334,"titles":335,"content":336,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#overview","Overview",[320,330],"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":338,"title":179,"titles":339,"content":340,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#key-features",[320,330],"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":342,"title":343,"titles":344,"content":345,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#state-variables","State Variables",[320,330],"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":347,"title":348,"titles":349,"content":181,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#methods","Methods",[320,330],{"id":351,"title":352,"titles":353,"content":354,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#initialization","Initialization",[320,330,348],"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":356,"title":357,"titles":358,"content":359,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#transaction-execution","Transaction Execution",[320,330,348],"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":361,"title":362,"titles":363,"content":364,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#user-operation-validation","User Operation Validation",[320,330,348],"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":366,"title":367,"titles":368,"content":369,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#signature-validation","Signature Validation",[320,330,348],"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":371,"title":372,"titles":373,"content":374,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#key-management","Key Management",[320,330,348],"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":376,"title":377,"titles":378,"content":379,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#utility-methods","Utility Methods",[320,330,348],"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":381,"title":382,"titles":383,"content":384,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#access-control","Access Control",[320,330],"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":386,"title":387,"titles":388,"content":389,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#events","Events",[320,330],"AccountInitialized: Emitted during initialization.SigningKeyAdded: Emitted when a new signing key is added.SigningKeyRemoved: Emitted when a signing key is removed.",{"id":391,"title":392,"titles":393,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#localaccountfactory-contract","LocalAccountFactory Contract",[320],{"id":395,"title":334,"titles":396,"content":397,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#overview-1",[320,392],"The LocalAccountFactory contract is responsible for deploying new LocalAccount instances using the CREATE2 opcode, allowing for deterministic contract addresses.",{"id":399,"title":179,"titles":400,"content":401,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#key-features-1",[320,392],"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":403,"title":348,"titles":404,"content":181,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#methods-1",[320,392],{"id":406,"title":407,"titles":408,"content":409,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#create-account","Create Account",[320,392,348],"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":411,"title":412,"titles":413,"content":414,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#get-address","Get Address",[320,392,348],"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":416,"title":417,"titles":418,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#localverifier-contract","LocalVerifier Contract",[320],{"id":420,"title":334,"titles":421,"content":422,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#overview-2",[320,417],"The LocalVerifier contract provides signature verification functionality for P256 signatures, compatible with WebAuthn standards.",{"id":424,"title":179,"titles":425,"content":426,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#key-features-2",[320,417],"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":428,"title":348,"titles":429,"content":181,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#methods-2",[320,417],{"id":431,"title":432,"titles":433,"content":434,"level":298,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#verify-signature","Verify Signature",[320,417,348],"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":436,"title":437,"titles":438,"content":439,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#signature-structure","Signature Structure",[320,417],"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":441,"title":382,"titles":442,"content":443,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#access-control-1",[320,417],"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":445,"title":446,"titles":447,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#key-concepts","Key Concepts",[320],{"id":449,"title":450,"titles":451,"content":452,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#erc-4337-account-abstraction","ERC-4337 Account Abstraction",[320,446],"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":454,"title":455,"titles":456,"content":457,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#p256-elliptic-curve-cryptography","P256 Elliptic Curve Cryptography",[320,446],"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":459,"title":460,"titles":461,"content":462,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#webauthn-integration","WebAuthn Integration",[320,446],"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":464,"title":465,"titles":466,"content":181,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#additional-context","Additional Context",[320],{"id":468,"title":469,"titles":470,"content":471,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#gas-optimization","Gas Optimization",[320,465],"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":473,"title":474,"titles":475,"content":476,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#future-enhancements","Future Enhancements",[320,465],"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":478,"title":479,"titles":480,"content":481,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#references","References",[320],"EIP-4337: Account AbstractionEIP-7212: P256 Precompile ProposalWebAuthn SpecificationP256 Elliptic Curve DetailsWycheproof Test VectorsStrauss-Shamir TrickExtended Jacobian Coordinates",{"id":483,"title":199,"titles":484,"content":485,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fidentity#next-steps",[320],"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":487,"title":488,"titles":489,"content":490,"level":30,"kind":31,"priority":30},"\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":492,"title":493,"titles":494,"content":495,"level":23,"kind":31,"priority":30},"\u002Fdocs#who-should-use-local-protocol","Who should use Local Protocol",[488],"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":497,"title":498,"titles":499,"content":500,"level":23,"kind":31,"priority":30},"\u002Fdocs#who-is-this-documentation-for","Who is this documentation for",[488],"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":502,"title":503,"titles":504,"content":505,"level":30,"kind":31,"priority":30},"\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":507,"title":508,"titles":509,"content":510,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#why-market-relative-teleport-exists","Why market-relative teleport exists",[503],"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":512,"title":513,"titles":514,"content":515,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#per-market-seed-commitments-root-of-roots","Per-market seed commitments (root of roots)",[503],"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":517,"title":518,"titles":519,"content":520,"level":23,"kind":31,"priority":30},"\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",[503],"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":522,"title":523,"titles":524,"content":525,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#recommended-seed-construction-rule-deterministic-low-governance","Recommended seed construction rule (deterministic, low-governance)",[503],"The protocol builds the market-local teleport mass  from a union of endogenous and exogenous anchors, then normalizes and clips.",{"id":527,"title":528,"titles":529,"content":530,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#_1-endogenous-anchors-earned-seeds-diversity-time-not-volume","1) Endogenous anchors (earned seeds): diversity + time, not volume",[503,523],"Let Window_t be the last  epochs (a global constant). A participant  is endo-eligible in market  iff: Verified(v)",{"id":532,"title":533,"titles":534,"content":535,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#_2-exogenous-anchors-market-anchors-concave-weight-from-locked-capital","2) Exogenous anchors (Market Anchors): concave weight from locked capital",[503,523],"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":537,"title":538,"titles":539,"content":540,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#_3-mixture-clipping","3) Mixture + clipping",[503,523],"Then apply a per-address cap (e.g., ) and renormalize.",{"id":542,"title":543,"titles":544,"content":545,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#market-vaults-a-startup-credit-line-primitive-for-a-market","Market Vaults: a “startup credit line” primitive for a market",[503],"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":547,"title":548,"titles":549,"content":550,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#fee-attribution-is-ledger-defined","Fee attribution is ledger-defined",[503,543],"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":552,"title":553,"titles":554,"content":555,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#vault-invariants-mechanical-constraints","Vault invariants (mechanical constraints)",[503,543],"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":557,"title":90,"titles":558,"content":559,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fbootstrapping#related",[503],"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":561,"title":562,"titles":563,"content":564,"level":30,"kind":31,"priority":30},"\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":566,"title":567,"titles":568,"content":569,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets#what-lives-here","What lives here",[562],"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":571,"title":572,"titles":573,"content":574,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets#start-here","Start here",[562],"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":576,"title":577,"titles":578,"content":579,"level":30,"kind":31,"priority":30},"\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":581,"title":582,"titles":583,"content":584,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fregistry#markets-are-derived-from-execution","Markets are derived from execution",[577],"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":586,"title":587,"titles":588,"content":589,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fregistry#marketregistry-canonicalization","MarketRegistry (canonicalization)",[577],"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":591,"title":592,"titles":593,"content":594,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fregistry#interactionrecords","InteractionRecords",[577],"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":596,"title":597,"titles":598,"content":599,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fregistry#validity-rule-critical","Validity rule (critical)",[577,592],"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":601,"title":90,"titles":602,"content":603,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmarkets\u002Fregistry#related",[577],"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":605,"title":606,"titles":607,"content":608,"level":30,"kind":31,"priority":30},"\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":610,"title":199,"titles":611,"content":612,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fmore-resources#next-steps",[606],"Read the whitepaper — the original Local Protocol whitepaper.Browse the code on GitHub — protocol implementations and tooling.",{"id":614,"title":615,"titles":616,"content":617,"level":30,"kind":31,"priority":30},"\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":619,"title":620,"titles":621,"content":622,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fidentity-proofs#how-identity-proofs-affect-diffusion-and-incentives","How identity proofs affect diffusion and incentives",[615],"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":624,"title":199,"titles":625,"content":626,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fidentity-proofs#next-steps",[615],"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":628,"title":629,"titles":630,"content":631,"level":30,"kind":31,"priority":30},"\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":633,"title":634,"titles":635,"content":636,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs#spectrum-of-verifiability","Spectrum of Verifiability",[629],"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":638,"title":639,"titles":640,"content":641,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs#proofs-as-graph-attributes","Proofs as Graph Attributes",[629],"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":643,"title":644,"titles":645,"content":646,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs#trust-propagation-under-diffusion","Trust propagation under diffusion",[629,639],"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":648,"title":649,"titles":650,"content":651,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs#probabilistic-evidence-and-confidence","Probabilistic evidence and confidence",[629],"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":653,"title":654,"titles":655,"content":656,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs#proof-attachments-in-state-diff-lists-sdls","Proof attachments in State Diff Lists (SDLs)",[629],"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":658,"title":199,"titles":659,"content":660,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs#next-steps",[629],"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":662,"title":663,"titles":664,"content":665,"level":30,"kind":31,"priority":30},"\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":667,"title":668,"titles":669,"content":670,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#the-problem","The problem",[663],"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":672,"title":673,"titles":674,"content":675,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#proof-of-location-as-a-soft-proof","Proof-of-location as a soft proof",[663],"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":677,"title":678,"titles":679,"content":680,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#why-this-helps-immature-markets","Why this helps immature markets",[663],"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":682,"title":90,"titles":683,"content":684,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Flocation-proofs#related",[663],"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":686,"title":687,"titles":688,"content":689,"level":30,"kind":31,"priority":30},"\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":691,"title":199,"titles":692,"content":693,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Foverview#next-steps",[687],"Identity ProofsService ProofsProofs as ProbabilitiesLocation Proofs",{"id":695,"title":696,"titles":697,"content":698,"level":30,"kind":31,"priority":30},"\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":700,"title":701,"titles":702,"content":703,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fprobabilities#confidence-weighted-evidence","Confidence-weighted evidence",[696],"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":705,"title":706,"titles":707,"content":708,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fprobabilities#how-probabilistic-proofs-affect-the-graph","How probabilistic proofs affect the graph",[696],"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":710,"title":711,"titles":712,"content":713,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fprobabilities#dampening-over-distance-and-time","Dampening over distance and time",[696],"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":715,"title":716,"titles":717,"content":718,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fprobabilities#practical-guidance-protocol-level","Practical guidance (protocol-level)",[696],"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":720,"title":199,"titles":721,"content":722,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fprobabilities#next-steps",[696],"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":724,"title":725,"titles":726,"content":727,"level":30,"kind":31,"priority":30},"\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":729,"title":730,"titles":731,"content":732,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fservice-proofs#how-service-proofs-affect-diffusion-and-incentives","How service proofs affect diffusion and incentives",[725],"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":734,"title":446,"titles":735,"content":736,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fservice-proofs#key-concepts",[725],"Transaction Verification: Confirms that services have been provided as agreed.Graph Integration: Boosts graph value, aligning rewards with verifiable transactions.",{"id":738,"title":199,"titles":739,"content":740,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fproofs\u002Fservice-proofs#next-steps",[725],"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":742,"title":743,"titles":744,"content":745,"level":30,"kind":31,"priority":30},"\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":747,"title":748,"titles":749,"content":750,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#introduction-to-graph-value","Introduction to Graph Value",[743],"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":752,"title":325,"titles":753,"content":754,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#components",[743],"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":756,"title":757,"titles":758,"content":759,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#epoch-update-rule","Epoch update rule",[743],"Graph Value is updated once per epoch: Where: is a smoothing factor are policy weightsnorm denotes protocol-defined normalization and clipping",{"id":761,"title":762,"titles":763,"content":764,"level":72,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#how-is-consumed","How  is consumed",[743,757],"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":766,"title":767,"titles":768,"content":769,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#per-transaction-reward-claim-sketch","Per-transaction reward claim (sketch)",[743],"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":771,"title":90,"titles":772,"content":773,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fgraph-value#related",[743],"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":775,"title":776,"titles":777,"content":778,"level":30,"kind":31,"priority":30},"\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":780,"title":199,"titles":781,"content":782,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity#next-steps",[776],"If you haven’t read the core model yet: Snapshot-Relative DiffusionGraph Commitments & Epoch SnapshotsOptimistic Diffusion Claims Then continue here: Graph ValueSybil Resistance",{"id":784,"title":785,"titles":786,"content":787,"level":30,"kind":31,"priority":30},"\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":789,"title":199,"titles":790,"content":791,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Foverview#next-steps",[785],"Graph ValueSybil Resistance",{"id":793,"title":794,"titles":795,"content":796,"level":30,"kind":31,"priority":30},"\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":798,"title":446,"titles":799,"content":800,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance#key-concepts",[794],"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":802,"title":199,"titles":803,"content":804,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance#next-steps",[794],"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":806,"title":807,"titles":808,"content":809,"level":30,"kind":31,"priority":30},"\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":811,"title":199,"titles":812,"content":813,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust#next-steps",[807],"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":815,"title":816,"titles":817,"content":818,"level":30,"kind":31,"priority":30},"\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":820,"title":199,"titles":821,"content":822,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Foverview#next-steps",[816],"Trust PropagationSampling & SlashingSelf-Policing",{"id":824,"title":825,"titles":826,"content":827,"level":30,"kind":31,"priority":30},"\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":829,"title":446,"titles":830,"content":831,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fpropagation#key-concepts",[825],"Decaying Trust: Trust assumptions weaken over longer paths from the source.Network-Wide Impact: Trust spreads through the transaction graph, enhancing overall reliability.",{"id":833,"title":834,"titles":835,"content":836,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fpropagation#trust-under-snapshot-relative-diffusion","Trust under snapshot-relative diffusion",[825],"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":838,"title":199,"titles":839,"content":840,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fpropagation#next-steps",[825],"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":842,"title":843,"titles":844,"content":845,"level":30,"kind":31,"priority":30},"\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":847,"title":446,"titles":848,"content":849,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#key-concepts",[843],"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":851,"title":852,"titles":853,"content":854,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#canonical-randomness-and-delayed-sampling","Canonical randomness and delayed sampling",[843],"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":856,"title":857,"titles":858,"content":859,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#what-gets-slashed","What gets slashed",[843],"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":861,"title":862,"titles":863,"content":864,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#where-the-details-live","Where the details live",[843],"The precise transcript format and verifier checks are defined by the claim protocol: Optimistic Diffusion ClaimsGraph Commitments & Epoch Snapshots",{"id":866,"title":199,"titles":867,"content":868,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fsampling-slashing#next-steps",[843],"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":870,"title":871,"titles":872,"content":873,"level":30,"kind":31,"priority":30},"\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":875,"title":876,"titles":877,"content":878,"level":23,"kind":31,"priority":30},"\u002Fdocs\u002Ftrust\u002Fself-policing#why-this-emerges-under-optimistic-claims","Why this emerges under optimistic claims",[871],"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":16,"title":17,"titles":880,"content":881,"level":30,"kind":882,"priority":30},[],"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":884,"title":885,"titles":886,"content":887,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#intro-to-pagerank","Intro to PageRank",[17],"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":889,"title":890,"titles":891,"content":892,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#the-basic-idea","The Basic Idea",[17],"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":894,"title":895,"titles":896,"content":897,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#beyond-simple-incentives","Beyond Simple Incentives",[17],"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":899,"title":900,"titles":901,"content":902,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#network-maturity-and-early-adopter-rewards","Network Maturity and Early Adopter Rewards",[17,895],"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":904,"title":905,"titles":906,"content":907,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#sybil-resistance-verifiability-and-security","Sybil Resistance, Verifiability, and Security",[17,895],"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":909,"title":910,"titles":911,"content":912,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#the-island-effect","The Island Effect",[17,895,905],"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":914,"title":915,"titles":916,"content":917,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#propagation-of-trust","Propagation of Trust",[17,895,905],"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":919,"title":920,"titles":921,"content":922,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#a-spectrum-of-verifiability","A Spectrum of Verifiability",[17,895,905],"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":924,"title":925,"titles":926,"content":927,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#sampling-trust","Sampling Trust",[17,895,905],"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":929,"title":930,"titles":931,"content":932,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#difficulty-in-manufacturing-connectivity","Difficulty in Manufacturing Connectivity",[17,895,905],"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":934,"title":935,"titles":936,"content":937,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#generalizing-to-various-networks","Generalizing to Various Networks",[17,895],"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":939,"title":940,"titles":941,"content":942,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#centrality-as-an-implicit-referral-mechanism","Centrality as an Implicit Referral Mechanism",[17,895],"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":944,"title":945,"titles":946,"content":947,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#what-are-the-risks","What are the Risks?",[17],"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":949,"title":950,"titles":951,"content":952,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#potential-for-centralization","Potential for Centralization",[17,945],"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":954,"title":955,"titles":956,"content":957,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#computational-complexity","Computational Complexity",[17,945],"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":959,"title":960,"titles":961,"content":962,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fpage-rank#wrapping-up","Wrapping Up",[17],"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":5,"title":6,"titles":964,"content":965,"level":30,"kind":882,"priority":30},[],"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":967,"title":968,"titles":969,"content":970,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#local-protocol-design-recap","Local Protocol Design Recap",[6],"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":972,"title":930,"titles":973,"content":974,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#difficulty-in-manufacturing-connectivity",[6,968],"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":976,"title":639,"titles":977,"content":978,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#proofs-as-graph-attributes",[6],"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":980,"title":825,"titles":981,"content":982,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#trust-propagation",[6,639],"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":984,"title":615,"titles":985,"content":986,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#identity-proofs-as-node-attributes",[6],"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":988,"title":989,"titles":990,"content":991,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#incorporating-identity-proofs-into-eigenvector-centrality","Incorporating Identity Proofs into Eigenvector Centrality",[6,615],"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":993,"title":994,"titles":995,"content":996,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#service-proofs","Service Proofs",[6],"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":998,"title":999,"titles":1000,"content":1001,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#service-proofs-in-the-adjacency-matrix","Service Proofs in the Adjacency Matrix",[6,994],"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":1003,"title":1004,"titles":1005,"content":1006,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#impact-on-eigenvector-centrality-and-rewards","Impact on Eigenvector Centrality and Rewards",[6,994,999],"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":1008,"title":696,"titles":1009,"content":1010,"level":298,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#proofs-as-probabilities",[6,994,999],"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":1012,"title":1013,"titles":1014,"content":1015,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#random-sampling-and-slashing","Random Sampling and Slashing",[6],"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":1017,"title":1018,"titles":1019,"content":1020,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#inverse-doping-vector","Inverse Doping Vector",[6,1013],"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":1022,"title":1023,"titles":1024,"content":1025,"level":72,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#slashing-neighbors","Slashing Neighbors",[6,1013],"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":1027,"title":1028,"titles":1029,"content":1030,"level":23,"kind":882,"priority":30},"\u002Fblog\u002Fproofs#conclusion","Conclusion",[6],"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":1032,"\u002Fdocs\u002Farchitecture":1032,"\u002Fdocs\u002Farchitecture\u002Foverview":1032,"\u002Fdocs\u002Farchitecture\u002Fperformance-storage":1032,"\u002Fdocs\u002Farchitecture\u002Fsettlement":1032,"\u002Fdocs\u002Farchitecture\u002Fsharding":1032,"\u002Fdocs\u002Farchitecture\u002Fstate-model":1032,"\u002Fdocs\u002Fgames-and-graphs\u002Faudits-and-penalties":1033,"\u002Fdocs\u002Fgames-and-graphs\u002Fdiffusion":1033,"\u002Fdocs\u002Fgames-and-graphs\u002Fexample":1033,"\u002Fdocs\u002Fgames-and-graphs\u002Fgraph":1033,"\u002Fdocs\u002Fgames-and-graphs":1033,"\u002Fdocs\u002Fgames-and-graphs\u002Foptimistic-claims":1033,"\u002Fdocs\u002Fgames-and-graphs\u002Foverview":1033,"\u002Fdocs\u002Fgames-and-graphs\u002Fsnapshot-commitments":1033,"\u002Fdocs\u002Fidentity":1033,"\u002Fdocs":1034,"\u002Fdocs\u002Finsurance\u002Fdispute-resolution":1032,"\u002Fdocs\u002Finsurance":1032,"\u002Fdocs\u002Finsurance\u002Finsurance-amm":1032,"\u002Fdocs\u002Fmarkets\u002Fbootstrapping":1034,"\u002Fdocs\u002Fmarkets":1033,"\u002Fdocs\u002Fmarkets\u002Fregistry":1033,"\u002Fdocs\u002Fmore-resources":1032,"\u002Fdocs\u002Fproofs\u002Fidentity-proofs":1033,"\u002Fdocs\u002Fproofs":1033,"\u002Fdocs\u002Fproofs\u002Flocation-proofs":1033,"\u002Fdocs\u002Fproofs\u002Foverview":1033,"\u002Fdocs\u002Fproofs\u002Fprobabilities":1033,"\u002Fdocs\u002Fproofs\u002Fservice-proofs":1033,"\u002Fdocs\u002Fsecurity\u002Fgraph-value":1033,"\u002Fdocs\u002Fsecurity":1033,"\u002Fdocs\u002Fsecurity\u002Foverview":1033,"\u002Fdocs\u002Fsecurity\u002Fsybil-resistance":1033,"\u002Fdocs\u002Ftrust":1033,"\u002Fdocs\u002Ftrust\u002Foverview":1033,"\u002Fdocs\u002Ftrust\u002Fpropagation":1033,"\u002Fdocs\u002Ftrust\u002Fsampling-slashing":1033,"\u002Fdocs\u002Ftrust\u002Fself-policing":1033,"\u002Fblog\u002Fpage-rank":1035,"\u002Fblog\u002Fproofs":1035},"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",1783724201338]