開發意圖導向（intent-centric）程式的挑戰
意圖導向（intent-centric）是近期區塊鏈應用的發展趨勢，它透過抽象化操作的方式提升效率和使用者體驗。然而，實際開發 intent-centric app 的時候也會遇到一些過往沒有的技術挑戰。
求解器（solver）的中心化問題：
意圖導向應用相當於讓使用者和區塊鏈的互動模式從 imperative 走向 declarative，好處除了簡化操作，也給予求解器彈性，有機會創造更好的執行結果，但也正是這樣的彈性，讓使用者對求解器多了一層信任假設。
以資產交易為例，原本使用者發起的操作內容可能是「到 Curve 上用 USDT 換 USDC，再去 Uniswap 把 USDC 換成 ETH」，現在變成「用 5000 USDT 換到不少於 2 ETH」。前者的執行結果未必是最好，不過至少是使用者指定的兌換方式；而後者在求解器運作得宜時會得到更好的執行結果，但操弄的空間始終存在，需要對 surplus shifting 之類的不良行為設下限制。
和帳號抽象（AA, account abstraction）的競合：
意圖導向和帳號抽象是差不多時間開始發展的方案，兩者時常處於競爭關係，甚至有彼此妨礙的部分。它們想解決的區塊鏈使用者體驗問題有部分重疊，比方說 gas fee。而 AA 的發展讓合約錢包普及率上升，對 intent-centric app 卻可能是個壞消息。從架構設計層面而言，很多 intent 都是基於鏈下的密碼學簽名，這對普通的私鑰錢包（EOA）很容易，但 AA 錢包卻未必都有實作類似的方法，即便有，也需要鏈上合約乃至 solver 的額外支援。當然，也有 intent-centric app（CoWAMM）用了重載過的 EIP1271 來提供表現力比 EOA 更好的 intent，充分發揮垂直整合的優勢，不過那就是後話了。
麻煩的是，由於帳號抽象和各種 DApp 的相容性還不太好，很多 AA 錢包都做成了白名單特定功能在錢包裡的模式。那麼，理所當然的，總是傳統鏈上送交易的合約先被整合，反過來說，intent-centric app 大概也只能建議使用者先用傳統錢包。如果要克服這個不良循環，就需要在設計 intent 的時候考慮到更多不同錢包類型，或者提供多種操作方式，暫時讓鏈上直送交易和鏈下簽名並存。
