Follow CoinFabrik Blog on Feedspot

Continue with Google
Continue with Facebook


Following our Smart Contract Auditing: Human vs. Machine article, we now analyze Slither, which is another static analysis tool from Trail of Bits. It includes aids for contract summaries, which can be helpful for making a mental model of the contract and rechecking assumptions. Considering the ease of use, it’s a good idea to try them out.

Executing it on a contract is simple, since by default all checks are executed:

It can also create files in dot format specifying the call graph for a contract and can also provide a summary of contract functions and inheritance information. An interesting feature it provides is the vars-and-auth printer, which specifies what state variables are written by each function, which in big projects can be a screenful, but is useful information indeed.

Slither also includes a function summary mode that specifies state variables which are read or written, internal calls and what modifiers affect each function:

Another interesting thing is that it has a Python API that allows instrumentation of the static analysis engine. This means that the engine can be used to derive specific information from contracts automatically, and in general can be used to suit the user’s needs.

Now, after familiarizing ourselves with the tool we decided to check the same contracts from our previous article, to see how well it fared against other tools. The results were not the best, but certainly not far from the norm when compared with other tools in the same range of utility:

100Function Default Visibility
101Integer Overflow and Underflow
106Unprotected SELFDESTRUCT Instruction
108State Variable Default Visibility
109Uninitialized Storage Pointer
112Delegatecall to Untrusted Callee
113DoS with Failed CallN/A
114Transaction Order DependenceN/A
116Timestamp Dependence
119Shadowing State Variables
120Weak Sources of Randomness from Chain AttributesN/A


While Slither provides some information for doing a contract-wide overview, it still shows that contract security tools still have a long way to go before being able to replace a human auditor. What this tool excels at, however, is that it can ease the job for the auditor looking at the code by providing information visually, which inevitably makes it easier to understand. In the same vein, and following the same philosophy of Trail of Bits’ other tool Manticore, having an API for script creation can mean applying different filters to the information presented by the contract, so it can be viewed from different angles.

The post Auditing Solidity Code with Slither appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 


In this blog post, we present a high-level overview of the paper describing the Ouroboros Proof of Stake protocol implemented in Cardano´s blockchain. After the overview follow some comments about theoretical aspects of the protocol. In general, Proof of Stake (PoS) consensus protocols elect the network nodes responsible to send the next block to the blockchain on the basis of the nodes’ amount of stake. The great benefits of PoS blockchains compared to Proof of Work blockchains are

  1. Much smaller consume of energy when scaled to millions of users
  2. Decentralised due to its intrinsic way of electing the next block proposer (no mining power concentration)
  3. Better performance

The main challenge of such protocols consists in designing a secure block proposer election which is safe against any adversarial intent to bias the outcome of the sortition. The Ouroboros PoS protocol solves this challenge and provides formal security proofs which guarantee a consistent view of the ledger to all users. There are several other research projects on this topic such as Algorand and Snow White. The Dfinity project is only about consensus, but can be coupled with some PoS to protect against Sybil attacks. There are different versions of PoS protocols like Ethereum’s Casper bonded PoS which is based on penalizing misbehaviour or delegated PoS proposals, e.g. in BitShares.

Historical note: In 2011, QuantumMechanics proposes in the forum BitcoinTalk PoS instead of PoW.

Ouroboros Protocol Overview

In this section we briefly summarize the basic ideas behind the Ouroboros protocol.

2.1. Epochs. The entire history of the blockchain is built by epochs in which the distribution of stake is considered to be fixed. Each epoch is subdivided into slots and each slot has one block proposer who extends the chain by signing the block which includes the slot number. The genesis block contains the public keys of all stakeholder together with their stake which is updated at the end of each epoch.

2.2. Leader Election and Consensus. For each slot of an epoch a stakeholder U is elected for proposing a block with the probability reflecting his or her amount of stake at the current epoch. Similar to Bitcoin, honest block proposers select the longest chain to continue the blockchain, and valid blocks are those belonging to the chain of maximal length.

2.3. Incentives. Stakeholders should be online and verify transactions when they are elected for a block proposer (or even a bit before). The incentive function distributes the transaction fees of the blocks between block proposers. There are also block endorsers who are elected the same way as block proposers. They can reject or let pass the blocks and receive as well a part of the fee.

2.4. Stake Delegation. It is important that most stakeholders are online when elected. If this is not possible, stakeholders can delegate their rights to other stakeholders who form a staking pool. This is instantiated with a proxy signature scheme while the size of the staking pool is such that a malicious majority basically never occurs.

 A “close-up” of some aspects of Ouroboros

The essential contribution of Ouroboros by Kiayias et al. to the cryptocurrency research community consists in setting forth a formal security model for PoS protocols and in defining a PoS protocol along with an instantiation. We try to detail the most important contributions in a concise manner.

3.1. Security Model. The authors of Ouroboros introduce a new security model suitable for their PoS protocol. This model is a modification and extension of the Bitcoin Backbone model. The functionalities modeled are the communication to extend the chain and for key registration reflecting the possibility of the adversary to corrupt stakeholders. The authors consider first a static state in which one epoch describes the entire lifetime of the blockchain and corruption is only allowed at the very beginning. In a second step, the dynamic state is described as an increasing sequence of epochs (static states) which reflects stakeholder and stake changes shortly before of each new epoch. The set of functionalities is extended  by a perfect sub-routine of a random beacon generation necessary for the leader election. This random beacon is implemented later with standard cryptographic tools as explained below.

3.2. Proof: Static State. The security proof in the static state translates the chain extension rule into a pure combinatorial argument leading to the concept of forkable strings. The static model differs from the Bitcoin protocol as the next slot leaders of an entire epoch are known at once giving the adversary new attack strategies. Therefore, the proof of consistency and availability of the Ouroboros protocol does not follow directly from the Backbone Protocol paper. To capture this novelty, the notion of forkable strings is introduced representing honest and dishonest slot leaders in form of a string. Each entry of the string is associated to a directed tree with a labelling function reflecting all possible results of adversarial intents to fork the blockchain. The main result shows that even in the presence of an adversary the density of forkable strings decreases rapidly in time (even in exponential decay; see [RMKQ17]). The proof reformulates the problem as biased random walks and then applies probability estimates of Markov chains.

3.4. Instantiation and Proof: Dynamic State. The dynamic protocol adds to the static protocol the selection of the next slot leaders. The block proposers for each slot of epoch j are elected using a pseudo-random number generator with the follow-the-satoshi rule. It is necessary to introduce entropy in order to prevent grinding attacks. Ouroboros generates the random seed (uniformly distributed) using a secure multi-party coin-tossing protocol. Each block proposer of the previous epoch commits to a secret string in the commitment phase which they have to reveal at the end of the epoch in the opening phase and from which the random seed is derived. To protect the protocol against adversaries who will not open their secret, a verifiable secret sharing protocol is used so that honest parties can recover the secret even if an adversary withholds its secret. In order to prove high probability of consistency and liveness of the protocol, some assumptions have to be made. These are that all honest players are online for a sufficient long time, that the maximum stake shift over the last blocks is restricted, and that the adversary is not allowed to instantaneously corrupt. There is a lower bound for the corruption delay.

3.5. Nash Equilibrium. Beyond the cryptographic security, there might be rational strategies to win more than the honest strategy pays out. The authors prove (see theorem 7.1) that together with the second layer system of endorsement the honest strategy of the protocol is a near-Nash equilibrium showing in particular that the selfish-mining strategy does not apply to Ouroboros (See also this critical analysis).


Ouroboros Praos / Genesis / Crypsinous

Some improvements in subsequent work address the follwing topics

4.1 Network assumption. The synchronous network assumption says that the network delay  is bounded by a known constant, i.e. < c. This assumption is not uncommon but the strongest about networks. In the subsequent work [DGKR17], Ouroboros Praos, the assumption is weakened to the semi-synchronous network assumption where c is unknown.

4.2 Adaptive Adversary. The Ouroboros protocol has to assume a certain delay for the corruption of stakeholders by an adversary. The Ouroboros Praos PoS protocol is fully adaptive corruption resistant in the sense that the adversary can corrupt at any time. This comes by using the same concept of Algorand, i.e. verifiable random functions.

4.3 Secure Bootstrapping. See the video Ouroboros Genesis for bootstrapping PoS protocols without any trust assumptions (and a great exposition of the entire Ouroboros proof).

4.4 Privacy. Crypsinous uses SNARKs to introduce privacy to Proof of Stake protocols.



[DGKR17] B. David, P. Gazi, A. Kiayias, and A. Russell, Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake protocol, Cryptology ePrint Archive, Report 2017/573, 2017.

[DPS16] P. Daian, R. Pass, and E Shi, Snow White: Provably secure proofs of stake, Cryptology ePrint Archive, Report 2016/919, 2016.

[GKL15] J. Garay, A. Kiayias, and N. Leonardos, The bitcoin backbone protocol: Analysis and applications, Advances in Cryptology – EUROCRYPT 2015 (Elisabeth Oswald and Marc Fischlin, eds.), Springer Berlin Heidelberg, 2015, pp. 281–310.

[KRDO17] A. Kiayias, A. Russell, B. David, and R. Oliynykov, Ouroboros: A provably secure proof-of-stake blockchain protocol, CRYPTO, Springer, 2017, pp. 357–388.

[RMKQ17] Alexander Russell, Cristopher Moore, Aggelos Kiayias, and Saad Quader, Forkable strings are rare, Cryptology ePrint Archive, Report 2017/241, 2017, https://eprint.iacr.org/2017/241.

The post Some Insights into Cardano´s Blockchain appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this article we are benchmarking several auditing tools. The smart contract security audit is a critical phase in the development of smart contracts. The DAO hack was just one trip in the odyssey to secure Ethereum smart contracts and compatible blockchains like RSK and Cardano. It is important to highlight that back in 2016 A Call for a Temporary Moratorium on The DAO was published but it fell on deaf ears. Lesson learned: never deploy a smart contract without one or more security audits. It is tempting to use automated security tools to save time and money but they cannot replace human brains right now.

Linters and analysis tools are used to quickly point out errors in the syntax and in the smart contract logic. More complex tools can be used to better analyze in depth the behavior of smart contracts.

In this article we will examine how some of these tools fare against well known vulnerabilities extracted from the Smart Contract Weakness Registry.


We selected a set of tools that have different ways to analyse and report errors and are well known in the community. We have linters like Solhint and Solium that will perform an analysis at the source code level, and other more advanced like Oyente that acts at the opcode level to detect erroneous behavior.


A symbolic execution tool that provides an API for writing your own tests from within Python. It comes with a set of heuristics for detecting some common mistakes, and we checked those.


Mythril is a tool defined specifically for security and does seem to fare well against common bugs, yet still wasn’t perfect. It can also generate a control flow graph and can install a certain version of solc.


An Analysis Tool for Smart Contracts. It performs the evaluation a the opcode level so problems at the Solidity syntax will not be detected. Our tests were done with the latest release available as a docker container which includes Oyente v0.2.7.3.


SmartCheck is an online tool that automatically checks Smart Contracts for vulnerabilities and bad practices. We testested against v0.0.9 released on October 25.


This tool examines syntax and style errors, and a few security problems. We ran our tests against Solhint v1.4.0.


This is a linter designed to highlight style issues with the code. However, it also accepts some plugins that help detect security issues too. We tested against version 1.1.8. This tool has a plugin system, which provides the ability to extend it.


This is a tool provided as a plugin to the SonarQube console to analyse the code. It classifies what it finds in “code smells”, vulnerabilities and bugs. It can also import Solium reports, which can be further enhanced with Solium’s own plugins. We tested version by itself to see what we found.


We selected a representative subset from the SWC registry to run our test against. We specially chose some from the ranking in the Decentralized Application Security Project of vulnerabilities with a largest impact.

  • SWC-100: Function Default Visibility
    In solidity functions without visibility are marked as public and it will expose them, .
  • SWC-101: Integer Overflow and Underflow
    The result of arithmetic operations might exceed the maximum type value, or fall below the minimum if not properly addresses these will trigger unintended behavior.
  • SWC-106: Unprotected SELFDESTRUCT Instruction
    The SELFDESTRUCT operation causes the smart contract calling it to be deleted from the state and it cannot be called afterward. The attack to the Parity Multi-Sig wallet was caused by a contract that wasn’t properly initialized and left it unprotected.
  • SWC-107: Reentrancy
    When a contracts makes a calls to external contract it giving up control and it is possible for another function on the same contract to be called.
  • SWC-108: State Variable Default Visibility
    Explicitly defining storage variable visibility prevent the misuse of them from inheriting contracts.
  • SWC-109: Uninitialized Storage Pointer
    Uninitialized local storage variables can point to existing storage variables in the contract incorrect use will cause inadvertently overwrites.
  • SWC-112: Delegatecall to Untrusted Callee
    To call an untrusted contracts with delegatecall enables the target to modify the storage of the caller.
  • SWC-113: DoS with Failed Call
    Making calls to external contracts might fail. If several calls are executed inside a loop a single failure will cause the whole transaction to revert.
  • SWC-114: Transaction Order Dependence
    Miners are allowed to reorder transactions. A contract that depends on certain transaction order might be susceptible to attacks, for example Front Running.
  • SWC-116: Timestamp Dependence
    The timestamp in the block is controlled by the miner and it can manipulate it at his convenience. It should not be used for critical calculations.
  • SWC-119: Shadowing State Variables
    Solidity allow using the same names for variables in different contexts. Using the same name is confusing and might cause subtle bugs.
  • SWC-120: Weak Sources of Randomness from Chain Attributes
    The possible sources of randomness available to smart contracts is limited and an incorrect calculation can cause the results not to be random. The SmartBillions lottery was attacked through the incorrect assumption that all block hashes were accessible to smart contracts, only the last 256 hashes are available.

The following table resumes the execution of the differents tools against our tests.

100Function Default Visibilityn/a (1) (2.a)
101Integer Overflow and Underflow (2.b)
106Unprotected SELFDESTRUCT Instruction
108State Variable Default Visibilityn/a (1) (2.c)
109Uninitialized Storage Pointer
112Delegatecall to Untrusted Callee✘ (2.d)
113DoS with Failed Call
114Transaction Order Dependence
116Timestamp Dependence
119Shadowing State Variablesn/a (1) (2.e)
120Weak Sources of Randomness from Chain Attributes


  1. Oyente analysis is at the EVM level so it will not be able to detect issues with the Solidity language.
  2. Solium uses a plugin architecture, to detect some of the attacks a separate plugin has to be enabled.
    1. security/enforce-explicit-visibility
    2. zeppelin/no-arithmetic-operations
    3. zeppelin/constant-candidates
    4. security/no-low-level-calls
    5. zeppelin/no-state-variable-shadowing



Most of the tools analyzed find the more common errors like function or variable visibility or arithmetic overflows/underflows. Some event will identify and recommend better practices.

Most of them will fail against more complex attacks like transaction reordering, or denial of service attacks. These attacks are complex to detect for a competent auditor and often requires interaction between several contracts.

In general the outcome was far from perfect. They find the more simple errors and failed against more complex attacks. Humans win.


If you liked this article, you might also like:


The post Smart Contract Auditing: Human vs. Machine appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The crypto market is still inefficient. Cryptoassets have different rates on different exchanges. The big question is how we can profit from that inefficiency. One approach is making transactions between exchanges, but if we buy a cryptoasset on one exchange, by the time we can sell it on another, the price difference may no longer exist. For a discussion of this problem, see What I Have Learned from My Arbitrage Experiences with Cryptoassets.

A more efficient approach is using what I call virtual transactions: buying a pair on one exchange and simultaneously selling this pair in another exchange. In order to use virtual transactions to exploit arbitrage opportunities, you must have funded wallets before profitable oscillations events. In a profitable oscillation event, the price difference for a given pair between two exchanges allows you to make profit using two virtual transactions. The first virtual transaction at the time of the event and the opposite operation once the event dissapears and the price difference returns to average values in a considered period.

Put in mathematical terms:


where is the amount of assets you are exchanging, refers to the values you would pay buying these assets, refers to the values you would receive selling these assets, the sub-indices and refers to the two exchanges and the supra-indices and refers to the first and second virtual transactions. The  operator is used to average the values in a given period. This method is a statistical arbitrage method known as pair trading and works using co-integrated pairs. For a deeper look into pair trading algorithms, see Introduction to Pairs Trading. Most arbitrage only monitor for price differences and is just a particular case of this method, considering the second half of the equation equal to zero.

Statistical arbitrage has its risks, since it is necessary to hold cryptoassets, unless the chosen exchanges accept a stable currency as collateral for margin trading. Although there is a profit due to arbitrage, there may also be a devaluation of our capital due to market volatility. On the other hand, it is also necessary to hold a quote currency buffer in each exchange to cover price fluctuations.

Some useful tips! Your trading bot should:

  • Exploit profitable oscillations events as quickly as possible. Use market type orders and not limit type orders.
  • Use leverage whenever possible. Some exchanges like Bitfinex, Huobi, Okex, Kraken and Bitmex allow you to execute your long/short positions with 2x, 3x and even 100x, which allows you to get a higher ROI on the invested capital. Even better, using margin trading, on some exchanges you can keep your collateral in stable coins using a market-neutral strategy.

I apply this statistical arbitrage method using the pair XTZ/BTC between the exchanges Gateio and Hitbtc, from 28th August to 23th September 2018. Yo can download the log using this link. I deposited 0.2 BTC on each exchange, and I bought some XTZ on Hitbtc (using exactly 0.15384 BTC). I left some free bitcoins as a buffer (~30%) to cover price volatility in future trades. Each step of the log starts with Opening trades and ends with Closing trades. Opening trades are an XTZ purchase on Gateio and an XTZ sale on Hitbtc, and Closing trades an XTZ sale on Gateio and an XTZ purchase on Hitbtc. The same amount of bitcoins is invested at the beginning of each step. The amount of XTZ traded on each exchange in a step remains fixed, but can vary between steps. All orders are executed using market type. The ROI of the operations in the period considered is 4.2% of the total BTC initially invested, without considering XTZ valuation changes.

If you liked this article, you might also like:

Disclaimer: CoinFabrik does not provide financial advice. This material has been prepared for educational purposes only, and is not intended to provide, and should not be relied on for, financial advice. Consult your own financial advisors before engaging in any investment.

The post An Efficient Algorithm to Exploit Arbitrage Opportunities in Crypto Markets appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Prediction markets are a special kind of betting platforms that can be used for multiple purposes ranging from insuring a crop from bad weather to predicting the outcome of an event based on the wisdom of the crowd.  Among other popular uses of prediction markets are hedging an investment, shorting the market, creating a futures market and predicting the outcome of an election. Given the fact that blockchain based projects that belong to the fintech area have been among the most successful ones based on this new technology, I believe that prediction market applications could become very successful and help complement the existing fintech platforms ecosystem.

How do prediction markets work?

  • A participant creates a “market”, which is simply an event that will happen in the future and has more than one possible outcome. For example, Will Donald Trump be impeached before the end of his mandate?
  • Bet orders are placed by many participants. These orders consists in a yes or no answer to the question, the probability (or degree of certainty) of this happening and the amount of money to place at stake.
  • Bet orders are accepted when complementary bets are made. If a stake of u$ 1 with a 70% probability of yes is made,  It will be on hold until someone bets at least the same amount of money with a 30% probability or higher to no.
  • Before the market closes accepted orders can be sold or bought to a different price from their original value, this price is usually adjusted according to market expectations.
  • When the market closes, in this case when Trump finishes his mandate or is impeached, the holders of winner bets are paid.

After testing existing applications for more than two weeks I came to the conclusion that the actual state of the art of blockchain based market prediction applications leaves much to be desired. Without taking into account the applications I couldn’t install or synchronize with the network, I found that all of them have either serious usability difficulties or are very limited.  Besides, the actual blockchain transaction times and the lack of liquidity makes it impossible for these platforms to be used in reality for purposes such as shorting the market.

Following is description of the table’s contents. Betting currency contains the coin in which bets are made. Dispute and Market creator are the coins used to settle disputes and to set a new future event on which to stake, in the reviewed companies both coins coincide but, this is not necessarily always the case. Participation rewards can be earned by performing the different actions stated in this column. Does it have a dispute mechanism? Shows if the platform has a clearly defined procedure for settling an argument about a result. Does it have a user reputation measurement? States if the platform associates to each participant a metric representing the correctness of his previous predictions. Can anybody create a market? Shows if all platform users are allowed to create a new future circumstance on which to place bets. Does the better choose probability or result? states  weather is possible to set the degree of certainty of the chosen event or only the event itself. Can bets be sold before the market closes? Tells if there is a procedure allowing platform users to sell their current positions on an open market. Does it have multiple options bets? Says if the platform allows betting on more than two results. Application status shows the actual state of the software.  Application type tells what kind of application needs to be installed or if the product can be used through a webpage. Blockchain network states the name of the network in which the platform is based. Coin holders shows the amount of people that hold coins and therefore can use the application. Foundation date and Initial investment contain the year at which the company was created and the capital that it was founded with. Finally, Where does it work? Shows the places of the world where betting could be done.


Dispute and Market creator
Participation rewardsmarket creator gets a fee
he sets between 0 and 50%
noneresult settlers split 1%
of loosing bets
noneto be decided
by market creators
Does it have a dispute mechanism?yesnoyesnoyes
Does it have a user reputation
Can anybody create a market?yesyesyesyesno
Does the better choose probability or result?probabilityresultresultprobabilityresult
Can bets be sold before the
market closes?
Does it have multiple options bets?yesyesyesnoyes
Application statuslivelivelivelivebeta (test network)
Application typewebpagewebpagedesktop webpagewebpage
Blockchain network EthereumEthereumQtumAmoveoEthereum
Coin holders51961768733102268010088
Foundation date20142015201720182015
Initial Investment5.3 Millons43.5 Millons33.3 Millons0 U$ (open source)12.5 Millons
Where does it work?WorldwideWorldwideeverywhere but US,
China, and Singapore
If you liked this article, you might also like:

Disclaimer: CoinFabrik does not provide financial advice. This material has been prepared for educational purposes only, and is not intended to provide, and should not be relied on for, financial advice. Consult your own financial advisors before engaging in any investment.

The post Blockchain Mediated Prediction Markets appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 


Coinfabrik has been hired to audit the EasyPool smart contracts.
We start this PDF report writing a summary with the smart contracts provided by the client and a list of the analysis methods used to audit the contracts. Next, we detailed our findings ordering the issues by severity, followed by all the observations we considered important to add. Furthermore, we ended up this audit report with a conclusion explaining how do the auditors value the code reviewed, and what are the most important things that need to be corrected to it to make it work flawlessly and securely.


The contracts audited are from the EasyPool repository at https://github.com/gitigs/easypool. The audit is based on the commit c2e8b3c566da84071776ba02dc6f35f8e0dc0a4e, and updated to reflect changes done on commit 81c55b9fe2c437ec864ece8bc60cf9d5c6e4d3fa

The audited contracts are:

  • ProPool.sol: Pool management
  • common/Affiliate.sol: Affiliate management for use in FeeService.sol
  • common/CMService.sol: Service for managing the contracts
  • common/FeeService.sol: Fee management service
  • common/PoolFactory.sol: Pool deployment function
  • common/PoolRegistry.sol: Pool registering
  • common/Restricted.sol: Operator management functions
  • library/ProPoolLib.sol: Pool manipulation functions
  • library/QuotaLib.sol: Share claiming functions

The ProPool contract provides a public interface for managing the pool, the implementation of the functions being done on the ProPoolLib contract. This latter contract uses another library, defined in QuotaLib, to define an internal data structure within the contract’s representation of an investment pool. There’s also a dependency on a pair of functions from the FeeService contract.

As for CMService, it depends on the interface for PoolRegistry and PoolFactory, which inherit from the Restricted contract, adding operator management functions. PoolFactory also depends on ProPool, since it deploys new instances of the ProPool contract. CMService allows setting fee services, changing the pool factory contract, and such functions. PoolRegistry brings a function to register new pools, emitting an event.

Fortunately, on analysis of these contracts only a few minor issues, mostly with maintainability, were found. We proceed to detail the checks we’ve made, the improvements to the contracts which could help development, and a conclusion.

As for the audit, the following analyses were performed:

  • Misuse of the different call methods: call.value(), send() and transfer().
  • Integer rounding errors, overflow, underflow and related usage of SafeMath functions.
  • Old compiler version pragmas.
  • Race conditions such as reentrancy attacks or front-running.
  • Misuse of block timestamps, assuming anything other than them being strictly increasing.
  • Contract soft locking attacks (DoS).
  • Potential gas cost of functions being over the gas limit.
  • Missing function qualifiers and their misuse.
  • Fallback functions with a higher gas cost than the one that a transfer or send call allow.
  • Fraudulent or erroneous code.
  • Code and contract interaction complexity.
  • Wrong or missing error handling.
  • Overuse of transfers in a single transaction instead of using withdrawal patterns.
  • Insufficient analysis of the function input requirements.
Detailed findings

Critical severity

None found.

Medium severity

None found.

Minor severity Warnings on compilation

The contracts emit warnings when compiled. It would add to the auditability of the contracts themselves if they were removed. While they may not cause any problem directly, they can occlude other more important warnings. We recommend fixing these before deployment, mostly as a way of ensuring that everything’s going well.

These warnings mostly concern uninitialized storage pointers, which are by default zeroed. However, these aren’t considered as severe as they are later initialized correctly.

Inconsistent usage of SafeMath

There’s not enough usage of SafeMath in some lines in QuotaLib.sol, yet it is declared as being used in the following statement:

library QuotaLib {    

using SafeMath for uint;


We recommend either removing the statement or following through in the usage consistently since this could lead to errors and possible future changes could cause bugs. We also recommend the use of SafeMath in the other contracts, which it can be seen that it was considered yet decided against in some commented out parts of the code, which declare


// We could use SafeMath to catch errors in the logic,

// but if there are no such errors we can skip it.

// using SafeMath for uint;



This is something which was found in ProPoolLib.sol, in Affiliate.sol and in FeeService.sol. While it is true that SafeMath has no purpose if the code is correct, it can act as a safeguard if that isn’t the case. It’d be advisable for the team to reconsider this design decision since it’d mean arithmetical operations are guarded against overflow.

Enhancements Not enough documentation

In the QuotaLib.sol contract there’s not enough documentation. It’d be advisable for the development team to fix this, as it helps auditability and legibility of the contracts. There are many comments of the form:


* @dev ...



Changing these to have meaningful commentary can avoid errors when handling the contract, so it’s suggested to follow through.

Old compiler pragmas

The contracts have the following pragma directive:

pragma solidity ^0.4.24;


We remind the development team that the Solidity compiler has been updated. While this isn’t critical in these particular contracts, there are bugfixes which if absent could’ve caused problems. As usual, it is recommended to stay on top of the new versions, which could avoid problems with things like the ABI encoding, parser issues, et cetera.


We annotate some of the verifications done to the contracts to indicate that they were performed even when no critical issue was found during the audit.

  • Misuse of the different call methods: call.value(), send() and transfer().
    We found no incorrect use of call() or send(), and transfer(). Calls to these methods were done on checked input, with correct coverage of requirements.
  • Integer rounding errors, overflow, underflow and related usage of SafeMath functions.
  • Race conditions such as reentrancy attacks or front-running.
    • The only call to an external contract is in the addressCall function, but considering it’s private and is only called from payToPresale, which calls to this function with the presaleAddress that’s set. Since this is only callable by the pool administrator and the state change of the pool is done before the call, the pool will have a consistent internal state, so reentrancy can’t cause damage.
    • There are many setters for addresses that could if not enough checks are done on input, cause transfers to unwanted addresses. However, these functions have the correct modifiers so only the administrator of the pool can change these.
  • Misuse of block timestamps, assuming things other than them being strictly increasing.
    • Timestamps aren’t used in the contract at all, so attacking the contract from that angle is impossible.
  • Contract softlocking attacks (DoS) / unbounded gas usage.
    No function in the contract has a loop that can be abused to cause a soft lock or an unbounded usage of gas.

We found the contracts to be simple and straightforward. No critical issues were found, yet some possible legibility issues were considered. Overall the contracts had decent documentation, except for some points, but in general they were simple enough to follow that it wasn’t critical. There is some code which we recommend reviewing, but in general the state is good, the only trouble being somewhat inconsistent snippets which reduce legibility, which could lead to bugs if additions are made.

Disclaimer: This audit report is not a security warranty, investment advice, or an approval of the EasyPool project since Coinfabrik has not reviewed its platform. Moreover, it does not provide a smart contract code faultlessness guarantee.

The post EasyPool Smart Contract Security Audit – appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In this article we review the main ideas presented in the last cryptoassets valuation Satis Group’s article published by Bloomberg. Satis Group is an ICO advisory firm which has helped model one of the first bitcoin valuation in 2014. According to their report, the cryptoassets ecosystem forecast is promising. Bitcoin and Monero cryptocurrencies are both expected to grow, as are exchange utility tokens and tokens for loans and lending. The article uses three valuation frameworks: the top-down method, the bottom-up method, and some others relative methods. See our article A Review On Cryptoasset Valuation Frameworks for a review of these frameworks.

Top Down Method
This method uses the quantity theory of money to assess the value of cryptoassets (see our analysis of Stellar lumens tokens with this approach). It analyzes the value captured through crypto market adoption, share of that adoption by individual sectors, and velocity of the underlying use case. It mainly applies with utility tokens and currencies, assuming that their value is directly correlated with the size of the use case and economy they support. Based on this framework, the following figure estimates the cryptoasset market capitalization over time:
Figure 1: Estimated Cryptoasset Market Capitalization Over Time

In the following table, Satis Group estimates the market adoption of cryptoassets in different areas:

Figure 2: Estimated Penetration of Cryptoassets, as Means of Exchange for Each Addressable Market

The following figure shows a dramatic increase in the offshore deposits within the cryptoassets market in the next 1 – 2 years as custody solutions come online. In five years, offshore deposits could represent the 90% of the total crypto market capitalization.

Figure 3: Cryptoasset Market Penetration of TAM by USE Case (as % of Total Cryptoasset Market Capitalization)
Among store of value assets, the privacy sector is expected to grow the most, lead by Monero and ZCash.
Satis Group analysis of platform networks suggests that Ethereum will lose share, but it will continue to be used because there is an established community and a lot of dependency generated around the platform. Satis Group do not forsee any competitor growing as much as Ethereum has grown, during its ecosystem and value expansion over the past two years.
In the following table, Satis Group estimates the value of the top ten cryptoassets in the next few years:
Figure 4: Estimated Value of Top 10 Cryptoassets
Satis Group believes the largest opportunity for cryptoassets will be in store of value markets which explains the substantial upside they forecast for Monero and Bitcoin.
In addition, Satis details several factors that favor the growth of BTC in particular: “1) increasing liquidity and purchasing avenues, 2) increasing brand recognition, 3) its position as the default base – pair within the crypto markets , 4) declining relative volatility, 5) relative lack of attack vectors, 6) network capacity alleviation through the maturity of layer – 2 solutions, and 7) an increasingly high attack and overthrow cost.”
Other currency networks which are expected to grow include “networks that have cultivated relatively organic growth and community (such as LTC)” and “cryptoassets with subtle (…) differences in governance and technical reputation (such as DCR).”
On the other hand, Satis sees “meaningful  downside from networks that have inherited brand recognition and potentially short – lived adoption during hiccups from their fork – parent (such as BCH), and very little value in networks that are misleadingly marketed and not even required for use within their own network (such as XRP)”.

Utility tokens will gain in market usability, but not in token price.  Although utility cryptoassets will further penetrate larger markets (such as IT spending, gambling, and gaming), the high velocity of these applications combined with a lack of value- retaining construct will result in lower value. Low velocity utilities like loan tokens (SALT, LEND) could increase in value due to its low velocity. (See our previous article: Cryptocurrency Backed Lending Platforms for a comparison of these services).

Relative Valuation Methods
Different metrics can be applied to similar cryptoassets to compare performance. These methods includes comparative valuations, relative to cryptoassets with similar qualities in various sectors. For example, the exchange multiple, calculated as the total token market capitalization over the exchange daily volume is useful to compare exchange tokens:
Figure 5: Exchange Multiples
This exchange multiple is then used to predict token price:
Figure 6: Exchange Multiples, Implied Values
Bottom-Up Methods
Bottom-up methods are traditional methods which calculate the net present value of the future stream of returns. They can be used for cryptoassets which generate yield, wether it be trough the substantial return of coins to validators through master nodes and staking, or through discounts for trading with exchange tokens. We calculate the value of a token based on different projections of annualized growth of economic activity and discount rates (WACC) using a discounted cash flow  analysis. In the table below, Satis analyzes the Binance BNB token. BNB net present value is calculated for different scenarios. All forecasted prices are above the price at the time of writing.
Figure 7: Sensitivity of the BNB price to annualized growth of Binance trading volume and discounted rates.
Disclaimer: CoinFabrik does not provide financial advice. This material has been prepared for educational purposes only, and is not intended to provide, and should not be relied on for, financial advice. Consult your own financial advisors before engaging in any investment.

The post A Summary of Satis Group’s Latest Cryptoasset Valuation Report appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The second stage of the Dogethereum bridge is being presented on September 5, 2018 and live streamed. The bridge uses “superblocks” to move coins from Dogecoin to Ethereum and collateralization to move coins from Ethereum to Dogecoin. We are excited because this innovation can also be used to bridge other blockchain pairs.

Last year Oscar Guindzberg and CoinFabrik partnered to create a decentralized trustless bridge between Dogecoin and Ethereum in response to the challenging Dogecoin and Ethereum bounty. The prototype, which TrueBit also collaborated on, was released in February 2018 and was awarded a third of the bounty.

Ismael Bejarano and Catalina Juarros from CoinFabrik worked with Oscar Guindzberg on a daily basis, and CoinFabrik co-founder Pablo Yabo oversaw the project.

Future improvements could include an improved user interface, the ability to use a decentralized oracle, a mechanism to penalize operators for improper behavior, and the use of state channels to implement the challenge design pattern.

The project is open source with an MIT license which is a permissive free software license enabling anyone to reuse or innovate over our code. The full project is available here and a presentation of the process and the way we resolved some of the most challenging aspects is available here.

This project uses a mechanism called superblocks to save Ethereum gas when the bridge is moving Dogecoins to Ethereum. Without superblocks, it would cost ~22 ethers per day to run the bridge, about USD 6,000 at today’s rate. We have published a white paper explaining how superblocks work here.

The project also includes a user manual so you can try the bridge yourself.

Oscar is an independent software developer with experience in multiple blockchain technologies. He was a core developer at RSK and worked on bridging the Bitcoin blockchain and RSK sidechain. CoinFabrik is a company which specializes in decentralized solutions using a wide range of blockchain technologies. It offers a wide range of services including research, consulting, development, security audits, ICO launches, and training. CoinFabrik also offers customizable cryptoasset exchanges, wallets, and ICO and custody platforms.

The post Dogethereum: A Decentralized Blockchain Bridge Between Dogecoin and Ethereum is Born appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 


Coinfabrik was asked to audit the contracts setting the DS Protocol, which has the goal to
enable security token offerings as well as managing the token lifecycle post-sale. Firstly, we
will provide a summary of our discoveries and secondly, we will show the details of our


The contracts audited are from the Securitize private repository. The audit is based on the
commit 6817cb339defe4d67e63a3835dffcf95ba458119 , and updated to reflect changes at
c3729ea216eb33f093e6e5b209378e4d6728bbd7 .

Audited Contracts

The audited contracts are the following:

  • These contracts refer to the eternal storage:
    ● storage/EternalStorageClient.sol: Function wrappers for Eternal Storage access.
    Automatically generated.
    ● storage/DSEternalStorage.sol: The eternal storage itself, which adds delete functions
    to Zeppelin’s eternal storage.
    The rest of the contracts all use the Eternal Storage for storing data:
    ● token/DSToken.sol: The token contract code, it’s accessed by a proxy entry point
    with delegation. It’s also an ESPausableToken.
    ● token/ESPausableToken.sol: ESStandardToken with pausing.
    ● token/ESStandardToken.sol: ESBasicToken with all ERC20 functions.
    ● token/ESBasicToken.sol: The transfer only portion of an ERC20 token.
    ● compliance/ESComplianceService.sol: Validation functions for token actions.
    Declares overridable boolean functions for compliance customization.
    ● compliance/ESComplianceServiceNotRegulated.sol: ESComplianceService without
    regulation, all overrides do not restrict anything.
    ● compliance/ESComplianceServiceWhitelisted.sol: ESComplianceService with simple
    whitelisting regulation.
    ● compliance/ESComplianceServiceRegulated.sol: ESComplianceService with
    stronger regulations, like region based restrictions, investor counting or token locking.
    ● compliance/ESLockManager.sol: Token locking contract logic for compliance.
    ● compliance/ESWalletManager.sol: Allows categorization of wallet addresses for
    ● compliance/ESIssuanceInformationManager.sol: Allows storage and retrieval of
    simple compliance information in form of strings.
    ● trust/ESTrustService.sol: Common address role implementation for function
    ● ESServiceConsumer.sol: Allows access to different deployed contracts of the project,
    returning the properly typed interfaces. This is also where common function privilege
    modifiers reside.
    ● registry/ESRegistryService.sol: Allows adding and retrieving investor information.
    ● util/ESPausable.sol: Simple pause modifiers.
    These are proxy related contracts only being used by the token at the moment:
    ● util/Proxy.sol: Allows delegation of all calls to a different contract address, serving as
    a permanent entry point while maintaining storage.
    ● util/ProxyTarget.sol: Needed for proxy callable contracts, declares the two addresses
    stored in Proxy so they don’t overlap at the delegated contract.
    These are all interfaces, mostly used as return types for ESServiceConsumer:
    ● token/DSTokenInterface.sol
    ● compliance/DSComplianceServiceInterface.sol
    ● compliance/DSLockManagerInterface.sol
    ● compliance/DSWalletManagerInterface.sol
    ● compliance/DSIssuanceInformationManagerInterface.sol
    ● trust/DSTrustServiceInterface.sol
    ● DSServiceConsumerInterface.sol
    ● registry/DSRegistryServiceInterface.sol
    Unused contracts:
    ● trust/DSTrustService.sol: Same as ESTrustService without Eternal Storage.
    ● DSServiceConsumer.sol: Same as ESServiceConsumer without Eternal Storage.
    Truffle contracts:
    ● util/Migrations.sol: Truffle migration contract.
Analyses performed

The following analyses have been performed:
● Misuse of the different call methods: call.value(), send() and transfer().
● Integer rounding errors, overflow, underflow and related usage of SafeMath
● Old compiler version pragmas.
● Race conditions such as reentrancy attacks or front running.
● Misuse of block timestamps, assuming anything other than them being strictly
● Contract softlocking attacks (DoS).
● Potential gas cost of functions being over the gas limit.
● Missing function qualifiers and their misuse.
● Fallback functions with a higher gas cost than the one that a transfer or send call
● Fraudulent or erroneous code.
● Code and contract interaction complexity.
● Wrong or missing error handling.
● Overuse of transfers in a single transaction instead of using withdrawal patterns.
● Insufficient analysis of the function input requirements.

Findings Critical severity

None has been found.

Medium severity

Insufficient deletion at ESRegistryService
The function removeInvestor at ESRegistryService.sol includes this for loop to delete

for ( uint index = 0 ; index < 8 ; ++ index ) 
{ deleteUint ( "investors" , _id , index , "value" ); 
deleteUint ( "investors" , _id , index , "expiry" ); 
deleteString ( "investors" , _id , index , "proof_hash" ); }

But the index counter only goes up to 8, while the parameter _attributeId in the function
setAttribute may be any value between 0 and 255:

function setAttribute ( string _id , uint8 _attributeId , uint256 _value , 
uint256 _expiry , string _proofHash ) public onlyExchangeOrAbove returns ( bool ) 
{ setUint8 ( "investors" , _id , _attributeId , "value" , _value ); 
setUint8 ( "investors" , _id , _attributeId , "expiry" , _expiry );
setString8 ( "investors" , _id , _attributeId , "proof_hash" , _proofHash ); 
setAddress ( "investors" , _id , "last_updated_by" , msg . sender ); 
emit DSRegistryServiceInvestorChanged ( _id , msg . sender ); return true; }

This will result in erroneous saved data after an investor deletion. We recommend either restricting this parameter to only contain values up to 8, or increasing the counter while checking the gas costs for removeInvestor do not get dangerously near the gas limit per block. This was fixed in multiple commits with the last change being in commit 6bdcb8fc454f2f68441eda7bf2b6842269e665c0.

The unassigned boolean return value of function defaults to false The function recordTransfer at ESComplianceServiceRegulated.sol does not have a return statement:

function recordTransfer ( address _from , address _to , uint _value ) internal returns ( bool )
{ if ( _value > 0 &&
getToken (). balanceOfInvestor ( getRegistryService (). getInvestor ( _from )) == _value ) {
adjustInvestorCount ( _from , false );
if ( _value > 0 &&
getToken (). balanceOfInvestor ( getRegistryService (). getInvestor ( _to )) == 0 ) {
adjustInvestorCount ( _to , true );

This means the function will return the default value of false , which means this require at the
end of the function will inevitably fail when called:

function validate ( address _from , address _to , uint _value ) onlyToken public {
uint code;
string memory reason;
( code , reason ) = preTransferCheck ( _from , _to , _value );
require ( code == 0 , reason );
require ( recordTransfer ( _from , _to , _value ));

We recommend returning a proper value, true specifically if the check never fails.
This was fixed in commit 9dfd0e8ee78ae61445aee9d57d844fc59d8454b2.

Minor severity

Possible hash collision in EternalStorageClient
The contract EternalStorageClient is automatically generated, and uses abi.encodePacked
to pack multiple parameters in a single bytes typed value. This value is then hashed in the
EternalStorage contract to get a valid storage address. One example of many:

function setBoolean ( string p1 , bool v ) internal {
setBooleanGeneric ( abi . encodePacked ( namespace , p1 ), v );
function setBoolean ( string p1 , string p2 , bool v ) internal {
setBooleanGeneric ( abi . encodePacked ( namespace , p1 , p2 ), v );

These functions are supposed to always point to different boolean values, but they don’t if
the string at the first function is the same as the concatenation of the strings at the second
function. That means, for example, these calls:

setBoolean (" Audit ", true );
setBoolean (" Au ", " dit ", true );

Are essentially the same, since abi.encodePacked concatenates the strings and does not
save length information. Note that this may also happen between different types, for
example of this function:

function setBoolean ( string p1 , address p2 , bool v ) internal {
setBooleanGeneric ( abi . encodePacked ( namespace , p1 , p2 ), v );

May also collide with the other two functions if the address p2 concatenated with p1 has the
same representation as the string p1 of the first function or the strings p1 and p2 of the
second one.
Since the file is automatically generated, we recommend adding some unique identifier at
each call of abi.encodePacked , ensuring these collisions will not happen between different
This issue was acknowledged by the team, it was not changed due to gas costs but they
ensured it will be fixed in the future.
Wrap common Eternal Storage accesses in functions
While the Eternal Storage has many upsides, it has the big downside of removing a lot of
compiler information and adding verbosity to the contracts. Since variables are accessed by
strings, these strings can contain typos and get or set erroneous values without the compiler
noticing. The types themselves may also differ, with a variable that was set an int may be
mistakenly accessed as a uint.
While we checked and haven’t found any of these problems, it may become an issue if the
contracts develop further in the future. This in conjunction with the verbosity will definitely
make more difficult the development of these contracts. Proper testing can definitely help
here, but it may not be perfect and some issues may go unnoticed until deployment.
We recommend at the very least declaring all the strings as constants to remove the
possibility of typos. We also recommend wrapping common function calls to reduce the
verbosity and the possibility of other errors. For example, this chain of function calls:

setUint ( "totalSupply" , getUint ( "totalSupply" ). add ( _value ));

Maybe replaced with something like this:

increaseTotalSupply ( _value);

With the definition of being just the calls you had before:

function increaseTotalSupply ( uint256 _value ) internal {
setUint ( "totalSupply" , getUint ( "totalSupply" ). add ( _value ));

Which can further be improved by declaring the strings as constant:

string constant TOTAL_SUPPLY = "totalSupply";
function increaseTotalSupply ( uint256 _value ) internal {
setUint ( TOTAL_SUPPLY , getUint ( TOTAL_SUPPLY ). add ( _value ));

This was enhanced in multiple commits, with the last change being at commit


The contracts were well written and had a good amount of documentation. We found some
issues but nothing critical. It’s always good to see code reuse, in this case, reusing
OpenZeppelin’s contracts, which are already well tested and commonly used

The post DS Token Security Audit Review appeared first on CoinFabrik Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Thanks to the invention of cryptocurrencies a new kind of financial product has been made possible, the crypto-backed loans. Following is a brief comparison of 10 platforms that providing access to it. As we can see by looking at the table the options vary greatly respect to the interest rates, platforms fees, and currencies accepted. Besides, you should bear in mind the that companies tend have different methods for evaluating borrowers and that according to each particular risk assessment they can offer different financial options. It is interesting to notice also that although many of them claim to be peer to peer loans there are many cases in which the platform is the one that ends up doing the actual money lending. In order to have a broader view of these financial products it use useful to know that in the United States mortgage APR (annual interests rates) are round 4-5% and the average credit card APR is 15.07%.

An interesting feature that most of these lending companies have in common is an automatic mechanism to deal with coins volatility. You need to send a certain amount of crypto to a company’s wallet for backing up your loan, nevertheless the market price of crypto can become significantly lower in just a short period of time. This is why smart contracts play an important part in these new platforms. They allow the triggering of an alarm if the price is below a certain level and if nothing is done  after a certain period of time the loan is cancel, the crypto collateral is liquidated and later on sent to the corresponding lender’s wallet.

Following is brief description of the table’s contents. Loan term, minimum and maximum show the ranges of time you can ask a loan for along with its maximum and minimum amounts. Lending, collateral and interests currency enumerate the currencies in which the loan is made, collateral must be deposited and interests must be paid. Interests contains a percentage range at which money is lent, bear in mind that these percentages can vary with time. Time for getting the money states how long it takes since you requested the money until you can actually dispose of it. Repayment type shows when and at which frequencies you need to return the money lent and pay the interests. Fees displays the fees that are left to the platform, and who they are taken from. Loan is done trough enumerates which methods the platform utilizes for transferring the money. Places where it lends has the places of the world where the lending could be done. Finally, foundation date and initial investment contain the year at which the company was created and the capital that it was founded with.

Loan Term1 - 36 months1 - 24 months1 - 12 months1 day - 1 year1 year (renewable)1 day - 60 months (5 years)1 - 12 months6 weeks, 6 months, 12 months,
36 months or 60 months
1 day - unlimited7 days - 5 years
Loan Minimum5000100011002000500.5 BTC$1,000 or 0.01 BTCnone0.01 BTC
Loan Maximum25000000100000050000000none10000000none10 BTC250000.5 BTC for unapproved profiles500 BTC
Lending CurrencyUSDEuro, USD & TetherEther & USDT (tether)USDUSDUSD, EUR, GBP, CNY, JPY,
USD, EUR, GBPBTC, USD, KSH (Kenya)BTCBTC (but is fiat tied)
Collateral CurrencyEther & BTCEther, BTC, BNB & Nexomore than 130 ERC20 coinsEther & BTCEther & BTCBTC, ETH, Litecoin,Ripple,
Monero, Zcash & Dash
BTCBTCBTC & GET tokensINST1, BTCpop, BTCM, ETH and Clam
(around 200 alt coins)
Interests CurrencyUSDUSD, Euro, BTC, ETH & NexoEtherCELUSD, BTC & EtherSame as borrowed fiat currencySame as borrowed fiat currencyBTC & USDTBTCBTC
(APR = annual %
MPR = monthly %)
APR 12 - 22%with nexo as collateral APR 8%
otherwise APR 16%
MPR 0.1% - 50%APR 5% - 9%APR 12% - 14%APR 0% - 1000%APR 27%
APR 20% with NBTK
0.01 - 3.00% daily, depending on the lender
APR 7% - 25%
Average APR 20% depending on
the borrower's rating
0 - 1% daily depending on the lenderAPR 10% - 45%, depending on
the borrower & lender agreement
Time for getting the money1-7 days1-7 days1-30 days (depends on lenders)1-2 days1-2 days3 days1 day average1 - 5 days1- 30 daystime for loan to get funded by BTCpop members
Repayment Type Monthly interests
Monthly interests + loan %
Monthly Interests
Early Cancelation accepted
Monthly interests + loan %Monthly Interests + loan %Monthly InterestsMonthly Interests + loan %
Monthly Interests
Monthly Interests
Each x% loan paid lowers x% future interests
Monthly Interests + loan %
Monthly Interests
Full repayment at the endDifferent Fixed repayments scheemes
Fees$25 or 1 SALT for membership
1 - 100 SALT according to the loan value
NoneBorrower .25% if collateral LEND, else .5%
Lender 5% of interests if collateral LEND,
else 10%
None1% - 4% of the loan1 CLT ($10) for borrowed loan
10% of interest gained by lending
10% interest gained by lendingBorrower pays 1% - 3%,
depending on loan length,
lender pays 1% at the end
30% of lender's profit
0.01 BTC to acces the platform
Borrower pays 1 - 5% of the loan,
depending on amount
Lender pays 5%
Loan is done trough (digital
wallets are always used)
Bank transferBank Transfer
Nexo credit card
Only Digital walletsBank Transfer
Debit Card
Bank Transfer or Wire
ACH (automatic clearing house)
Debit Card
Swift or Sepa Bank Transfer
Wire Transfer
Debit Card
Bank transferOnly Digital walletsOnly Digital wallets
Places where it lendsNew Zealand, UK and 35 US states WorldwideWorldwide except USEurope & US35 US statesWorldwide except AsiaWorldwideWorldwideWorldwide except Cuba, India, Iran,
Nigeria, North Korea and Poland
More than 60 Countries
Foundation date2016201820172017201720172015201320172014 (refunded in 2016)
Initial investment$48.5 Millon $52.5 Million$16.5 Millon$50 Millon$56.4 Million$3.2 Millon$1.91 Millon$ 7.6 Millon$1.2 MillonUndisclosed amount
If you liked this article, you might also like:

The post Cryptocurrency Backed Lending Platforms appeared first on CoinFabrik Blog.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview