Pith. sign in

REVIEW 4 major objections 5 minor 48 references

IntraLayer: A Platform of Digital Finance Platforms

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read IntraLayer argues that a single algorithmic fiduciary hub, acting as a gateway between blockchains and financial platforms, can replace many bilateral connections, cut setup and clearing costs, and raise capital efficiency across digital…

desk verdict An honest architecture white paper with a concrete but unsupported cost-savings claim; not yet a research contribution. read the letter →

arxiv 2412.07348 v1 pith:IOEVINT5 submitted 2024-12-10 q-fin.GN

Arman Abgaryan , Utkarsh Sharma This is my paper · ORCID
classification q-fin.GN
keywords IntraLayerdigitalfinanceinteroperabilityhub-and-spokegatewayalgorithmicfiduciarycross-chaintransactionsliquidityfragmentationdecentralizedplatformofplatforms
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes IntraLayer, a decentralised network designed as a hub-and-spoke gateway that lets users on any connected blockchain or financial platform transact with agents on all others through one platform. The central claim is that a single gateway entity acting as an "algorithmic fiduciary" can reduce the cost and complexity of cross-platform finance: setup becomes one connection instead of many, and clearing scales as $2n-1$ interactions rather than $n(n-1)$. The authors model this as a set of optimisation objectives over data connectivity, value transfer, liquidity, setup simplicity, unified clearing, agent population, capital efficiency, and fiscal sustainability, though they state the optimisation problems are not solved in this work. If correct, the framework would consolidate fragmented liquidity, lower switching costs, and broaden access to cross-chain and DeFi-CeFi markets.

What carries the argument

The load-bearing mechanism is the hub-and-spoke gateway: a single entity $G$ (IntraLayer) connecting all $N_a$ agents, so each agent maintains one link instead of $N_a-1$ bilateral links. Around this core, the machinery includes Universal Financial Controllers (UFCs), bespoke smart contracts that encode clearing logic, state aggregation, and automated settlement; IntraLayer Vaults that serve as liquidity pools, asset storage, and access points on each chain; a Dynamic Function Market Maker (DFMM) with an algorithmic accounting asset as the central price-discovery and conversion node; and a cross-chain communication protocol. The cost-savings identity in Objective 5, from $n(n-1)$ to $2n-1$ interactions, is what carries the quantitative claim of reduced cost and complexity.

What would settle it

Measure real cross-platform transaction costs, including setup, clearing, and latency, for a hub-and-spoke gateway serving the same set of blockchains as a set of bilateral bridges. If the gateway's total per-epoch cost exceeds $n(n-1)$ times the average bilateral path cost, or if hub downtime or congestion makes end-to-end latency worse than direct links, the central cost-savings claim is refuted. Since the paper itself does not solve its optimisation problems, a concrete numerical simulation using the stated cost functions would also serve as a test.

Watch

Extended reading notes

Core claim

The paper's central discovery claim is that a single, algorithmically governed gateway, IntraLayer, can serve as a "platform of digital finance platforms": users deposit assets into IntraLayer vaults, codify conditional instructions in Universal Financial Controllers (UFCs), and the network executes transactions across connected blockchains and off-chain systems on their behalf. The hub-and-spoke topology is the source of the efficiency gain: Objective 5 asserts that a unified clearing layer reduces the number of interactions from $n(n-1)$ to $2n-1$, and Objective 4 asserts that a single gateway $G$ allows any agent to reach all others through one connection. The authors frame this as an optimisation programme over incentives, fees, budgets, and network-owned capital, and describe an architecture that includes oracles, a cross-chain communication protocol, a smart contract platform, a dynamic function market maker, vaults, and a cross-chain inventory management system.

Load-bearing premise

The argument depends on the assumption that a single gateway entity can be built, secured, and governed without introducing offsetting costs such as congestion, breakdowns, or bad behaviour at the hub that eat the savings from replacing many bilateral links.

Editorial extensions

If this is right

  • A user could deposit assets on one blockchain and deploy them across many connected platforms through a single interface, without opening bilateral accounts or bridges.
  • The cost of adding a new platform to the network grows roughly linearly with the number of connected agents, making ecosystem growth cheaper at the margin than in a fully bilateral model.
  • Fragmented liquidity pools would be connected through a common conversion node, reducing slippage and unlocking capital that is currently stranded on individual chains.
  • New entrants such as dApps, users, or institutions face one integration instead of many, lowering switching costs and easing lock-in effects.
  • The same gateway could bridge decentralised and centralised finance, with UFCs enforcing rules for regulated off-chain agents.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper treats the gateway's existence as an assumption rather than a result; a natural next step is to test whether a real hub can keep its per-transaction processing, security, and governance costs below the bilateral costs it replaces.
  • The $2n-1$ scaling identity ignores congestion and single-point-of-failure risk; a fair comparison should include expected downtime and throughput limits of the hub.
  • One could extend the framework by modelling the hub's optimal size: at some number of connected platforms, adverse selection, regulatory burden, or validator collusion may offset the savings.
  • If validated, the same hub-and-spoke logic could apply to any fragmented network of financial rails, including CBDC systems and traditional clearing, not just blockchain platforms.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. This manuscript proposes IntraLayer, a proof-of-stake decentralized network intended to act as a hub-and-spoke 'platform of digital finance platforms' and as an algorithmic fiduciary. The paper models the digital finance ecosystem as a directed graph and states eight optimization objectives covering data integration, value integration, liquidity integration, setup simplicity, unified clearing, agent population, path efficiency, and fiscal sustainability. It then describes an architecture comprising an oracle service (DORA), a cross-chain communication protocol, a smart contract platform (Moonshot), a Dynamic Function Market Maker, a liquidity network of IntraLayer Vaults, and a Cross-chain Inventory Management System. The business model includes bootstrapping and matured phases, Proof of Efficient Liquidity, iAssets, and a DeFi-CeFi gateway vision. The central claim is that a single gateway reduces cross-platform transaction costs from n(n−1) bilateral interactions to 2n−1 hub interactions and increases capital efficiency for all connected agents. The paper explicitly states that the optimization problems are not solved and that quantitative simulation is deferred to future work.

Significance. If the cost-reduction and capital-efficiency claims were established, a hub-and-spoke interoperability layer of this kind could substantially reduce fragmentation in digital finance, lower setup costs for cross-chain applications, and enable new forms of algorithmic fiduciary services. The manuscript is transparent about its limitations: Section 7 admits the stated optimization problems are 'not solved in this work,' and footnote 1 says several statements are introduced solely to set up a future framework. The paper does not provide machine-checked proofs, reproducible code, parameter-free derivations, or falsifiable quantitative predictions. Its current value lies in the breadth of the architectural vision and the articulation of design objectives, not in a verified economic result. Because the central economic claims are asserted rather than derived, the significance for a research journal depends on a major revision that either adds rigorous cost analysis or explicitly narrows the claims to a non-quantitative design proposal.

major comments (4)
  1. [Section 3.1, Objective 5] The central cost-savings claim is asserted, not derived. The displayed formula compares n(n−1)(C_DC + C_VC) + n·C_Processing with 2n·(C_DC + C_VC) + C*_Processing(...), while the accompanying text says the system scales to 'only 2n−1 interactions.' The formula uses 2n, not 2n−1, and C*_Processing is an unspecified function with unquantified inputs. More importantly, the comparison omits (i) the per-agent cost of establishing and maintaining a connection to the hub (C_SC is minimized but never bounded below zero), (ii) congestion and throughput costs at the hub that scale with aggregate transaction volume, (iii) security, staking, insurance, and governance costs that grow with value-at-risk concentrated in a single gateway, and (iv) the opportunity cost of capital locked in the hub's liquidity network. Without these terms, no inequality establishing 'substantial cost savings' is available. A concrete test would be to write the hub total cost as 2n(C_DC + C_VC) + C*_Processing + H(n, volume, security) and state the parametric condition under which it is less than the bilateral baseline.
  2. [Section 3, Eqs. (1)-(3), and Section 7] The formal optimization framework is not well-posed. The paper defines P as 'a set of design sets, each of which are presently of unspecified dimensions,' uses R^dx with dx 'a placeholder for any notation of unknown dimension,' and specifies functions f1, f2, CE, SR, and ξ without concrete domains or codomains. The transition equation D_{u+Δu} = g_D(D_{0:u}, κ_{0:u}, ...) uses g_D: R^dx → R^dx on arguments of changing length. Section 7 explicitly states that these optimization problems are 'not solved in this work.' Therefore the abstract's claim that the infrastructure 'optimises transactional efficiency' is not supported by the presented mathematics; the equations are illustrative. Either solve a representative instance or explicitly label these as qualitative goals without claiming optimization.
  3. [Section 4 and Section 6.2.2] The architecture's claimed benefits are grounded in references [1], [2], [13], and [17], which are the authors' own preprints or preprints by close collaborators, and these are treated as established results. For example, Objective 1's data-connectivity cost reduction relies on DORA [13], Objective 3's slippage reduction relies on DFMM [1], Objective 5's processing cost relies on Moonshot [17], and the liquidity bootstrapping claim relies on PoEL [2]. These sources are not peer-reviewed or benchmarked in this manuscript, so the claimed performance rests on self-referential support. The paper should either provide independent verification or simulations, or state explicitly that system performance is an assumption rather than a demonstrated result.
  4. [Section 3.1, Objective 4, and Section 5] The hub-and-spoke assumption is load-bearing. Objective 4 begins with 'if a single gateway entity (G) exists' and concludes that IntraLayer 'would minimise setup costs,' but the paper does not analyze whether such a gateway can be built, secured, and governed without offsetting costs. Congestion at the hub, single-point-of-failure and slashing risk, governance of the algorithmic fiduciary, and adverse selection in the hub's intermediation are not discussed. Since the central economic claim is net cost reduction, these omissions are not tertiary; they must be addressed or the claim must be narrowed to a conditional statement about an idealized gateway.
minor comments (5)
  1. [Section 3.1, Eq. (3)] The notation f2(Ψ_e(...) = Σ..., d_e(...) = Σ..., F_DC^e) is not well-formed; the equality signs inside the function arguments should be replaced by separate argument definitions, or the equation should be rewritten to clarify the composition of f2.
  2. [Section 3.1, Eq. (5) and Eq. (7)] The pair-level cost efficiency CE is defined as a ratio of nominal value to cost, while the aggregate CE functions in Eqs. (6) and (7) are volume-weighted averages; the relationship between these two definitions should be stated explicitly to avoid suggesting that aggregate efficiency is a simple sum.
  3. [Section 5.1.1, Eq. (19)] The collateralisation rate formula uses H^{a1k}_{A1g t}·p_{A1g t} + L^{a3k}_t over L_t. At inception L_t = L^{a3k}_t, but if the lessee earns fees or incurs losses, L^{a3k}_t changes; the formula should state how such changes affect the collateral ratio and whether rebalancing or liquidation is triggered.
  4. [Section 5.1.1, PnL formula] The leveraged PnL formula is presented without defining C_{Adc_t} and without clarifying whether it is gross or net of borrowing costs and collateral; please add definitions and a derivation so the formula can be checked.
  5. [Appendix A] The notation table lists κ both as a proportionality constant (N_p = κ·N_a^x) and as a set of state variables; these uses should be distinguished, and the table should include the domain of Θ, which appears in the core objective but is only described in prose.

Circularity Check

2 steps flagged · score 5.0 of 10

Core liquidity and bootstrapping mechanisms are imported from the authors' own preprints (DFMM, PoEL), making key efficiency claims self-referential; Objective 5's cost-savings identity is an assumption, not a derivation.

  1. self citation load bearing [Section 6.1.1 (Bootstrapping Phase) and Section 6.2.2 (Proof of Efficient Liquidity); references [1], [2]]
    "In the bootstrapping phase, IntraLayer relies on the Proof of Efficient Liquidity (PoEL) protocol [2] to attract and retain staked capital and liquidity. ... Whilst the specifics of the PoEL protocol are beyond this paper’s scope, it is essential to note that ζ is determined using demand for liquidity across various pools at each epoch..."

    Reference [2] is by Abgaryan, Sharma, and Tobkin, i.e., the present authors. The paper makes fiscal sustainability and liquidity bootstrapping depend on PoEL, yet explicitly defers PoEL's mechanism and properties to that prior preprint. No proof, simulation, or external benchmark is provided here, so the load-bearing premise that PoEL bootstraps capital efficiently is supported only by the authors' own earlier work. This is a self-citation chain rather than an independently verified result.

  2. self citation load bearing [Section 4, item 5 (Liquidity Network); Section 6.2.1 (Towards Network-owned Liquidity); reference [1]]
    "The liquidity network’s design, resembling a star graph T(V′, E′) ⊆ (N, N · N − 1), positions the DFMM [1] (including its intermediating accounting asset), as the central node."

    Reference [1] is Abgaryan and Sharma, the present authors. The DFMM is the mechanism claimed to reduce execution costs, minimize slippage, and rebalance inventory, and this underpins the hub-and-spoke value-conversion efficiency of the entire network. These properties are not derived or demonstrated in the present paper; they are imported from the authors' own preprint. Since the central value-conversion and capital-efficiency benefits rest on DFMM's unproven properties, the cited support is self-referential rather than independently established.

full rationale

This is a design/vision paper that explicitly does not solve its optimization problems, so there is no fitted parameter being renamed as a prediction. The clearest circularity is the reliance of the core infrastructure on the authors' own prior preprints: the liquidity network is defined around 'the DFMM [1]' and the bootstrapping phase 'relies on the Proof of Efficient Liquidity (PoEL) protocol [2]'. Both are by the present authors, and their advertised efficiency properties are not restated, proved, or benchmarked here; PoEL's specifics are explicitly 'beyond this paper’s scope'. The central economic-efficiency and capital-efficiency claims therefore reduce, at the points where they depend on these mechanisms, to self-citation rather than to demonstrated derivation. Objective 5's cost-savings formula is an algebraic definition of savings (old cost minus new cost) and its 'substantial' conclusion is an unproved assumption; that is a correctness gap, not circularity, because no quantity is fitted and then renamed. No numerical predictions are made, so no fitted-input-renamed-as-prediction pattern is present. The self-citations are load-bearing for two mechanisms, but the paper also contains substantial independent architectural content (UFCs, vaults, CIMS, iAssets), so the work is only partially self-referential rather than wholly forced.

Assumptions & free parameters 6 free parameters · 5 assumptions · 4 invented entities

The paper's central framework rests on economic and architectural assumptions rather than mathematical axioms. It introduces no solved equations, so most variables are placeholders; the few scalar parameters (α, β_u, κ, x, ϖ, ρ) are chosen by hand and not calibrated. The architecture's efficacy relies on self-cited prior papers for DORA, Moonshot, DFMM, and PoEL, which provide no independent evidence here.

free parameters (6)
  • α
    Weighting factor between system revenue maximization and resource management in Eq. (18); no calibration or derivation.
  • β_u
    'Some weight' in the master objective (Section 3), left unspecified.
  • κ
    Proportionality constant in network path model Np = κ·N_a^x (Sec 6.1.1), chosen by hand.
  • x
    Power-law exponent in Np = κ·N_a^x, chosen by hand to reflect Metcalfe or Zipf behavior.
  • ϖ
    Fraction of revenue reserved for network-owned liquidity (Sec 6.2.1), chosen by hand.
  • ρ (collateralisation rate)
    Collateralization rate in CIMS leasing (Eq. 19), described as adjustable but with no calibration.
assumptions (5)
  • domain assumption A single gateway entity G exists such that all agents can interact through it in a hub-and-spoke topology.
    Objective 4 states this existence condition; the entire setup-cost reduction depends on it.
  • domain assumption Transaction costs decompose into five independent components: data connectivity, value connectivity, value conversion, clearing, and setup complexity.
    Section 3.1 presents the decomposition for C^{a,b}_e; no evidence is given that these components are separable or exhaustive.
  • domain assumption Network value grows according to Metcalfe's law or Zipf's law.
    Objective 6 cites [46] and [3] and uses this growth assumption to justify agent acquisition objectives.
  • ad hoc to paper The optimization problems are well-posed despite unspecified dimensions R^dx and functions f1, f2, CE, and others.
    Placeholders like dx and 'unspecified dimensions' mean the objectives are not fully defined; the paper still treats them as solvable.
  • domain assumption Rational economic agents respond predictably to incentives such that staking and collateral guarantees secure data and value transfer.
    Sections 3.1 and 5.1.1 rely on incentive-based security without modeling adversarial behavior.
invented entities (4)
  • Universal Financial Controller (UFC)
    purpose: Programmable smart contract on IntraLayer's platform that encodes clearing, settlement, and routing logic for multi-chain transactions.
    Defined in Section 4, Definition 2; no implementation or test is provided.
  • IntraLayer Vault
    purpose: Smart contract system acting as liquidity pool, asset storage, and access point on each connected blockchain.
    Definition 3; component of the proposed architecture with no code or deployment evidence.
  • iAsset and interim Liquidity Provider (iLP)
    purpose: Receipt token representing ownership in vault deposits, used to route rewards and enable on-platform management.
    Definitions 4 and 5; proposed mechanism with no independent evidence.
  • Algorithmic fiduciary role
    purpose: Position of IntraLayer as an automated executor of user instructions across chains, analogous to a bank or prime broker.
    Described in Section 5; no legal or technical implementation exists.

how reviews work

0 comments
Cite this review

Pith. "Pith review of IntraLayer: A Platform of Digital Finance Platforms." pith.science (2026). https://pith.science/paper/IOEVINT5

@misc{pith2026241207348,
  author       = {Pith},
  title        = {Pith review of: IntraLayer: A Platform of Digital Finance Platforms},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IOEVINT5}},
  note         = {Machine review of arXiv:2412.07348}
}
read the original abstract

IntraLayer presents an innovative framework that enables comprehensive interconnectivity in digital finance. The proposed framework comprises a core underlying infrastructure and an overarching strategy to create a pioneering "platform of platforms", serving as an algorithmic fiduciary. By design, this infrastructure optimises transactional efficiency for a broad spectrum of agents, thereby facilitating the sustainable creation of intrinsic economic value. Complementing the infrastructure, our forthcoming work will present an overarching adaptive fiscal policy to optimise IntraLayer's resources, striking a balance between sustaining the network and enhancing the proposal herein.

Figures

Figures reproduced from arXiv: 2412.07348 by the authors.

Figure 1
Figure 1. IntraLayer building blocks. To further elucidate the proposed network’s functionality, we describe its infrastructural components, which collectively enable cost-optimised transactional paths between agents. 1. Oracle Service (OS): IntraLayer’s oracle service, DORA [13], establishes secure, reliable, and low-latency connections between blockchains and external systems. Its design, represented by POS ∈ Rη and POS ⊂ P… view at source ↗
Figure 2
Figure 2. Schematic showcasing operational flow in IntraLayer. [PITH_FULL_IMAGE:figures/full_fig_p022_2.png] view at source ↗
Figure 5
Figure 5. Interm LP Bridging 4The exact mechanism used to ensure the fungibility of different iAssets by guaranteeing that a slashing event due to validator misbehaviour results in all iAssets of the same type being slashed will be elaborated in the notes that follow. 34 [PITH_FULL_IMAGE:figures/full_fig_p034_5.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6: Integrating Off-chain Fiduciary Services. [PITH_FULL_IMAGE:figures/full_fig_p040_6.png]
Figure 7
Figure 7. Figure 7: IntraLayer Example: Secure an ecosystem of services interoperable [PITH_FULL_IMAGE:figures/full_fig_p042_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 43 canonical work pages

  1. [1]

    Dynamic function market maker

    Arman Abgaryan and Utkarsh Sharma. Dynamic function market maker. arXiv preprint arXiv:2307.13624 , 2023

    arXiv 2023

  2. [2]

    Proof of efficient liquidity: A staking mechanism for capital efficient liquidity

    Arman Abgaryan, Utkarsh Sharma, and Joshua Tobkin. Proof of efficient liquidity: A staking mechanism for capital efficient liquidity. arXiv preprint arXiv:2401.04521, 2024

    arXiv 2024

  3. [13]

    Dora: Distributed oracle agreement with simple majority

    Prasanth Chakka, Saurabh Joshi, Aniket Kate, Joshua Tobkin, and David Yang. Dora: Distributed oracle agreement with simple majority. arXiv preprint arXiv:2305.03903, 2023

    arXiv 2023

  4. [17]

    Moonshot: Optimising chain-based rotating leader bft via optimistic proposals

    Isaac Doidge, Raghavendra Ramesh, Nibesh Shrestha, and Joshua Tobkin. Moonshot: Optimising chain-based rotating leader bft via optimistic proposals. arXiv preprint arXiv:2401.01791 , 2024

    arXiv 2024

  5. [3]

    Zipf’s law and the internet

    Lada A Adamic and Bernardo A Huberman. Zipf’s law and the internet. Glottometrics, 3(1):143–150, 2002

    work page 2002

  6. [4]

    Allen, S

    S. Allen, S. Capkun, I. Eyal, G. Fanti, B. Ford, J. Grimmelmann, A. Juels, K. Kostiainen, S. Meiklejohn, A. Miller, E. Prasad, K. W¨ ust, and F. Zhang. Design choices for central bank digital currency: Policy and technical considerations. NBER Working Paper 27634 , 2020

    work page 2020

  7. [5]

    Almashaqbeh and R

    G. Almashaqbeh and R. Solomon. Sok: Privacy-preserving computing in the blockchain era. https://eprint.iacr.org/2021/727.pdf, 2021

    work page 2021

  8. [6]

    P. G. Arabehety, G. Chen, W. Cook, and C. McKay. Digital finance interoperability & financial inclusion. Cgap report, CGAP, 2016

    work page 2016

Show all 48 references
  1. [7]

    https://www.arweave.org/

    Arweave. https://www.arweave.org/. [Online; accessed 16-February- 2024]

    2024

  2. [8]

    Rise of the central bank digital currencies: Drivers, approaches and technologies

    Raphael Auer, Giulio Cornelli, and Jon Frost. Rise of the central bank digital currencies: Drivers, approaches and technologies. SSRN Electronic Journal, 2020

    2020

  3. [9]

    Bartoletti, J

    M. Bartoletti, J. H. y. Chiang, and A. Lluch-Lafuente. Sok: Lending pools in decentralized finance. arXiv preprint arXiv:2012.13230 , 2020

    2012 arXiv

  4. [10]

    Belchior, A

    R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia. A survey on blockchain interoperability: Past, present, and future trends. ACM Computing Surveys (CSUR) , 54:1–41, 2021

    2021

  5. [11]

    https://bitcoin.org/

    Bitcoin. https://bitcoin.org/. [Online; accessed 16-February-2024]

    2024

  6. [12]

    https://cardano.org/

    Cardano. https://cardano.org/. [Online; accessed 16-February-2024]

    2024

  7. [14]

    https://cosmos.network/

    Cosmos. https://cosmos.network/. [Online; accessed 16-February-2024]

    2024

  8. [15]

    David and Julie Ann Bunn

    Paul A. David and Julie Ann Bunn. Gateway technologies and the evolutionary dynamics of network industries. Technical report, Center for Economic Policy Research, Stanford University, 1987. 43 DRAFT

    1987

  9. [16]

    David and Julie Ann Bunn

    Paul A. David and Julie Ann Bunn. The economics of gateway technologies and network evolution: Lessons from electrical supply history. Information Economics and Policy , 3:165–202, 1988

    1988

  10. [18]

    Presentation and publication: Loss and slippage in networks of automated market makers

    Daniel Engel and Maurice Herlihy. Presentation and publication: Loss and slippage in networks of automated market makers. arXiv preprint arXiv:2110.09872, 2021

    2021 arXiv

  11. [19]

    https://ethereum.org/

    Ethereum. https://ethereum.org/. [Online; accessed 16-February-2024]

    2024

  12. [20]

    Farrell and G

    J. Farrell and G. Saloner. Converters, compatibility, and the control of interfaces. Journal of Industrial Economics , 40:9–35, 1992

    1992

  13. [21]

    Fern´ andez-Villaverde, D

    J. Fern´ andez-Villaverde, D. Sanches, L. Schilling, and H. Uhlig. Central bank digital currency: Central banking for all? Review of Economic Dynamics, pages 225–242, 2021

    2021

  14. [22]

    https://filecoin.io/

    Filecoin. https://filecoin.io/. [Online; accessed 16-February-2024]

    2024

  15. [23]

    An interoperability architecture for blockchain gateways

    Thomas Hardjono, Martin Hargreaves, and Ned Smith. An interoperability architecture for blockchain gateways. https://datatracker.ietf.org/doc/draft-hardjono-blockchain-interop-arch/, 2020

    2020

  16. [24]

    Jung and D

    H. Jung and D. Jeong. Blockchain implementation method for interoperability between cbdcs. Future Internet, 13, 2021

    2021

  17. [25]

    Kades and F

    M. Kades and F. Scott Morton. Interoperability as a competition remedy for digital networks. Report, Washington Center for Economic Growth, Washington, DC , 2020

    2020

  18. [26]

    Optimal clearing arrangements for financial trades

    Thorsten Koeppl, Cyril Monnet, and Ted Temzelides. Optimal clearing arrangements for financial trades. Journal of Financial Economics , 103:189–203, 2012

    2012

  19. [27]

    Ampleforth: A new synthetic commodity

    Evan Kuo, Brandon Iles, and Manny Rincon Cruz. Ampleforth: A new synthetic commodity. Ampleforth White Paper , 2019

    2019

  20. [28]

    https://litecoin.org/

    Litecoin. https://litecoin.org/. [Online; accessed 16-February-2024]

    2024

  21. [29]

    Longo, A

    E. Longo, A. E. C. Redondi, M. Cesana, and P. Manzoni. Border: A benchmarking framework for distributed mqtt brokers. IEEE Internet of Things, 9:17728–17740, 2022

    2022

  22. [30]

    mix and match

    C. Matutes and P. Regibeau. “mix and match”: Product compatibility without network externalities. The RAND Journal of Economics , 19:221– 234, 1988. 44 DRAFT

    1988

  23. [31]

    F. Menge. Enterprise service bus. Free and open source software conference, 2, 2007

    2007

  24. [32]

    V. Mohan. Automated market makers and decentralized exchanges: A defi primer. Financial Innovation , 2:20, 2022

    2022

  25. [33]

    Mohanty, D

    D. Mohanty, D. Anand, H. M. Aljahdali, and S. G. Villar. Blockchain interoperability: Towards a sustainable payment system. Sustainability, 14:913, 2022

    2022

  26. [34]

    https://www.getmonero.org/

    Monero. https://www.getmonero.org/. [Online; accessed 16-February- 2024]

    2024

  27. [35]

    https://scrt.network/

    Secret Network. https://scrt.network/. [Online; accessed 16-February- 2024]

    2024

  28. [36]

    https://ont.io/

    Ontology. https://ont.io/. [Online; accessed 16-February-2024]

    2024

  29. [37]

    https://polkadot.network/

    Polkadot. https://polkadot.network/. [Online; accessed16-February- 2024]

    2024

  30. [38]

    https://solana.com/

    Solana. https://solana.com/. [Online; accessed 16-February-2024]

    2024

  31. [39]

    https://sovrin.org/

    Sovrin. https://sovrin.org/. [Online; accessed 16-February-2024]

    2024

  32. [40]

    https://www.stellar.org/

    Stellar. https://www.stellar.org/. [Online; accessed 16-February-2024]

    2024

  33. [41]

    https://www.storj.io/

    Storj. https://www.storj.io/. [Online; accessed 16-February-2024]

    2024

  34. [42]

    https://www.wanchain.org/

    Wanchain. https://www.wanchain.org/. [Online; accessed 16-February- 2024]

    2024

  35. [43]

    Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J

    Sam M. Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J. Knottenbelt. Sok: Decentralised finance (defi). arXiv preprint arXiv:2101.08778 , 2021

    2021 arXiv

  36. [44]

    J. Xu, K. Paruch, S. Cousaert, and Y. Feng. Sok: Decentralized exchanges (dex) with automated market maker (amm) protocols. ACM Computing Surveys, 55:1–50, 2023

    2023

  37. [45]

    Xu and N

    J. Xu and N. Vadgama. From banks to defi: The evolution of the lending market. Enabling the Internet of Value: How Blockchain Connects Global Businesses, pages 53–66, 2022

    2022

  38. [46]

    Moore’s law, metcalfe’s law, and the theory of optimal interoperability

    Christopher S Yoo. Moore’s law, metcalfe’s law, and the theory of optimal interoperability. Colorado Technology Law Journal, 14:16–7, 2015

    2015

  39. [47]

    Knottenbelt

    Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias, and William J. Knottenbelt. Sok: Communication across distributed ledgers. Technical Report, 2019. https://eprint.iacr.org/2019/1128.pdf

    2019

  40. [48]

    https://z.cash/

    Zcash. https://z.cash/. [Online; accessed 16-February-2024]. 45

    2024

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.