├── img ├── token-lifecycle.jpg ├── token-interactions.jpg └── proof-of-asset-scheme.jpg ├── Brickblock Technical Whitepaper.pdf ├── Brickblock Technical Whitepaper - Chinese.pdf ├── Brickblock Technical Whitepaper - Spanish.pdf └── README.md /img/token-lifecycle.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/brickblock-io/whitepaper-technical/HEAD/img/token-lifecycle.jpg -------------------------------------------------------------------------------- /img/token-interactions.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/brickblock-io/whitepaper-technical/HEAD/img/token-interactions.jpg -------------------------------------------------------------------------------- /img/proof-of-asset-scheme.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/brickblock-io/whitepaper-technical/HEAD/img/proof-of-asset-scheme.jpg -------------------------------------------------------------------------------- /Brickblock Technical Whitepaper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/brickblock-io/whitepaper-technical/HEAD/Brickblock Technical Whitepaper.pdf -------------------------------------------------------------------------------- /Brickblock Technical Whitepaper - Chinese.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/brickblock-io/whitepaper-technical/HEAD/Brickblock Technical Whitepaper - Chinese.pdf -------------------------------------------------------------------------------- /Brickblock Technical Whitepaper - Spanish.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/brickblock-io/whitepaper-technical/HEAD/Brickblock Technical Whitepaper - Spanish.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Brickblock Technical Whitepaper 2 | by Marius Hanne, Jakob Drzazga, Adrian Kizlauskas, Philip Paetz, Martin Mischke 3 | 4 | ### Abstract 5 | This document describes a smart contract platform built on top of a globally distributed 6 | computing network such as [Ethereum](https://ethereum.org/) or [Rootstock](http://www.rsk.co). 7 | The suggested Proof-of-Asset (PoA) scheme will enable users to seamlessly trade tokens, 8 | which represent different types of Foreign-Asset on all [ERC20](https://theethereum.wiki/w/index.php/ERC20_Token_Standard) compatible markets. 9 | 10 | The basic idea is to create a number of PoA contracts, each representing a different foreign asset. 11 | By linking the token contract to a digital trust fund DTF, there will be a near 1:1 coupling between 12 | the value of the token and the foreign asset. 13 | 14 | Users can purchase PoA-Token in exchange for Native-Currency, trade them, 15 | or hold them and receive a share of any dividends that the asset pays out. 16 | 17 | Investors may redeem their PoA tokens, prompting the DTF to liquidate the corresponding foreign assets 18 | and refund their current market value in native currency. 19 | 20 | ### Table of Contents 21 | * [1. Overview](#1-overview) 22 | * [2. Brickblock](#2-brickblock) 23 | + [2.1. Brickblock Token (BBT)](#21-brickblock-token-bbt) 24 | + [2.2. Access Token (ACT)](#22-access-token-act) 25 | + [2.3. Digital Trust Fund (DTF)](#23-digital-trust-fund-dtf) 26 | + [2.4. Fees](#24-fees) 27 | + [2.5. Contract Discovery and Upgrades](#25-contract-discovery-and-upgrades) 28 | + [2.6. Broker registration](#26-broker-registration) 29 | * [3. Proof-of-Asset](#3-proof-of-asset) 30 | + [3.1. Creation](#31-creation) 31 | + [3.2. Activation](#32-activation) 32 | + [3.3. Trading](#33-trading) 33 | + [3.4. Dividend Payout](#34-dividend-payout) 34 | + [3.5. Redemption](#35-redemption) 35 | + [3.6. Extension](#36-extension) 36 | + [3.7. Fraud Proofs](#37-fraud-proofs) 37 | * [4. Real-World-Asset Funds](#4-real-world-asset-funds) 38 | + [4.1. Funding](#41-funding) 39 | + [4.2. Failed](#42-failed) 40 | + [4.3. Pending](#43-pending) 41 | + [4.4. Activation](#44-activation) 42 | + [4.5. Dividend Payout](#45-dividend-payout) 43 | + [4.6. Redemption](#46-redemption) 44 | + [4.7. Extension](#47-extension) 45 | * [5. Crypto Funds](#5-crypto-funds) 46 | + [5.1. Passive (CTF)](#51-passive-ctf) 47 | + [5.2. Active (CMF)](#52-active-cmf) 48 | + [5.3. Autonomous (ACF)](#53-autonomous-acf) 49 | * [6. Compatibility](#6-compatibility) 50 | * [Glossary](#glossary) 51 | 52 | 53 | ## 1. Overview 54 | During a contribution period, Brickblock tokens (BBT) will be distributed among participating contributors. 55 | Brickblock tokens can be traded on any market, or locked up in order to generate so called access tokens (ACT). 56 | Access tokens are required to pay the fees for operating PoA contracts and keeping them alive over time. 57 | Proof-of-Asset tokens represent a certain foreign asset available to trade on the Brickblock platform. 58 | The assets backing those tokens are held by a pulicly auditable digital trust fund. 59 | All these tokens implement the ERC20 specification and are seamlessly tradeable on compatible third-party markets. 60 | 61 | 62 | 63 | *Figure 1: The different types of tokens, and how they interact* 64 | 65 | 66 | ## 2. Brickblock 67 | Brickblock will be represented by a smart contract that runs on the 68 | blockchain, which handles broker registration and manages individual PoA 69 | contracts. 70 | 71 | ### 2.1. Brickblock Token (BBT) 72 | The Brickblock contract itself implements an ERC20-compatible token, 73 | which will be distributed to the contributors of our fundraiser. 74 | 75 | In addition to being tradeable, these tokens are needed to generate new 76 | access tokens. 77 | 78 | ### 2.2. Access Token (ACT) 79 | Access tokens are required to pay fees to operate PoA contracts and keep 80 | them alive. They can only be generated by locking BBT into the access 81 | token contract. 82 | 83 | While BBT are locked, the contract will credit new ACT to the senders 84 | account. The rate at which ACT are generated increases over time while 85 | the BBT are locked. Generated ACT can be withdrawn at any time, however, 86 | doing so resets the age of the locked BBT that generated them. 87 | 88 | Access tokens are required to operate certain functions of the PoA 89 | contracts, and are destroyed upon use. The PoA contract will notify the 90 | access token contract of the user’s address and the number of ACT 91 | required. If the user has enough tokens in his or her account, then the 92 | requested amount will be subtracted and the operation will be allowed to 93 | continue. If the balance is not enough, then the call will throw an 94 | exception, preventing the PoA contract from executing the requested 95 | function. 96 | 97 | ### 2.3. Digital Trust Fund (DTF) 98 | Brickblock will set up a digital trust fund that holds the assets that 99 | are backing the PoA tokens in an investment account with a custodian. 100 | 101 | The custodian will both notarize any activities on the DTF’s account and 102 | publish proof allowing everyone to verify that all liabilities are 103 | accounted for. 104 | 105 | ### 2.4. Fees 106 | Over its lifetime, a PoA contract requires various parties to pay three 107 | different types of fees in the form of ACT: a creation fee, a 108 | liquidation fee, and an existence fee. 109 | 110 | A creation fee needs to be paid by a broker to create a new PoA contract 111 | and offer it to investors. 112 | 113 | A liquidation fee needs to be paid by users in case they want to redeem 114 | their tokens for native currency. 115 | 116 | An existence fee needs to be paid by anyone interested in the contracts 117 | continued operation. If there is not enough interest to cover fees, the 118 | contract suspends operations until enough fees are paid to revive it. 119 | This will help to remove obsolete and unwanted contracts, and provides 120 | an additional incentive to brokers to make attractive offers. 121 | 122 | The paid ACT will be burned and thus removed from circulation. 123 | Brickblock does not keep or trade them after they have been used. 124 | 125 | ### 2.5. Contract Discovery and Upgrades 126 | To enable the upgrading of features, all smart contracts will be 127 | accessed through a proxy contract with a fixed address. 128 | 129 | Individual contracts can also be suspended, as an emergency measure, in 130 | the case of a bug being discovered. 131 | 132 | We acknowledge the partial loss of real decentralization by being the 133 | single party controlling the upgrade mechanism. However, BBT holders 134 | will have the ability to veto and thus delay any change being deployed 135 | to the production network. 136 | 137 | ### 2.6. Broker registration 138 | Brokers must be approved by the Brickblock team and undergo strict 139 | due-diligence procedures before being allowed to trade on the platform. 140 | The Brickblock contract holds a list of all currently active brokers and 141 | allows the Brickblock administration to add and remove them. To add a 142 | broker to the list, a fee must be paid in ACT. 143 | 144 | ## 3. Proof-of-Asset 145 | 146 | 147 | *Figure 2: The Proof-of-Asset Scheme* 148 | 149 | The Proof-of-Asset mechanism works by establishing a “triangle of trust” 150 | between a user, the DTF and a broker, mediated by a mutually trusted 151 | smart contract. 152 | 153 | A User pays native currency to the contract. The broker can claim this 154 | amount once he or she has sent the required assets to the DTF. 155 | 156 | The DTF proves receipt of the assets to the smart contract, which 157 | releases the native currency to the broker and the newly created PoA 158 | tokens to the User. 159 | 160 | The user can trust the contract to only activate when a valid 161 | proof-of-assets is received, or refund the initial amount. 162 | 163 | The broker can similarly trust the contract to release the funds, and 164 | must trust the DTF to send the proof of receipt to the contract. The 165 | actual proof of receipt will be provided publicly by that custodian, who 166 | must be trusted not to misappropriate the funds in any case. 167 | 168 | Until this process has established trust with brokers, the DTF will 169 | assume a micro-credit to make an atomic swap with the broker through the 170 | custodian. Instead of the broker, the DTF will receive the native 171 | currency from the smart contract, and convert it to pay back the 172 | micro-credit. 173 | 174 | The custodian notarizes and publishes any transactions and balances of 175 | the DTF’s account. This allows users to independently verify that all 176 | liabilities of the DTF are still accounted for at any point in time. In 177 | case of a mismatch, the user can send a fraud proof to the PoA contract, 178 | causing it to lock down and suspend all trading. 179 | 180 | Users who want to purchase tokens instantly for a fixed price can do so 181 | on arbitrary, ERC20-compatible, external token markets. This alleviates 182 | the burden of acquiring and handling a basket of all the different 183 | currencies, and allows users to simply buy PoA tokens with a single 184 | currency and without any waiting periods, especially in the case of 185 | coin-traded funds (CTFs). 186 | 187 | ### 3.1. Creation 188 | When creating a new PoA contract, the broker defines its parameters: 189 | 190 | | Parameter | Description | 191 | |----------------|--------------------------------------------------------------------------------| 192 | | Asset ID | Identification of the asset, like ISIN | 193 | | Name / Symbol | Name and symbol of the token within the smart contract ecosystem | 194 | | Minimum Supply | Minimum amount of initial funding required | 195 | | Custodian Info | Data required to validate the proof from the custodian | 196 | | Timeout | Time at which the `funding` stage is canceled if it has not reached the target | 197 | 198 | The contents of these fields vary between the different types of PoA 199 | contracts, which are detailed below. 200 | 201 | For example, a CTF contract usually requires only a negligible minimum 202 | supply. Thus, it has no `funding` stage and requires no extension 203 | contract, since its new tokens activate as soon as they are created. 204 | 205 | The custodian info for a real-world-asset contract is a custodian’s 206 | public key, which is used to sign the proof-of-assets. A crypto-asset 207 | contract requires a list of all the accounts used to hold the different 208 | currencies. 209 | 210 | ### 3.2. Activation 211 | To activate a PoA contract, it must receive valid proof from the 212 | custodian that the assets have been received by the DTF. 213 | 214 | For real-world-asset contracts, this proof is a signature from the 215 | custodian, notarizing the current account balance of the DTF. 216 | 217 | For crypto-asset contracts, the proof is based on validating the 218 | inclusion of a funding transaction in the foreign blockchain. 219 | 220 | If no valid proof is received within the specified timeout, the contract 221 | pays back all collected funds to the investors. 222 | 223 | ### 3.3. Trading 224 | All PoA tokens are tradeable on ERC20-compatible external markets, as 225 | with any other token. 226 | 227 | ### 3.4. Dividend Payout 228 | When the asset tracked by the PoA contract yields any dividends, those 229 | will be converted to native currency by the DTF, sent to the PoA 230 | contract, and distributed among all token holders. Users can then claim 231 | their share of the profits at any time. 232 | 233 | ### 3.5. Redemption 234 | At any time users can redeem their active PoA tokens for their current 235 | value in native currency. 236 | 237 | To do this, the user must first complete a mandatory know-your-customer 238 | (KYC) process with Brickblock. 239 | 240 | When the user sends PoA tokens back to the contract, they will receive 241 | the current value of the tracked asset in native currency. The contract 242 | will notify the DTF, which provides the required native currency and 243 | liquidates the appropriate number of shares through the broker. 244 | 245 | ### 3.6. Extension 246 | To extend the of a PoA contract, a subcontract, which implements a new 247 | funding round identical to the parent contract, can be created. Upon 248 | activation, the subcontract will send the proof-of-assets to its parent, 249 | prompting it to merge the new balances. 250 | 251 | Note that this will only be necessary when the new funding round itself 252 | has a Minimum Supply restriction. In most cases, users can simply 253 | purchase new tokens from the contract while the DTF acquires the 254 | necessary additional assets. 255 | 256 | ### 3.7. Fraud Proofs 257 | All liabilities of the DTF will be publicly accounted for in a way that 258 | allows everyone spotting a discrepancy to prove this fact to the PoA 259 | contract. 260 | 261 | When the contract receives valid proof-of-fraud, it automatically locks 262 | down and suspends any activities. 263 | 264 | Unless the contract is provided with a new and valid proof-of-assets 265 | within a certain time, it will self-destruct and invalidate all its 266 | tokens. 267 | 268 | After the contract has been unlocked again, it will resume normal 269 | operations. 270 | 271 | ## 4. Real-World-Asset Funds 272 | The real-world-asset funds contract implements funds consisting of 273 | foreign assets, such as exchange-traded funds (ETF) and real estate 274 | funds (REF). 275 | 276 | ### 4.1. Funding 277 | The PoA contract initially sells its tokens to investors in exchange for 278 | native currency, until the specified funding goal is reached. 279 | 280 | ### 4.2. Failed 281 | If the funding goal is not reached within the specified time frame or 282 | the activation times out, then the contract moves into the `failed` 283 | stage. 284 | 285 | Investors can send their purchased PoA tokens back to the contract, and 286 | they will receive their native currency in return. 287 | 288 | ### 4.3. Pending 289 | If the funding goal is reached, the contract goes into the `pending` 290 | stage and tells the broker to secure the foreign assets. 291 | 292 | The broker secures the foreign assets and transfers them to the DTF’s 293 | account with the custodian. 294 | 295 | The custodian will notarize and publish all transactions on the DTF’s 296 | account, along with the corresponding PoA contracts address. 297 | 298 | The custodian will do so to activate the PoA contract, by 299 | cryptographically signing a statement consisting of the following: 300 | 301 | | Parameter | Description | 302 | |-----------|-----------------------------------------| 303 | | Address | The address of the contract | 304 | | ISIN | The identification of the foreign asset | 305 | | Amount | The number of shares transferred | 306 | 307 | ### 4.4. Activation 308 | If the Proof is valid, the contract transitions into the `active` stage. 309 | If the contract is not activated within a certain time frame, it moves 310 | into the `failed` stage. 311 | 312 | The contract verifies that the signed statement both consists of the 313 | expected data and has a valid signature from the custodian. To do this, 314 | it first recreates the expected statement data from its own memory, then 315 | it uses this data in combination with the received signature to recover 316 | the signing address. If the recovered address equals that of the 317 | custodian, it is simultaneously proven that the data is correct and the 318 | signature was indeed made by the custodian. If the statement data is 319 | different from the information that the custodian used to create the 320 | signature, recovery yields a different address and the contract does not 321 | activate. 322 | 323 | The PoA contract notifies the broker that his or her funds are cleared. 324 | The broker can now request reimbursement from the PoA contract and will 325 | receive the collected native currency. 326 | 327 | ### 4.5. Dividend Payout 328 | Whenever the tracked asset yields any dividends, they will be converted 329 | into native currency and sent to the PoA contract. 330 | 331 | Investors can then claim their share of the dividends at any time. 332 | 333 | ### 4.6. Redemption 334 | Investors can redeem their PoA tokens for the current market price of 335 | the tracked asset. 336 | 337 | Tokens sent back to the contract are burned, and the DTF requests the 338 | broker to liquidate the associated assets. 339 | 340 | The DTF converts the received funds into native currency and sends it to 341 | the contract, for the user to claim. 342 | 343 | ### 4.7. Extension 344 | A broker can decide to extend the asset base of an existing PoA 345 | contract. 346 | 347 | To do so, the PoA contract creates a new instance of itself, which will 348 | run through the same funding and activation process previously 349 | described. It will also naturally share certain properties, such as the 350 | ISIN and Symbol, with its parent. 351 | 352 | Once the subcontract has completed `funding`, it moves into the 353 | `absorbed` stage, and the parent merges its token balances. Since the 354 | subcontract follows the exact same rules as the parent, the parent can 355 | accept the new tokens as valid and fungible with its own. 356 | 357 | 358 | 359 | *Figure 3: Proof-of-Asset token lifecycle for ETFs / REFs* 360 | 361 | ## 5. Crypto Funds 362 | The crypto fund contracts implement funds consisting of different crypto 363 | currencies or tokens, such as [Bitcoin](https://bitcoin.org), 364 | [Litecoin](https://litecoin.org/), [Dash](https://www.dash.org/), 365 | [Ethereum](https://ethereum.org/), [Golem](https://golem.network/), or 366 | even BBT or ACT themselves. 367 | 368 | There are three types of contracts, coin-traded funds (CTFs), coin 369 | managed funds (CMFs), and autonomous coin funds (ACFs). 370 | 371 | Users can purchase PoA tokens representing a certain basket of foreign 372 | or native currencies and tokens. 373 | 374 | Those funds can be passive CTFs, operating on pre-defined rules, or 375 | active CMFs, traded by a broker on secured or unsecured markets. 376 | 377 | In the future, we hope to add fully autonomous coin funds that implement 378 | all trading logic inside the contract. 379 | 380 | ### 5.1. Passive (CTF) 381 | The passive coin-traded fund contract holds a certain composition of 382 | different cryptocurrencies, based on a pre-defined set of rules. 383 | 384 | By changing the composition of the creation and redemption basket, the 385 | contract adjusts its holdings to the changing market. 386 | 387 | The custodian answers requests for quotes (RFQs) for the current basket 388 | composition. 389 | 390 | ### 5.2. Active (CMF) 391 | The coin managed fund contract will allow fund managers to trade the 392 | received funds in their own accounts on third-party markets. 393 | 394 | Users can pay in any currency and the fund manager converts it to the 395 | desired composition. 396 | 397 | #### 5.2.1. Secured Accounts 398 | Brickblock will offer secured accounts, on which the fund managers can 399 | trade, on verified and trusted exchanges. These accounts will have 400 | limited functionality and can only be used to trade. Withdrawals are 401 | only allowed back to the DTF. This will allow less-trusted fund managers 402 | to offer their services in a controlled fashion in order to establish a 403 | track record and gain credibility. 404 | 405 | #### 5.2.2. Unsecured Accounts 406 | To offer established fund managers the full flexibility they need to 407 | perform well, they may be allowed to trade on their own accounts. They 408 | are provided with full ownership of the funds and can manage them in any 409 | way they choose. Fund managers may optionally provide proof-of-assets if 410 | their setup supports them, but this is not mandatory. 411 | 412 | Users will always be aware of the type of account and fund manager 413 | securing their investments, and they can factor this information into 414 | their risk calculation. 415 | 416 | In the future, Brickblock will provide insurance for custodian accounts 417 | or trusted fund managers. 418 | 419 | #### 5.2.3. Dividends 420 | If a fund yields dividends, they are collected by the fund manager, 421 | converted to native currency, and sent to the contract. Token holders 422 | are notified and can claim their share at any time. 423 | 424 | #### 5.2.4. Redemption 425 | Investors can redeem their tokens at any time, sending them back to the 426 | contract. The fund manager will liquidate positions, convert them into 427 | native currency, and send it to the contract for the user to claim. 428 | 429 | ### 5.3. Autonomous (ACF) 430 | We also want to explore fully automatic contracts trading autonomously 431 | across multiple blockchains. 432 | 433 | Until a reliable two-way peg between most crypto-currencies is 434 | implemented, the only option to do that is by using a third-party 435 | exchange. The contract could interface with an API such as 436 | [shapeshiftbot](https://github.com/axic/shapeshiftbot) and exchange 437 | currencies on its own. 438 | 439 | By allowing users to submit trading algorithms and market models 440 | implemented as smart contracts, we aim to create a market for 441 | trading-bots. Developers can offer their results, and users can evaluate 442 | the performance and invest in the preferred contracts. 443 | 444 | ## 6. Compatibility 445 | All token contracts will be compatible with the 446 | [ERC20](https://theethereum.wiki/w/index.php/ERC20_Token_Standard) 447 | specification, which makes it trivial to trade them in compatible 448 | exchanges and wallets. 449 | 450 | We are evaluating several options for contract discovery and upgrading, 451 | and hope to find a common solution together with other projects. 452 | 453 | Bitcoin and derived blockchains will be verifiable by the smart contract 454 | through simplified payment verification (SPV), for example 455 | [BTCRelay](http://btcrelay.org/). 456 | 457 | The underlying smart contract engine has not yet been decided. We are 458 | currently prototyping on the [Ethereum](https://ethereum.org/) 459 | blockchain, and will also evaluate comparable systems such as 460 | [Rootstock](http://www.rsk.co), [Tezos](https://www.tezos.com/) and 461 | [EOS](https://www.eos.io/). 462 | 463 | ### Glossary 464 | - **Asset Base**: The amount of managed by the PoA contract. 465 | - **Custodian**: A trustworthy organization holding the portfolios of the DTF. 466 | - **Digital Trust Fund (DTF)**: A strictly regulated financial entity which legally owns the assets on behalf of its investors. 467 | - **Foreign Asset**: An asset existing outside of the Ethereum ecosystem, i.e. not Ether but REFs, ETFs or CTFs. 468 | - **Native Currency**: A currency native to the blockchain platform, like Ether (ETH) for Ethereum. 469 | - **PoA Token**: A smart token as per ERC20, representing an equal value to a certain foreign asset. 470 | 471 |
472 | 473 | #### Disclaimer 474 | 475 | Please note that this document is still an early draft; some 476 | implementation details are missing or subject to change. 477 | 478 | The purpose of this document is to convey the technical aspects of our 479 | vision, giving the reader a way to evaluate the feasibility of our 480 | design. 481 | 482 | We are in the process of developing a proof-of-concept implementation 483 | and will release a first prototype before our pre-sale in August. 484 | Technical implementation details will be added as soon as they are 485 | decided. 486 | 487 | We are open to feedback and suggestions from the community and will do 488 | our best to thoroughly evaluate all options and not rush any decisions. 489 | 490 | Copyright (c) 2017 brickblock.io Without permission, anyone may use, reproduce or distribute any material in this whitepaper for non-commercial and educational use (i.e., other than for a fee or for commercial purposes) provided that the original source and the applicable copyright notice are cited. 491 | --------------------------------------------------------------------------------