diff --git a/public/index.html b/public/index.html index ecaf8c7..7577dd2 100644 --- a/public/index.html +++ b/public/index.html @@ -166,6 +166,8 @@ style="display:flex;flex-direction:row;justify-content: space-around; align-item - -### Who? - -There are three parties involved in a payment - -- Consumer (ie payer) -- Provider (ie payee) -- Facilitator - -All of us are consumers, some are providers, a few are facilitators. - -### What users want - -> Users want secure, fast, low cost transactions - -However participants have different priorities, _eg_ - -- Consumers want ease-of-use -- Providers want fast confirmation -- Facilitators need to handle at scale - -### Existing systems (1/2) - -- Cash: Permissionless, instant, scalable-ish (lots of people can use it at the same time, but only to pay people near them), -questionable security (fraud happens). -- Bank transfer: Permissioned, some instant others very slow, scalable. -- Contactless/ Card: Permissioned, near instant, scalable - -### ... (2/2) - -- Decentralised Ledger \*: permissionless, maybe fast or scalable but generally not both. - - -\* There are many different designs of decentralised ledger, -each with different choices and trade-offs. -Some permissioned, some more decentralised than others, some faster, _etc_. - - -### Market size - - -- Contactless transactions will reach $11 trillion by 2027 source : Juniper Research - -- Market Cap for crypto : > $3 trillion source : coinmarketcap.com (Dec 2024) - -### Intersection - -> Can we have contactless like experience but permissionless. - -### Problem statement - -We want a payment system that is: - -1. Permissionless and secure -2. Near instant -3. Highly scalable - -### Bitcoin Lightning Network? - -In a lightning network: - -- The network is fundamentally a set of channels, not a shared ledger. -- There is no need to reach consensus, or globally broadcasting state. -- Payments are routed across channels by participants. -- Speed of payment isn't a global property, but a more local one. - -BLN does this and is the closest to meeting our aims. - -### Problems with BLN - -However it has some issues: - -- Large technical and resource overhead to use. Every user must run a node. -- Difficult to efficiently manage capital. -Liquidity is required to enable payments to be routed across a network. -Moving capital between channels requires multiple transactions. - -## Solution - -### Cardano Lightning - -### Design - -- A perturbation on BLN: its a Lightning Network -- Focused on addressing the key technical blockers -to it being used as a day-to-day payment system. - -### Tailored Nodes - -CL recognises a diversity users have a diversity of needs. - -- For consumers we have a lightweight node, minimal resources, and runs on their phone. -- Some providers might be happy running their own servers, others wont. -There's a flexible CL node + SDK to suit a full spectrum of usecases. - -### Leveraging Cardano - -- Cardano's more powerful scripting language allows -us to achieve more with less. In particular we can optimize capital allocation for nodes. - -- For the facilitators, we have a node for efficient handling of many channels concurrently. -Those with capital and wanting to put it to use become the facilitators. -They receive income on the service they provide, each payment they facilitate in routing. - -## Team diff --git a/template.html b/template.html deleted file mode 100644 index 7fa2f49..0000000 --- a/template.html +++ /dev/null @@ -1,795 +0,0 @@ - - -
- - -$for(author-meta)$ - -$endfor$ -$if(date-meta)$ - -$endif$ -$if(keywords)$ - -$endif$ -