
__Blockchains are siloed systems that can only reference their own data, established by consensus. Oracles are the solution to the problem of working with external information, which is vital for many everyday use cases.__

Blockchains are intentionally self-contained. They reference information only recorded within their immediate ecosystem, that has been agreed upon by a majority of miners. Since the whole point of a blockchain, based on consensus, is that there are no sources of centralisation or single points of failure, that poses a problem.

What happens when you want to engage with external information? Many blockchain-based applications need to process data from the real world. That might be financial information, such as market data and prices from exchanges, for DeFi applications; it could be sporting results, for eSports predictions markets; it could even be [atmospheric noise information, for random number generators](https://www.random.org/).

## Introducing Oracles

Oracles are the software that serves as a link between these real-world sources of data and the siloed world of the blockchain. They are simple in principle, since they only need to create a series of transactions with the necessary data (ideally formatted in an easily-accessible way) at regular intervals. 

However, while anyone can record information to an open blockchain, that is a source of centralisation. So how do you trust an oracle?

The answer is: you don’t. Just like the blockchain’s consensus method itself, you need multiple oracles pulling data from multiple sources, then coming to agreement about the value to record to the blockchain. So you don’t need to trust an individual miner, and you don’t need to trust an individual oracle.

## Example: bitcoin price data

As an example, let’s say we want to record bitcoin’s closing price every day to the Ergo blockchain, to give us a long-term and reliable source of price data.

We could take a dozen – or even a hundred – different data feeds, each pulling data from a major exchange. Coinbase, Bitstamp, Kraken, and so on. We make sure that many exchanges are represented, and while it’s good to have several examples of data from the same exchange, we don’t want any exchange over-represented.

Then the parties need to reach consensus about the price. Let’s say there are 100 parties and prices involved. There are different ways they could do that:

* Take the mean of all the prices they provide
* Discard the highest and lowest 20 prices, and take the mean of the remaining 60 prices
* Select the median price
* Weight the prices, with the central cluster of prices having greater weight, and take the mean

The aim is to discard or downweight any outliers, which could be due to extreme price fluctuations on a single exchange, API outages, or dishonest oracle data providers, while retaining many good data points to ensure a single reliable record of price.

Oracles are a hugely important part of the blockchain ecosystem. Once you have robust oracles in place, you can create all kinds of DeFi applications – including stablecoins, which are a vital part of the blockchain economy, and one we’ll be exploring on Ergo in the coming months.


Building Ergo: Oracles


## Introduction

[ErgoTool](https://github.com/aslesarenko/ergo-tool) is a command line interface (CLI) for
[Ergo blockchain](https://ergoplatform.org/). You can use ErgoTool without running your
own Ergo node. Even though running a node is the most secure way to communicate with the
Ergo blockchain network, ErgoTool however, aims to provide more foundational tools at
your disposal. Surely, you still can use it with your own running node. 

In this post we will walk through simple steps to generate a mnemonic phrase, create a
local secret storage and use it to send ERGs between addresses, all with the help of
ErgoTool commands.

## Getting Started

First of all we need to install ErgoTool on our system from sources by following the
[installation instructions](https://github.com/aslesarenko/ergo-tool#installation). In the
directory where we cloned ErgoTool there is `ergo-tool.sh` script which we are going to
use to run commands. Run the following command to check ErgoTool is installed correctly.

```bash
$ ./ergo-tool.sh help     
command name is not specified (run ergo-tool without arguments to list commands)

Command Name:	help
Usage Syntax:	ergo-tool help <commandName>
Description:	prints usage help for a command
Doc page:	https://aslesarenko.github.io/ergo-tool/api/org/ergoplatform/appkit/ergotool/HelpCmd.html
```

Let's see what we get here. ErgoTool outputs the error message with the information about
`help` command. This is a typical output of ErgoTool when one of the known commands is
specified, but it is used incorrectly. As we can learn from the message, the `help`
command requires us to specify additional `<commandName>` argument. Also, each command has
an API doc page with all the details about command execution, so its url is shown here.

## Create a New Mnemonic Phrase

Mnemonic is a random sequence of characters which is used to generate a master key
according to [Hierarchical Deterministic
Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) specification.
For convenience random sequence of english words is used, but this is not required.
Run the following command to generate a new mnemonic phrase:

```bash
$ ./ergo-tool.sh mnemonic          
bird harbor wheat innocent business disease busy quick yellow trust time oil enter situate moon
```

Write it down on a paper and keep in a safe and secret place. 
As an additional security measure you can create an arbitrary mnemonic password. 
In some sense it can serve like an additional non-vocabulary word in the mnemonic. 
Mnemonic password is optional and is used for additional security.
If you decide to use mnemonic password you should also write it down and keep in a secret and
probably different from mnemonic place. 

**Important, both mnemonic phrase and mnemonic password are required to restore secret keys,
if you lose any of them then you will not be able to regenerate you master key again.**

Next let's use the generated mnemonic to create a storage with a master secret key.

## Create a New Encrypted Storage

For better security neither mnemonic phrase nor password is required by ErgoTool to
perform the transaction signing. Instead, the secret key from the encrypted storage is
required to sign spending transaction. We can generate a secret key and store it in an
encrypted storage using `createStorage` command.

```bash
$ ./ergo-tool.sh help createStorage

Command Name:	createStorage
Usage Syntax:	ergo-tool createStorage [<storageDir>="storage"] [<storageFileName>="secret.json"]
Description:	Creates an encrypted storage file for the mnemonic entered by the user
Doc page:       https://aslesarenko.github.io/ergo-tool/api/org/ergoplatform/appkit/ergotool/CreateStorageCmd.html

$ ./ergo-tool.sh createStorage 
Enter mnemonic phrase> bird harbor wheat innocent business disease busy quick yellow trust time oil enter situate moon
Mnemonic password> 
Repeat mnemonic password> 
Storage password> 
Repeat storage password> 
Storage File: storage/secret.json
```

A master secret key is generated from the (mnemonic phrase, mnemonic password) pair and
saved encrypted in the `storage/secret.json` file. Mnemonic itself is not stored in the
file and there is no way to restore it from the file, even if you know the passwords.
 
Please take care to enter correct mnemonic password, the one you chose and saved before.
Since a mnemonic password is optional you can leave it empty by pressing enter.

If you forget the storage password (aka encryption password), you will not be able to use
that storage file anymore, however, you can always restore your secret keys from (mnemonic
phrase, mnemonic password) pair and thus create a new storage file with a new password.

Keep your storage file and storage password in secret, anyone who obtain both your storage
file and storage password will be able to decipher it and access secret keys.

## Extracting Data From Storage

Secret storage contains master secret key and as a result can be used to compute both the
public key and the pay-to-public-key address which correspond to that secret key. The
`extractStorage` command is doing just that.

```bash
$ ./ergo-tool.sh help extractStorage

Command Name:	extractStorage
Usage Syntax:	ergo-tool extractStorage <storage file> address|masterKey|publicKey|secretKey mainnet|testnet
Description:	Reads the file, unlocks it using password and extract the requested property from the given storage file.
Doc page:	https://aslesarenko.github.io/ergo-tool/api/org/ergoplatform/appkit/ergotool/ExtractStorageCmd.html 

$ ./ergo-tool.sh extractStorage storage/secret.json address mainnet     
Storage password> 
9iHiSAg3ko2ZGxR2vhc1Aem3tShqfzEPDAF7XK5cdtbZ3Ut2CCf
```

Here the command transforms the secret key to the corresponding public key and then creates 
the pay-to-public-key address on the mainnet.

The same way we can obtain public key, private key and other data from the storage.

```bash
$ ./ergo-tool.sh extractStorage storage/secret.json secretKey mainnet
Storage password> 
55dfde63c9b6b4f47683592e85ee997ba2e93507f38ba3f9c82933bcfbc677ca

$ ./ergo-tool.sh extractStorage storage/secret.json publicKey mainnet
Storage password> 
03f07aecb145a85920bf6e9be80efe5f1cd1a165b45ad3aa8e5c4ca3ba50856bb8
```

## Listing Unspent Boxes

ErgoTool has the special command to list all available (aka unspent) boxes for a given address.

```bash
$ ./ergo-tool.sh listAddressBoxes 9f4QF8AD1nQ3nJahQVkMj8hFSVVzVom77b52JU7EW71Zexg6N8v                                                                
BoxId                                                             NanoERGs          
4840cb6facc20b765085db0ad24768ed0c5e7afd413e8e58e597c33a993f8119  4987000000
```

if we specify `--print-json` option, then ErgoTool will output all the boxes in json format

```bash
$ ./ergo-tool.sh listAddressBoxes --print-json 9f4QF8AD1nQ3nJahQVkMj8hFSVVzVom77b52JU7EW71Zexg6N8v
[{"boxId":"4840cb6facc20b765085db0ad24768ed0c5e7afd413e8e58e597c33a993f8119","value":4987000000,"ergoTree":"0008cd02472963123ce32c057907c7a7268bc09f45d9ca57819d3327b9e7497d7b1cc347","creationHeight":125646,"assets":[],"additionalRegisters":{},"transactionId":"820c688f4b9d709924ba0186ee930a7df374d8852920bc769fc1f1d0b313e5ab","index":2}]
```

## Transfer Coins

Now, with secret key stored securely in the encrypted storage file, we can use ErgoTool to
transfer coins from our address to some other recipient address. The command to do that is
`send`.

```bash
./ergo-tool.sh help send                                     

Command Name:	send
Usage Syntax:	ergo-tool send <storageFile> <recipientAddr> <amountToSend>
Description:	send the given <amountToSend> to the given <recipientAddr> using 
 the given <storageFile> to sign transaction (requests storage password)
Doc page:	https://aslesarenko.github.io/ergo-tool/api/org/ergoplatform/appkit/ergotool/SendCmd.html
```
The storage file is necessary in order to access secret key and generate a signature. The
storage password will be requested by ErgoTool to unlock and decipher the file content.
The command `send` supports the `--dry-run` option which forces ErgoTool to create the
signed transaction, but instead of sending it to the blockchain, ErgoTool prints the
transaction on the console.

```bash
$ ./ergo-tool.sh send --dry-run storage/E1.json 9hHDQb26AjnJUXxcqriqY1mnhpLuUeC81C4pggtK7tupr92Ea1K 5000000
Storage password>
Creating prover... Ok
Loading unspent boxes from at address 9f4QF8AD1nQ3nJahQVkMj8hFSVVzVom77b52JU7EW71Zexg6N8v... Ok
Signing the transaction... Ok
Tx: {
  "id": "2633733a1d81b8fc747d984bdc36fac42cb52118b5057375b081b4c543c62b0e",
  "inputs": [
    {
      "boxId": "4840cb6facc20b765085db0ad24768ed0c5e7afd413e8e58e597c33a993f8119",
      "spendingProof": {
        "proofBytes": "060e7c99c9c9cecf89ec5c3e7b692075e0b3415318f8064c64f7f01401ac29c6637b44535151e51d43d4cd25e05ad459dbe33718a99a22dd",
        "extension": {}
      }
    }
  ],
  "dataInputs": [],
  "outputs": [
    {
      "boxId": "4eaed414ae763158126859bbf912fa9ffb9ea67ac13d81d473b1c81ec65b06fd",
      "value": 5000000,
      "ergoTree": "ErgoTree(0,WrappedArray(),Right(ConstantNode(SigmaProp(ProveDlog(ECPoint(6ba5cf,8ae5ac,...))),SSigmaProp)),80,[B@1117fff48)",
      "creationHeight": 130508,
      "assets": [],
      "additionalRegisters": {},
      "transactionId": "2633733a1d81b8fc747d984bdc36fac42cb52118b5057375b081b4c543c62b0e",
      "index": 0
    },
    {
      "boxId": "059b426fe2aaef10b6a9a618f0c5b4e97d4dd9931328bf4f52bcf92b0943a42c",
      "value": 1000000,
      "ergoTree": "ErgoTree(16,WrappedArray(IntConstant(0), IntConstant(0), ConstantNode(Coll(16,2,4,-96,11,8,-51,2,121,-66,102,126,-7,-36,-69,-84,85,-96,98,-107,-50,-121,11,7,2,-101,-4,-37,45,-50,40,-39,89,-14,-127,91,22,-8,23,-104,-22,2,-47,-110,-93,-102,-116,-57,-89,1,115,0,115,1),Coll[SByte$]), ConstantNode(Coll(1),Coll[SInt$]), IntConstant(1)),Right(BoolToSigmaProp(AND(ConcreteCollection(WrappedArray(EQ(Height$(163),SelectField(ExtractCreationInfo(ByIndex(Outputs$(165),ConstantPlaceholder(0,SInt$),None)),1)), EQ(ExtractScriptBytes(ByIndex(Outputs$(165),ConstantPlaceholder(1,SInt$),None)),SubstConstants(ConstantPlaceholder(2,Coll[SByte$]),ConstantPlaceholder(3,Coll[SInt$]),ConcreteCollection(WrappedArray(CreateProveDlog(DecodePoint(MinerPubkey$(172)))),SSigmaProp))), EQ(SizeOf(Outputs$(165)),ConstantPlaceholder(4,SInt$))),SBoolean)))),4836,[B@111805c40)",
      "creationHeight": 130508,
      "assets": [],
      "additionalRegisters": {},
      "transactionId": "2633733a1d81b8fc747d984bdc36fac42cb52118b5057375b081b4c543c62b0e",
      "index": 1
    },
    {
      "boxId": "0638ddb0fe6a8cc6ca4f981f71777f4a6e8aad72d57fdf945b24e0ef4ca714e1",
      "value": 4981000000,
      "ergoTree": "ErgoTree(0,WrappedArray(),Right(ConstantNode(SigmaProp(ProveDlog(ECPoint(472963,7c85fd,...))),SSigmaProp)),80,[B@111816258)",
      "creationHeight": 130508,
      "assets": [],
      "additionalRegisters": {},
      "transactionId": "2633733a1d81b8fc747d984bdc36fac42cb52118b5057375b081b4c543c62b0e",
      "index": 2
    }
  ]
}
```

Note the "ergoTree" scripts are deserialized and printed as abstract syntax trees. This
printing format can be regulated by additional options so that the scripts can be printed as
human readable ErgoScript. (Not yet implemented, but somewhere on the roadmap.)

If we exclude `--dry-run` option, the transaction will be sent and included in the
blockchain.

```bash
$ ./ergo-tool.sh send storage/E1.json 9hHDQb26AjnJUXxcqriqY1mnhpLuUeC81C4pggtK7tupr92Ea1K 5000000          
Storage password>
Creating prover... Ok
Loading unspent boxes from at address 9f4QF8AD1nQ3nJahQVkMj8hFSVVzVom77b52JU7EW71Zexg6N8v... Ok
Signing the transaction... Ok
Sendng the transaction... Ok
Server returned tx id: "c5710af17f5124a232a5ef731fdf94a493025334c2a7d5a79e9923210972b962"
```
The newly created transaction will be broadcast all over the blockchain and miners start
to include it in a new block. Once the new block with our transaction is mined and
accepted by the network our transfer is confirmed and we can [see it in Explorer](https://explorer.ergoplatform.com/en/transactions/c5710af17f5124a232a5ef731fdf94a493025334c2a7d5a79e9923210972b962).

We can also list boxes of the recipient address and see the coin we created among others
(until it is spent by the recipient)

```bash
$ ./ergo-tool.sh listAddressBoxes 9hHDQb26AjnJUXxcqriqY1mnhpLuUeC81C4pggtK7tupr92Ea1K                      
BoxId                                                             NanoERGs          
252c5ce38fc367001ea48fa6813e6252ebc169288d9b5392c572edb55380b3cd  5000000
6df9dbf08b4859b7e280afbd0822dcf20dba5bf8e3e33b78fe278df6597276f1  2000000
d47f958b201dc7162f641f7eb055e9fa7a9cb65cc24d4447a10f86675fc58328  1000000
e050a3af38241ce444c34eb25c0ab880674fc23a0e63632633ae14f547141c37  1000000
b50ed8c2953fd33b52af816c4caa63ec5b6d236a262a5a192534695c3478da78  1000000
26d6e08027e005270b38e5c5f4a73ffdb6d65a3289efb51ac37f98ad395d887c  10000000000
```

## Security Notes

ErgoTool is created with security in mind and tries its best to safeguard the usage of
sensitive information like mnemonic phrases (which are never stored persistently), 
passwords (which are never shown on the screen) etc. In addition, secret keys are never
stored on local disk unencrypted and surely never sent anywhere.

## Conclusion

ErgoTool is designed to look and feel like a typical CLI utility:

- which is easy to use and fast to run from command line
- can be scriptable via shell scripts
- has built-in usage help 

At the same time ErgoTool is designed to be easily extensible:

- implemented in high-level language Scala
- reuses the core libraries which are used in Ergo network client
- open-sourced and fully documented

This last point is especially important as many new commands can be easily added to
ErgoTool, thanks to its architecture. If you need a specific feature or a command 
please file an issue or maybe even a PR.

The extensibility of ErgoTool is a subject of the next planned blog post, stay tuned!

## References

1. [Ergo Site](https://ergoplatform.org/en/)
2. [Ergo Sources](https://github.com/ergoplatform/ergo)
3. [Ergo Appkit](https://github.com/aslesarenko/ergo-appkit)
4. [Ergo Tool](https://github.com/aslesarenko/ergo-tool)


Make Your Own Ergo Wallet: Managing Ergo Coins with ErgoTool

5 Ways Ergo Application Development Is Changed Forever Thanks To Appkit


This tutorial explains how to install and run a full Ergo node. It does not cover mining.

## Node security

There are a few important aspects of node usage that your wallet and money's safety depends on:

* An Ergo node requires storing security-critical parameters in the configuration file. You should never make this file public.
* An Ergo node provides a REST API for interacting with the built-in wallet. Sensitive API methods require a security token, which should never be sent over untrusted channels.
* Access to the Ergo REST API must be restricted to known hosts. In particular, the API must not be accessible from the Internet.

## Prerequisites

To run an Ergo node you need JRE version >= 8 to be installed. One way to install it is to use [Oracle implementation of Java](https://www.oracle.com/technetwork/java/javase/downloads/index.html).

The next step is to download the latest [Ergo client release](https://github.com/ergoplatform/ergo/releases/) jar file and create a node configuration file.

Note that instead of downloading the jar, you can clone the repository and create the jar yourself using [SBT](https://www.scala-sbt.org/) by issuing the `sbt assembly` command.

Denote by **ergo_folder** the folder where the jar is kept. 
 
## Running the node for the first time

Create a configuration file `ergo.conf` with the following text in **ergo_folder**. 
```shell
ergo {
    directory = ${ergo.directory}"/.ergo"
    node {
        mining = false
    }
    wallet.secretStorage.secretDir = ${ergo.directory}"/wallet/keystore"
}
```

The parameter `${ergo.directory}` points to the directory where the jar will be run from. 
Open a command prompt and `cd` to **ergo_folder**. Then issue the following command to run the node for the first time:

```shell
  java -jar ergo-<release>.jar --mainnet -c ergo.conf
```
The node will start syncing immediately after this. Wait for a few minutes for the API to start and go to the next step.

**Note:** You can use any name for the file instead of `ergo.conf`. All configuration parameters are to be passed through this file and you only need to rewrite parameters that you want to change from the default values. The above config file actually has the default values. 

## Compute the hash of your secret

First, select a secret to protect your API. 
Then go to http://127.0.0.1:9053/swagger#/utils/hashBlake2b and call the API to compute the hash of your secret. Refer to the image below.

![Compute Hash of secret](/img/blog/how_to_setup_1img.png)

Copy the response containing the hash for use in the next step (see below image). In our example, the secret is `hello` whose hash corresponds to `324dcf027dd4a30a932c441f365a25e86b173defa4b8e58948253471b81b72cf`. 

**IMPORTANT** You must use a different and strong secret. 

![response](/img/blog/how_to_setup_2img.png)

## Update config file with API key hash

Edit the config file `ergo.conf` and paste the hash copied in the previous step. The file should look as follows:

```shell
ergo {
    directory = ${ergo.directory}"/.ergo"
    node {
        mining = false
    }
    wallet.secretStorage.secretDir = ${ergo.directory}"/wallet/keystore"
}

scorex {
    restApi {
        # Hex-encoded Blake2b256 hash of an API key. 
        # Should be 64-chars long Base16 string.
        # below is the hash of the string 'hello'
        # replace with your actual hash 
        apiKeyHash = "324dcf027dd4a30a932c441f365a25e86b173defa4b8e58948253471b81b72cf"
    }
}
```

## Initialize wallet

Restart the node and go to [http://127.0.0.1:9053/panel](http://127.0.0.1:9053/panel) to access the panel. Then set the API key secret from the previous step. Note that you need to set the **secret** and not the hash from the config file. In our example, this is the string `hello`. 

![set API key](/img/blog/how_to_setup_3img.png)

Finally, click on initialize wallet:

![click on initialize wallet](/img/blog/how_to_setup_4img.png)

In the pop-up that opens, you must enter a wallet password. The mnemonic password is optional. After you click send, the wallet will return a mnemonic sentence as shown below. 

![mnemonic sentence](/img/blog/how_to_setup_5img.png)

You must copy this sentence and save it in a safe place. This sentence will be needed to restore the wallet on a different computer.

## Get wallet addresses

This is a test to ensure you have set up the node properly. It will return the current addresses in the wallet. 
In the panel at [http://127.0.0.1:9053/panel](http://127.0.0.1:9053/panel) click on the `Wallet` tab on the left and then on `Get all wallet addresses` to view the addresses currently maintained by the wallet. It should return at least one address if the node is set correctly.

![Get addresses](/img/blog/how_to_setup_6img.png)

## Use the Swagger UI

A Swagger UI is available at [http://127.0.0.1:9053/swagger](http://127.0.0.1:9053/swagger). You had already used it earlier to compute the hash of your secret. 
You can also use this UI to make API calls for advanced operations that are not (yet) available in the panel. Some examples of this are:

1. Creating non-standard transactions with registers and context variables.
2. Creating transactions that issue tokens.
3. Creating transactions that use certain boxes as inputs. 

A future article will discuss each of these operations in detail. 

Note that most methods in the API are protected and you would need to use your secret (from earlier) to access these methods. The following images show the process of setting this secret in the Swagger UI.

Navigate to the top of the page and click the "Authorize" button. Enter your secret in the form that pops-up as shown in the figure below.
![Enter API key](/img/blog/how_to_setup_7img.png)

After the password is entered and you have clicked "Authorize", you will be shown the popup below:
![Logged in](/img/blog/how_to_setup_8img.png)

Now navigate to [http://127.0.0.1:9053/swagger#/wallet/walletAddresses](/img/blog/how_to_setup_9img.png) and click on "Try it out". You should see the same list of addresses as you saw earlier from the panel. 

![Get addresses](/img/blog/how_to_setup_10img.png)


How to set up and configure a full Ergo node


In today's article, we will have a closer look into the Ergo address formatting. In addition to that we are going to explain how they work specifically as well as what makes them preferable to other types of blockchain addresses.

Let's start at the very beginning.

The moment you install any cryptocurrency wallet you automatically create an address with it. Very loosely speaking you can compare a wallet to a traditional bank account and an address to the matching account number.
It is precisely one of these alphanumeric addresses that's needed to either send money from person A to person B, receive money or [withdraw your mining rewards](https://ergoplatform.org/blog/2019_07_03_mining_withdrawal/).
If you want to get started using the Ergo wallet and dive deeper into its functions go check out the [following link](https://ergoplatform.org/blog/2019_06_04_wallet-documentation/).

Now, what exactly are addresses?

Addresses are short strings that correspond to certain scripts and are used to protect a box ([this](https://www.ergoforum.org/t/ergo-terminology-a-box-and-a-register/32) post that core developer *kushti* published on our forum explains very well what a "box" is).
Unlike a (hex-encoded) binary representation of a script, an Ergo address is using a Base58-encoding and therefore has some very useful characteristics to it which the binary representation do not offer:

* The integrity of an address can easily be checked via an integrated checksum (which is a "small-sized datum derived from a block of digital data for the purpose of detecting errors that may have been introduced during its transmission or storage", according to Wikipedia).
* A prefix of the address is showing you the network and address type. In particular, the network prefix prevents you from mistakenly sending mainnet tokens to the testnet address.
* The address is using an encoding (namely, Base58 as mentioned) which is avoiding similarly looking characters and is friendly to double-clicking and also line-breaking in emails.
* An address is encoding network type, address type, checksum, and enough information to correspond with particular scripts.

Let's look at the prefix byte which contains information about the network and address types:

Possible network types are:

* Mainnet - 0x00
* Testnet - 0x10

Address types are (semantics described below):

* 0x01 - Pay-to-PublicKey(P2PK) address
* 0x02 - Pay-to-Script-Hash(P2SH)
* 0x03 - Pay-to-Script(P2S)


For an address type, we form content bytes as follows:

* P2PK - serialized (compressed) public key
* P2SH - first 192 bits of the Blake2b256 hash of serialized script bytes
* P2S  - serialized script (this is where mining rewards go!)

For example, sending 10 Ergs to a P2PK address usually means that a corresponding transaction 
will contain a box in which 10 Ergs are locked by a public key encoded in the P2PK address. Similarly,
in case of a P2S address the box will be locked by a script encoded in the address. In the most complicated case of a 
P2SH script, the box will be protected by a special predefined script which is taking first 192 bits of Blake2b256 hash 
value for a script which should be shown by an input spending the box. 


Here is an example of how particular addresses are going to look on the testnet: 

* 3 - P2PK (3WvsT2Gm4EpsM9Pg18PdY6XyhNNMqXDsvJTbbf6ihLvAmSb7u5RN)
* ? - P2SH (rbcrmKEYduUvADj9Ts3dSVSG27h54pgrq5fPuwB)
* ? - P2S (Ms7smJwLGbUAjuWQ)

And here is how they are looking on our mainnet:

* 9 - P2PK (9fRAWhdxEsTcdb8PhGNrZfwqa65zfkuYHAMmkQLcic1gdLSV5vA)
* ? - P2SH (8UApt8czfFVuTgQmMwtsRBZ4nfWquNiSwCWUjMg)
* ? - P2S (4MQyML64GnzMxZgm, BxKBaHkvrTvLZrDcZjcsxsF7aSsrN73ijeFZXtbj4CXZHHcvBtqSxQ)

In short summary:

* Prefix byte = network type + address type (for example, P2S script on the testnet starts with 0x13 before Base58)
* checksum = leftmost_4_bytes (blake2b256 (prefix byte || content bytes))
* address = prefix byte || content bytes || checksum

If any of this sparked your interest, you are very welcome to join our community and ask further questions on our [telegram channel](https://t.me/ergoplatform) and/or [forum](https://www.ergoforum.org/). 
See you there!


Ergo Addresses

An Ergo node provides a built-in wallet for storing private keys and signing transactions. The following describes how to set up and protect your Ergo wallet. 

The wallet uses the [BIP39 standard](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) to generate a seed from a mnemonic sentence, which is then used to generate the private keys according to the [BIP32 standard ](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) (Hierarchical Deterministic Wallets). You can use your own mnemonic sentence composed of the words from [one of these wordists](https://github.com/ergoplatform/ergo-wallet/tree/master/src/main/resources/wordlist) if you want to.
The allowed sentence lengths are 12, 15, 18, 21, 24 representing respectively, 128, 160, 192, 224, 256 bits of security. In order to initialize a wallet with such a mnemonic, you should use the `wallet/restore` API endpoint. 
However, it is far more secure to use the mneomnic generated by the wallet.

At this stage, all interactions with the wallet can only be done through the node's REST API. Please ensure that you have [set an API key](https://github.com/ergoplatform/ergo/wiki/Ergo-REST-API#setting-an-api-key) in your node before performing the next steps.

## Configuring the wallet

The wallet is configured through the node configuration file. Below are the configuration parameters worth paying attention to when configuring wallet for the first time:

* `ergo.wallet.seedStrengthBits` - Bit-length of a seed in case it will be generated by the node. Note: the stronger the seed the longer the mnemonic sentence length is. Options: `128, 160, 192, 224, 256`
* `ergo.wallet.secretStorage.secretDir` - Directory where secret will be stored in encrypted form
* `ergo.wallet.mnemonicPhraseLanguage` - Language to be used in mnemonic sentence. Options: `"chinese_simplified", "chinese_traditional", "english", "french", "italian", "japanese", "korean", "spanish"`

## Using the wallet for the first time

The wallet needs to be initialized via the REST API when running the node for the first time. Two options are available here: 

1. Initialize it from scratch (seed will be generated by the node) by making a POST request to `/wallet/init` with data `body: {"pass": "123", "mnemonicPass": "abc"}`. *Don't forget to save the mnemonic phrase that the node responds with*. (Note: The parameter `mnemonicPass` in request body is optional and is used for protecting the mnemonic phrase).
2. Restore the wallet from an existing seed. You will have to provide your mnemonic phrase When using this option. This is done by making a POST request to `/wallet/restore` with data `body: {"pass": "123", "mnemonic": "abandon abandon ...", "mnemonicPass": "abc"}` (Note: the `mnemonicPass` field is required only in case your mnemonic phrase was protected by an additional password at creation).

## Unlocking the wallet

After initialization and before every use the wallet needs to be unlocked by making a `POST` request to `/wallet/unlock` with data `body: {"pass": "123"}`. (Note: use the password you had chosen at initialization stage)

You must perform this step every time the node is restarted or the wallet is locked.
In particular, the wallet must be unlocked for the following operations:  

* Using internal miner
* Signing transactions
* Tracking boxes

## Locking the wallet

A wallet is automatically locked after some time, which means that all currently loaded secrets are flushed from the memory. You can also use the REST API to lock the wallet by making a `GET` request to `/wallet/lock`. 
It is recommended to lock the wallet when it is not in use. 
After locking, you will need to unlock the wallet to use it again.

## Managing keys

A wallet implements BIP32 ("Hierarchical deterministic wallets"). When the wallet is initialized the only root key is created.
In order to derive additional key pair corresponding to a specific derivation path (method: POST, request body: `{"derivationPath": "m/1/2"}`) the `/wallet/deriveKey` API route can be used.
In order to simply create additional key pair use a `/wallet/deriveNextKey` API route (method: GET).


Wallet documentation

This article describes a full featured ICO (Initial Coin Offering) implemented in ErgoScript. The example covers several important and novel features of the Ergo Platform and shows how it can support complex contracts with tiny amount of code. 

## Part 1. Preliminaries

An important design decision in a cryptocurrency protocol is specifying what a spending transaction actually spends. There are two possibilities here. The first a UTXO-based model, as in Bitcoin, where a transaction spends one-time asset containers (called as 'coins' or UTXOs in Bitcoin) and creates new ones. The other is an account-based model, as in Nxt, Ethereum or Waves, where a transaction transfers some amount of asset from an existing long-living account to another, possibly new, long-living account, with possible side-effects on the way, such as contract execution in Waves or Ethereum. In this regard, Ergo is similar to Bitcoin, because it uses the UTXO-based approach, where one-time containers called boxes are being spent. Interestingly, an Ergo transaction can also have data-inputs which are not being spent, but rather used to provide some information from the current set of unspent boxes.

It is not trivial to create an ICO on top of an UTXO based model, because, in contrast to account-based models, there is no explicit persistent storage here. However, Ergo brings a spending transaction into the execution context of a script. 
With this small change it becomes possible to express dependencies between transaction outputs and inputs. In turn, by setting dependencies we can execute even arbitrarily complex Turing-complete programs on top of blockchain (see the ["Self-reproducing Coins as Universal Turing Machine" paper](https://link.springer.com/chapter/10.1007/978-3-030-00305-0_4)). In this article we will define a concrete scenario of a multi-stage contract using an ICO, where we have three stages (funding, token issuance, withdrawal).

Now imagine an ICO for thousands of participants. Unlike Ethereum, Ergo does not provide possibility to store large sets of data and carry them over throughout contract execution. Rather, it allows to store only about 40-bytes header of a data 
structure, represented as key -> value dictionary, authenticated similarly to Merkle tree. To access some elements 
in the dictionary, or to modify it, a spending transaction which is triggering protecting script execution should 
provide lookup or modification proofs. This gives possibility for a contract to authenticate potentially huge datasets without requiring much memory to store contract state. However, storing space in the state (of active contracts) would mean bigger transactions, but this problem is easier from scalability point of view, and scalability is a top priority for Ergo. 


## Part 2. The ICO Contract

There could be many possible scenarios associated with an Initial Coin Offering (ICO). In this article we consider an ICO that wants to collect at least a certain amount of funds (in Ergs) to start the project. Once the funding threshold is crossed and funding period ends, the project is kickstarted and ICO tokens are issued by the project based on the total funding collected. In the withdraw phase, which extends forever, the investors withdraw ICO tokens based on the amount they had invested during the funding period. The contract steps are briefly described below with details provided further:

* First, *funding epoch* takes place. It starts with a project's box authenticating an empty dictionary. The dictionary is intended for holding (investor, balance) pairs, where investor is a script protecting the box containing withdrawn tokens. For the balance, we assume that 1 token is equal to 1 Ergo during the ICO. During the funding epoch, it is only possible to put Ergs into the project's box.
A funding transaction spends the project's box and creates a new project box with updated information. For that, a spending transaction for the project's box also has other inputs which hold investor withdrawing scripts. Investor scripts and input values should be added to the tree of the new box. There could be many chained funding transactions.  
* Second, the funding period finishes, after which the tree holding the investors data becomes read-only. An authenticated tree could have different modification operations allowed individually: inserts, deletes, updates, or all the operations could be disallowed (so the tree could be in the read-only mode). Also, this transaction creates tokens of the ICO project which will be withdrawn in the next stage. The project can withdraw Ergs at this stage.  
* Third, investors withdraw their ICO tokens. For that, a spending transaction creates outputs with guarding conditions and token values taken from the tree. The withdrawn pairs are also cleared from the tree. There could be many chained spending transactions.

These three stages should be linked together in the logical order. A seqience of boxes are used to achieve these goals.

## Part 3. The ICO Contract Details

Now it is the time to provide details and ErgoScript code of the ICO contract stages.

### The Funding Stage

In the funding stage, which comes first, we assume that initially a project creates a box committing to an empty dictionary (stored in the register R5) with some guarding script described below. This stage lasts at least till height 2,000. More concretely, the first transaction with height of 2,000 or more should change the output box's script as described in the next section (transactions at lower heights must output a box with the same script).

The project's box checks that it is always first input and output of a transaction. The other inputs are considered investors' inputs. An investor's input contains the hash of a script in register R4. This hash represents the _withdraw script_ that will be used later on in the withdraw phase. The hashes as well as the monetary values of all investing inputs should be added to the dictionary. The 
spending transaction provides a proof that investor data are indeed added to the dictionary, and the proof is checked in the contract. 

It is not checked in the funding sub-contract that the dictionary allows only insertions, and not updating existing values or removals (it is not hard to add an explicit check though). 

The spending transaction should pay a fee, otherwise, it is unlikely that it would be included in a block. Thus, the funding contract checks that the spending transaction has two outputs (one for itself, another to pay fee), the fee is to be no more than a certain limit (just one nanoErg in our example), and the guarding proposition should e such that only a miner can spend the output (we use just a variable "feeProp" from compilation environment in our example without providing any details). This "feeProp" corresponds to a standard, though not required by protocol. 

The code below enforces the conditions described above. Please note that the 
"nextStageScriptHash" environment variable contains hash of the issuance stage serialized script. 
```scala
    val selfIndexIsZero = INPUTS(0).id == SELF.id

    val proof = getVar[Coll[Byte]](1).get

    val inputsCount = INPUTS.size

    val toAdd: Coll[(Coll[Byte], Coll[Byte])] = INPUTS.slice(1, inputsCount).map({ (b: Box) =>
        val pk = b.R4[Coll[Byte]].get
        val value = longToByteArray(b.value)
        (pk, value)
    })

    val modifiedTree = SELF.R5[AvlTree].get.insert(toAdd, proof).get

    val expectedTree = OUTPUTS(0).R5[AvlTree].get

    val properTreeModification = modifiedTree == expectedTree

    val outputsCount = OUTPUTS.size == 2

    val selfOutputCorrect = if(HEIGHT < 2000) {
        OUTPUTS(0).propositionBytes == SELF.propositionBytes
    } else {
        blake2b256(OUTPUTS(0).propositionBytes) == nextStageScriptHash
    }

    val feeOutputCorrect = (OUTPUTS(1).value <= 1) && (OUTPUTS(1).propositionBytes == feeBytes)

    val outputsCorrect = outputsCount && feeOutputCorrect && selfOutputCorrect

    selfIndexIsZero && outputsCorrect && properTreeModification
```

### The Issuance Stage

This stage has only one spending transaction to get to the next stage (the withdrawal stage). The spending transactions makes the following modifications. Firstly, the it changes the list of allowed operations on the dictionary from "inserts only" to "removals only", as the next stage (withdrawal) is only dealing with removing entries from the dictionary.

Secondly, the contract checks that the proper amount of ICO tokens are issued. In Ergo, it is allowed to issue one new kind of token per transaction, and the identifier of the token should be equal to the (unique) identifier of the first input box. The issuance sub-contract checks that a new token has been issued, and the amount of it is equal to the amount of nanoErgs collected by the ICO at till now.

Thirdly, the contract checks that a spending transaction is indeed re-creating the box with the guard script corresponding to the next stage, the withdrawal stage.

Finally, the project should withdraw collected Ergs, and of course, each spending transaction should pay a fee. Thus, the sub-contract checks that the spending transaction has indeed 3 outputs (one each for the project tokens box, the Ergs wirhdrawal box, and the fee box), and that the first output and output is carrying the tokens issued. As we do not specify project money withdrawal details, we require a project signature on the spending transaction.
```scala
    val openTree = SELF.R5[AvlTree].get
    
    val closedTree = OUTPUTS(0).R5[AvlTree].get
    
    val digestPreserved = openTree.digest == closedTree.digest
    val keyLengthPreserved = openTree.keyLength == closedTree.keyLength
    val valueLengthPreserved = openTree.valueLengthOpt == closedTree.valueLengthOpt
    val treeIsClosed = closedTree.enabledOperations == 4
    
    val tokenId: Coll[Byte] = INPUTS(0).id
    
    val tokensIssued = OUTPUTS(0).tokens(0)._2
    
    val outputsCountCorrect = OUTPUTS.size == 3
    val secondOutputNoTokens = OUTPUTS(0).tokens.size == 1 && OUTPUTS(1).tokens.size == 0 && OUTPUTS(2).tokens.size == 0
    
    val correctTokensIssued = SELF.value == tokensIssued
    
    val correctTokenId = OUTPUTS(0).R4[Coll[Byte]].get == tokenId && OUTPUTS(0).tokens(0)._1 == tokenId
    
    val valuePreserved = outputsCountCorrect && secondOutputNoTokens && correctTokensIssued && correctTokenId
    val stateChanged = blake2b256(OUTPUTS(0).propositionBytes) == nextStageScriptHash
    
    val treeIsCorrect = digestPreserved && valueLengthPreserved && keyLengthPreserved && treeIsClosed
    
    projectPubKey && treeIsCorrect && valuePreserved && stateChanged
```

### The Withdrawal Stage

At this stage, investors are allowed to withdraw project tokens protected by a predefined guard script (whose hash is stored in the dictionary). Lets say withdraw is done in batches of size N. A withdrawing transaction, thus, has N + 2 outputs, where the first output carrys over the withdrawal sub-contract and balance tokens, the last output pays the fee and the remaining N outputs have guarding scripts and token values according to the dictionary. The contract requires two proofs for the dictionary elements: one proving that values to be withdrawn are indeed in the dictionary, and the second proving that the resulting dictionary does not have the withdrawn values. The sub-contract is below.  
```scala
    val removeProof = getVar[Coll[Byte]](2).get
    val lookupProof = getVar[Coll[Byte]](3).get
    val withdrawIndexes = getVar[Coll[Int]](4).get

    val out0 = OUTPUTS(0)

    val tokenId: Coll[Byte] = SELF.R4[Coll[Byte]].get

    val withdrawals = withdrawIndexes.map({(idx: Int) =>
        val b = OUTPUTS(idx)
        if(b.tokens(0)._1 == tokenId) {
            (blake2b256(b.propositionBytes), b.tokens(0)._2)
        } else {
            (blake2b256(b.propositionBytes), 0L)
        }
    })

    val withdrawValues = withdrawals.map({(t: (Coll[Byte], Long)) => t._2})

    val withdrawTotal = withdrawValues.fold(0L, { (l1: Long, l2: Long) => l1 + l2 })

    val toRemove = withdrawals.map({(t: (Coll[Byte], Long)) => t._1})

    val initialTree = SELF.R5[AvlTree].get

    val removedValues = initialTree.getMany(toRemove, lookupProof).map({(o: Option[Coll[Byte]]) => byteArrayToLong(o.get)})
    val valuesCorrect = removedValues == withdrawValues

    val modifiedTree = initialTree.remove(toRemove, removeProof).get

    val expectedTree = out0.R5[AvlTree].get

    val selfTokensCorrect = SELF.tokens(0)._1 == tokenId
    val selfOutTokensAmount = SELF.tokens(0)._2
    val soutTokensCorrect = out0.tokens(0)._1 == tokenId
    val soutTokensAmount = out0.tokens(0)._2

    val tokensPreserved = selfTokensCorrect && soutTokensCorrect && (soutTokensAmount + withdrawTotal == selfOutTokensAmount)

    val properTreeModification = modifiedTree == expectedTree

    val selfOutputCorrect = out0.propositionBytes == SELF.propositionBytes

    properTreeModification && valuesCorrect && selfOutputCorrect && tokensPreserved
```

## Possible Enhancements

Please note that there are many nuances our example contract is ignoring. For example, anyone listening to the blockchain is allowed to execute the contract and construct proper spending transactions during funding and withdrawal stages. In the real-world, additional signature from the project or a trusted arbiter may be used. 

Also, there is no self-destruction case considered in the withdrawal contract, so it will live until being destroyed by miners via storage rent mechanism, potentially for decades or even centuries. For the funding stage, it would be reasonable to have an additional input from the project with the value equal to the value of the fee output. And so on.


An ICO Example On Top Of Ergo

Paper published, we would be happy to get feedback!

ErgoScript, a Cryptocurrency Scripting Language Supporting Noninteractive Zero-Knowledge Proofs


A lot of blockchain-related news these days are saying us that a bank _X_ or a corporation _Y_
is going to use a "blockchain" to "reduce costs". Basically it means that just another buzzword is 
considered by big banksters as just another tool to extract value from everywhere in a more efficient way,
and also to save on cutting job positions.  

While I am avoiding to say anything about "Satoshi's vision" (nothing but speculations could be dug there after 
his exodus), a broad view I witnessed in the early years around online forums users is that a cryptocurrency 
should provide tools to enrich the ordinary people behind their small businesses providing no much above making ends meet, not depersonalized big financial capital. The tools of 
a cryptocurrency in the eyes of the original broad community vision should allow people to do economic activity dependless on business size, geographic location, interest rates set by big players, and so on. 
The tools should allow people to do contracts (no paper contracts, but digital, self-enforcing, and reasonably smart contracts) dependless on differences in jurisdictions, traditions, followed business practices etc.

I hope Ergo would be useful here. Thousands of small cooperatives and individual entrepreneurs are more important to healthy and sustainable wealth growth around the globe than a couple of corporations hiding profits in offshore heavens. 

As an example, let's consider a cooperative federation (such as [Radical Routes](http://www.radicalroutes.org.uk/)) willing to provide financial help to an entrepreneur thousands kilometers away (say, in Rojava). 

We need to assume some details now. In the first place, assume that there are four cooperatives in the network. They collectively lock _10,000_ Ergs (in equal parts, so _2,500_ Ergs each) in a contract, which says the following:

1. The cooperatives are associated with public keys _pubkeyA_, _pubkeyB_, _pubkeyC_, _pubkeyD_. The entrepreneur is associated with a public key _businessKey_.
2. The cooperatives are locking money in a coin protected by a funding contract, then doing due diligence and vote on whether to fund the entrepreneur or not. All the contract fund (_10,000_ Ergs) is going to the entrepreneur if _3_ votes out of _4_ are for that. Technically, the voting is done via 3-out-of-4 threshold signature. If voting is not successful (_3_ out of _4_ signatures are not collected) before the block number _1,000_, any cooperative (actually, anyone) can submit withdraw transaction, which is returning _2,500_ Ergs (at least) to every cooperative. Further, the funding contract will also be called the voting contract.
3. The investments could be spent on three goals, with some strict bounds. Namely, the entrepreneur must spend at least _5,000_ Ergs on equipment, at least _2,000_ Ergs on construction of a building needed, other funds the entrepreneur may spend arbitrarily.
4. To be sure that equipment money will be spent on equipment, the cooperative federation is using public keys of known equipment sellers in the area of the entrepreneur. For example, consider that there are equipment sellers with public keys _pubkeyTool1_, _pubkeyTool2_, _pubkeyTool3_, _pubkeyTool4_ in the area. Technically, the transfer is organized as a collective signature of one equipment sellers (thus ring signature from equipment sellers ring AND entrepreneur's signature)
5. Similarly, assume that there are _3_ builders in the are cooperative federation is recognizing, associated with public keys _pubkeyConstr1_, _pubkeyConstr2_, and _pubkeyConstr3_.
6. Similarly to the voting contract, if equipment and construction contracts are not co-signed before block number _5000_, the federation cooperatives could withdraw funds. 

There are different ways to define contracts in Ergo. A script in the low-level language, **ErgoTree**, is describing a (single) logical condition on whether a coin could be spent according it, and also a spending proof provided by a spending transaction. Internally, the condition is represented as a typed syntax tree thus the name. The structure is allowing us to do ahead-of-time cost analysis etc. Higher-level language called **ErgoScript** allows to have more traditional and readable description, use variables and break logic into subroutines. 

Let's start with the main contract defined in (1-3) above:

```scala
{
 val votingSuccess  = atLeast(3, Array(pubkeyA, pubkeyB, pubkeyC, pubkeyD))
 val properSpending = OUTPUTS(0).value >= 5000L &&
                      blake2b256(OUTPUTS(0).propositionBytes) == spendingContract1Hash &&
                      OUTPUTS(1).value >= 2000L &&
                      blake2b256(OUTPUTS(1).propositionBytes) == spendingContract2Hash

 val withdrawCondition = HEIGHT >= 1000L &&
                         OUTPUTS(0).value >= 2500L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
                         OUTPUTS(1).value >= 2500L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
                         OUTPUTS(2).value >= 2500L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
                         OUTPUTS(3).value >= 2500L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes 

 (votingSuccess && properSpending) || withdrawCondition
}
```

This script in the **ErgoScript** is to be compiled into a syntax tree (which is to be written into the blockchain in a serialized form) by binding it with concrete values for variables (_pubkeyA_, _pubkeyB_, _pubkeyC_, _pubkeyD_, _spendingContract1Hash_, _spendingContract2Hash_). _spendingContract1Hash_ is a hash of (serialized) equipment spending script which will be provided below, _spendingContract2Hash_ is a hash of construction spending script. 


The equipment spending script is below: 

```scala
{
 val spendingSuccess = (pubkeyTool1 || pubkeyTool2 || pubkeyTool3 || pubkeyTool4) && businessKey

 val withdrawCondition = HEIGHT > 5000L &&
                         OUTPUTS(0).value >= 1250L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
                         OUTPUTS(1).value >= 1250L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
                         OUTPUTS(2).value >= 1250L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
                         OUTPUTS(3).value >= 1250L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes 

 spendingSuccess || withdrawCondition
}
```

And the construction script is: 

```scala
{
 val spendingSuccess = (pubkeyConstr1 || pubkeyConstr2 || pubkeyConstr3) && businessKey

 val withdrawCondition = HEIGHT > 5000L &&
                         OUTPUTS(0).value >= 500L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
                         OUTPUTS(1).value >= 500L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
                         OUTPUTS(2).value >= 500L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
                         OUTPUTS(3).value >= 500L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes 

 spendingSuccess || withdrawCondition
}
```

Now assume that the cooperative federation has created a coin protected by the voting contract. Below is how the entrepreneur can do his business:

1. Create a transaction which consumes the coin and create at least three coins, one with equipment spending contract, another with construction spending contract, third is creating a coin protected by entrepreneur's public key.  
2. Send the transaction to the cooperatives, wait for the transaction with the threshold-signed input being published on the blockchain.  
3. Consider a contract with an equipment seller, co-sign a spending transaction.
4. Consider a contract with a builder, co-sign a spending transaction.


The entrepreneur can easily run away without doing any business, but with no more than _3,000_ Ergs. This can be fixed, e.g. this money could be made spendable only after block number _5,000_, and before that money could be withdrawn by the cooperatives. For equipment and construction spendings, the entrepreneur is working along with some, presumably already reputable, business. Thus the investor is reducing its risks.

You can find [code and example transactions online](https://github.com/ScorexFoundation/sigmastate-interpreter/blob/master/src/test/scala/sigmastate/utxo/examples/CoopExampleSpecification.scala). Please note that we have more examples of complex signature schemes, multi-step contracts (with on-the-go execution paths revealing, like MAST in Bitcoin, but with cycles allowed), oracles, crowdfunding and so on. Please check our [examples repository](https://github.com/ScorexFoundation/sigmastate-interpreter/tree/master/src/test/scala/sigmastate/utxo/examples). 
