deBridge Korea

여행을 갈 때 공항에 도착하는 것이 목적은 아니다. ㅤ 호텔로 이동하고, 짐을 풀고, 예약한 식당까지 가야 비로소 하고 싶었던 일이 시작된다. ㅤ 그런데 누군가 나를 낯선 나라의 공항에 내려놓고 “이동 완료!”라고 말한다면 조금 억울하다. ㅤ ㅋㅋ 나는 여행을 하러 왔지 입국장 바닥을 구경하러 온 것이 아니다. ㅤ Cross-Chain에서도 비슷한 일이 생긴다. ㅤ 사용자는 Token을 다른 Chain으로 옮기는 것 자체가 최종 목적이 아닌 경우가 많다. ㅤ Solana의 자산으로 Base의 Application을 사용하고 싶거나, Ethereum의 Liquidity를 다른 Chain의 Yield Strategy에 배치하고 싶다. ㅤ 하지만 기존 Bridge를 이용하면 자산이 목적지 Chain에 도착한 뒤에도 해야 할 일이 계속 남는다. ㅤ 필요한 Token으로 다시 Swap하고, Gas를 준비하고, Application을 찾아 Wallet을 연결하며, Contract Approval과 Deposit을 따로 실행한다. ㅤ Bridge는 끝났지만 사용자의 목적은 아직 출발도 못 한 셈이다. ㅤ 내가 @debridge를 볼 때 가장 중요하게 보는 변화가 이것이다. ㅤ deBridge는 자신을 단순한 Bridge가 아니라 Cross-Chain Execution Layer로 설명한다. ㅤ 사용자가 어느 길로 이동할지를 직접 정하는 대신 원하는 결과를 먼저 지정하는 구조다. ㅤ 예를 들어 “Solana의 SOL을 Base의 USDC로 바꿔줘”라고 요청하면 deBridge는 Source Chain의 자산과 Destination Chain의 결과를 연결한다. ㅤ 여기서 핵심은 deBridge Liquidity Network, DLN이다. ㅤ 사용자가 Order를 생성하면 Source Chain의 Token은 Smart Contract로 들어간다. ㅤ 경쟁하는 Solver가 Destination Chain에서 요청된 Token을 먼저 전달하고, 완료된 Order에 따라 Source Chain의 자산을 가져간다. ㅤ 사용자의 자산이 거대한 Liquidity Pool 안에서 한참 기다리는 방식이 아니다. ㅤ 각 Order마다 필요한 Liquidity가 On-Demand로 제공된다. ㅤ deBridge는 이를 0-TVL Architecture라고 설명한다. ㅤ 공유 Liquidity Pool에 많은 자산을 미리 쌓아두지 않고 Smart Contract가 자산을 장기간 보관하는 금고가 아니라 Order가 지나가는 Pipe 역할을 한다. ㅤ 하나의 큰 Pool이 공격받아 여러 사용자의 자산이 동시에 위험해지는 구조를 줄이려는 것이다. ㅤ Solver는 더 좋은 결과를 제공하기 위해 경쟁하고, 사용자는 제시된 Rate와 Destination Chain에서 받을 Amount를 확인한다. ㅤ 공식 문서에 따르면 Quoted Rate는 보장되며, Order가 완료되지 않으면 사용자는 취소하고 자산과 Fee를 회수할 수 있다. ㅤ 하지만 내가 더 흥미롭게 보는 기능은 Hooks다. ㅤ 자산을 다른 Chain으로 이동시킨 뒤 별도의 Contract Call을 자동으로 이어갈 수 있다. ㅤ Swap 이후 Deposit을 실행하거나, 특정 Application에 자산을 배치하는 것처럼 여러 단계를 하나의 Cross-Chain Workflow로 묶을 수 있다. ㅤ 사용자는 Bridge를 이용하고 싶은 것이 아니다. ㅤ 다른 Chain의 Opportunity를 사용하고 싶은 것이다. ㅤ deBridge의 홈페이지 문구인 “Trade What’s Next”도 이 관점에서 읽힌다. ㅤ 지금 가진 자산이 어느 Chain에 있는지보다 다음에 무엇을 하고 싶은지가 먼저다. ㅤ deBridge는 25개 이상의 Blockchain에서 200억 달러 이상의 Cross-Chain Volume을 처리했다고 밝히고 있다. ㅤ 공식 사이트에는 Median Settlement Time 약 1.96초, 출시 이후 100% Uptime과 26회 이상의 Audit도 표시돼 있다. ㅤ 나는 이 숫자들이 속도와 운영 기록을 보여주지만 사용자가 느끼는 진짜 성능은 Chain을 몇 초 만에 건넜는가만으로 결정되지 않는다고 생각한다. ㅤ 도착한 뒤에 다시 무엇을 해야 하는지가 여전히 많이 남아 있다면 사용 경험은 빠르다고 느껴지지 않는다. ㅤ 물론 Intent와 Solver 구조에도 확인할 부분은 있다. ㅤ Solver Competition이 충분한지, 큰 Order에서도 좋은 Rate가 유지되는지, 지원하지 않는 Chain과 Token은 무엇인지, Destination Contract Call이 실패하면 어떤 상태로 돌아오는지 살펴봐야 한다. ㅤ 한 번의 Click으로 많은 일이 실행될수록 사용자는 최종 결과와 실패 조건을 더 정확히 이해해야 한다. ㅤ 편리함은 단계를 없애지만 위험까지 없애주는 마법은 아니니까. ㅋㅋ ㅤ 💡 HD Insight — Outcome Distance ㅤ 나는 Cross-Chain UX를 평가할 때 Bridge Speed보다 Outcome Distance가 중요하다고 생각한다. ㅤ 자산이 Source Chain을 떠난 순간부터 사용자가 원했던 최종 결과에 도달할 때까지 몇 번의 행동이 더 필요한지를 뜻한다. ㅤ Token이 2초 만에 Destination Chain에 도착해도 다시 Swap하고, Gas를 구하고, Wallet을 연결하고, Approve와 Deposit을 해야 한다면 Outcome Distance는 여전히 길다. ㅤ 반대로 Settlement가 조금 더 걸리더라도 최종 Token을 받고, 원하는 Application의 Contract Call까지 완료된다면 사용자가 느끼는 거리는 짧아질 수 있다. ㅤ 이 기준으로 보면 좋은 Bridge는 Chain 사이의 거리를 줄이는 도구가 아니다. ㅤ 사용자의 의도와 결과 사이의 거리를 줄이는 도구다. ㅤ 나는 앞으로 Wallet과 dApp이 “어느 Chain으로 보낼까요?”라고 묻는 대신 “도착해서 무엇을 할까요?”라고 묻게 될 것이라 생각한다. ㅤ 사용자는 Route를 설계하지 않는다. ㅤ Yield를 얻고 싶고, NFT를 구매하고 싶으며, Game을 시작하거나 다른 Market에서 거래하고 싶을 뿐이다. ㅤ Chain은 그 목적을 실행하는 과정에 숨어야 한다. ㅤ 그때 Bridge의 성공 지표도 달라질 수 있다. ㅤ 얼마나 많은 자산을 옮겼는가? ㅤ 얼마나 빠르게 옮겼는가? ㅤ 그리고 더 중요하게는 사용자의 다음 행동을 얼마나 많이 완료해 주었는가? ㅤ 나는 deBridge가 단순한 자산 이동량을 넘어 Outcome Distance를 얼마나 줄일 수 있는지를 보고 싶다. ㅤ 공항에 빨리 도착한 것도 좋지만 결국 여행은 공항 밖에서 시작된다. ㅤ Crypto도 다른 Chain에 도착했다는 알림보다 내가 원했던 일이 이미 끝났다는 알림이 훨씬 반가울 것 같다. ㅋㅋ ㅤ @debridge @AlexSmirnov @deBridge_KR @Yurieiswinning @gal_stern @ayushdegen ㅤ #deBridge #DLN #CrossChain #Intent #ChainAbstraction #ZeroTVL #SolverNetwork #DeFi #CrossChainExecution #OutcomeDistance #Web3

서울에 있는 친구가 부산의 가족에게 급하게 현금을 보내야 한다. 서울에서 지폐를 봉투에 넣어 부산까지 직접 배달할 수도 있다. 하지만 더 빠른 방법이 있다. 서울의 친구에게 돈을 받고, 부산에 있는 다른 사람이 가족에게 먼저 현금을 건네는 것이다. 실물 지폐는 도시를 건너지 않았지만 가치는 목적지에 도착했다. ㅋㅋ 급한 사람에게 중요한 것은 내 지폐의 여행경로가 아니라 돈이 도착하는 시간이다. 기존 Bridge를 생각하면 한 Chain의 자산이 다리를 건너 다른 Chain으로 이동하는 모습이 떠오른다. 하지만 Blockchain은 서로 다른 Ledger를 사용하기 때문에 Token이 물리적으로 Network 사이를 이동하는 것은 아니다. Source Chain에서 자산을 Lock하고, Destination Chain에서 Wrapped Asset을 발행하거나 미리 준비된 Liquidity Pool에서 자산을 지급하는 방식이 많다. 이 구조에서는 Bridge Pool에 많은 Liquidity가 계속 잠겨 있어야 한다. 지원하는 Chain과 Token이 늘어날수록 Pool도 여러 곳으로 나뉜다. Liquidity가 부족하면 큰 거래가 어렵고, Pool에 자산이 많이 모이면 공격자가 노릴 만한 금고도 커질 수 있다. 내가 @debridge를 볼 때 흥미롭게 생각하는 부분은 Cross-chain Delivery의 방식을 바꿨다는 것이다. deBridge의 DLN, deBridge Liquidity Network는 Intent-based Order와 경쟁 Solver를 이용하는 0-TVL Cross-chain Execution 구조다. 사용자가 Source Chain에서 원하는 조건의 주문을 만들면 입력 자산은 Smart Contract에 Lock된다. Solver들은 주문을 확인한 뒤 Destination Chain에 자신이 보유한 Liquidity를 사용해 사용자가 요청한 자산을 직접 지급한다. 가장 먼저 조건을 충족한 Solver가 Destination Contract에 주문을 Fulfill하고, 그 상태가 확인되면 Cross-chain Message가 돌아가 Source Chain에 잠긴 자산을 Solver에게 Unlock한다. 중간에 거대한 Liquidity Pool을 유지하지 않고 각 Solver의 분산된 Inventory가 필요한 순간에 목적지 Liquidity가 되는 방식이다. 여기서 재미있는 점은 사용자가 자산이 실제로 넘어오기를 기다리는 것이 아니라 목적지에서 누가 먼저 지급할지를 경쟁시킨다는 것이다. Solver는 속도와 수익성을 계산한다. 어떤 주문을 처리할지, 몇 번의 Block Confirmation을 기다릴지, 어느 Chain에 Liquidity를 배치할지 스스로 판단한다. 사용자는 Source Chain에서 한 번 서명하고 Destination Wallet로 자산을 받는다. 공식 문서에서는 Cross-chain Swap이 일반적으로 몇 초 안에 Fulfill되고, deBridge가 사용자의 자산을 Custody하지 않는다고 설명한다. DLN API는 Quote와 Order 생성, 거래 Lifecycle 관리를 제공하고, Limit Order와 Slippage·MEV Protection을 지원한다. Wallet이나 DEX, Portfolio Application은 복잡한 RPC와 Smart Contract Logic을 직접 만들지 않고도 Cross-chain Swap을 서비스 안에 넣을 수 있다. Hooks를 활용하면 새로운 Chain에서 Token을 구매한 뒤 Native Gas를 채우고, 특정 Protocol에 Deposit하는 과정까지 하나의 Cross-chain Action으로 연결할 수 있다. 최근에는 MCP Server를 통해 AI Agent가 여러 Chain의 자산을 모으고, 한 Token으로 Swap한 다음, 원하는 Strategy에 넣는 Multi-step Intent도 구성할 수 있도록 확장하고 있다. 나는 이 변화가 Bridge를 하나의 장소에서 하나의 결과로 바꾼다고 생각한다. 사용자는 Bridge를 이용하고 싶은 것이 아니다. 다른 Chain의 기회를 잡고 싶은 것이다. 어떤 Token을 Lock하고, 누가 Destination Liquidity를 제공하며, 언제 Message가 돌아가는지는 목적을 위한 내부 과정에 가깝다. 물론 Solver 구조에도 확인할 부분은 있다. 경쟁이 충분하지 않으면 Quote가 좋지 않을 수 있고, 특정 Chain에 Solver Liquidity가 부족하면 큰 주문의 체결 조건이 불리해질 수 있다. Source와 Destination Chain의 Finality, Smart Contract와 Validator Network의 Risk도 남아 있다. 0-TVL은 위험을 없애는 주문이 아니라 항상 한곳에 쌓아두는 Liquidity Risk를 줄이는 설계다. ㅋㅋ 수영장을 없앴다고 물과 관련된 모든 사고가 사라지는 것은 아니다. 💡 HD Insight — Liquidity Relay 나는 Cross-chain의 속도가 Asset Transfer Speed만으로 결정되지 않는다고 생각한다. 더 중요한 것은 목적지에서 자산을 즉시 건넬 사람이 있는가다. 서울의 지폐를 부산까지 운반하는 대신 부산의 전달자가 먼저 지급하고 나중에 서울의 돈을 정산받는 것. 나는 이 구조를 Liquidity Relay라고 부르고 싶다. Relay 경기에서는 한 선수가 출발점부터 결승선까지 혼자 뛰지 않는다. 구간마다 가장 가까운 주자가 Baton을 받아 다음 구간으로 넘긴다. Cross-chain Liquidity도 마찬가지다. 각 Chain에 배치된 Solver가 자신이 가장 빠르게 처리할 수 있는 주문을 맡고, Settlement Message가 뒤에서 정산을 마무리한다. 이렇게 보면 좋은 Cross-chain Network는 가장 큰 Pool 하나를 가진 Network가 아닐 수 있다. 여러 Chain에 Liquidity를 배치한 Solver가 많고, 그들이 빠른 Delivery를 위해 경쟁하며, 어떤 Route에서도 Baton이 끊기지 않는 Network가 중요하다. 앞으로 AI Agent가 여러 Chain에서 실시간으로 기회를 찾고 자산을 움직이기 시작하면 이 Relay의 속도는 더 중요해질 수 있다. Agent는 Bridge 화면을 열어 어떤 Pool을 선택할지 고민하지 않는다. “이 자산을 저 Chain의 저 Strategy에 넣어라”라는 결과만 요청할 가능성이 높다. 그때 Cross-chain Infrastructure는 자산을 옮기는 다리보다 Intent를 가장 빨리 완성하는 Delivery Network에 가까워진다. deBridge라는 이름에는 Bridge가 들어가 있지만 나는 오히려 Bridge를 보이지 않게 만드는 방향이 이 프로젝트의 핵심이라고 생각한다. 다리를 건너는 장면이 멋있을 수는 있다. 하지만 급한 사람에게 가장 좋은 다리는 건넌 줄도 몰랐는데 이미 도착해 있는 다리다. ㅋㅋ @debridge @AlexSmirnov @deBridge_KR @Yurieiswinning @gal_stern @ayushdegen #deBridge #DLN #CrossChain #IntentBased #SolverNetwork #ZeroTVL #LiquidityRelay #Interoperability #DeFi #AIAgent #Web3

택배를 주문할 때 사람들은 빠른 배송을 좋아한다. 오늘 주문해서 내일 도착하면 기분이 좋다. 그런데 정말 중요한 것은 하루 늦게 도착하는 문제가 아닐 수도 있다. 배송되지 않았는데 물건도 사라지고 환불도 안 된다면 그때부터 진짜 사고가 시작된다. ㅋㅋ 배송조회에 ‘이동 중’만 일주일째 떠 있으면 사람은 갑자기 철학자가 된다. 내 물건은 지금 어디에 있는가? Cross-chain Transaction도 비슷하다. 자산을 다른 Chain으로 보내면 사용자는 빠른 도착을 기대한다. 하지만 더 불안한 순간은 Transaction이 중간에서 멈췄을 때다. Source Chain에서는 자산이 빠져나갔는데 Destination Chain에는 도착하지 않았다. Bridge 화면에는 Pending만 표시되고, 사용자는 Explorer를 오가며 Transaction Hash를 붙잡고 기다린다. 속도보다 먼저 확인해야 할 질문이 있다. 실패하면 내 자산을 확실히 되찾을 수 있는가? @debridge의 DLN 구조에서 내가 새롭게 눈여겨본 부분도 이것이다. 사용자가 Cross-chain Order를 만들면 입력 자산은 Source Chain의 DlnSource Contract에 들어간다. Solver가 Destination Chain에서 사용자가 요청한 자산을 전달하면 해당 Order는 Fulfilled 상태가 된다. 그 이후 Solver는 Source Chain의 자산을 Claim한다. 하지만 Order가 이행되지 않으면 사용자는 Order를 취소하고 입력 자산을 다시 회수할 수 있다. 공식 문서에 따르면 이 경우 Protocol Fee까지 포함해 돌려받을 수 있으며, Auto-cancellation도 이런 회수 과정을 자동화할 수 있다. Smart Contract는 자금을 장기간 보관하는 Pool이 아니라 Order가 통과하는 Pipe에 가깝게 작동한다. 자산에는 두 가지 종료 상태가 생긴다. 요청한 결과가 Destination에 도착하거나, 실패하면 Source로 돌아온다. ‘중간 어딘가에 계속 갇혀 있는 상태’를 정상적인 결과로 인정하지 않는 것이다. deBridge는 Cross-chain Quote도 사용자가 받을 최종 결과를 기준으로 제시하며, Order가 체결되면 해당 Quote를 보장하는 방향을 사용한다. 나는 Cross-chain UX에서 이런 실패 경로의 설계가 성공 경로만큼 중요하다고 생각한다. 대부분의 서비스는 얼마나 빠르게 도착하는지를 먼저 광고한다. 하지만 사용자가 가장 크게 신뢰를 잃는 순간은 조금 늦게 도착했을 때가 아니다. 무슨 일이 일어났는지 모르고, 되돌아갈 방법도 보이지 않을 때다. 물론 Cancel이 가능하다고 해서 모든 Risk가 사라지는 것은 아니다. Smart Contract Risk와 Chain 상태, Solver와 Oracle, Destination의 Liquidity 조건은 여전히 확인해야 한다. 하지만 실패를 예상하고 명확한 회수 경로를 미리 설계하는 것은 Cross-chain Infrastructure가 갖춰야 할 기본 예의에 가깝다. 성공하면 박수받고 실패하면 고객센터 주소만 알려주는 구조로는 곤란하다. ㅋㅋ 💡 HD Insight — Failure Recovery Certainty 나는 금융 Infrastructure의 신뢰를 평가할 때 Success Rate만 보면 부족하다고 생각한다. 성공하지 못했을 때 얼마나 확실하고 이해 가능한 방식으로 원래 상태로 돌아갈 수 있는지도 봐야 한다. 나는 이것을 Failure Recovery Certainty라고 부르고 싶다. 100번 중 99번 빠르게 처리되는 Service라도 한 번의 실패에서 자산이 며칠씩 갇힌다면 사용자는 다음 거래를 망설이게 된다. 반대로 실패가 발생하더라도 상태를 명확히 확인하고, 취소 조건을 알 수 있으며, 자산과 Fee를 회수할 수 있다면 그 실패는 통제 가능한 사건이 된다. 미래의 Cross-chain 경쟁은 가장 빠른 Route만 찾는 경쟁에서 끝나지 않을 것이다. 도착과 회수라는 두 개의 결말을 얼마나 확실하게 보장하는지가 중요해질 수 있다. 좋은 Bridge는 자산을 건너편으로 보내는 길만 만드는 것이 아니다. 건너지 못했을 때 안전하게 돌아오는 길까지 함께 만든다. 편도 항공권만 파는 여행사보다 귀국편까지 챙겨주는 여행사가 믿음직한 이유와 비슷하다. ㅋㅋ @debridge @AlexSmirnov @deBridge_KR @Yurieiswinning @gal_stern @ayushdegen #deBridge #DLN #CrossChain #FailureRecovery #AutoCancellation #GuaranteedQuote #SolverNetwork #SelfCustody #DeFi #Web3