· 運營商可以提供類似的功能，帶來極好的使用者體驗。
2.鏈下 ⟷ 鏈上
如上所述，顯而易見的解決方案是再次遵循標準步驟，但現在的順序有所變化：
· 從交易所提現到鏈上錢包
· 與鏈上 dapp進行互動
· 充值回交易所（如果適用的話）
同樣，運營商最好扮演中間人的角色。如果使用者想透過從其鏈下錢包傳送1個ETH與dapp進行互動，則運營商將提前使用運營商鏈上錢包的1個ETH，並在鏈上儲存此證明（以確保該過程可以無需信任地發生）。然後，運營商可以使用此證明，將1個ETH從使用者的鏈下錢包轉移到運營商的鏈下錢包（這稱為有條件轉賬，我們將在協議的更高版本中實現）。對運營商而言，這也是一個零和遊戲。
3.結論
透過依靠運營商，我們無需信任就可以縮小鏈上和鏈下之間的距離，以實現任何型別的互動。該解決方案的唯一缺點是，運營商必須在其鏈上錢包中儲存足夠資產，以便可以在鏈上進行管理。這不是資本使用高效的方法，除非這些服務允許增加的交易量超過其機會成本。此外，資產可以相當快速（5至10分鐘）在運營商的鏈上和鏈下錢包之間轉移，因此運營商的資產總額可以相對較低來支援這些操作。請注意，此類解決方案已經由Gnosis和Starkware提出，這裡只是舉幾個例子說明。
這些解決方案的設計受到所有第2層解決方案中嚴格限制的約束。對於這樣的方案， ZK rollup實際上是最好的第2層解決方案，因為所需時間很短（一旦在鏈上提交了證明，我們就可以確保完成工作）。例如，在optimistic rollup, 最終時間要長得多，這極大地增加了運營商提供此類功能所需的資產。
ZKP以更快的時間進行驗證，但出於實際原因，仍然存在間接狀態更新的主要問題。這個問題的另一種解決方案是每個人都建立在單個第2層解決方案上。隨著遞迴SNARK的發展進步，這應該是可能的。如果dapp，協議和其他版本都進入了第2層，在孤立的解決方案中，情況不會變得容易，將會更加困難。
4.示例
除了普通使用者以外，還可以在路印協議生態中找到其他例子，例如DEX聚合器和保證金/借貸協議。這兩種情況可以提供兩種方式：從路印協議構建的交易所獲取或者提供流動性。
DEX聚合器在過去的6個月裡很受歡迎，比如1inch, DEX.AG, Paraswap, 和 Totle 這樣的去中心化應用程式，他們透過聚合流動性給交易者提供最優惠的價格。目前，他們聚集了鏈上應用（Uniswap，Kyber），也希望能夠從第2層（如路印協議構建的DEX）獲得流動性。[特別是如果第二層效能支援價差，將獲取最有競爭力的價格]。路印協議構建的DEX也希望聚集鏈上應用的流動性，以增強其訂單簿的流動性。
保證金/借貸協議是開放式金融的重要組成部分，它允許貸款人賺取利息，而借款人獲得信貸（尤其是保證金交易）。與使用DEX聚合器的情況類似，協議（例如bZx）希望使用者在開倉時，從路印協議流動性中找到匹配的訂單。同樣地，路印協議也希望其使用者可以無需信任地訪問其中一些協議。對於後者，一個很好的解決方案是，協議的輸出是token本身，例如“position token”，由於它只是ERC20 token，因此可以在路印協議構建的交易所上線。
另外，我們還可以特定為路印協議構建的交易所的使用者批次實現可組合性。例如，使用者鎖倉在交易協議中的資產可以尋找DeFi獲利機會；可以設定DAO來管理儲存的資產，並投票決定將這些資產部署在借貸協議中，或者用於其他網路的質押等。確實，我們會實現路印協議DAO，除了DeFi決策外，還將管理某些協議引數。
