DCEP與現有的電子支付系統有一個最大的不同點在於，DCEP整體系統的設計是一個分散式的系統，整個支付流程需要多個系統與使用者的終端協同完成工作。而現有的電子支付，例如微信支付寶等產品，則是隻採用了一個支付中心，使用者的裝置僅僅是作為一個收集資訊的終端。
DCEP所具有的貨幣流通屬性，其流透過程的細節，以及對離線支付的要求，需要系統以分散式的形式執行。
因此，作為一個分散式系統，DCEP的設計勢必會受到一些分散式系統的基本邏輯與理論的影響。同時，DCEP的設計也會反映出這些邏輯與理論。
CAP是分散式系統中一致性（Consistency），可用性（Availability）與分割槽容錯性（Partition tolerance）三個單詞的簡寫。
這個理論的基本描述是，分散式系統中三者最多隻能實現兩點，不能同時兼顧。實際上這樣的三選其二的理論有很多，不僅僅是在分散式系統領域有體現。
這三者分別具體地表達瞭如下的含義：
實際上，分散式系統的設計邏輯，闡述的是分散式系統的三個屬性中，只能有兩個是強限制的，而另外一個是弱限制的即可。
CAP理論中三元素可以兩兩組合,形成三種組合方式：
根據DCEP的設計邏輯，在一次的具體交易流程中，參與交易的雙方終端與數字貨幣登記系統構成了一個分散式系統。其中裝置終端與登記系統都是這個系統中的節點。由於DCEP要求能夠進行離線交易，也就意味著在一次交易中，即便有節點完全無法線上，最終在網路回覆之後系統依舊能對交易的過程進行驗證，保證交易的正確性。
從這個角度來看，DCEP的設計是一種優先保證AP的設計。
但是這樣的設計會導致一個問題，那就是DCEP一定程度上放棄了一致性，會使得進行貨幣交易的時候有一定的雙花風險。DCEP透過雙重手段來降低與解決這種風險。
首先，DCEP的設計將系統出現不一致性的可能性不斷降低，保證非惡意情況下不會出現交易不一致的問題，同時能夠一定程度上抵禦惡意的雙花。
同時，DCEP透過技術之外的手段保證了一旦發生惡意雙花情況，可以對進行違規操作的人進行追責與管理。
從這個角度上來說，DCEP的核心設計邏輯中，優先保障系統的可用性與系統的分割槽容錯性，在滿足這個前提的情況下儘量的提升系統的一致性。
FLP定理講的是一個分散式的一個下限，原話說的是：在非同步通訊場景，即使只有一個節點失敗，也沒有任何演算法能保證非失敗節點達到一致性。
展開來說，這裡的非同步場景指的是，節點與節點間的通訊，通訊雙方是不可能知道通訊失敗的事實的。
因為網路中沒有預設節點發送資訊的到達時間，所以節點收不到資訊，只能被認為訊息延遲了，而不是節點離線導致通訊失敗。
而在這樣的非同步網路環境下分散式系統是無法正常的運作的。
因為只要有一個節點出現問題，整個網路中所有節點上的資料無法達成一致，即滿足上文所說的一致性。FLP定理指出了分散式系統正常運作的最低要求，只要我們的網路環境不低於FLP中的要求，系統就能夠正確的執行。
放在DCEP的場景中，NLP定理同樣也指出了離線支付的最低限度，同時也表明了系統可能出現問題的地方。
DCEP如果想要保證離線支付完成的絕對正確性，就需要拋棄非同步通訊假設，也就是需要對網路通訊中錢包的離線時間做出限定，當錢包過久離線，交易就可能出現不一致的情況，可能會導致雙花問題的產生。
但如果我們真正需要這個場景，可以參考Paxos的實現，降低此情況下可能產生不一致的可能性，最後採用法律手段或者懲罰性手段保證系統的正常執行，由於DCEP的設計能夠保證系統識別雙花的出現，並且會自動將最後一筆交易作廢，透過這樣的方式，為違規使用DCEP花費的行為提供了依據。