mirror of
https://github.com/aljazceru/ark.git
synced 2025-12-17 04:04:21 +01:00
Remove Website from monorepo
This commit is contained in:
tiero
@@ -1,7 +1,5 @@
|
||||
.git
|
||||
.github/
|
||||
website/
|
||||
noah/
|
||||
**/dist/
|
||||
**/build/
|
||||
**/*.yml
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@@ -0,0 +1 @@
|
||||
.DS_Store
|
||||
@@ -7,7 +7,6 @@ Welcome to the Ark monorepo.
|
||||
In this repository you can find:
|
||||
|
||||
- `server` - a proof of concept of an Ark Service Provider.
|
||||
- `website` - the website where to find documentation about Ark protocol and products.
|
||||
- `client` - the initial Ark wallet, served as CLI.
|
||||
|
||||
|
||||
|
||||
20
website/.gitignore
vendored
20
website/.gitignore
vendored
@@ -1,20 +0,0 @@
|
||||
# Dependencies
|
||||
/node_modules
|
||||
|
||||
# Production
|
||||
/build
|
||||
|
||||
# Generated files
|
||||
.docusaurus
|
||||
.cache-loader
|
||||
|
||||
# Misc
|
||||
.DS_Store
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
@@ -1,41 +0,0 @@
|
||||
# Website
|
||||
|
||||
This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
|
||||
|
||||
### Installation
|
||||
|
||||
```
|
||||
$ yarn
|
||||
```
|
||||
|
||||
### Local Development
|
||||
|
||||
```
|
||||
$ yarn start
|
||||
```
|
||||
|
||||
This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
|
||||
|
||||
### Build
|
||||
|
||||
```
|
||||
$ yarn build
|
||||
```
|
||||
|
||||
This command generates static content into the `build` directory and can be served using any static contents hosting service.
|
||||
|
||||
### Deployment
|
||||
|
||||
Using SSH:
|
||||
|
||||
```
|
||||
$ USE_SSH=true yarn deploy
|
||||
```
|
||||
|
||||
Not using SSH:
|
||||
|
||||
```
|
||||
$ GIT_USER=<Your GitHub username> yarn deploy
|
||||
```
|
||||
|
||||
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
|
||||
@@ -1,3 +0,0 @@
|
||||
module.exports = {
|
||||
presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
|
||||
};
|
||||
@@ -1,486 +0,0 @@
|
||||
---
|
||||
authors: bordalix
|
||||
description: Dive into the depths of Ark with our comprehensive guide on Liquidity Requirements. Explore how Ark liquidity intersect with Money Velocity
|
||||
image: /img/ark-agora.png
|
||||
slug: liquidity-requirements
|
||||
tags: [liquidity, ark, bitcoin]
|
||||
title: Understanding Ark Liquidity Requirements
|
||||
unlisted: true
|
||||
---
|
||||
|
||||
|
||||
|
||||
This post discusses the liquidity requirements and calculates the funding needs of Ark Service Provider (ASP), as all transactions within Ark must be funded by the ASP.
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
## What is Ark?
|
||||
|
||||
Ark is a promising second-layer solution for Bitcoin that improves the scalability and privacy of the network. It offers the following benefits:
|
||||
|
||||
- **No incoming liquidity required**: Receivers can accept payments without having to worry about having enough funds in their wallets.
|
||||
- **Confidential payments**: Ark protects the confidentiality of recipients, which is not always possible with other second-layer solutions.
|
||||
- **Scalable**: Ark is a solution for enabling the scalability of Bitcoin and applications and services which utilize the Bitcoin infrastructure.
|
||||
- **Secure**: Ark is a secure solution that is built on top of the Bitcoin blockchain.
|
||||
|
||||
:::tip
|
||||
It's recommended to read the [nomenclature](/docs/learn/nomenclature) first.
|
||||
:::
|
||||
|
||||
## Ark liquidity requirements
|
||||
|
||||
### Introduction
|
||||
|
||||
When Alice wishes to board an Ark, she finances an output that is eligible to be recognized as a VTXO in a future round. This does **not** necessitate any liquidity from the ASP:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Onchain
|
||||
direction LR
|
||||
Alice
|
||||
vtxo(10 BTC VTXO*)
|
||||
Alice --> vtxo
|
||||
end
|
||||
```
|
||||
|
||||
:::info
|
||||
Since this an onchain transaction, and VTXOs should be virtual, we marked it as VTXO\*.
|
||||
:::
|
||||
|
||||
When Alice makes her initial payment, for example, 1 BTC to Bob, the VTXO\* will be utilized to finance the [Pool transaction](/learn/nomenclature#pool-transaction-aka-ark-transaction), so again, the ASP will **not** need to supply any additional liquidity:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Onchain
|
||||
direction LR
|
||||
vtxo(10 BTC VTXO*)
|
||||
pool(Pool transaction)
|
||||
vtxo --> pool
|
||||
end
|
||||
subgraph Virtual
|
||||
subgraph VTXOs
|
||||
direction LR
|
||||
change(9 BTC Alice)
|
||||
bob(1 BTC Bob)
|
||||
end
|
||||
end
|
||||
pool --> VTXOs
|
||||
```
|
||||
|
||||
But if Alice tries to make a second payment, for example, 1 BTC to Charlie, she will now be utilizing a genuine virtual VTXO. In this case, the ASP will need to finance the following [Pool transaction](/learn/nomenclature#pool-transaction-aka-ark-transaction):
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Onchain
|
||||
direction LR
|
||||
vtxo(10 BTC VTXO*)
|
||||
pool(Pool transaction)
|
||||
vtxo --> pool
|
||||
ASP(9 BTC ASP)
|
||||
pool2(Pool transaction 2)
|
||||
ASP --> pool2
|
||||
end
|
||||
subgraph Virtual
|
||||
subgraph VTXOs
|
||||
direction LR
|
||||
change(9 BTC Alice)
|
||||
bob(1 BTC Bob)
|
||||
end
|
||||
subgraph new_VTXOs
|
||||
direction LR
|
||||
charlie(1 BTC Charlie)
|
||||
change2(8 BTC Alice)
|
||||
end
|
||||
forfeit(Forfeit to ASP)
|
||||
change --> forfeit
|
||||
end
|
||||
pool --> VTXOs
|
||||
pool2 --> new_VTXOs
|
||||
```
|
||||
|
||||
Finally, let's assume Alice also pays 1 BTC to Dave:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Onchain
|
||||
direction LR
|
||||
vtxo(10 BTC VTXO*)
|
||||
pool(Pool transaction)
|
||||
vtxo --> pool
|
||||
ASP(9 BTC ASP)
|
||||
pool2(Pool transaction 2)
|
||||
ASP --> pool2
|
||||
ASP2(8 BTC ASP)
|
||||
pool3(Pool transaction 3)
|
||||
ASP2 --> pool3
|
||||
end
|
||||
subgraph Virtual
|
||||
subgraph VTXOs
|
||||
direction LR
|
||||
bob(1 BTC Bob)
|
||||
charlie(1 BTC Charlie)
|
||||
change2(8 BTC Alice)
|
||||
end
|
||||
subgraph new_VTXOs
|
||||
direction LR
|
||||
dave(1 BTC Dave)
|
||||
change3(7 BTC Alice)
|
||||
end
|
||||
forfeit(Forfeit to ASP)
|
||||
change2 --> forfeit
|
||||
end
|
||||
pool --> VTXOs
|
||||
pool2 --> VTXOs
|
||||
pool3 --> new_VTXOs
|
||||
```
|
||||
|
||||
### Summary
|
||||
|
||||
- 10 BTC initial onboard from Alice
|
||||
- 4 payments:
|
||||
- Alice => Bob 1 BTC
|
||||
- Alice => Charlie 1 BTC
|
||||
- Alice => Dave 1 BTC
|
||||
- total payments = 3 BTC
|
||||
- ASP liquidity needed = 17 BTC
|
||||
|
||||
As we can see, the liquidity needs for the ASP depends on the following factors:
|
||||
|
||||
- Capital onboarded
|
||||
- Value of the payments
|
||||
|
||||
:::tip
|
||||
While onboarding does not require any liquidity from the ASP, next payments will.
|
||||
:::
|
||||
|
||||
### The liquidity problem
|
||||
|
||||
If the ASP exhausts its liquidity, it will have to cease accepting new payments and will be compelled to wait for the timelocks (4 weeks) on the on-chain transactions to expire in order to regain liquidity.
|
||||
|
||||
To avoid the ASP from running out of funds, it must be able to anticipate how much liquidity will be required throughout a 4 week period.
|
||||
|
||||
As we observed, the liquidity necessary during a period will rely on the capital onboarded and the number and value of payments made with that capital
|
||||
|
||||
Given this, we can assume the liquidity needed will be the consequence of a function of capital onboarded and a percentage of this capital utilized during the 4 weeks period.
|
||||
|
||||
Therefore, how much capital can an ASP accept from users without risking not having enough capital to finance payments inside Ark? In other words, what proportion of the capital inside an Ark is transferred in a 4 week period?
|
||||
|
||||
This is similar to the definition of Money Velocity, as defined by the St. Louis Fed:
|
||||
|
||||
> The velocity of money is the frequency at which one unit of currency is used to purchase domestically-produced goods and services within a given time period.
|
||||
|
||||
### Money Velocity (MV)
|
||||
|
||||
Here are some Money Velocity numbers:
|
||||
|
||||
- USD (Q3 2023): 1.327
|
||||
- Lightning (August 2023): 0.59 per month
|
||||
|
||||
If we use a Money Velocity of 1.00 (for simplicity), this means that each BTC inside the Ark will be spent once (1.00) during that given period. Since the ASP must fund all transactions and onboarding, this means that for each 1 BTC added to the Ark, the ASP will need 1 BTC to fund the onboarding and 1 BTC to fund the transfers inside the Ark. With an initial balance of 100 BTC, this results in a limit of 50 BTC allowed to onboard (100 = 50 for onboarding + 50 for trades).
|
||||
|
||||
If MV = 0.59, this means that those initial 100 BTC would allow for 62.89 BTC of onboarding, where (100 = 62.89 for onboarding + (69.89 \* 0.59 = 37.11) for trades).
|
||||
|
||||
In reality, the Money Velocity of Ark is likely to be somewhere between 1.00 and 0.59. This means that the ASP will need to have a certain amount of liquidity on hand to fund both onboarded BTC and transfers inside the Ark. The amount of liquidity required will depend on the specific Money Velocity of Ark, which is not yet known for sure.
|
||||
|
||||
Comparison table:
|
||||
|
||||
| Money Velocity | Balance | +Onboard (BTC) | Inside Ark (BTC) | Transfers (BTC) |
|
||||
| -------------: | ------: | -------------: | ---------------: | --------------: |
|
||||
| 0.59 | 100.00 | 62.89 | 0.00 | 37.11 |
|
||||
| 1.00 | 100.00 | 50.00 | 0.00 | 50.00 |
|
||||
| 1.327 | 100.00 | 42.97 | 0.00 | 57.03 |
|
||||
|
||||
After one month, all the funds used by the ASP, plus the funds sent by the users, become available again. This means that the ASP will have more available liquidity, so it can increase the allowed value for onboards. On the other hand, there is now more capital inside the Ark, so the ASP needs to reserve more capital to fund the transfers:
|
||||
|
||||
| Money Velocity | Balance | +Onboard (BTC) | Inside Ark (BTC) | Transfers (BTC) |
|
||||
| -------------: | ------: | -------------: | ---------------: | --------------: |
|
||||
| 0.59 | 162.89 | 79.11 | 62.89 | 83.78 |
|
||||
| 1.00 | 150 | 50.00 | 50.00 | 100.00 |
|
||||
| 1.327 | 142.97 | 36.93 | 42.97 | 57.03 |
|
||||
|
||||
Now, what would happen in a one-year period?
|
||||
|
||||
:::info
|
||||
You can run your own simulations with the <a href="/liquidity-simulator/" target="_blank">Ark liquidity simulator</a>.
|
||||
:::
|
||||
|
||||
### Simulating for 1 year
|
||||
|
||||
Columns definition:
|
||||
|
||||
- Inside Ark = Accumulated of allowed onboards
|
||||
- ASP Balance = Initial balance + Inside Ark
|
||||
- Reserved for trades = Inside Ark \* MV
|
||||
- Remaining = Balance - Reserved for trades
|
||||
- Allowed onboards = Remaining / (1 + MV)
|
||||
|
||||
Money Velocity: 0.59
|
||||
|
||||
| Month | Inside Ark | ASP Balance | Reserved for trades | Remaining | Allowed onboards |
|
||||
| ----: | :--------: | :---------: | :-----------------: | :-------: | :--------------: |
|
||||
| 0 | 0.00 | 100.00 | 0.00 | 100.00 | 0.00 |
|
||||
| 1 | 0.00 | 100.00 | 0.00 | 100.00 | 62.89 |
|
||||
| 2 | 62.89 | 162.89 | 37.11 | 125.79 | 79.11 |
|
||||
| 3 | 142.00 | 242.00 | 83.78 | 158.22 | 99.51 |
|
||||
| 4 | 241.51 | 341.51 | 142.49 | 199.02 | 125.17 |
|
||||
| 5 | 366.68 | 466.68 | 216.34 | 250.34 | 157.45 |
|
||||
| 6 | 524.13 | 624.13 | 309.24 | 314.89 | 198.05 |
|
||||
| 7 | 722.18 | 822.18 | 426.09 | 396.09 | 249.12 |
|
||||
| 8 | 971.29 | 1,071.29 | 573.06 | 498.23 | 313.35 |
|
||||
| 9 | 1,284.65 | 1,384.65 | 757.94 | 626.70 | 394.15 |
|
||||
| 10 | 1,678.80 | 1,778.80 | 990.49 | 788.31 | 495.79 |
|
||||
| 11 | 2,174.59 | 2,274.59 | 1,283.01 | 991.58 | 623.64 |
|
||||
| 12 | 2,798.23 | 2,898.23 | 1,650.95 | 1,247.27 | 784.45 |
|
||||
|
||||
Money Velocity: 1
|
||||
|
||||
| Month | Inside Ark | ASP Balance | Reserved for trades | Remaining | Allowed onboards |
|
||||
| ----: | :--------: | :---------: | :-----------------: | :-------: | :--------------: |
|
||||
| 0 | 0.00 | 100.00 | 0.00 | 100.00 | 0.00 |
|
||||
| 1 | 0.00 | 100.00 | 0.00 | 100.00 | 50.00 |
|
||||
| 2 | 50.00 | 150.00 | 50.00 | 100.00 | 50.00 |
|
||||
| 3 | 100.00 | 200.00 | 100.00 | 100.00 | 50.00 |
|
||||
| 4 | 150.00 | 250.00 | 150.00 | 100.00 | 50.00 |
|
||||
| 5 | 200.00 | 300.00 | 200.00 | 100.00 | 50.00 |
|
||||
| 6 | 250.00 | 350.00 | 250.00 | 100.00 | 50.00 |
|
||||
| 7 | 300.00 | 400.00 | 300.00 | 100.00 | 50.00 |
|
||||
| 8 | 350.00 | 450.00 | 350.00 | 100.00 | 50.00 |
|
||||
| 9 | 400.00 | 500.00 | 400.00 | 100.00 | 50.00 |
|
||||
| 10 | 450.00 | 550.00 | 450.00 | 100.00 | 50.00 |
|
||||
| 11 | 500.00 | 600.00 | 500.00 | 100.00 | 50.00 |
|
||||
| 12 | 550.00 | 650.00 | 550.00 | 100.00 | 50.00 |
|
||||
|
||||
Money Velocity 1.327
|
||||
|
||||
| Month | Inside Ark | ASP Balance | Reserved for trades | Remaining | Allowed onboards |
|
||||
| ----: | :--------: | :---------: | :-----------------: | :-------: | :--------------: |
|
||||
| 0 | 0.00 | 100.00 | 0.00 | 100.00 | 0.00 |
|
||||
| 1 | 0.00 | 100.00 | 0.00 | 100.00 | 42.97 |
|
||||
| 2 | 42.97 | 142.97 | 57.03 | 85.95 | 36.93 |
|
||||
| 3 | 79.91 | 179.91 | 106.04 | 73.87 | 31.74 |
|
||||
| 4 | 111.65 | 211.65 | 148.16 | 63.49 | 27.28 |
|
||||
| 5 | 138.94 | 238.94 | 184.37 | 54.57 | 23.45 |
|
||||
| 6 | 162.39 | 262.39 | 215.49 | 46.90 | 20.15 |
|
||||
| 7 | 182.54 | 282.54 | 242.23 | 40.31 | 17.32 |
|
||||
| 8 | 199.86 | 299.86 | 265.22 | 34.64 | 14.89 |
|
||||
| 9 | 214.75 | 314.75 | 284.98 | 29.78 | 12.80 |
|
||||
| 10 | 227.55 | 327.55 | 301.96 | 25.59 | 11.00 |
|
||||
| 11 | 238.55 | 338.55 | 316.55 | 22.00 | 9.45 |
|
||||
| 12 | 248.00 | 348.00 | 329.09 | 18.90 | 8.12 |
|
||||
|
||||
:::info Results
|
||||
|
||||
Simulating the three different MV values over a one-year period, we can conclude the following:
|
||||
|
||||
- If MV < 1, the ASP can onboard more BTC each month than in the previous month.
|
||||
- If MV = 1, the allowed value for onboarding BTC is always the same (half of the initial balance).
|
||||
- If MV > 1, the value of allowed BTC to onboard converges to 0 over time, with the maximum onboard value equal to (initial balance) / (MV - 1).
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
The Money Velocity (MV) for USD is quarterly. Assuming that M2 is constant and GDP is evenly distributed over the three months, the MV for one month should be ⅓ of the MV for the quarter, or 0.33.
|
||||
|
||||
:::
|
||||
|
||||
### Algorithm
|
||||
|
||||
#### Allowed onboard value
|
||||
|
||||
The value of allowed onboard BTC for this round will be:
|
||||
|
||||
:::info Allowed onboard formula
|
||||
|
||||
(Available balance - User’s funds in Ark \* MV) / (1 + MV)
|
||||
|
||||
:::
|
||||
|
||||
Where:
|
||||
|
||||
- Available balance = Initial ASP balance + User’s funds
|
||||
- User’s funds = All BTC onboarded by users until now
|
||||
- MV = Money Velocity
|
||||
|
||||
#### Money Velocity
|
||||
|
||||
To calculate the value of Money Velocity:
|
||||
|
||||
:::info Money Velocity formula
|
||||
|
||||
Average for the last N rounds of (amount transferred / user’s funds)
|
||||
|
||||
:::
|
||||
|
||||
#### Rational
|
||||
|
||||
The ASP keeps records of onboarded and transferred amounts from previous rounds, and uses them to calculate the Money Velocity (MV) for the current round. It then uses the MV to calculate the maximum amount that can be onboarded in the current round.
|
||||
|
||||
If you've read this far, thank you! But now it's time for the bad news.
|
||||
|
||||
## The UTXO model
|
||||
|
||||
<details>
|
||||
<summary>How the UTXO Model Works</summary>
|
||||
|
||||
In the UTXO model, each unit of cryptocurrency is treated as a unique and indivisible entity. When a user spends cryptocurrency, they are not actually spending their entire balance. Instead, they are spending specific UTXOs that they own.
|
||||
|
||||
Each UTXO has two important pieces of information:
|
||||
|
||||
- The amount of cryptocurrency: This is the value of the UTXO.
|
||||
- A locking script: This is a script that specifies how the UTXO can be spent. The locking script typically requires a digital signature from the owner of the UTXO.
|
||||
|
||||
When a user wants to spend cryptocurrency, they create a new transaction. This transaction has two parts:
|
||||
|
||||
- Inputs: These are the UTXOs that the user is spending.
|
||||
- Outputs: These are the new UTXOs that will be created as a result of the transaction.
|
||||
|
||||
The locking scripts of the input UTXOs must be satisfied in order for the transaction to be valid. This ensures that only the rightful owner of the cryptocurrency can spend it.
|
||||
|
||||
</details>
|
||||
|
||||
### The change problem
|
||||
|
||||
But since Ark uses a UTXO model, this MV theory doesn't work, as the ASP will also need to fund the change on each transaction. For example, if Alice has a 1 BTC VTXO and wants to pay Bob 0.2 BTC, the ASP will need to fund two new VTXOs:
|
||||
|
||||
- 0.2 BTC to Bob
|
||||
- 0.8 BTC to Alice (change)
|
||||
|
||||
#### Some simulations
|
||||
|
||||
Imagine that Alice boarded the Ark with 1 BTC. She has a 1 BTC VTXO and spends ⅓ of her money in the first month (MV = 0.33) using three payments of 0.11 BTC each.
|
||||
|
||||
Let's also assume that these payments are inside Ark (to Bob), which means that the ASP will also need to fund Bob's VTXO.
|
||||
|
||||
| Payment | Value | Alice VTXO | Bob VTXOs<br />(0.11 each) | Liquidity needed | Liquidity accum |
|
||||
| :-----: | :---: | :--------: | :------------------------: | :--------------: | :-------------: |
|
||||
| 0 | 0 | 1.00 | 0 | 0 | 0 |
|
||||
| 1 | 0.11 | 0.89 | 1 | 1.00 | 1.00 |
|
||||
| 2 | 0.11 | 0.78 | 2 | 0.89 | 1.89 |
|
||||
| 3 | 0.11 | 0.67 | 3 | 0.78 | **2.67** |
|
||||
|
||||
At the end of the transaction, Alice has one VTXO of 0.67 BTC and Bob has three VTXOs of 0.11 BTC each.
|
||||
|
||||
:::danger Huge funding needs (factor of **8**)
|
||||
|
||||
The ASP needed **2.67** of liquidity to support **0.33** traded inside Ark.
|
||||
|
||||
:::
|
||||
|
||||
Things get much worse if the user makes 10 payments instead of 3 (spending 0.033 BTC on each):
|
||||
|
||||
| Payment | Value | Alice VTXO | Bob VTXOs<br />(0.033 each) | Liquidity needed | Liquidity accum |
|
||||
| :-----: | :---: | :--------: | :-------------------------: | :--------------: | :-------------: |
|
||||
| 0 | 0 | 1.00 | 0 | 0 | 0 |
|
||||
| 1 | 0.033 | 0.97 | 1 | 1.00 | 1.00 |
|
||||
| 2 | 0.033 | 0.93 | 2 | 0.97 | 1.97 |
|
||||
| 3 | 0.033 | 0.90 | 3 | 0.93 | 2.90 |
|
||||
| 4 | 0.033 | 0.87 | 4 | 0.90 | 3.80 |
|
||||
| 5 | 0.033 | 0.84 | 5 | 0.87 | 4.67 |
|
||||
| 6 | 0.033 | 0.80 | 6 | 0.84 | 5.51 |
|
||||
| 7 | 0.033 | 0.77 | 7 | 0.80 | 6.31 |
|
||||
| 8 | 0.033 | 0.74 | 8 | 0.77 | 7.08 |
|
||||
| 9 | 0.033 | 0.70 | 9 | 0.74 | 7.81 |
|
||||
| 10 | 0.033 | 0.67 | 10 | 0.70 | **8.52** |
|
||||
|
||||
:::danger Huge funding needs (factor of **25**)
|
||||
|
||||
The ASP needed **8.52** of liquidity to support **0.33** traded inside Ark.
|
||||
|
||||
:::
|
||||
|
||||
### Possible mitigations
|
||||
|
||||
One can try to reduce these liquidity requirements by pushing several levers:
|
||||
|
||||
- Reduce MV by reducing the timelock (e.g., 2 weeks instead of 1 month).
|
||||
- Reduce transaction change by creating a set of UTXOs with a range of values on the first place, and then doing coin selection with the purpose of reducing change to the minimum possible.
|
||||
|
||||
#### Reduce transaction change
|
||||
|
||||
- Assuming MV = 0.33, and 10 payments of equal value during a month period
|
||||
- Dividing Alice’s initial UTXO into 10, 100, and 1000 VTXOs
|
||||
|
||||
Using a 1:10 ratio for VTXOs:
|
||||
|
||||
| VTXO Value | Payment<br />number | Payment<br />value | VTXOs used | Alice balance | Alice VTXOs | Liquidity needed | Liquidity accum |
|
||||
| :--------: | :-----------------: | :----------------: | :--------: | :-----------: | :---------: | :--------------: | :-------------: |
|
||||
| 0.1 | 0 | 0.000 | 0 | 1.000 | 10 | 0.0 | 0.00 |
|
||||
| 0.1 | 1 | 0.033 | 1 | 0.967 | 10 | 0.1 | 0.10 |
|
||||
| 0.1 | 2 | 0.033 | 1 | 0.934 | 10 | 0.1 | 0.20 |
|
||||
| 0.1 | 3 | 0.033 | 1 | 0.901 | 10 | 0.1 | 0.30 |
|
||||
| 0.1 | 4 | 0.033 | 1 | 0.868 | 10 | 0.1 | 0.40 |
|
||||
| 0.1 | 5 | 0.033 | 1 | 0.835 | 10 | 0.1 | 0.50 |
|
||||
| 0.1 | 6 | 0.033 | 1 | 0.802 | 10 | 0.1 | 0.60 |
|
||||
| 0.1 | 7 | 0.033 | 1 | 0.769 | 10 | 0.1 | 0.70 |
|
||||
| 0.1 | 8 | 0.033 | 1 | 0.736 | 10 | 0.1 | 0.80 |
|
||||
| 0.1 | 9 | 0.033 | 1 | 0.703 | 10 | 0.1 | 0.90 |
|
||||
| 0.1 | 10 | 0.033 | 1 | 0.670 | 10 | 0.1 | 1.00 |
|
||||
|
||||
Using a 1:100 ratio for VTXOs:
|
||||
|
||||
| VTXO Value | Payment<br />number | Payment<br />value | VTXOs used | Alice balance | Alice VTXOs | Liquidity needed | Liquidity accum |
|
||||
| :--------: | :-----------------: | :----------------: | :--------: | :-----------: | :---------: | :--------------: | :-------------: |
|
||||
| 0.01 | 0 | 0.000 | 0 | 1.000 | 100 | 0.0 | 0.00 |
|
||||
| 0.01 | 1 | 0.033 | 4 | 0.967 | 97 | 0.04 | 0.04 |
|
||||
| 0.01 | 2 | 0.033 | 4 | 0.934 | 94 | 0.04 | 0.08 |
|
||||
| 0.01 | 3 | 0.033 | 4 | 0.901 | 91 | 0.04 | 0.12 |
|
||||
| 0.01 | 4 | 0.033 | 4 | 0.868 | 88 | 0.04 | 0.16 |
|
||||
| 0.01 | 5 | 0.033 | 4 | 0.835 | 85 | 0.04 | 0.20 |
|
||||
| 0.01 | 6 | 0.033 | 4 | 0.802 | 82 | 0.04 | 0.24 |
|
||||
| 0.01 | 7 | 0.033 | 4 | 0.769 | 79 | 0.04 | 0.28 |
|
||||
| 0.01 | 8 | 0.033 | 4 | 0.736 | 76 | 0.04 | 0.32 |
|
||||
| 0.01 | 9 | 0.033 | 4 | 0.703 | 73 | 0.04 | 0.36 |
|
||||
| 0.01 | 10 | 0.033 | 4 | 0.670 | 70 | 0.04 | 0.40 |
|
||||
|
||||
Using a 1:1000 ratio for VTXOs:
|
||||
|
||||
| VTXO Value | Payment<br />number | Payment<br />value | VTXOs used | Alice balance | Alice VTXOs | Liquidity needed | Liquidity accum |
|
||||
| :--------: | :-----------------: | :----------------: | :--------: | :-----------: | :---------: | :--------------: | :-------------: |
|
||||
| 0.001 | 0 | 0.000 | 0 | 1.000 | 1000 | 0.0 | 0.00 |
|
||||
| 0.001 | 1 | 0.033 | 33 | 0.967 | 968 | 0.033 | 0.03 |
|
||||
| 0.001 | 2 | 0.033 | 33 | 0.934 | 936 | 0.033 | 0.07 |
|
||||
| 0.001 | 3 | 0.033 | 33 | 0.901 | 904 | 0.033 | 0.10 |
|
||||
| 0.001 | 4 | 0.033 | 33 | 0.868 | 872 | 0.033 | 0.13 |
|
||||
| 0.001 | 5 | 0.033 | 33 | 0.835 | 840 | 0.033 | 0.17 |
|
||||
| 0.001 | 6 | 0.033 | 33 | 0.802 | 808 | 0.033 | 0.20 |
|
||||
| 0.001 | 7 | 0.033 | 33 | 0.769 | 776 | 0.033 | 0.23 |
|
||||
| 0.001 | 8 | 0.033 | 33 | 0.736 | 744 | 0.033 | 0.26 |
|
||||
| 0.001 | 9 | 0.033 | 33 | 0.703 | 712 | 0.033 | 0.30 |
|
||||
| 0.001 | 10 | 0.033 | 33 | 0.670 | 680 | 0.033 | 0.33 |
|
||||
|
||||
Comparison table:
|
||||
|
||||
| VTXO ratio | MV | # Payments | ASP liquidity needed |
|
||||
| ---------: | ---: | ---------: | -------------------: |
|
||||
| 10 | 0.33 | 10 | 1.00 |
|
||||
| 100 | 0.33 | 10 | 0.40 |
|
||||
| 1000 | 0.33 | 10 | 0.33 |
|
||||
|
||||
:::info conclusion
|
||||
|
||||
Dividing the initial UTXO into more VTXOs decreases the need for funding.
|
||||
|
||||
:::
|
||||
|
||||
## Conclusion
|
||||
|
||||
The liquidity requirements for an ASP will depend on three major factors:
|
||||
|
||||
- **Money Velocity**: This is not under the control of the ASP, and if it is higher than 1, the Ark capacity will converge to a fixed value.
|
||||
- **The locktime period on VTXOs**: Reducing the locktime period will return the locked liquidity sooner. However, this also means that users will need to "recycle" their VTXOs sooner, which can be seen as a worse user experience.
|
||||
- **The VTXO ratio**: In other words, this is the maximum allowed value for a given VTXO. At one extreme, the ASP could force all VTXOs to be of 1 sat, which would eliminate any "wasted" liquidity on change. However, this would also require millions of signatures from the user and ASP to construct a payment, which would cause a worse user experience.
|
||||
|
||||
## References
|
||||
|
||||
- Velocity of M2 Money Stock
|
||||
by St Louis Fed
|
||||
<https://fred.stlouisfed.org/series/M2V>
|
||||
|
||||
- Lightning Report
|
||||
by River
|
||||
<https://river.com/learn/files/river-lightning-report-2023.pdf>
|
||||
|
||||
- Cryptocurrencies and the Velocity of Money
|
||||
by Ingolf Gunnar Anton Pernice, Georg Gentzen, and Hermann Elendner
|
||||
<https://cryptoeconomicsystems.pubpub.org/pub/pernice-cryptocurrencies-velocity/release/9>
|
||||
@@ -1,5 +0,0 @@
|
||||
bordalix:
|
||||
name: João Bordalo
|
||||
title: Developer
|
||||
url: https://github.com/bordalix
|
||||
image_url: https://github.com/bordalix.png
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Developers",
|
||||
"position": 2
|
||||
}
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: 'Get Started'
|
||||
---
|
||||
|
||||
:::info
|
||||
🚧 This page is currently under development, and some concepts may not be entirely accurate. We greatly value your feedback and contributions. If you have any suggestions, corrections, or would like to submit edits, please do so through the pull request link available at the bottom of each page.
|
||||
:::
|
||||
|
||||
## Overview
|
||||
|
||||
This guide will help you get started with integrating Ark into your applications.
|
||||
|
||||
## Use cases
|
||||
|
||||
- Create a Bitcoin wallet for your users with cheap and fast transactions.
|
||||
- Integrate Ark and Lightning Network to provide a seamless experience for your users.
|
||||
- Accept Bitcoin payments in your ecommerce store or point of sale.
|
||||
- Create virtual payment channels between your users.
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
description: Detailed information about the protocol, guidance on providing liquidity, and instructions on how to efficiently spend your coins off-chain in a secure manner
|
||||
sidebar_position: 1
|
||||
slug: /
|
||||
title: Introduction
|
||||
---
|
||||
|
||||
**Welcome to Ark's developer hub.** Here, you'll find detailed information about the protocol, guidance on providing liquidity, and instructions on how to efficiently spend your coins off-chain in a secure manner.
|
||||
|
||||
<div align="center">
|
||||
<img src="/img/ark-banner.png" alt="Noah designing the ark to onboard Bitcoin users"/>
|
||||
</div>
|
||||
|
||||
### 🤔 Why Ark?
|
||||
|
||||
Bitcoin is the world's most secure and censorship-resistant blockchain. However, it's not the fastest or the cheapest. Ark is a **second-layer solution** designed to **scale Bitcoin transactions**. It uses a shared UTXO model for confidential and off-chain payments through an intermediary server that cannot access your funds.
|
||||
|
||||
### 👶🏼 ELI5: Ark in Simple Terms
|
||||
|
||||
Consider the early private banks that issued banknotes in exchange for gold deposits. These banknotes were redeemable for gold at any time. The banknotes were more convenient to use than gold, but they were only as good as the bank that issued them. If the bank went bankrupt, the banknotes would become worthless.
|
||||
|
||||
When Alice **deposits Bitcoin with a server** (akin to a digital bank), she receives a digital check, similar to a banknote but with a crucial difference. This check is akin to **a cheque with an expiration date**.
|
||||
|
||||
The digital cheque Alice receives comes with an expiration date. To keep her funds secure and the cheque valid, she **must interact with the server at least once every month**. If Alice fails to do this, the server reserves the right to **claim the Bitcoin backing the cheque upon its maturity**.
|
||||
|
||||
She can use this check for payment with anyone else using the same digital bank, bypassing the need to use the Bitcoin blockchain. Before expiration, the check can be **redeemed** for Bitcoin, or it can be **refreshed** by interacting with the server.
|
||||
|
||||
Should the digital bank cease to exist, **users can still retrieve their digital gold without the bank's assistance**. This is similar to withdrawing gold from a defunct traditional bank, but in Ark's case, the process is enforced and automated by the Bitcoin blockchain. This ensures that your digital gold remains safe and accessible.
|
||||
|
||||
### 🔨 How Does it Work?
|
||||
|
||||
Start by exploring the [Nomenclature](./learn/nomenclature.md) to familiarize yourself with key concepts and terminology. Then, learn how to [Board the Ark](./learn/boarding.md), [Send Payments](./learn/payments.md), and eventually [Leave the Ark](./learn/leaving.md) to withdraw your funds back to the Bitcoin blockchain in case of server unresponsiveness.
|
||||
|
||||
### 🏃♀️ Running Ark
|
||||
|
||||
:::info
|
||||
🚧 **Work in progress**
|
||||
The Ark reference implementation is currently under development. Please check back soon for updates.
|
||||
:::
|
||||
|
||||
You can join an existing Ark service provider or run your own.
|
||||
|
||||
- [Join an Ark as User](./user/intro.md)
|
||||
- [Operate an Ark as Liquidity Provider](./provider/intro.md)
|
||||
|
||||
### 👩💻 Integrate Ark
|
||||
|
||||
:::info
|
||||
🚧 **Work in progress**
|
||||
The Ark libraries and developer tools are currently under development. Please check back soon for updates.
|
||||
:::
|
||||
|
||||
You can [integrate Ark](./developers/get-started.md) into your wallet or application to enable your users to send and receive Bitcoin payments off-chain.
|
||||
|
||||
### ⌨️ Contributing
|
||||
|
||||
We welcome contributions from the community. If you'd like to contribute to the reference implementation, please see the [Ark GitHub repository](https://github.com/ark-network/ark) repository.
|
||||
|
||||
### 🤓 Protocol Specifications
|
||||
|
||||
Follow the [BOATS GitHub repository](https://github.com/ark-network/boats) for updates.
|
||||
|
||||
### ➰ Stay in the Loop
|
||||
|
||||
- Join our community on [Telegram](https://t.me/ark_network_community).
|
||||
- Ask questions or get help on [Stack Overflow](https://bitcoin.stackexchange.com/questions/tagged/ark).
|
||||
- To propose protocol improvements, [open an issue on GitHub](https://github.com/ark-network/boats/issues/new).
|
||||
|
||||
### ⚖️ License
|
||||
|
||||
By contributing to this repository, you agree to license your work under the MIT license, unless specified otherwise. Contributions not originally authored by you must include a license header with the original author(s) and source.
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Learn",
|
||||
"position": 1
|
||||
}
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: 'Boarding the Ark'
|
||||
---
|
||||
|
||||
### Overview
|
||||
|
||||
Alice wants to board the Ark of a well-known Ark service provider (ASP). It requires an on-chain transaction.
|
||||
|
||||
Depending on the type of [Boarding transaction](./nomenclature#boarding-transaction) chosen by the ASP, the timeline is different.
|
||||
|
||||
### 🧳 Boarding with Luggage
|
||||
|
||||
- Alice must be online **at least once every 4 weeks** to keep her funds safe
|
||||
- If ASP is unresponsive, Alice can claim her funds back in **24 hours**
|
||||
- Easier for the ASP since all VTXOs are born equal
|
||||
- To unlock the boarding address Alice needs to make two transactions:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
V["VTXO's timeout after 24 hrs"]
|
||||
Covenant --> V
|
||||
```
|
||||
|
||||
#### Timeline of events
|
||||
|
||||
1. Alice creates a [Boarding transaction](./nomenclature#with-luggage)
|
||||
2. Alice adds any inputs she wants to cover the values the [VTXO](./nomenclature#vtxo-1) she will receive, plus on-chain fees
|
||||
3. Alice adds an output with **2 spending paths**:
|
||||
- This funds will belong to the ASP after 4 weeks:
|
||||
- `(ASP after 4w)`
|
||||
- A covenant output that forces coins to be spent by a [VTXO](./nomenclature#vtxo-1) with an output script with **2** spending paths:
|
||||
- `(Alice + ASP)`
|
||||
- `(Alice after 24h)`
|
||||
4. Alice notifies ASP about the [Boarding transaction](./nomenclature#with-luggage)
|
||||
5. Alice has now a promise of a [VTXO](./nomenclature#vtxo-1) enforced by a covenant
|
||||
|
||||
### 🎒 Boarding without Luggage
|
||||
|
||||
- Alice don't need to worry about being online to maintain access to her funds after boarding
|
||||
- If ASP is unresponsive, Alice can claim her funds back in **1 year**
|
||||
- ASP must be aware of the timeout on the [Boarding transaction](./nomenclature#without-luggage) to prevent double spending
|
||||
|
||||
#### Timeline of events
|
||||
|
||||
1. Alice creates a [Boarding transaction](./nomenclature#without-luggage)
|
||||
2. Alice adds any inputs she wants to cover the values the [VTXO](./nomenclature#vtxo-1) she will receive, plus on-chain fees.
|
||||
3. Alice adds an output with **2** spending paths:
|
||||
- `(Alice + ASP)`
|
||||
- `(Alice after 1y)`
|
||||
4. Alice notifies ASP about the [Boarding transaction](./nomenclature#without-luggage)
|
||||
5. Alice can have this deposit to be accepted as if it were a normal [VTXO](./nomenclature#vtxo-1) born in an Ark [Pool transaction](./nomenclature#pool-transaction-aka-ark-transaction)
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
title: 'Leaving the Ark'
|
||||
---
|
||||
|
||||
### Overview
|
||||
|
||||
Alice wants to leave the Ark and get her funds back on-chain. It requires an on-chain transaction.
|
||||
|
||||
### Cooperative exit
|
||||
|
||||
#### Timeline of events
|
||||
|
||||
1. Alice tells ASP she wants to trade [VTXO](./nomenclature#vtxo-1) for UTXO
|
||||
2. ASP (with Alice) prepares next [Pool transaction](./nomenclature#pool-transaction-aka-ark-transaction):
|
||||
- an additional output is added, locked by `Alice`
|
||||
3. Alice creates a [Forfeit transaction](./nomenclature#forfeit-transaction):
|
||||
- spends from VTXO (1) with `Alice + ASP`
|
||||
- adds connector output from Pool transaction (2) as input
|
||||
- signs it and send it to the ASP
|
||||
4. ASP broadcasts [Pool transaction](./nomenclature#pool-transaction-aka-ark-transaction)
|
||||
5. Alice has now a new UTXO
|
||||
6. For at most 4 weeks, Alice will be able to double spend her [VTXO](./nomenclature#vtxo-1), but if she does it, the ASP will have time (24 hours) to grab the funds from the [VTXO](./nomenclature#vtxo-1) to itself using the [Forfeit transaction](./nomenclature#forfeit-transaction)
|
||||
|
||||
### Non-cooperative exit
|
||||
|
||||
If ASP is unresponsive, Alice can unilaterally exit revealing the branch of the Pool transaction that locks her funds.
|
||||
|
||||
#### Timeline of events
|
||||
|
||||
1. Assuming a [VTXO](./nomenclature#vtxo-1) tree with radix of 2 and 8 [VTXOs](./nomenclature#vtxo-1):
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
tx1(TX 1) --> tx2(TX 2)
|
||||
tx1 --> tx3(TX 3)
|
||||
tx2 --> tx4(TX 4)
|
||||
tx2 --> tx5(TX 5)
|
||||
tx3 --> tx6(TX 6)
|
||||
tx3 --> tx7(TX 7)
|
||||
tx4 --> v1(VTXO 1)
|
||||
tx4 --> v2(VTXO 2)
|
||||
tx5 --> v3(VTXO 3)
|
||||
tx5 --> v4(VTXO 4)
|
||||
tx6 --> v5(VTXO 5)
|
||||
tx6 --> v6(VTXO 6)
|
||||
tx7 --> v7(VTXO 7)
|
||||
tx7 --> v8(VTXO 8)
|
||||
```
|
||||
|
||||
2. Assuming VTXO 1 and 2 belong to Alice and Bob
|
||||
3. Alice reveals the [VTXO](./nomenclature#vtxo-1) tree to spend the [Shared Output](./nomenclature#shared-output-aka-shared-utxo).
|
||||
4. Alice doesn't need to reveal the entire tree, just enough to validate it:
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
tx1(TX 1) --> tx2(TX 2)
|
||||
tx1 --> tx3(TX 3)
|
||||
tx2 --> tx4(TX 4)
|
||||
tx2 --> tx5(TX 5)
|
||||
tx4 --> v1(VTXO 1)
|
||||
tx4 --> v2(VTXO 2)
|
||||
```
|
||||
|
||||
5. Alice will need to wait 24 hours to be able to spend her [VTXO](./nomenclature#vtxo-1). This gives enough time to the ASP to prevent any double spend attempts by Alice.
|
||||
6. Bob can also spend his [VTXO](./nomenclature#vtxo-1) in 24 hours, or do nothing and maintain his [VTXO](./nomenclature#vtxo-1) on the Ark.
|
||||
@@ -1,155 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: 'Nomenclature'
|
||||
toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
:::info
|
||||
🚧 This page is currently under development, and some concepts may not be entirely accurate. We greatly value your feedback and contributions. If you have any suggestions, corrections, or would like to submit edits, please do so through the pull request link available at the bottom of each page.
|
||||
:::
|
||||
|
||||
## Intervenients
|
||||
|
||||
### ASP
|
||||
|
||||
ASPs are always-on servers that provide liquidity to the network, similar to how Lightning service providers work.
|
||||
|
||||
### Users
|
||||
|
||||
Any user that onboards the Ark or receives a payment inside an Ark.
|
||||
|
||||
### VTXO
|
||||
|
||||
Ark has a UTXO set that lives off the chain. These utxos are referred to as virtual UTXOs or VTXOs in short.
|
||||
|
||||
## Moments
|
||||
|
||||
### Boarding the Ark
|
||||
|
||||
When a User sends funds to the Ark and gets VTXOs in return.
|
||||
|
||||
### Unilateral exit
|
||||
|
||||
When a user decides to withdraw his funds from the Ark to mainchain, without asking the ASP for permission.
|
||||
|
||||
### Round
|
||||
|
||||
Periodic transaction crafted by the ASP that hits mainchain and creates new VTXOs.
|
||||
|
||||
## Transactions
|
||||
|
||||
### Notes
|
||||
|
||||
- In an optimistic scenario, transactions marked with a **\*** should never hit onchain.
|
||||
- All time periods used on timelocks (**5s**, **24h**, **4w**, **1y**) are arbitrary: any ASP can use different values.
|
||||
|
||||
### Legend
|
||||
|
||||
- **A**: Alice pubkey
|
||||
- **ASP**: ASP pubkey
|
||||
- **cov\*\*(script)**: covenant that forces the spending transaction to have a mandatory first output with the **script**
|
||||
- **and(A,B)**: both conditions needed to unlock
|
||||
- **or(A,B)**: only one condition needed to unlock
|
||||
- **and(A, or(S, after(24h)**: (Alice and Server) or (Alice after 24h)
|
||||
|
||||
### VTXO\*
|
||||
|
||||
- A Virtual UTXO: it looks like an UTXO but it should never hit onchain, thus a Virtual UTXO
|
||||
|
||||
| Inputs | Outputs |
|
||||
| ---------------------------- | ------------------------------------ |
|
||||
| Boarding or Pool transaction | `(Alice + ASP) or (Alice after 24h)` |
|
||||
|
||||
### Boarding transaction
|
||||
|
||||
There are 2 different ways a user can board the Ark:
|
||||
|
||||
- With luggage
|
||||
- Without luggage
|
||||
|
||||
Different ASPs can use different ways for users to board their Ark.
|
||||
|
||||
#### With luggage
|
||||
|
||||
- Initially proposed by [Steven Roose](https://roose.io/presentations/understanding-ark.pdf)
|
||||
- Alice funds an output that can be **accepted as a VTXO** in a future round
|
||||
- A covenant forces the creation of an output with the same script as [**VTXO**](#vtxo-1). No need for interactivity after funding it, anyone can spend.
|
||||
- **ASP** can unlock after a timeout ie. _4 weeks_
|
||||
- Alice is **required to be online** to maintain access to funds: after the timeout, ASP becomes the only owner funds
|
||||
|
||||
| Inputs | Outputs |
|
||||
| ------------ | ----------------------------------------------------------- |
|
||||
| Alice’s UTXO | `(ASP after 4w) or cov((Alice + ASP) or (Alice after 24h))` |
|
||||
|
||||
#### Without luggage
|
||||
|
||||
- Initially proposed by [Burak](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021694.html)
|
||||
- Alice funds an output that can be **accepted as a VTXO** in a future round
|
||||
- If ASP is not cooperative, **Alice** can unlock after a timeout ie. _1 year_
|
||||
- Alice is **not required to be online** to maintain access to funds: after the timeout, she becomes the only owner of the funds
|
||||
|
||||
| Inputs | Outputs |
|
||||
| ------------ | ----------------------------------- |
|
||||
| Alice’s UTXO | `(Alice after 1y) or (Alice + ASP)` |
|
||||
|
||||
### Forfeit transaction\*
|
||||
|
||||
- Insurance for the ASP, in case Alice tries to double spend her VTXO after spending it inside Ark
|
||||
- Before the ASP funds Bob’s VTXO in the next Pool transaction, he must receive this transaction signed by Alice
|
||||
- Uses a connector from the next Pool transaction to achieve atomicity
|
||||
|
||||
| Inputs | Outputs |
|
||||
| ------------------------------------ | ------- |
|
||||
| VTXO spending `Alice + ASP` | `ASP` |
|
||||
| Connector from next Pool transaction |
|
||||
|
||||
### Pool transaction (aka Ark transaction)
|
||||
|
||||
- Funded by the ASP, creates VTXOs
|
||||
- Has at least two outputs:
|
||||
- A shared output with a VTXOs tree
|
||||
- A connectors output with a connectors tree
|
||||
- A new transaction is broadcasted every 5 seconds
|
||||
|
||||
| Inputs | Outputs |
|
||||
| -------- | ----------------- |
|
||||
| ASP UTXO | Shared output |
|
||||
| | Connectors output |
|
||||
|
||||
### Shared output (aka Shared UTXO)
|
||||
|
||||
- Represents a tree of transactions
|
||||
- In an optimistic scenario, this tree is never revealed
|
||||
- Each leaf on this tree represents a VTXO
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Onchain
|
||||
shared(Shared output)
|
||||
end
|
||||
subgraph Virtual
|
||||
tx1(TX 1) --> tx2(TX 2)
|
||||
tx1 --> tx3(TX 3)
|
||||
tx2 --> v1(VTXO 1)
|
||||
tx2 --> v2(VTXO 2)
|
||||
tx3 --> v3(VTXO 3)
|
||||
tx3 --> v4(VTXO 4)
|
||||
end
|
||||
shared --> tx1
|
||||
```
|
||||
|
||||
- Tree can have a radix higher than 2 (ex: radix 4)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Onchain
|
||||
shared(Shared output)
|
||||
end
|
||||
subgraph Virtual
|
||||
tx1(TX 1) --> v1(VTXO 1)
|
||||
tx1 --> v2(VTXO 2)
|
||||
tx1 --> v3(VTXO 3)
|
||||
tx1 --> v4(VTXO 4)
|
||||
end
|
||||
shared --> tx1
|
||||
```
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
title: 'Payments'
|
||||
---
|
||||
|
||||
### Overview
|
||||
|
||||
Alice wants to send funds to Bob inside the Ark.
|
||||
|
||||
- All Ark payments and transactions are off-chain.
|
||||
- Bob doesn't need to have funds inside the Ark to receive funds. (ie. inbound liquidity problem)
|
||||
- Bob doesn't need to be online to receive funds
|
||||
- Bob wil be required to be online **at least once every 4 weeks** to keep his funds safe.
|
||||
|
||||
### Timeline of events
|
||||
|
||||
1. Alice tells ASP to send [VTXO](./nomenclature#vtxo-1) to Bob
|
||||
2. ASP (with Alice) prepares next [Pool transaction](./nomenclature#pool-transaction-aka-ark-transaction)
|
||||
3. Alice creates a [Forfeit transaction](./nomenclature#forfeit-transaction):
|
||||
- spends from VTXO (1) via `Alice + ASP`
|
||||
- adds connector output from Pool transaction (2) as input
|
||||
- signs (SIGHASH_ALL) and sends it to the ASP
|
||||
4. ASP broadcasts [Pool transaction](./nomenclature#pool-transaction-aka-ark-transaction)
|
||||
5. Bob has now a new [VTXO](./nomenclature#vtxo-1)
|
||||
6. For at most 4 weeks, Alice will be able to double spend her [VTXO](./nomenclature#vtxo-1), but if she does it, the ASP will have time to grab the funds from the [VTXO](./nomenclature#vtxo-1) to itself using the [Forfeit transaction](./nomenclature#forfeit-transaction)
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Create an Ark",
|
||||
"position": 3
|
||||
}
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Coordinator",
|
||||
"position": 3
|
||||
}
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
title: Configure the CLI
|
||||
---
|
||||
|
||||
Now that your service is up and running you can configure the `coordinator` CLI to interact with it.
|
||||
|
||||
The CLI makes use of a configuration file stored in its datadir - defaults to `~/.coordinator-cli` on Linux, `~/Library/Application\ Support/Coordinator-cli` on MacOS.
|
||||
|
||||
You can customize the datadir path of your coordinator cli by exporting the environment variable `export ARK_COORDINATOR_CLI_DATADIR=path/to/datadir`.
|
||||
|
||||
:::tip
|
||||
Add this env var to your bash profile otherwise you'll need to always export it when running `coordinator` commands.
|
||||
:::
|
||||
|
||||
You can manage the configuration of your CLI with the features of the `coordinator config` command. Following, you can learn all what you can do with this command.
|
||||
|
||||
### Initialize CLI config
|
||||
|
||||
You can initialize the configuration of your CLI by the means of flags
|
||||
|
||||
```bash
|
||||
$ coordinator config init
|
||||
```
|
||||
|
||||
This command brings the configuration of your CLI to its default status unless you don't specify a flag for those params you want to tweak.
|
||||
|
||||
Run `coordinator config init --help` to see all available configuration flags.
|
||||
|
||||
### Customize CLI config
|
||||
|
||||
You can change granular params of the CLI's configuration by using the `set` subcommand as shown below:
|
||||
|
||||
```bash
|
||||
$ coordinator config set no-tls true
|
||||
```
|
||||
|
||||
### Show CLI config
|
||||
|
||||
You can take a look at the configuration of your CLI with:
|
||||
|
||||
```bash
|
||||
$ coordinator config
|
||||
```
|
||||
|
||||
You've learned everything about configuring the CLI, let's see how it does let you interact with the Coordinator.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
title: Configure the Coordinator
|
||||
---
|
||||
|
||||
The Coordinator can be configured by exporting environment variables at startup, or by adding a configuration file to its datadir.
|
||||
|
||||
### Configure with environment variables
|
||||
|
||||
The following table lists all the environment variables available, along with a brief description and their default values:
|
||||
|
||||
| Name | Description | Default Value |
|
||||
|---|---|---|
|
||||
| ARK_COORDINATOR_DATADIR | Let's you change the service's datadir path | `~/.coordinatord` (Linux).<br/><br/>`~/Library/Application\ Support/Coordinatord` (MacOS). |
|
||||
|
||||
### Configure with file
|
||||
|
||||
You can configure the Coordinator by adding a `config.json` file to its datadir.
|
||||
|
||||
Below, you can see all the props you can add to the config file:
|
||||
|
||||
```json
|
||||
{
|
||||
//TBD
|
||||
}
|
||||
```
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Overview
|
||||
---
|
||||
|
||||
# Ark Coordinator
|
||||
|
||||
The Coordinator handles the perpetual creation of new Ark rounds every 5 seconds.
|
||||
|
||||
It can be served in one of the following ways:
|
||||
|
||||
* [Dockerized application](run-docker.md)
|
||||
* [Standalone application](run-standalone.md)
|
||||
|
||||
<!-- any dependency? -->
|
||||
|
||||
Once your coordinator is up and running you can [configure the CLI](configure-cli.md) to interact with it.
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
title: Run with Docker
|
||||
---
|
||||
|
||||
The Coordinator can be served as a dockerized application by following the steps below:
|
||||
|
||||
1. Install [Docker](https://docs.docker.com/engine/install) - if you're on Linux, don't forget the [post-installation steps](https://docs.docker.com/engine/install/linux-postinstall/)!
|
||||
2. Download the latest image of the connector with `docker pull ghcr.io/ark-network/coordinatord:latest`
|
||||
3. Create a `coordinatord/` folder in your current directory - to mount the datadir as external volume - and start the dockerized service with
|
||||
|
||||
```bash
|
||||
$ docker run -it -d --name coordinatord \
|
||||
-u
|
||||
-v "$(pwd)/coordinatord:/home/ark/.coordinatord" \
|
||||
-e ARK_COORDINATOR_LOG_LEVEL=5 \
|
||||
ghcr.io/ark-network/coordinatord:latest
|
||||
```
|
||||
|
||||
You can check the logs of the service at anytime by running `docker logs coordinatord`.
|
||||
|
||||
The dockerized Coordinator can be configured by the means of environment variables or by adding a `config.json` file to the `coordinatord/` folder you've created. Learn more about this by visiting [this section](configure-service.md).
|
||||
|
||||
The service comes also with an embedded CLI, so it's enough for you to create an alias like the following to use it:
|
||||
|
||||
```bash
|
||||
$ alias coordinator="docker exec coordinatord coordinator"
|
||||
```
|
||||
|
||||
Take a look at how to [configure the CLI](configure-cli.md) before start interacting with the running Coordinator.
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: Run Standalone
|
||||
---
|
||||
|
||||
The Coordinator can be served as a standalone binary by following the steps below:
|
||||
|
||||
1. Download the lastest [release](https://github.com/ark-network/ark-coordinator/releases) of the service and the CLI for Linux or MacOS.
|
||||
2. Rename the binaries `coordinatord` and `coordinator` , move them to your _PATH_ (eg. `/usr/local/bin`), and grant them exec permissions with `chmod +x /usr/local/bin/coordinatord` and `chmod +x /usr/local/bin/coordinator`.
|
||||
3. Start the service with
|
||||
|
||||
```bash
|
||||
ARK_COORDINATOR_LOG_LEVEL=5
|
||||
coordinatord & > ~/ark-logs/coordinator.logs.txt &
|
||||
```
|
||||
|
||||
The command above redirects all the logs to the file `~/ark-logs/coordinator.logs.txt`. Therefore you can check the logs of the service at anytime by consulting that file.
|
||||
|
||||
The Coordinator service makes use of a datadir - defaults to `~/.coordinatord` on Linux, `~/Library/Application\ Support/Coordinatord` on MacOS - that can be customized by exporting the environment variable `export ARK_COORDINATOR_DATADIR=path/to/datadir` at its startup.
|
||||
|
||||
You can configure the Coordinator by the means of environment variables or by adding a `config.json` file to the service's datadir. Learn more about this by visiting [this section](configure-service.md).
|
||||
|
||||
Once the service is started you can [configure the CLI](configure-cli.md) and start interacting with it.
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
sidebar_position: 6
|
||||
title: Use the CLI
|
||||
---
|
||||
|
||||
Now that your CLI is configured to connect with the running Coordinator, let's take a look at what it makes you capable of.
|
||||
|
||||
### List pool transactions
|
||||
|
||||
You can retrieve the list of pool transactions made in a certain time range with:
|
||||
|
||||
```bash
|
||||
$ coordinator pools --start --end
|
||||
```
|
||||
|
||||
You can omit the `--end` flag if you want to retrieve all pool transactions from a certain time unitl now.
|
||||
|
||||
For each pool tx, you can see details like the txid, status, and amount of liquidity added to the Ark.
|
||||
|
||||
You can also list all pool transactions created so far with:
|
||||
|
||||
```bash
|
||||
$ coordinator pools --all
|
||||
```
|
||||
|
||||
Run `coordinators pools --help` to see the full list of available flags.
|
||||
|
||||
### Get pool transaction details
|
||||
|
||||
You can get details about a specific pool transaction with:
|
||||
|
||||
```bash
|
||||
$ coordinator pool --id <txid>
|
||||
```
|
||||
|
||||
### Register inputs and outptus
|
||||
|
||||
You can manually register the VTXOs you're going to spend and the related receivers with:
|
||||
|
||||
```bash
|
||||
$ coordinator register --inputs '[{"txid": "<txid>", "vout": <vout>}]' --outputs '[{"pubkey": "<pubkey>", "amount": <amount>}]'
|
||||
```
|
||||
|
||||
The Coordinator answers with a message containing the virtual (forfeit) transaction spending your coins and the list of all the new VTXOs created in the next round - including those you registered.
|
||||
|
||||
<!-- Ref to some toool that allows to revealing the congestion control tree -->
|
||||
|
||||
### Finalize input and outputs
|
||||
|
||||
Once you signed the virtual transaction you can send it back to the Coordinator and finalize the process with:
|
||||
|
||||
```bash
|
||||
$ coordinator finalize --vtx <signed_vtx>
|
||||
```
|
||||
|
||||
In response you get the id of the pool transaction that is going to be broadcasted by the server.
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Gateway",
|
||||
"position": 2
|
||||
}
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Overview
|
||||
---
|
||||
|
||||
# Ark Gateway
|
||||
|
||||
The Gateway handles users' requests to onboard (join) and offboard (leave) the Ark.
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
The Ark Service Provider (ASP) is composed by 3 services that have different responsibilities:
|
||||
|
||||
- Gateway, handles (on/off)boarding requests
|
||||
- Coordinator, handles coinjoin rounds and creation of pool txs (every 5 secs)
|
||||
- Treasury, handles verification & approval of pool txs, and operations altering the capacity of the service
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Treasury",
|
||||
"position": 4
|
||||
}
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Overview
|
||||
---
|
||||
|
||||
# Ark Treasury
|
||||
|
||||
The Treasury is in charge of verifying and approving pool transactions created by the Coordinator.
|
||||
|
||||
It does also handles the management of the ASP capacity - ie. depositing or removing funds - and liquidity - monitoring/sweeping expired VTXOs.
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Roadmap",
|
||||
"position": 5
|
||||
}
|
||||
@@ -1,84 +0,0 @@
|
||||
# Roadmap
|
||||
|
||||
The roadmap provides an overview of the planned projects and modules for the Ark network. It outlines the current development status and expected functionalities of each module. Please note that the roadmap is subject to change as the project evolves.
|
||||
|
||||
For the latest updates and progress reports, please check the this page regularly.
|
||||
|
||||
## Projects
|
||||
|
||||
### ☁️ `arkd` - Ark Service Provider Daemon
|
||||
|
||||
- Status: Pre-Alpha
|
||||
|
||||
The `arkd` is the Ark daemon, the initial implementation of an ASP (Ark Service Provider) as a standalone always-on server.
|
||||
It uses [Ocean](https://github.com/vulpemventures/ocean) as Bitcoin and Liquid wallet backend.
|
||||
It exposes a gRPC interface that Ark wallets can use to interact with the Provider.
|
||||
|
||||
- [x] Setup Ocean Wallet for funding rounds
|
||||
- [ ] Start producing rounds from Ark wallets
|
||||
- [x] Register VTXOs to be spent & new VTXOs to be created
|
||||
- [x] Build congestion control tree
|
||||
- [x] Root node
|
||||
- [x] VTXOs Script
|
||||
- [x] Tap Leaf Script Validation
|
||||
- [x] Unroll Clause Transaction Builder.
|
||||
- [ ] Verifiy forfeit transactions
|
||||
- [x] Sign & Broadcast Pool transactions
|
||||
- [x] Sweep expired VTXOs
|
||||
- [ ] Accept VTXOs from Boarding transactions
|
||||
- [ ] Detect double spends to recover with forfeit transactions
|
||||
|
||||
### 🌐 Ark Explorer
|
||||
|
||||
Status: Not started yet
|
||||
|
||||
The Ark Explorer module will consist of a console and an Electrum-like server. It will allow users to retrieve VTXOs, pool transactions, and access transaction data. More details about this module will be provided as development progresses.
|
||||
|
||||
### 👩💻 `ark` - Ark CLI
|
||||
|
||||
- Status: Pre-Alpha
|
||||
|
||||
The `ark` module will be an Ark wallet implemented as a command line interface (CLI). It will also be in the alpha status, indicating that it is still being developed and may have some limitations.
|
||||
|
||||
- [x] Create and manage Ark wallets
|
||||
- [x] Connect to an Ark Service Provider.
|
||||
- [ ] Send and receive Ark transactions
|
||||
- [x] Join a round
|
||||
- [ ] Validate Tree and Sign forfeit transaction
|
||||
- [x] Finalize a Tree
|
||||
- [ ] on-boarding
|
||||
- [ ] Boarding address Script
|
||||
- [ ] Tap Leaf Script Validation
|
||||
- [ ] off-boarding
|
||||
- [x] Cooperative exit
|
||||
- [ ] Unilateral exit
|
||||
|
||||
### 🚰 Ark Faucet
|
||||
|
||||
Status: Alpha
|
||||
|
||||
The Ark Faucet allows users to request testnet VTXOs for testing purposes, without having to onboard to the Ark provider.
|
||||
|
||||
### 📱 Ark Mobile App
|
||||
|
||||
Status: Not started yet
|
||||
|
||||
The Ark App module will serve as a reference implementation for an Ark wallet as Mobile App. It will provide a user-friendly interface for managing Ark transactions and other wallet-related functionalities.
|
||||
|
||||
### 🖥️ Ark Desktop App
|
||||
|
||||
Status: Not started yet
|
||||
|
||||
The Ark Desktop module will be a reference implementation for an Ark wallet as a desktop application. It will provide a user-friendly interface for managing Ark transactions and other wallet-related functionalities.
|
||||
|
||||
### 👨🏻💻 Ark SDK
|
||||
|
||||
Status: Not started yet
|
||||
|
||||
Rust-based SDK with first-class support Java, Swift and JavaScript bindings for implementing Ark wallets and interacting with ASPs. It will provide a set of APIs for managing wallets, transactions, and other Ark-related functionalities.
|
||||
|
||||
### 🗼 Ark Tower
|
||||
|
||||
Status: Not started yet
|
||||
|
||||
Delegate automatic refereshes of VTXOs to trust-minimized Ark Tower nodes. Additional information about this module will be shared as development continues.
|
||||
@@ -1,4 +0,0 @@
|
||||
{
|
||||
"label": "Join the Ark",
|
||||
"position": 4
|
||||
}
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: Ark CLI
|
||||
---
|
||||
|
||||
The Ark CLI allows you to interact with the Ark Service Provider (ASP). It is a command line tool that can be used to create and manage your Ark Wallet.
|
||||
|
||||
## Configure the CLI
|
||||
|
||||
The CLI requires an initial setup to initialize the wallet and connect to the ASP:
|
||||
|
||||
```bash
|
||||
$ ark init init --password <PASSWORD> --ark-url <ARK_URL>
|
||||
```
|
||||
|
||||
You can also restore a wallet by specifying the hex encoded private key with the `--prvkey` flag.
|
||||
|
||||
## Receive VTXO
|
||||
|
||||
### Get receiving address
|
||||
|
||||
You can print your onchain and offchain receiving addresses to receive funds with:
|
||||
|
||||
```bash
|
||||
$ ark receive
|
||||
```
|
||||
|
||||
This command also shows the list of relays used to reach the ASP.
|
||||
|
||||
:::tip
|
||||
testnet only: `ark faucet` to receive newly created VTXO from the service provider.
|
||||
:::
|
||||
|
||||
### Print balance
|
||||
|
||||
You can see both the onchain and offchain balance of the wallet with:
|
||||
```bash
|
||||
$ ark balance
|
||||
```
|
||||
|
||||
## Send VTXO(s)
|
||||
|
||||
You can make an offchain payment by sending to either one or many receivers:
|
||||
|
||||
```bash
|
||||
$ ark send --to <ARK_ADDRESS> --amount <AMOUNT>
|
||||
$ ark send --receivers '[{"to": "<ARK_ADDRESS>", "amount": <AMOUNT>}, ...]'
|
||||
```
|
||||
|
||||
The amount must be specified in _sats_ unit.
|
||||
|
||||
## Redemption
|
||||
|
||||
### Collaborative redemption
|
||||
|
||||
You can redeem onchain your funds by collaborating with the ASP with:
|
||||
|
||||
```bash
|
||||
$ ark redeem --address <ONCHAIN_ADDRESS> --amount <AMOUNT>
|
||||
```
|
||||
|
||||
Any change produced with this operation goes to your offchain address.
|
||||
|
||||
### Unilateral redemption
|
||||
|
||||
If the ASP is unresponsive you can redeem all your offchain funds unilaterally with:
|
||||
|
||||
```bash
|
||||
$ ark redeem --address <ONCHAIN_ADDRESS> --force
|
||||
```
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Overview
|
||||
---
|
||||
|
||||
An Ark client is a software that allows users to interact with the Ark Service Provider. It can be a Browser Extension, a Progressive Web Application, a desktop or mobile app.
|
||||
@@ -1,162 +0,0 @@
|
||||
// @ts-check
|
||||
// Note: type annotations allow type checking and IDEs autocompletion
|
||||
|
||||
const lightCodeTheme = require('prism-react-renderer/themes/synthwave84')
|
||||
const darkCodeTheme = require('prism-react-renderer/themes/dracula')
|
||||
|
||||
/** @type {import('@docusaurus/types').Config} */
|
||||
const config = {
|
||||
title: 'Ark',
|
||||
tagline: 'TBD',
|
||||
favicon: 'img/ark-logo.png',
|
||||
url: 'https://arkdev.info',
|
||||
baseUrl: '/',
|
||||
organizationName: 'Ark',
|
||||
projectName: 'Ark Website',
|
||||
onBrokenLinks: 'throw',
|
||||
onBrokenMarkdownLinks: 'warn',
|
||||
i18n: {
|
||||
defaultLocale: 'en',
|
||||
locales: ['en'],
|
||||
},
|
||||
|
||||
presets: [
|
||||
[
|
||||
'classic',
|
||||
/** @type {import('@docusaurus/preset-classic').Options} */
|
||||
({
|
||||
docs: {
|
||||
routeBasePath: '/docs',
|
||||
sidebarPath: require.resolve('./sidebars.js'),
|
||||
editUrl: 'https://github.com/ark-network/ark/edit/master/website/',
|
||||
exclude: [
|
||||
'**/provider/gateway/**',
|
||||
'**/provider/coordinator/**',
|
||||
'**/provider/treasury/**',
|
||||
'**/user/ark-cli.md',
|
||||
],
|
||||
},
|
||||
blog: {
|
||||
showReadingTime: true,
|
||||
editUrl:
|
||||
'https://github.com/ark-network/ark/edit/master/website/blog',
|
||||
|
||||
blogTitle: 'Blog',
|
||||
blogDescription: 'Posts about Ark development',
|
||||
},
|
||||
}),
|
||||
],
|
||||
],
|
||||
|
||||
themeConfig:
|
||||
/** @type {import('@docusaurus/preset-classic').ThemeConfig} */
|
||||
({
|
||||
// Replace with your project's social card
|
||||
image: 'img/ark-banner.png',
|
||||
navbar: {
|
||||
title: 'Ark',
|
||||
logo: {
|
||||
alt: 'Ark Logo',
|
||||
src: 'img/ark-logo.png',
|
||||
srcDark: 'img/ark-logo.png',
|
||||
},
|
||||
items: [
|
||||
{
|
||||
type: 'docSidebar',
|
||||
sidebarId: 'tutorialSidebar',
|
||||
position: 'left',
|
||||
label: 'Docs',
|
||||
},
|
||||
{ to: '/blog', label: 'Blog', position: 'left' },
|
||||
{
|
||||
href: 'https://github.com/ark-network',
|
||||
label: 'GitHub',
|
||||
position: 'right',
|
||||
},
|
||||
],
|
||||
},
|
||||
footer: {
|
||||
links: [
|
||||
{
|
||||
title: 'LEARN',
|
||||
items: [
|
||||
{
|
||||
label: 'Nomenclature',
|
||||
to: '/docs/learn/nomenclature',
|
||||
},
|
||||
{
|
||||
label: 'Board an Ark',
|
||||
to: '/docs/learn/boarding',
|
||||
},
|
||||
{
|
||||
label: 'Send Payments',
|
||||
to: '/docs/learn/payments',
|
||||
},
|
||||
{
|
||||
label: 'Leave an Ark',
|
||||
to: '/docs/learn/leaving',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'DOCS',
|
||||
items: [
|
||||
{
|
||||
label: 'Overview',
|
||||
to: '/docs',
|
||||
},
|
||||
{
|
||||
label: 'Join an Ark',
|
||||
to: '/docs/user/intro',
|
||||
},
|
||||
{
|
||||
label: 'Create an Ark',
|
||||
to: '/docs/provider/intro',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'COMMUNITY',
|
||||
items: [
|
||||
{
|
||||
label: 'Telegram',
|
||||
href: 'https://t.me/ark_network_community',
|
||||
},
|
||||
{
|
||||
label: 'Stack Exchange',
|
||||
href: 'https://bitcoin.stackexchange.com/questions/tagged/ark',
|
||||
},
|
||||
{
|
||||
label: 'Github',
|
||||
href: 'https://github.com/ark-network',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'MORE',
|
||||
items: [
|
||||
{
|
||||
label: 'Blog',
|
||||
to: '/blog',
|
||||
},
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
colorMode: {
|
||||
defaultMode: 'light',
|
||||
disableSwitch: false,
|
||||
respectPrefersColorScheme: true,
|
||||
},
|
||||
prism: {
|
||||
theme: lightCodeTheme,
|
||||
darkTheme: darkCodeTheme,
|
||||
},
|
||||
}),
|
||||
markdown: {
|
||||
mermaid: true,
|
||||
},
|
||||
themes: ['@docusaurus/theme-mermaid'],
|
||||
}
|
||||
|
||||
module.exports = config
|
||||
@@ -1,44 +0,0 @@
|
||||
{
|
||||
"name": "ark-website",
|
||||
"version": "0.0.0",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"docusaurus": "docusaurus",
|
||||
"start": "docusaurus start",
|
||||
"build": "docusaurus build",
|
||||
"swizzle": "docusaurus swizzle",
|
||||
"deploy": "docusaurus deploy",
|
||||
"clear": "docusaurus clear",
|
||||
"serve": "docusaurus serve",
|
||||
"write-translations": "docusaurus write-translations",
|
||||
"write-heading-ids": "docusaurus write-heading-ids"
|
||||
},
|
||||
"dependencies": {
|
||||
"@docusaurus/core": "2.4.3",
|
||||
"@docusaurus/preset-classic": "2.4.3",
|
||||
"@docusaurus/theme-mermaid": "2.4.3",
|
||||
"@mdx-js/react": "^1.6.22",
|
||||
"clsx": "^1.2.1",
|
||||
"prism-react-renderer": "^1.3.5",
|
||||
"react": "^17.0.2",
|
||||
"react-dom": "^17.0.2"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "2.4.3"
|
||||
},
|
||||
"browserslist": {
|
||||
"production": [
|
||||
">0.5%",
|
||||
"not dead",
|
||||
"not op_mini all"
|
||||
],
|
||||
"development": [
|
||||
"last 1 chrome version",
|
||||
"last 1 firefox version",
|
||||
"last 1 safari version"
|
||||
]
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=16.14"
|
||||
}
|
||||
}
|
||||
@@ -1,33 +0,0 @@
|
||||
/**
|
||||
* Creating a sidebar enables you to:
|
||||
- create an ordered group of docs
|
||||
- render a sidebar for each doc of that group
|
||||
- provide next/previous navigation
|
||||
|
||||
The sidebars can be generated from the filesystem, or explicitly defined here.
|
||||
|
||||
Create as many sidebars as you want.
|
||||
*/
|
||||
|
||||
// @ts-check
|
||||
|
||||
/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
|
||||
const sidebars = {
|
||||
// By default, Docusaurus generates a sidebar from the docs folder structure
|
||||
tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
|
||||
|
||||
// But you can create a sidebar manually
|
||||
/*
|
||||
tutorialSidebar: [
|
||||
'intro',
|
||||
'hello',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Tutorial',
|
||||
items: ['tutorial-basics/create-a-document'],
|
||||
},
|
||||
],
|
||||
*/
|
||||
};
|
||||
|
||||
module.exports = sidebars;
|
||||
@@ -1,128 +0,0 @@
|
||||
import React, { useEffect, useState } from 'react'
|
||||
|
||||
const isArm = async () => {
|
||||
// available on Chrome, Edge and Opera
|
||||
if (typeof navigator.userAgentData?.getHighEntropyValues === 'function') {
|
||||
const { architecture } = await navigator.userAgentData.getHighEntropyValues(
|
||||
['architecture']
|
||||
)
|
||||
return architecture === 'arm'
|
||||
}
|
||||
// for Firefox
|
||||
const w = document.createElement('canvas').getContext('webgl')
|
||||
const d = w.getExtension('WEBGL_debug_renderer_info')
|
||||
const g = (d && w.getParameter(d.UNMASKED_RENDERER_WEBGL)) || ''
|
||||
return Boolean(g.match(/Apple M[123]/)) // TODO: Linux
|
||||
}
|
||||
|
||||
const Button = ({ children, onClick, colored }) => {
|
||||
const backgroundColor = colored
|
||||
? 'var(--ifm-color-primary-lightest)'
|
||||
: 'var(--ifm-color-emphasis-200)'
|
||||
return (
|
||||
<button
|
||||
onClick={onClick}
|
||||
style={{
|
||||
backgroundColor,
|
||||
borderRadius: '8px',
|
||||
borderWidth: '1px',
|
||||
cursor: 'pointer',
|
||||
fontSize: '1rem',
|
||||
padding: '1rem',
|
||||
width: '18rem',
|
||||
}}>
|
||||
{children}
|
||||
</button>
|
||||
)
|
||||
}
|
||||
|
||||
const Section = ({ children }) => (
|
||||
<div style={{ margin: '10vh 0', maxWidth: '600px' }}>{children}</div>
|
||||
)
|
||||
|
||||
const SpaceBetween = ({ children }) => (
|
||||
<div
|
||||
style={{
|
||||
display: 'flex',
|
||||
justifyContent: 'space-between',
|
||||
}}>
|
||||
{children}
|
||||
</div>
|
||||
)
|
||||
|
||||
export default function Buttons() {
|
||||
const [binaryUrl, setBinaryUrl] = useState('')
|
||||
const [downloadText, setDownloadText] = useState('Download binary')
|
||||
|
||||
const fileURL = (filename) =>
|
||||
`https://install-latest-cli.arkdev.info/latest-release/${filename}`
|
||||
|
||||
useEffect(async () => {
|
||||
const nua = navigator.userAgent
|
||||
const isMacOS = Boolean(nua.match(/OS X /))
|
||||
const isLinux = Boolean(nua.match(/Linux/))
|
||||
const isSafari = Boolean(nua.includes('Safari') && !nua.includes('Chrome'))
|
||||
if (!isMacOS && !isLinux) return // no binaries available
|
||||
if (isSafari) return // Safari hides the CPU architecture
|
||||
const os = isMacOS ? 'darwin' : 'linux'
|
||||
const arch = (await isArm()) ? 'arm64' : 'amd64'
|
||||
const file = `ark-${os}-${arch}`
|
||||
setBinaryUrl(fileURL(file))
|
||||
setDownloadText(`Download ${file}`)
|
||||
})
|
||||
|
||||
const viewOnGithub = () =>
|
||||
window.open('https://github.com/ark-network/ark', '_blank')
|
||||
|
||||
const downloadAlpha = () => {
|
||||
// if we know user OS and architecture, start download immediately
|
||||
if (!binaryUrl) window.open(binaryUrl, '_blank')
|
||||
document.querySelector('#available-binaries').scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
})
|
||||
}
|
||||
|
||||
return (
|
||||
<Section>
|
||||
<SpaceBetween>
|
||||
<Button onClick={viewOnGithub}>
|
||||
<SpaceBetween>
|
||||
View on Github
|
||||
<svg
|
||||
className='github_svg__lucide github_svg__lucide-github'
|
||||
xmlns='http://www.w3.org/2000/svg'
|
||||
width='1em'
|
||||
height='1em'
|
||||
fill='none'
|
||||
stroke='currentColor'
|
||||
strokeLinecap='round'
|
||||
strokeLinejoin='round'
|
||||
strokeWidth='2'
|
||||
viewBox='0 0 24 24'>
|
||||
<path d='M15 22v-4a4.8 4.8 0 0 0-1-3.5c3 0 6-2 6-5.5.08-1.25-.27-2.48-1-3.5.28-1.15.28-2.35 0-3.5 0 0-1 0-3 1.5-2.64-.5-5.36-.5-8 0C6 2 5 2 5 2c-.3 1.15-.3 2.35 0 3.5A5.4 5.4 0 0 0 4 9c0 3.5 3 5.5 6 5.5-.39.49-.68 1.05-.85 1.65S8.93 17.38 9 18v4'></path>
|
||||
<path d='M9 18c-4.51 2-5-2-7-2'></path>
|
||||
</svg>
|
||||
</SpaceBetween>
|
||||
</Button>
|
||||
<Button onClick={downloadAlpha} colored={true}>
|
||||
<SpaceBetween>
|
||||
{downloadText}
|
||||
<svg
|
||||
className='download_svg__lucide download_svg__lucide-download'
|
||||
xmlns='http://www.w3.org/2000/svg'
|
||||
width='1em'
|
||||
height='1em'
|
||||
fill='none'
|
||||
stroke='currentColor'
|
||||
strokeLinecap='round'
|
||||
strokeLinejoin='round'
|
||||
strokeWidth='2'
|
||||
viewBox='0 0 24 24'>
|
||||
<path d='M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4M7 10l5 5 5-5M12 15V3'></path>
|
||||
</svg>
|
||||
</SpaceBetween>
|
||||
</Button>
|
||||
</SpaceBetween>
|
||||
</Section>
|
||||
)
|
||||
}
|
||||
@@ -1,148 +0,0 @@
|
||||
import Buttons from './buttons.js'
|
||||
|
||||
# Welcome to Ark
|
||||
|
||||
A second-layer solution designed to scale Bitcoin transactions
|
||||
|
||||
<Buttons />
|
||||
|
||||
## Why Ark?
|
||||
|
||||
Bitcoin is the world's most secure and censorship-resistant blockchain. However, it's not the fastest or the cheapest. Ark is a second-layer solution designed to scale Bitcoin transactions. It uses a shared UTXO model for confidential and off-chain payments through an intermediary server that cannot access your funds.
|
||||
|
||||
## Try it
|
||||
|
||||
Start by downloading a compatible binary.
|
||||
|
||||
### Available binaries
|
||||
|
||||
- [ark-darwin-amd64](https://install-latest-cli.arkdev.info/latest-release/ark-darwin-amd64)
|
||||
- [ark-darwin-arm64](https://install-latest-cli.arkdev.info/latest-release/ark-darwin-arm64)
|
||||
- [ark-linux-amd64](https://install-latest-cli.arkdev.info/latest-release/ark-linux-amd64)
|
||||
- [ark-linux-arm64](https://install-latest-cli.arkdev.info/latest-release/ark-linux-arm64)
|
||||
|
||||
Move it to somewhere on your PATH:
|
||||
|
||||
```bash
|
||||
$ mv <file> /usr/local/bin/ark
|
||||
$ chmod +x /usr/local/bin/ark
|
||||
```
|
||||
|
||||
### Configure the CLI
|
||||
|
||||
The CLI requires an initial setup to initialize the wallet and connect to the ASP:
|
||||
|
||||
```bash
|
||||
$ ark init --password <password> --ark-url https://asp.arkdev.info
|
||||
```
|
||||
|
||||
You can also restore a wallet by specifying the hex encoded private key with the `--prvkey` flag.
|
||||
|
||||
### View balance
|
||||
|
||||
You can see both the onchain and offchain balance of the wallet with:
|
||||
|
||||
```bash
|
||||
$ ark balance
|
||||
```
|
||||
|
||||
To see your balance with your VTXOs expiration details use `--expiry-details`:
|
||||
|
||||
```bash
|
||||
$ ark balance --expiry-details
|
||||
```
|
||||
|
||||
### Receive funds
|
||||
|
||||
You can print your onchain and offchain receiving addresses with:
|
||||
|
||||
```bash
|
||||
$ ark receive
|
||||
```
|
||||
|
||||
#### Add funds to the ark wallet:
|
||||
|
||||
Fund the `onchain_address` from previous command with https://liquidtestnet.com/faucet.
|
||||
|
||||
### Onboard the ark
|
||||
|
||||
```
|
||||
$ ark onboard --amount <amount>
|
||||
```
|
||||
|
||||
This command will send funds from your onchain balance to your offchain balance.
|
||||
|
||||
After confirmation, your ark wallet will be funded and ready to spend offchain.
|
||||
|
||||
:::danger Use sats
|
||||
Amount is always specified in _sats_ unit.
|
||||
:::
|
||||
|
||||
### Make payments
|
||||
|
||||
You can make a payment by sending to either one or many receivers:
|
||||
|
||||
```bash
|
||||
$ ark send --to <address> --amount <amount>
|
||||
$ ark send --receivers '[{"to": "<address>", "amount": <amount>}, ...]'
|
||||
```
|
||||
|
||||
:::tip
|
||||
You can send funds to onchain or offchain addresses:
|
||||
|
||||
- funds to onchain addresses will come from your onchain balance
|
||||
- funds to offchain addresses will come from your offchain balance
|
||||
|
||||
:::
|
||||
|
||||
### Collaborative redemption
|
||||
|
||||
You can redeem your funds onchain collaborating with the ASP:
|
||||
|
||||
```bash
|
||||
$ ark redeem --address <onchain_address> --amount <amount>
|
||||
```
|
||||
|
||||
This command will send funds from your offchain balance to your onchain balance.
|
||||
|
||||
:::info
|
||||
Any change produced with this operation goes to your offchain address.
|
||||
:::
|
||||
|
||||
### Unilateral redemption
|
||||
|
||||
If the ASP is unresponsive you can redeem all your offchain funds unilaterally:
|
||||
|
||||
```bash
|
||||
$ ark redeem --address <onchain_address> --force
|
||||
```
|
||||
|
||||
:::danger
|
||||
The tag `--force` will make ark ignore `--amount` and redeem all funds.
|
||||
:::
|
||||
|
||||
### Help
|
||||
|
||||
You can see all available commands with `help`:
|
||||
|
||||
```
|
||||
$ ark help
|
||||
```
|
||||
|
||||
### Create a second CLI
|
||||
|
||||
To create a second CLI, on a different terminal use a different datadir by exporting the env var `ARK_WALLET_DATADIR`:
|
||||
|
||||
```bash
|
||||
$ export ARK_WALLET_DATADIR=path/to/custom
|
||||
$ ark init --password <password> --ark-url https://asp.arkdev.info
|
||||
```
|
||||
|
||||
:::info
|
||||
By default the CLI uses the following datadir:
|
||||
|
||||
- POSIX (Linux/BSD): ~/.Ark-cli
|
||||
- Mac OS: $HOME/Library/Application Support/Ark-cli
|
||||
- Windows: %LOCALAPPDATA%\Ark-cli
|
||||
- Plan 9: $home/Ark-cli
|
||||
:::
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.0 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 113 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 113 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
File diff suppressed because it is too large
Load Diff
@@ -1,134 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<title>Ark liquidity simulator</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<link rel="stylesheet" href="style.css" />
|
||||
<body>
|
||||
<div style="display: flex">
|
||||
<div style="width: 15%; border-right: 1px solid grey">
|
||||
<p><strong>ASP</strong></p>
|
||||
<p>
|
||||
<label>
|
||||
Initial budget (BTC)
|
||||
<input type="number" id="initialBudget" value="1" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#initialBudget').value=1">1</a>
|
||||
·
|
||||
<a onclick="dqs('#initialBudget').value=10">10</a>
|
||||
·
|
||||
<a onclick="dqs('#initialBudget').value=100">100</a>
|
||||
</p>
|
||||
<p>
|
||||
<label>
|
||||
Timelock (days)
|
||||
<input type="number" id="timelock" value="28" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#timelock').value=14">2 weeks</a>
|
||||
·
|
||||
<a onclick="dqs('#timelock').value=28">1 month</a>
|
||||
</p>
|
||||
<p>
|
||||
<label>
|
||||
VTXO ratio (1/n)
|
||||
<input type="number" id="vtxoRatio" value="1" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#vtxoRatio').value=1">1</a>
|
||||
·
|
||||
<a onclick="dqs('#vtxoRatio').value=10">10</a>
|
||||
·
|
||||
<a onclick="dqs('#vtxoRatio').value=100">100</a>
|
||||
</p>
|
||||
<p>
|
||||
<label>
|
||||
Dust limit (sats)
|
||||
<input type="number" id="dustLimit" value="450" />
|
||||
</label>
|
||||
</p>
|
||||
<p style="margin-top: 3rem"><strong>Users</strong></p>
|
||||
<p>
|
||||
<label>
|
||||
Number of users
|
||||
<input type="number" id="numberUsers" value="4" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#numberUsers').value=4">4</a>
|
||||
·
|
||||
<a onclick="dqs('#numberUsers').value=40">40</a>
|
||||
·
|
||||
<a onclick="dqs('#numberUsers').value=400">400</a>
|
||||
</p>
|
||||
<p>
|
||||
<label>
|
||||
Onboard amount (BTC)
|
||||
<input type="number" id="onboardAmount" value="0.01" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#onboardAmount').value=0.01">0.01</a>
|
||||
·
|
||||
<a onclick="dqs('#onboardAmount').value=0.1">0.1</a>
|
||||
·
|
||||
<a onclick="dqs('#onboardAmount').value=1">1</a>
|
||||
</p>
|
||||
<p>
|
||||
<label>
|
||||
Monthly Money Velocity
|
||||
<input type="number" id="moneyVelocity" value="0.33" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#moneyVelocity').value=0.33">0.33</a>
|
||||
·
|
||||
<a onclick="dqs('#moneyVelocity').value=0.50">0.50</a>
|
||||
·
|
||||
<a onclick="dqs('#moneyVelocity').value=1">1</a>
|
||||
</p>
|
||||
<p>
|
||||
<label>
|
||||
Monthly Payments
|
||||
<input type="number" id="numberPayments" value="10" />
|
||||
</label>
|
||||
<br />
|
||||
<a onclick="dqs('#numberPayments').value=1">1</a>
|
||||
·
|
||||
<a onclick="dqs('#numberPayments').value=10">10</a>
|
||||
·
|
||||
<a onclick="dqs('#numberPayments').value=100">100</a>
|
||||
</p>
|
||||
</div>
|
||||
<div style="width: 85%; padding: 0 3rem">
|
||||
<p><strong>Stats</strong></p>
|
||||
<div class="graphContainer">
|
||||
<div>
|
||||
<p><strong>Payments</strong></p>
|
||||
<div id="graph1"></div>
|
||||
</div>
|
||||
<div>
|
||||
<p><strong>VTXOs</strong></p>
|
||||
<div id="graph2"></div>
|
||||
</div>
|
||||
<div>
|
||||
<p><strong>Budget</strong></p>
|
||||
<div id="graph3"></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="flexed">
|
||||
<p><strong>Timeline</strong></p>
|
||||
<p>
|
||||
<button id="playButton">Play</button>
|
||||
<button id="pauseButton">Pause</button>
|
||||
<button id="resetButton">Reset</button>
|
||||
</p>
|
||||
</div>
|
||||
<p style="margin-top: 0">
|
||||
Each color tone represents a specific user<br />
|
||||
Mouse over a circle to see a JSON representation of the payment
|
||||
</p>
|
||||
<div class="timelineContainer"></div>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
<script src="decimal.js"></script>
|
||||
<script src="script.js"></script>
|
||||
</html>
|
||||
@@ -1,261 +0,0 @@
|
||||
const dqs = (selector) => document.querySelector(selector)
|
||||
|
||||
const clock = {
|
||||
current: 0,
|
||||
intervalId: '',
|
||||
pause: () => clock.removeInterval(),
|
||||
play() {
|
||||
const maxDays = Number(dqs('#timelock').value)
|
||||
// if already running, do nothing
|
||||
if (clock.intervalId) return
|
||||
// reset and play timeline if on the end of previous timeline
|
||||
if (clock.current === maxDays) {
|
||||
clock.reset()
|
||||
clock.play()
|
||||
return
|
||||
}
|
||||
// start clock
|
||||
clock.intervalId = setInterval(() => {
|
||||
clock.current += 1
|
||||
if (clock.current === maxDays) clock.removeInterval()
|
||||
days.db.push(days.randomDay())
|
||||
ui.render()
|
||||
}, 300)
|
||||
},
|
||||
reset() {
|
||||
clock.removeInterval()
|
||||
clock.current = 0
|
||||
days.db = []
|
||||
ui.render()
|
||||
},
|
||||
removeInterval: () => {
|
||||
if (clock.intervalId) {
|
||||
clearInterval(clock.intervalId)
|
||||
clock.intervalId = ''
|
||||
}
|
||||
},
|
||||
}
|
||||
|
||||
const days = {
|
||||
db: [],
|
||||
untilNow: () => {
|
||||
const users = {}
|
||||
let eachPayment = 0
|
||||
let eachVTXO = 0
|
||||
let numEvents = 0
|
||||
let numVTXOs = 0
|
||||
let sumPayments = 0
|
||||
let sumVTXOs = 0
|
||||
days.db.forEach((day) => {
|
||||
if (!day) return
|
||||
day.forEach((event) => {
|
||||
if (!users[event.user]) users[event.user] = 0
|
||||
users[event.user] += 1
|
||||
eachVTXO = event.vtxos.each
|
||||
eachPayment = event.payment.value
|
||||
numEvents += 1
|
||||
numVTXOs = Decimal.add(numVTXOs, event.vtxos.num).toNumber()
|
||||
sumPayments = Decimal.add(sumPayments, event.payment.value).toNumber()
|
||||
sumVTXOs = Decimal.add(sumVTXOs, event.vtxos.sum).toNumber()
|
||||
})
|
||||
})
|
||||
return {
|
||||
eachPayment,
|
||||
eachVTXO,
|
||||
numEvents,
|
||||
numUsers: Object.keys(users).length,
|
||||
numVTXOs,
|
||||
ratioVTXOsPayments: Decimal.div(sumVTXOs, sumPayments).toNumber(),
|
||||
sumPayments,
|
||||
sumVTXOs,
|
||||
}
|
||||
},
|
||||
randomDay: () => {
|
||||
let day
|
||||
const numberUsers = dqs('#numberUsers').value
|
||||
const onboardAmount = dqs('#onboardAmount').value
|
||||
const timelock = Number(dqs('#timelock').value)
|
||||
const moneyVelocity = Decimal.div(timelock, 28)
|
||||
.mul(dqs('#moneyVelocity').value)
|
||||
.toNumber()
|
||||
const numberPayments = Decimal.div(timelock, 28)
|
||||
.mul(dqs('#numberPayments').value)
|
||||
.toNumber()
|
||||
const vtxoRatio = Number(dqs('#vtxoRatio').value)
|
||||
const paymentValue = Decimal.mul(onboardAmount, moneyVelocity)
|
||||
.div(numberPayments)
|
||||
.toNumber()
|
||||
const vtxoVal = Decimal.div(onboardAmount, vtxoRatio).toNumber()
|
||||
const vtxoNum = Decimal.div(paymentValue, vtxoVal).ceil().toNumber()
|
||||
const vtxoSum = Decimal.mul(vtxoNum, vtxoVal).toNumber()
|
||||
const paymentChange = Decimal.sub(vtxoSum, paymentValue).toNumber()
|
||||
for (let user = 0; user < numberUsers; user++) {
|
||||
const rand = timelock * Math.random()
|
||||
if (rand < numberPayments) {
|
||||
if (!day) day = []
|
||||
day.push({
|
||||
user,
|
||||
payment: {
|
||||
value: paymentValue,
|
||||
change: paymentChange,
|
||||
},
|
||||
vtxos: {
|
||||
each: vtxoVal,
|
||||
num: vtxoNum,
|
||||
sum: vtxoSum,
|
||||
},
|
||||
})
|
||||
}
|
||||
}
|
||||
return day
|
||||
},
|
||||
}
|
||||
|
||||
const pretty = {
|
||||
btc: (num) => pretty.num(num, 0, 8),
|
||||
num: (num = 0, min = 0, max = 2) => {
|
||||
if (num === 0) return '0'
|
||||
return new Intl.NumberFormat('en-us', {
|
||||
minimumFractionDigits: min,
|
||||
maximumFractionDigits: max,
|
||||
}).format(num)
|
||||
},
|
||||
}
|
||||
|
||||
const ui = {
|
||||
theme: {
|
||||
circle: { radius: 5 },
|
||||
colors: [
|
||||
'indianred',
|
||||
'lightCoral',
|
||||
'red',
|
||||
'darkred',
|
||||
'pink',
|
||||
'hotpink',
|
||||
'mediumvioletred',
|
||||
'lightsalmon',
|
||||
'coral',
|
||||
'orangered',
|
||||
'darkorange',
|
||||
'orange',
|
||||
'gold',
|
||||
'moccasin',
|
||||
'khaki',
|
||||
'darkkhaki',
|
||||
'thistle',
|
||||
'plum',
|
||||
],
|
||||
margin: 10,
|
||||
vSpace: 20,
|
||||
},
|
||||
renderStats: () => {
|
||||
const dustLimit = Decimal.div(
|
||||
dqs('#dustLimit').value,
|
||||
100_000_000 // from satoshis to btc
|
||||
)
|
||||
const initialBudget = Number(dqs('#initialBudget').value)
|
||||
const {
|
||||
eachPayment,
|
||||
eachVTXO,
|
||||
numUsers,
|
||||
numEvents,
|
||||
numVTXOs,
|
||||
ratioVTXOsPayments,
|
||||
sumPayments,
|
||||
sumVTXOs,
|
||||
} = days.untilNow()
|
||||
const connectorsValue = Decimal.mul(numVTXOs, dustLimit).toNumber()
|
||||
const totalCost = Decimal.add(sumVTXOs, connectorsValue).toNumber()
|
||||
const budget = {
|
||||
initial: initialBudget,
|
||||
payments: sumVTXOs,
|
||||
connectors: connectorsValue,
|
||||
available: Decimal.sub(initialBudget, totalCost).toNumber(),
|
||||
}
|
||||
const stats = `
|
||||
<p>Each: ${pretty.btc(eachPayment)} BTC</p>
|
||||
<p>Number of users: ${numUsers}</p>
|
||||
<p>Number of events: ${numEvents}</p>
|
||||
<p>Total payments: ${pretty.btc(sumPayments)} BTC</p>
|
||||
`
|
||||
const vtxos = `
|
||||
<p>Each: ${pretty.btc(eachVTXO)} BTC</p>
|
||||
<p>VTXOs used: ${numVTXOs}</p>
|
||||
<p>Total value: ${pretty.btc(sumVTXOs)} BTC</p>
|
||||
<p>Ratio value / payments: ${pretty.num(ratioVTXOsPayments)}</p>
|
||||
`
|
||||
const liquidity = `
|
||||
<p>Initial: ${pretty.btc(budget.initial)} BTC</p>
|
||||
<p>Payments: ${pretty.btc(budget.payments)} BTC</p>
|
||||
<p>Connectors: ${pretty.btc(budget.connectors)} BTC</p>
|
||||
<p>Available: ${pretty.btc(budget.available)} BTC</p>
|
||||
`
|
||||
dqs('#graph1').innerHTML = stats
|
||||
dqs('#graph2').innerHTML = vtxos
|
||||
dqs('#graph3').innerHTML = liquidity
|
||||
},
|
||||
renderTimeline: () => {
|
||||
const container = dqs('.timelineContainer')
|
||||
const containerWidth = container.offsetWidth - ui.theme.margin * 2
|
||||
const steps = dqs('#timelock').value
|
||||
const stepWidth = Decimal.div(containerWidth, steps).toNumber()
|
||||
const height = container.offsetHeight - 2
|
||||
const width = clock.current * stepWidth + ui.theme.margin * 2
|
||||
const viewbox = `0 0 ${width} ${height}`
|
||||
// render event inside timeline
|
||||
const _event = (event, idx, index) => {
|
||||
const r = ui.theme.circle.radius
|
||||
const cx = index * stepWidth + r + ui.theme.margin
|
||||
const cy = (idx + 2) * ui.theme.vSpace
|
||||
const fill = ui.theme.colors[event.user % ui.theme.colors.length]
|
||||
return `
|
||||
<circle alt="alt" cx="${cx}" cy="${cy}" r="${r}" fill="${fill}">
|
||||
<title>${JSON.stringify(event, null, 2)}</title>
|
||||
</circle>
|
||||
`
|
||||
}
|
||||
// render day inside timeline
|
||||
const _day = (day, index) => {
|
||||
if (!day) return
|
||||
const cx = index * stepWidth + ui.theme.circle.radius + ui.theme.margin
|
||||
const cy = ui.theme.vSpace
|
||||
const idx = index + 1
|
||||
const num = `<text text-anchor="middle" x="${cx}" y="${cy}" class="small">${idx}</text>`
|
||||
return num + day.map((event, idx) => _event(event, idx, index)).join()
|
||||
}
|
||||
// render days inside timeline
|
||||
const _days = () => days.db.map((day, index) => _day(day, index)).join()
|
||||
// timeline is a svg
|
||||
const svg = `
|
||||
<svg viewBox="${viewbox}" height="${height}" width="${width}" xmlns="http://www.w3.org/2000/svg">
|
||||
<style>
|
||||
.small {
|
||||
font: italic 12px sans-serif;
|
||||
}
|
||||
</style>
|
||||
<rect x="0" y="0" width="100%" height="100%" fill="#eee"/>
|
||||
${_days()}
|
||||
</svg>
|
||||
`
|
||||
dqs('.timelineContainer').innerHTML = svg
|
||||
},
|
||||
resizeTimeline: () => {
|
||||
const container = dqs('.timelineContainer')
|
||||
const numberUsers = Number(dqs('#numberUsers').value)
|
||||
const height = (numberUsers + 2) * ui.theme.vSpace
|
||||
// don't reduce size
|
||||
if (container?.offsetHeight > height) return
|
||||
container.style.height = `${height}px`
|
||||
},
|
||||
render: () => {
|
||||
ui.resizeTimeline()
|
||||
ui.renderTimeline()
|
||||
ui.renderStats()
|
||||
},
|
||||
}
|
||||
|
||||
window.onload = () => {
|
||||
dqs('#pauseButton').onclick = () => clock.pause()
|
||||
dqs('#playButton').onclick = () => clock.play()
|
||||
dqs('#resetButton').onclick = () => clock.reset()
|
||||
}
|
||||
@@ -1,30 +0,0 @@
|
||||
input {
|
||||
margin: 0.21rem 0;
|
||||
max-width: 90%;
|
||||
width: 10rem;
|
||||
}
|
||||
a {
|
||||
color: lightCoral;
|
||||
cursor: pointer;
|
||||
}
|
||||
.flexed {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
}
|
||||
.graphContainer {
|
||||
column-gap: 3rem;
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
margin-bottom: 3rem;
|
||||
}
|
||||
.graphContainer > div {
|
||||
border: 1px solid grey;
|
||||
height: 12rem;
|
||||
padding: 0 1rem;
|
||||
}
|
||||
.timelineContainer {
|
||||
border: 1px solid grey;
|
||||
text-align: right;
|
||||
height: 120px;
|
||||
max-height: 60vh;
|
||||
}
|
||||
8134
website/yarn.lock
8134
website/yarn.lock
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user