Roostoo (iOS / Android) is a simulated crypto exchange mobile app that offers users a virtual portfolio to partake in real-time mock trading

Roostoo

Today, renewal of the Boost Note has been officially launched! https://boostnote.io/ https://github.com/BoostIO/BoostNote.next Since we launched the first version of the markdown editor called in about 3 years ago, there have been both ups and downs. Boost Note The greatest of these ups is that we gained more than 600k of beloved Boost Note users; and as an open source project, we’re creating Boost Note together with every single of you from all over the world. I can’t thank those who have contributed to Boost Note enough, we are really grateful for this. At the end of this post, I will introduce almost 100 people who contributed recently. The major down happened right after we released the first version of Boost Note, when all the members left and I was the only one remaining on the team. Although it was really a hard time for me, many contributors helped Boost Note and me. Boost Note could never come this far without your support. I will never ever forget what you all did. This experience has strongly bonded us to our corporate mission. Our mission is ‘to empower creators by realizing the standards of tomorrow’. Lately, you have been hearing that technology replaces more and more jobs. I think the programmer will be the protagonist in this new era, so we believe you are the most important creators. I would like to empower even more all the talented developers out there, like our helpful Boost Note contributors, and make this world a better place together. From now on of Boost Note(iOS/Android) will be released by the end of January! The original plan was to release before 2019 ends, my apologies for not being able to meet this deadline. Mobile App In addition, we’ll also launch the team version of Boost Note. If you are interested to try it out, please sign up here and we will invite you! https://boostnote.io/wiki The goodie campaign We started a campaign in which you can get your hands on some Boost Note goodies. You will receive these rewards for free if you write an article about Boost Note and share it on your SNS! We’ll send you two stickers(old and new logos) and a webcam cover * This offer is limited to the first 100 applicants! We’re waiting for you to apply! application form To our proud contributors We received tons of contributions on the . We really want to thank all of you in face to face, but sorry it ended up being written here. Thank you with all my heart! old Boostnote sota1235 daiyam ZeroX-DG roottool yosmoc AWolf81 bimlas nathan-castlehow PaulRosset ytk141 Antogin nadr0 enyaxu dredav pfftdammitchris vienai8d AgentEpsilon Simon-the-Sorcerer hooklife abnersajr richardtks anasasilva MSSandroid mrseanbaines arcturus140 LeoLamCY nagledb max-buranbaev mirsch lazytyper bkjohnson xxdavid mikeres0 lurong-hkg ivanovserge andyklimczak KuangLei Djdany95 twhiting redcom kg86 hooskers empeje XGHeaven SCdF Gansgar robbawebba ibraude Olcod asmsuechan sosukesuzuki ehhc yougotwill mslourens rayou nlopin amedora MiloTodt voidsatisfaction hikerpig kohei-takata duartefrazao dojineko PrimaMateria Redsandro miguelalexbt kawmra clone1612 GuilhermeJSilva elfman sferra romainwn kostaldavid8 Paalon yamash723 mikaoelitiana zhouxiaoxiaoxujian minbaby jarvisuser90 Rxbsxn shmolf maykefreitas jacobherrington hsiehjack SalvatoreTosti KazumiHARADA zzdjk6 saaguero lvarado kazuhisya gediminaspetrikas dtom90 StormBurpee MrBMT Danmou jhdcruz alwxkxk Thank you so much!!

A Letter from the Boost Note Team

Build First, Hodl Never This article contains a project update from the MythX team as well as some of my own views. Its contents don’t necessarily reflect the opinion of ConsenSys-the-corporation. If you followed crypto news over the past couple of weeks you might have noticed that . I think it’s fair to say that many members of the ConsenSys mesh — including those of us that were lucky enough to hodl on to our jobs — have recently had reason to do some introspection. things have been turbulent at ConsenSys Believe it or not but most people at ConsenSys truly believe into the potential of decentralized infrastructure. P2P transfer of value over the Internet. A distributed consensus machine that allows for arbitrary Turing-complete computations. The promises are endless! But clearly we haven’t delivered on them yet, at least not in a way that would have justified the exorbitant crypto valuations of 2017 and early 2018. No coin offerings, please move along. The epic bubble of 2017-2018 was caused by the ICO craze and general FOMO but the tech just wasn’t ready for mainstream adoption. There are some obvious lessons to be drawn here: Instead of raising millions of USD on half-baked whitepapers we should work towards scaling the Ethereum infrastructure and building useful things that foster real-world adoption. Tokens allow us to build great crypto-economic incentive systems (e.g. ) but the majority of projects do not require a custom token. In many cases all the token does is raise the barrier of entry for users which ultimately is bad for everyone. token-curated registries We shouldn’t lose track of the ideals that brought us into the space, even in the light of strong incentives to make a quick buck. That said, we also need to be pragmatic along the way. The revolution won’t happen overnight. We must play a long game instead of seeking short-term gain. We believe that ConsenSys’ contributions to infrastructure and tooling are essential to the success of Ethereum. It’s not an accident that Ethereum has the biggest developer community — this was made possible by the likes of , , and . Yes, some of this stuff is centralized, but not mindlessly so. For example, while Infura makes Ethereum more accessible other folks at ConsenSys are working on light clients that will mean less dependence on Infura in the future. Truffle Ganache Infura Metamask right now, Over the past two years I’ve put my heart and soul into building Mythril (the security analyzer, not the social network thing. It’s going to be called now anyway since ). Mythril/MythX brings security into the smart contract development lifecycle. We think that better security (and thus increased trust by end users) is as essential for adoption as higher TPS and better usability. MythX the Tolkien Estate has threatened with a prolonged Orc siege Besides the , which has just cracked 300k total downloads, the MythX team has been working on a . The idea was to build an “INFURA for smart contract security” that allows anyone to build integrations with development and testing environments. According to our white-paper, end users would purchase “tokenized licenses” denominated in MYTH tokens and we would share part of the proceeds back to the tool developers. Mythril open-source tool SaaS platform with a novel token-based SaaS subscription model So far nothing special but now comes the twist: Instead of doing an ICO, our token would be released via a bonding curve market contract We’d call it “utility token 2.0”. It would be a revolutionary new way of kickstarting our ecosystem and incentivizing the community to produce quality tools and grow our user-base. Our war cry was . at the end of the roadmap. “build first, hodl later” Over the last few months however, the team has been reflecting on the plan and re-assessed the potential drawbacks of bringing another utility token into this world. For instance, even though we ran extensive simulations, the price discovery mechanism wasn’t guaranteed to work in the real world — legitimate users could be priced out by speculators, and the volatility inherent in our token (as well as ETH) could turn out to be disadvantageous for our community and users. More fundamentally, we also found that including a token in the mix simply made the user experience worse. The requirement to buy a custom token to “fuel” the API is confusing for users and frankly simply paying in ETH was a lot more convenient. Therefore, we decide to call off the MYTH token and instead accept ETH, DAI and potentially other stable coins for payment. By using USD-pegged pricing, we will lower the barrier of entry and create a system that’s more enticing to new developers and users. At the same time we’ll still be able to leverage the key advantages that public blockchain infrastructure offers: Anyone with an Internet connection can participate in our security tools market even without a bank account. No value is extracted from our economy by credit card processors and banks. Revenue sharing can be implemented in a transparent (and eventually fully decentralized) fashion. Our new motto is “Build first, hodl never”. TL;DR We believe that one of the most promising use-cases for Ethereum is enabling transparent and intermediary-free transfer of value. We also believe that introducing a utility token causes too many risks and disadvantages for end users. Therefore, we’re calling off the MYTH token, pricing our license plans in USD and adding support for stablecoin payments. Will our system be fully trustless and decentralized? No. Will it be as easy to use as paying by credit card? Probably not, but we’ll get there eventually. We hope to become a model for a new wave of Ethereum projects that will bring the Internet of Value to the mainstream. Questions? Give us a shout on . Discord About Mythril and MythX is a free and open-source smart contract security analyzer. It uses symbolic execution to detect a variety of security vulnerabilities. Mythril is a cloud-based smart contract security service that seamlessly integrates into smart contract development environments and build pipelines. It bundles multiple bleeding-edge security analysis processes into an easy-to-use API that allows anyone to create purpose-built smart contract security tools. MythX is compatible with Ethereum, Tron, Vechain, Quorum, Roostock and other EVM-based platforms. MythX

Why We’re Calling Off Our Token and Using Stablecoins Instead

In this article I explain how to use Mythril to find and exploit security bugs in Ethereum smart contracts. The articles will cover basic principles and advanced techniques, such as testing security properties, proving invariants, analyzing multi-contract systems and auto-looting ETH from vulnerable contracts on the Ethereum network. — also known as the “Swiss army knife of smart contract security” — has lots of bells and whistles, but to use it effectively you need a basic understanding of the analysis techniques used. This article provides an overview of the most important concepts. Mythril The first key step we usually recommend to new users is . You should do this also in case you to want follow the examples in this article (if run into trouble installing, you can ask for help in our ). installing Mythril Discord support channel After successful installation the command line tool will be available on your system. Make sure you have version 0.19.7 or higher: myth $ myth -V Mythril version v0.19.7 The basic command for executing security analysis is : -x / --fire-lasers $ myth -x <Solidity file>   $ myth --rpc RPC_OPTION -xa <contract address> This command runs a generic analysis that works reasonably well in most situations. Before we get ahead of ourselves though, let’s have a look at what is going on behind the scenes. Multi-Transactional Symbolic Execution Mythril checks for security issues by running a custom implementation of the Ethereum Virtual Machine. The analysis process involves the following steps: Obtain the contract bytecode by compiling a Solidity file or loading it from an Ethereum node; Initialize the contract account state either by running the creation bytecode (if source code was provided) or by retrieving data from an Ethereum node on-demand; the code to explore all possible program states over transactions, whereby defaults to two but can be set to an arbitrary number; Symbolically execute n n Whenever an undesirable states is encountered (such as “the contract kills itself”), logically prove or disprove the reachability of those states given certain assumptions (e.g. “given the right inputs can kill the contract“). anybody When find a vulnerable state, we can compute the input transactions required to reach that state. This is useful not only to to determine the root cause of an issue, but also for should one be so inclined. crafting exploits Basic Usage With that out of the way, let’s try Mythril on a smart contract exploitation challenge from . is a simple smart contract that allows users to buy and sell tokens for the once-in-a-lifetime bargain price of 1 ETH. Here is the source code: CaptureTheEther TokenSale Working with code is easier than working with on-chain contract instances because that way Mythril can show you the the code responsible for each bug it finds. Copy/paste the code into a file called and run the following command: tokensale.sol $ myth -mether_thief -x tokensale.sol Note the use of the argument which accepts a comma-separated list of to execute. Let’s have a closer look at a particularly useful module called . -m analysis modules Ether Thief Looting that precious ETH As its name subtly foreshadows, the module checks for transaction sequences that extract ETH from the contract. Specifically, it looks for states that fulfill the following conditions: Ether Thief A non-zero amount of ETH can be withdrawn from the contract; The sender withdrawing the ETH is the contract creator; not The amount of ETH withdrawn can be greater than the total amount previously paid into the contract by the same sender. This is a pretty low-false-positive way of of spotting contracts that “leak” ETH to anonymous attackers. Let’s now unleash this module on the TokenSale contract: $ myth -mether_thief -x tokensale.sol ==== Ether thief ====SWC ID: 105Type: WarningContract: TokenSaleChallengeFunction name: sell(uint256)PC address: 693 Users other than the contract creator can withdraw ETH from the contract account without previously having sent any ETH to it. This is likely to be vulnerability. -------------------- In file: tokensale.sol:25msg.sender.transfer(numTokens * PRICE_PER_TOKEN) -------------------- Myhril claims that to have found an issue in the withdrawal function but the root cause is not immediately apparent. If you haven’t spotted the bug yet, take another good look at the code and try to figure out the attack. Concretizing Transactions (a.k.a. Auto-Exploit-Generator) As you have probably deduced there’s an integer overflow issue at play here. To exploit the issue you need to pass a very specific value to the function. Don’t fire up your calculator just yet though, there’s some good news: Mythril can compute the correct input transactions for you automagically. All you need to do is add the flag: buy() --verbose-report $ myth -mether_thief -x tokensale.sol --verbose-report ==== Ether thief ====SWC ID: 105Type: WarningContract: TokenSaleChallengeFunction name: sell(uint256)PC address: 693 Users other than the contract creator can withdraw ETH from the contract account without previously having sent any ETH to it. This is likely to be vulnerability. -------------------- In file: tokensale.sol:25msg.sender.transfer(numTokens * PRICE_PER_TOKEN) --------------------DEBUGGING INFORMATION: Transaction Sequence: Transaction Sequence: {'2': {'calldata': '0xd96a094a20', 'call_value': '0x0', 'caller': '0xaaaaaaaabbbbbbbbbcccccccddddddddeeeeeeee'},'5': {'calldata': '0xe4849b32084031', 'call_value': '0x0', 'caller': '0xaaaaaaaabbbbbbbbbcccccccddddddddeeeeeeee'}} The section contains the two transactions computed by . A look at the fields shows that no ETH is transferred the contract by the sender. Let’s have a closer look at the calldata: DEBUGGING INFORMATION Ether Thief call_value to The first transaction contains the first four bytes of the function signature hash of as well as an innocent-looking extra byte — — which represents the leftmost byte of (the remaining zeroes don’t have to be sent explicitly as the EVM will interpret uninitialized calldata as ). The value passed to works out to: buy(uint256 num_tokens) 0x20 uint256 num_tokens 0x00 num_tokens buy(0x2000000000000000000000000000000000000000000000000000000000000000) Let’s look at the effect this input has on the statement on line 16: require require(msg.value == numTokens * PRICE_PER_TOKEN); is set to 1 Ether which corresponds to 1e18 wei. As it turns out, multiplying this amount with the value Mythril has computed for results in an integer overflow. More specifically, the result of the binary multiplication is zero — note that there are other input values that could be used here. PRICE_PER_TOKEN numTokens uint256(1e18) * uint256(numTokens) The statement therefore passes and a large amount of tokens is credited on the sender’s account even though they’re not sending any ETH. require In transaction two, the illegitimate tokens are then sold in return for ETH (call to ). Because Mythril represents the contract balance symbolically it outputs a large random value for . In reality, the attacker would use a lower value corresponding to the actual number of ETH in the account. sell(uint256) numTokens If you haven’t done so already, now is the time to fire up and . Metamask give the challenge a shot Configuring transaction count An important concept to know when using Mythril is . This variable specifies the number of transactions to be executed symbolically. The default value of two is sufficient for detecting many common bugs such as the integer overflows, uninitialized storage variables and misnamed constructors. However, a search that goes two transactions deep will discover bugs that need three or more transactions to reach. transaction count not Unfortunately, because each transaction can have multiple valid final states, the space of states to explore grows exponentially with the number of transactions. Symbolically executing three transactions therefore takes significantly longer than executing two (we’re currently working on a way of optimizing the number of transactions executed within a predefined timeframe — I’ll update this article as soon as this becomes available). To demonstrate this let’s have a look at another example. See if you can spot the security issue (beware of spoilers in the contract name): This contract has a “backdoor” that allows anyone knowing the secret password to become the owner (but as we know, private state variables aren’t really secret — the only difference is that the solc doesn’t generate an accessor function for them). Another popular Mythril module is . This module checks for transactions that, if sent by anyone other than the contract creator, will “accidentally” kill the contract. Running the S_uicide_ module on the code above returns the following output: Suicide $ myth -msuicide -x killme.sol The analysis was completed successfully. No issues were detected. Mythril appears to overlook the vulnerability. The reason for this is that a minimum of three transactions is needed to kill the contract: The sender must provide the correct password to call to become the owner, and finally call to trigger the suicide. activatePassword(bytes11 password), pwnContract() kill() Let’s see what happens if we increase the number of transactions executed using the argument: -t / --transaction-count $ myth -t3 -msuicide --verbose-report -x killme.sol ==== Unchecked SUICIDE ====SWC ID: 106Type: WarningContract: KillmeFunction name: kill()PC address: 422Estimated Gas Usage: 630 - 1055 A reachable SUICIDE instruction was detected. The remaining Ether is sent to the caller's address. -------------------- In file: killme.sol:21 selfdestruct(msg.sender); -------------------- DEBUGGING INFORMATION: Transaction Sequence: {'2': {'calldata': '0xa6e0e35e63727970746f6b69747479', 'call_value': '0x0', 'caller': '0x0000000000000000000000000000000000000001'},'3': {'calldata': '0x2eb00c1b', 'call_value': '0x0', 'caller': '0x0000000000000000000000000000000000000001'},'4': {'calldata': '0x41c0e1b5', 'call_value': '0x0', 'caller': '0x0000000000000000000000000000000000000001'}} This time the issue was detected and we get a sequence of three transactions. Inspecting the calldata more closely reveals the names and arguments of the functions being called: TL;DR Mythril’s and modules detect security bugs that allow attackers to steal from, and even kill, poor innocent smart contracts. When the flag is added, Mythril will output the input transaction(s) needed to trigger each bug detected. Increasing helps Mythril detect more bugs but also increases execution time exponentially. Ether Thief Suicide --verbose-report transaction count About Mythril and MythX is a free and open-source smart contract security analyzer. It uses symbolic execution to detect a variety of security vulnerabilities. Mythril is a cloud-based smart contract security service that seamlessly integrates into smart contract development environments and build pipelines. It bundles multiple bleeding-edge security analysis processes into an easy-to-use API that allows anyone to create purpose-built smart contract security tools. MythX is compatible with Ethereum, Tron, Vechain, Quorum, Roostock and other EVM-based platforms. MythX

Practical Smart Contract Security Analysis and Exploitation— Part 1

Bernhard Mueller, the creator of MythX , shows how to detect vulnerabilities in Ethereum smart contracts. Below, we’ll be running on some intentionally vulnerable contracts from the (thanks to the guys from for giving me permission!). If you haven’t tried the wargame yourself, be aware that there are spoilers ahead! I recommend giving it a shot yourself first if you haven’t already. Mythril Ethernaut wargame Zeppelin solutions Token The objective in of Ethernaut is to hack a basic token contract called . Check out the to see if you can spot the bug. level three Token code When analyzing the smart contracts with Mythril you can choose from three input options: Solidity code file: This only works if the is installed. solc command line compiler Solidity bytecode: If you don’t have solc, you can compile the code with and pass the runtime binary code to Mythril via the argument. Remix -c Contract address: To scan a contract instance on the blockchain, use the option. -a ADDRESS I’ll be using option 1 below — for detailed instructions on the other input options check out the . README Copy/paste the code into a text file and save it as , then run the command. Mythril outputs detected issues on the console: ethernaut-token.sol myth -x $ myth -x Desktop/ethernaut-token.sol ==== Integer Underflow ====SWC ID: 101Type: WarningContract: TokenFunction name: transfer(address,uint256)PC address: 469Estimated Gas Usage: 758 - 1043The subtraction can result in an integer underflow. --------------------In file: Desktop/ethernaut-token.sol:13 balances[msg.sender] - _value -------------------- ==== Integer Underflow ====SWC ID: 101Type: WarningContract: TokenFunction name: transfer(address,uint256)PC address: 551Estimated Gas Usage: 1291 - 1766The subtraction can result in an integer underflow. --------------------In file: Desktop/ethernaut-token.sol:14 balances[msg.sender] -= _value -------------------- ==== Integer Overflow ====SWC ID: 101Type: WarningContract: TokenFunction name: transfer(address,uint256)PC address: 627Estimated Gas Usage: 6814 - 27479This binary add operation can result in integer overflow.--------------------In file: Desktop/ethernaut-token.sol:15 balances[_to] += _value -------------------- In this case, it has detected one integer overflow and two integer underflow issues in the function . Let’s have a look at the code to see what’s going on: transfer function transfer(address _to, uint _value) public returns (bool) {require(balances[msg.sender] — _value >= 0);balances[msg.sender] -= _value;balances[_to] += _value;return true;} We can see that will indeed wrap if is larger than . In that case the sender will end up with an astronomical amount of tokens! balances[msg.sender] — _value _value balances[msg.sender] Fallout This is of the Ethernaut challenge. Have a look at the code first — the problem isn’t that hard to spot! level two Here’s what Mythril has to say about it: $ myth -x ethernaut-fallout.sol==== Ether thief ====SWC ID: 105Type: WarningContract: FalloutFunction name: collectAllocations()PC address: 1018Estimated Gas Usage: 1112 - 1723 Arbitrary senders other than the contract creator can withdraw ETH from the contract account without previously having sent an equivalent amount of ETH to it. This is likely to be a vulnerability. --------------------In file: ethernaut-fallout.sol:25 msg.sender.transfer(this.balance) -------------------- ==== Integer Overflow ====SWC ID: 101Type: WarningContract: FalloutFunction name: allocate()PC address: 1366Estimated Gas Usage: 713 - 998This binary add operation can result in integer overflow. --------------------In file: ethernaut-fallout.sol:16 allocations[msg.sender] += msg.value -------------------- Mythril claims that it is possible withdraw ETH from the contract using the function . But isn’t that function protected by the modifier? collectAllocations() onlyOwner If you’re unclear about an issue Mythril reports, you can add the flag to get additional debugging information. --verbose-report $ myth -x ethernaut-fallout.sol --verbose-report==== Ether thief ====(...)--------------------DEBUGGING INFORMATION: Transaction Sequence:{'2': {'calldata': '0x6fab5ddf', 'call_value': '0x0', 'caller': '0xaaaaaaaabbbbbbbbbcccccccddddddddeeeeeeee'},'6': {'calldata': '0x8aa96f38', 'call_value': '0x0', 'caller': '0xaaaaaaaabbbbbbbbbcccccccddddddddeeeeeeee'}} Note that transactions are shown in the “Debugging Information” section. These are the transaction Mythril thinks will trigger the vulnerability. two With that in in mind, take another careful look at the source code. You might notice that the constructor name is slightly different from the contract name, and thus compiles into a regular public function that anyone can call to set a new owner! This is similar to the . Rubixi vulnerability The ‘calldata’ field of the first transaction shown by Mythril contains the leftmost 4 bytes of the Keccak hash of , the function signature of the wrongly named constructor. You can verify this with the hash utility: Fal1out() $ myth --hash "Fal1out()"0x6fab5ddf The second transaction represents a call to : collectAllocations() $ myth --hash "collectAllocations()"0x8aa96f38 Delegation of Ethernaut is a multi-contract scenario. Fortunately, Mythril can process multiple contracts and understands various types of message calls between contracts. When you analyze a contract on the blockchain Mythril can automatically detect and download dependencies during runtime. Level 4 To try this out, I deployed the and contracts on a local instance. Linking is accomplished by passing the address of the instance to the constructor of . Delegate Delegation Ganache Delegation Delegate On-chain analyses are launched using the argument. The command shown below also includes three additional flags: -a ADDRESS activates the Ganache RPC preset; --rpc ganache activates the dynamic loader. This tells Mythril to also retrieve and scan any additional referenced contracts; -l activates informational debugging output. This will give us some insight into what the loader is doing. -v1 $ myth --rpc ganache -xla 0x64e1b27e8dbd44769dc8f43cb78447760b1bc1f0 -v1 INFO:root:SVM initialized with dynamic loader: <mythril.support.loader.DynLoader object at 0x102329ef0>INFO:root:Dynld at contract 0x64e1b27e8dbd44769dc8f43cb78447760b1bc1f0: Concat(0, Extract(167, 8, storage_1)) INFO:root:Dependency address: 0x28241019d1b3b2b3763a9d4c7f37fca8ab02e449 INFO:root:Unsupported symbolic calldata offset**INFO:root:- Entering function 0x28241019d1b3b2b3763a9d4c7f37fca8ab02e449:owner()**(...) INFO:root:Dynamic contract address at storage index 1 INFO:root:DELEGATECALL to: 0x28241019d1b3b2b3763a9d4c7f37fca8ab02e449 INFO:root:Execution complete, saved 374 statesINFO:root:38 nodes, 37 edgesINFO:root:Resolving pathsINFO:root:Analyzing storage operations... ==== Unchecked CALL return value ====Type: InformationalContract: 0x64e1b27e8dbd44769dc8f43cb78447760b1bc1f0Function name: mainPC address: 171 The function main contains a call to an address obtained from storage. The return value of this call is not checked. Note that the function will continue to execute with a return value of '0' if the called contract throws. -------------------- ==== CALLDATA forwarded with delegatecall() ====Type: InformationalContract: 0x64e1b27e8dbd44769dc8f43cb78447760b1bc1f0Function name: mainPC address: 171 This contract forwards its calldata via DELEGATECALL in its fallback function. This means that any function in the called contract can be executed. Note that the callee contract will have access to the storage of the calling contract. DELEGATECALL target: Concat(0, Extract(167, 8, storage_1)) -------------------- Two issues have been identified here: Unchecked return value in the (fallback) function. This seems weird, as we can clearly see that the in the fallback function is wrapped into an -statement. However, if you check the disassembly, you’ll find that the compiler optimizes this out. CALL main delegatecall() if forwarded with : Mythril also warns about forwarding through and notes that arbitrary functions in the called contract can be executed. CALLDATA delegatecall() msg.data DELEGATECALL Mythril seems to have missed the the fact that the state variable can be overwritten by calling the function. Why is that? If you consider the overall logic of both contracts, you’ll note that even though changing the state variable named might appear critical, it doesn’t have any further implications (i.e., it doesn’t allow you to do anything you couldn’t have done anyway), so Mythril doesn’t consider it a vulnerability. _owner pwn() _owner About Mythril and MythX is a free and open-source smart contract security analyzer. It uses symbolic execution to detect a variety of security vulnerabilities. Mythril is a cloud-based smart contract security service that seamlessly integrates into smart contract development environments and build pipelines. It bundles multiple bleeding-edge security analysis processes into an easy-to-use API that allows anyone to create purpose-built smart contract security tools. MythX is compatible with Ethereum, Tron, Vechain, Quorum, Roostock and other EVM-based platforms. MythX

Analyzing Ethereum Smart Contracts for Vulnerabilities

Bernhard Mueller, the creator of MythX , shows how to detect vulnerabilities in Ethereum smart contracts. On November 6th, a user playing with the Parity multisig wallet library contract , effectively freezing the funds on all Parity multisig wallets linked to the library’s code. According to early estimates this might have made more than $100 million worth of Ether inaccessible (update: in the meantime, that number has ). “accidentally” triggered its kill() function gone up to $280 million As it happens, just a couple of weeks ago I wrote about . The newest Parity accident was caused by an instance of this vulnerability. In this blog article, I’ll examine what happened in the latest attack and introduce a new analysis module that can be used detect similar issues in Solidity code and on-chain contracts. using symbolic analysis to detect unprotected SUICIDE instructions Mythril Ethereum rendition by Shed Designs for EventChain.io First, let’s have a brief look at what happened. User (for the sake of simplicity, I’ll just call him “the attacker”) managed to cause havoc by sending only two transactions. The called the function to set the state variable to devops199’s address. devops199 first transaction initWallet owner Function: initWallet(address[] _owners, uint256 _required, uint256 _daylimit)MethodID: 0xe46dcfeb[0]:0000000000000000000000000000000000000000000000000000000000000060[1]:0000000000000000000000000000000000000000000000000000000000000000[2]:0000000000000000000000000000000000000000000000000000000000000000[3]:0000000000000000000000000000000000000000000000000000000000000001[4]:000000000000000000000000ae7168deb525862f4fee37d987a971b385b96952 You might be wondering why this worked so easily. Weren’t there checks in place to prevent random senders from calling ? As you can see in the , access to this function is restricted with the modifier: initWallet source code only_uninitialized / throw unless the contract is not yet initialized.modifier only_uninitialized { if (m_numOwners > 0) throw; _; }// constructor — just pass on the owner array to the multiowned and// the limit to daylimit function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized This modifier allows the wallet to be initialized once. Normally, when a new wallet is set up, this library function is called immediately during creation. However, itself was never to be supposed to be used as a . It’s only purpose was to provide code to other contracts calling it via . Therefore, and very unfortunately, the library contract instance itself had never been initialized. This was an oversight by the developers, and can be partly attributed to Ethereum’s confusing library/CALL semantics. This topic would warrant its own blog post at some point, but for now let’s focus on the particular attack. WalletLibrary wallet DELEGATECALL Being the contract owner, the attacker now called the function in the : kill second transaction Function: kill(address _to)MethodID: 0xcbf0b0c0[0]:000000000000000000000000ae7168deb525862f4fee37d987a971b385b96952 This terminated the library contract, causing all wallets that depend on the library code to be unusable. Detecting the Bug “unchecked suicide” module attempts to detect exposed kill functions like the one in . The module is executed automatically when running mythril with the option. Mythril’s WalletLibrary -x To try it out, you can run the analysis against the . Unfortunately, Mythril’s on-chain scanning feature can’t be used on the dead contract instance, and the code only compiles with solc 4.10. The best way to get it to work is to first compile the code in , then pass the runtime bytecode to Mythril with the option. You should get the following output: Parity wallet WalletLibrary remix -c ./myth -x -c "60606040(…)0029"=== Unchecked SUICIDE === Type: Warning The function kill(address) executes the SUICIDE instruction. The remaining Ether is sent to an address provided as a function argument. There is a check on storage index keccac_1461501637330902918203684832716283019655932542975_&_caller. This storage index can be written to by calling the function 'initMultiowned(address[],uint256)'. There is a check on storage index 0. This storage index can be written to by calling the function 'initMultiowned(address[],uint256)'. There is a check on storage index 1. This storage index can be written to by calling the function 'initMultiowned(address[],uint256)'. The algorithm works as follows: of all intructions that are not constrained by msg.sender (i.e. callable by anyone); Make an inventory SSTORE Look for instructions and check the constraints on each. SUICIDE If a ‘tainted’ for every relevant storage index found, attempt to solve the constraints on the basic block containing the block to make sure it is reachable. SSTORE SUICIDE It’s a pretty simple check, but sufficient to detect trivial flaws like the Parity one (although it isn’t false-positive-proof). About Mythril and MythX is a free and open-source smart contract security analyzer. It uses symbolic execution to detect a variety of security vulnerabilities. Mythril is a cloud-based smart contract security service that seamlessly integrates into smart contract development environments and build pipelines. It bundles multiple bleeding-edge security analysis processes into an easy-to-use API that allows anyone to create purpose-built smart contract security tools. MythX is compatible with Ethereum, Tron, Vechain, Quorum, Roostock and other EVM-based platforms. MythX

What Caused the Accidental Killing of the Parity Multisig Wallet & How to Detect Similar Bugs

Note: This is an article from ancient times. For an up-to-date introduction to Mythril, read this article instead. Unless you’ve been living under a rock for the past three years, you have surely taken notice of an industry buzzword that has been giving “machine learning” a run for its money: . Blockchain Ethereum is one of the most successful implementations of the concept. In contrast to Bitcoin, which offers limited scripting capabilities, Ethereum provides a Turing-complete virtual machine. State transitions in the network (such as a changes in account balance of a particular token) are regulated by code running in the virtual machine, a.k.a. “smart contracts”. An ancient security saying goes: “With great flexibility comes great potential for vulnerabilities”. It doesn’t help that the semantics of Ethereum’s most popular high-level programming language Solidity are often counter-intuitive, creating many possibilities for developers to mess up. A great example for this is the , which allowed an unknown attacker to . Parity multisig wallet bug withdraw 153,037 Ether (worth more that USD 30 million) after their tinder date turned out to be a real creep The Parity debacle shows that implementation errors can remain undetected for months, even when the contract is deployed on the mainnet and its source code is openly available. One can only speculate what kind of vulnerabilities might be hidden in the thousands contracts deployed on the chain, many of which are black-boxes (in the sense that the source code isn’t published on ). Etherscan Not surprisingly, such a rich source of potential vulnerabilities with a monetary payout doesn’t escape the attention of security folks of the “white-hat” and “black-hat” varieties. It’s all over again — only this time there is real profit (*note that not only does the EVM have a stack, it also doesn’t have registers, so almost every instruction uses the stack). smashing the stack* for fun and profit When I started looking into Ethereum a few weeks ago, I found quite a few useful tools for analyzing contracts on the mainnet. and allow researchers to conveniently browse, disassemble and debug contracts in the web browser. The can (to a certain extent) restore source code from a given bytecode. and make it easy to compile and debug Solidity code. Etherscan remix Porosity decompiler Truffle testrpc However, I also found that there were many things I couldn’t do efficiently: Most notably, searching the blockchain for interesting contracts and scripting static/dynamic analysis in Python (I haven’t quite jumped on the doing-everything-in-JavaScript train yet). Therefore, I started writing up a collection of Python modules and a command line tool. And crucially, I polished the thing to a point where others might be able to use it. The outcome is , an Ethereum disassembler / blockchain exploration & analysis tool. A brief tutorial follows. Mythril Setup Originally, I was hoping to run and directly access the state in its LevelDB. Unfortunately, PyEthApp seems to have suffered a lack of maintenance and development for quite some time and doesn’t sync with the Ethereum mainnet. Mythril therefore needs RPC access to a fully connected node. and start your node as follows: PyEthApp go-ethereum Install go-ethereum $ geth --rpc --rpcapi eth,debug --syncmode fast console 2>/dev/null Note that Mythril uses , so some while it should work with other Ethereum clients, some functions won’t be available. non-standard go-ethereum debug APIs Mythril itself can be installed via Pypi: $ pip install mythril This will install both the Python modules and the command line tool. myth Database Initialization Mythril enables search operations like those described in the in minutes instead of days. To achieve this, it creates a snapshot of the contracts deployed on the mainnet. Run the following command to initialize the database: legendary “Mitch Brenner” blog post $ myth --init-db The whole process takes some time (to be honest it’s not very efficient, I hope to provide a better implementation at some point). If you don’t want to sync the whole chain right away, you can hit at any point, and syncing will auto-resume the next time you run mythril with the flag. ctrl+c --init-db Command line Usage Once you have some contracts in your database, you can run search commands to look for function signatures and opcode sequences. The expression syntax is as follows: func#[function signature]# code#[opcodes]# For example, the command below will output all contracts that have a function named : changeMultisig(address) $ myth --search “func#changeMultisig(address)#”Matched contract with code hash 2bfa6e34330ac57501bd0f6c84d50fcdAddress: 0x3665f2bf19ee5e207645f3e635bf0f4961d661c0, balance: 4999600000000000000Matched contract with code hash 98623854d849f0d97c55b98e0238eb7bAddress: 0x2d36cb89a977209703c1d6304f23198c22b7a498, balance: 63686800960937000000 The search feature supports simple boolean expressions. The following command above prints all contracts that contain both a function named and the opcode sequence : changeMultisig(address) PUSH1 0x50, POP $ myth --search “func#changeMultisig(address)# and code#PUSH1 0x50,POP#” Disassembler The disassembler is invoked with the flag. It accepts either a bytecode string via the argument or a contract address via (this will download the contract code from your Ethereum node). -d -c -a ADDRESS Mythril tries to resolve function names using a built-in signatures file originally obtained from the . If you end up using Mythril, you are very welcome to . Ethereum Signature Database commit updates to that file $ myth -d -a 0x2d36cb89a977209703c1d6304f23198c22b7a4980 PUSH1 0x602 PUSH1 0x404 MSTORE(…)212 — FUNCTION changeMultisig(address) -213 CALLVALUE214 ISZERO Call graph One of Mythril’s “killer features” is the call graph generator. Adding the argument will cause Mythril to save a graph in HTML format: -g OUTPUT_FILE myth -g ~/Desktop/graph.html -a 0x2d36cb89a977209703c1d6304f23198c22b7a498 Open the resulting file in the web browser to view the graph. Usually, you can get a pretty good overview of available execution paths (fortunately, smart contracts aren’t all that complex). Using the call graph together with execution tracing to gradually reverse engineer a contract has been working well for me, although it would be nice to have a GUI-based SVG editor to annotate (if you know one, please let me know in the comments). Finding cross-references It is often useful to identify other contracts referenced by a particular contract. Let’s assume you want to search for contracts that use the instruction in their fallback function, as was the case in the Parity Bug. You can do this using dynamic analysis: Simply run every contract in the PyEthereum VM without any inputs, and check if the instruction is executed. The Mythril repo contains an showing how to do this. It should output something like the following: DELEGATECALL DELEGATECALL example script $ python examples/find-fallback-dcl.pyDELEGATECALL in fallback function: Contract 0x07459966443977122e639cbf7804c446DELEGATECALL in fallback function: Contract 0x17c9e5b7f2bfd8307d628f2d9fcc9352DELEGATECALL in fallback function: Contract 0x17f9db8b6ffa854335b319d01f09ba39 (…) As the name implies, the instruction delegates execution to a different contract, so naturally you’ll be interested which contract is called. You can print the addresses of referenced contracts with the option: DELEGATECALL --xrefs $ myth --xrefs 0x07459966443977122e639cbf7804c4460x5b9e8728e316bbeb692d22daaab74f6cbf2c4691 Instead of using the command line tool, you can also follow the cross-references programmatically and run further analysis on the referenced contracts ( contains an example for this as well). find-fallback-dcl.py Advanced Usage While the command line tool is neat, only with custom code may you unlock the full power of Mythril. In addition to the contract database, disassembler and EVM tracing modules, Mythril also includes modified version of , allowing you to deploy and trace code on a node. By combining all this you can piece together some decent static and dynamic analysis. ethjsonrpc testrpc Search To open the contract database from a Python program use the function. This will return a object (by default, the database lives in , but you can override this in the constructor). Call the method to start a search: get_persistent_storage ContractStorage [your-home]/.mythril search(expression, callback) from mythril.ether.contractstorage import get_persistent_storage contract_storage = get_persistent_storage() contract_storage.search("FUNC#getOwner()#", myCallback) The callback function passed in the second argument will be called for every search result. It receives the following arguments: The hash key identifying the contract in Mythril’s database An object containing the current contract ETHContract A list of addresses at which the contract lives in the blockchain A list balances of the each of the deployed contracts def myCallBack(contract_hash, contract, addresses, balances): Do something… A useful pattern is searching for some particular type of contract, and then performing a set of analysis task on each result. Let’s have a look at a . second example doing just that Tracing Execution Let’s assume you want to scan the contract database for conditions akin to the Parity bug, but in a generic way. One idea is to look for function that, when passed either no argument, an address, or a list of addresses, ends up writing your address to storage with the instruction. Of course this doesn’t necessarily mean that you’re overwriting an important state variable such as or , but it’s definitely the kind of behavior you want to investigate further. any SSTORE owner owners In the , we saw how code can be traced in the PyEthereum VM. For a more advanced analysis that also incorporates state (such as available accounts, contract storage, calling the constructor, etc.) it is better to deploy the contract on . In my test environment, I have geth running on port 8545 and a testrpc instance on port 8546, which allows me to move contracts from the real network to testrpc instantly. To run the , start testrpc as follows: prior example testrpc example code $ testrpc --port 8546 --gasLimit 0xFFFFFFF --account \0x0b6f3fd29ca0e570faf9d0bb8945858b9c337cd2a2ff89d65013eec412a4a811,500000000000000000000 --account \0x2194ac1cd3b9ca6cccc1a90aa2c6f944994b80bb50c82b973adce7f288734d5c,500000000000000000000 We want to look at contracts in the database, so we can either use a search term that matches every contract, or simply iterate over the contracts: all for k in contract_keys: contract = contract_storage.contracts[k] This will return objects that store both the code of the contract ( ) and the code of the transaction that created the contract ( ). ETHContract contact.code contract.creation_code To re-create the contract in your own private chain or on testrpc, replay the contract creation transaction using Mythril’s : JSON RPC client from mythril.rpc.client import EthJsonRpc testrpc = EthJsonRpc(“localhost”, 8546) # Deploy on testrpc creator_addr = "0xadc2f8617191ff60a36c3c136170cc69c03e64cd" ret = testrpc.eth_sendTransaction(from_address=creator_addr, gas=5000000, value=0, data=contract.creation_code)receipt = testrpc.eth_getTransactionReceipt(ret)contract_addr = receipt[‘contractAddress’] This should return a transaction receipt containing the contract address. Note that testrpc “mines” a new block whenever it receives a transaction, so your contract is deployed instantaneously. The class lets you access the list of instructions, formatted easm code, cross-references and functions of a contract. It takes a single constructor argument, the contract bytecode: Disassembly disas = Disassembly(contract.code) The Disassembly object has two lists, and , that contain mappings between function names and addresses. You can iterate over to get the signature of each function (note that unidentified functions are labeled as “UNK_[address]”). func_to_addr addr_to_func func_to_addr for function_selector in disas.func_to_addr: do something with the function signature. E.g.: "changeOwner(address)" "deposit()" "UNK_0x5b980628" In the , every available function is called multiple times with various arguments (e.g. no argument, an address, a list of addresses). I won’t explain all of that in detail here — please have a look at the code to see how to encode the call data and send the transaction. example script Finally, to trace execution of a function call, use the RPC method: traceTransaction tx = testrpc.eth_sendTransaction(to_address=contract_addr, from_address=addr_schnupper, gas=5000000, value=0, data=data) trace = testrpc.traceTransaction(tx) This will return a dictionary containing every instruction executed, along with the stack at each point of execution. We are only interested in instructions that have our target address on the second-to-top position on the stack (i.e. the “attacker’s” address is written to storage). We can search the instruction list as follows: SSTORE for t in trace[‘structLogs’]:if t['op'] == 'SSTORE':if addr_schnupper[2:] in t['stack'][-2]:return True Possible next steps could include running further static and dynamic analysis to determine the effects of the overwritten address, or dumping a callgraph for manual analysis. The usage scenarios detailed here are only the tip of the iceberg: You can build almost arbitrarily complex blockchain scanners on top of Mythril’s APIs. However, note that many of Mythril’s components such contract storage, search expressions, and others still have a lot of room for improvement. You are welcome to contribute better implementations and additional analysis scripts on the . GitHub repository About Mythril and MythX is a free and open-source smart contract security analyzer. It uses symbolic execution to detect a variety of security vulnerabilities. Mythril is a cloud-based smart contract security service that seamlessly integrates into smart contract development environments and build pipelines. It bundles multiple bleeding-edge security analysis processes into an easy-to-use API that allows anyone to create purpose-built smart contract security tools. MythX is compatible with Ethereum, Tron, Vechain, Quorum, Roostock and other EVM-based platforms. MythX

Introducing Mythril: A framework for bug hunting on the Ethereum blockchain

Comprehensive Guide to the Boulder / Denver Startup and Tech Scene

promises something very special: to by building the . Mattermark organize the world’s information Bloomberg for startups And I’m totally sold on that promise. Imagine if a piece of software could really identify a startup’s growth potential or real-world momentum(!) and provide you with everything you need to know to make an investment, hiring or sales decision in one place. Brad Feld, Boulder’s preeminent venture capitalist, invested and is very , which more than $10M. bullish on the company raised And CEO Danielle Morrill totally floored me with this quote at a recent conference in Las Vegas: http://tech.co/celebrate-danielle-morrill-mattermark-2015-10 So freakin’ cool. So I’m all in on Mattermark. And before I dive a bit deeper into my experiences with the tool let me state that I really understand that the problem is extremely difficult to tackle and that I know that the company has a very long-term vision. It’s all good. No haters here. Having said that I do believe that if Mattermark’s selling something there has to be an (minimum sellable product) and I just don’t see it. MSP I was always curious where they go their information and how good it was. I do due diligence for early-stage investors and we’re doing this: startup so I wanted Mattermark to have great information because that would be of benefit to everybody out there and would most certainly make my life a lot easier. So a couple of days ago I got a trial subscription to Mattermark and started checking on some of the companies I know to see if I could source some decent data. Most of the companies I took a look at are early but those are the ones that are hard to gather good intelligence on. It’s easy to get a good read on a company like but early stage is where it gets interesting. There were and with the proliferation of non-accredited investors and everyday investors coming into the marketplace as a result of Title III of the JOBS Act, early stage investors need all the information they can get. Buffer 73,400 entrepreneurial ventures funded last year Again — and I can’t stress this enough — I understand that Mattermark is early and the team is passionate and the problem is really, really hard to tackle and all of that. But if you’re charging I expect that this is something serious. Keep in mind that the company isn’t saying it’s just giving you a tool to play around with but doesn’t believe in the quality of its data. It doesn’t show me that when I look at Buffer’s profile the chance that it’s right is 99% and when I look at an earlier-stage company the data might be only 70% reliable. $500 a month Before I get into what I’ve found this is my big ask: Am I not getting Mattermark? Am I using it wrong? Is everybody else thrilled and I just don’t get it? Or do you just believe what you read without being really inquisitive like that making a million dollars will make you happy (it doesn’t I can tell you for a fact) or that a $100 dollar bottle of wine is better than a $10 bottle (answer: rarely). 1. Roost Roost is a company that is building the AirBnB for self-storage. Roost has raised just under $2M and was established in 2014. 500 Startups Batch 12 A lot of the information on Mattermark doesn’t match up for the company. For example, while the year it was founded is true, look at the Last Funded box. How can a company founded a year ago have taken funding 7 years ago? Also, I know for a fact from the CEO that the company has 7 employees and they’re actually listed as the Key People on the right hand side. So why does it say that the company has 53 employees? So what happened here? Mattermark took information about the company that was Roost.com and was sold a couple of years ago and layered it underneath new information about the new Roost, which bought the old domain name. The CEO confirmed this to be true. Techcrunch/Crunchbase got it wrong too, mixing up the two companies (see the article on the left and the company profile on the right). But this is no excuse and it’s easy to fix this. 2. Contractor Insights Contractor Insights is a company I was a part of for a short while that was registered in Delaware as a C-Corp and then registered as a foreign entity in the state of Colorado) in March 2015 . The company exists and is actually launching a product soon but it does not exist in Mattermark. No record. The startup is in the process of redoing its landing page so I know it’s live and moving forward and does have a founder and possibly outside financing. It most certainly exists and even has a LinkedIn company page: 3. Intelclinic Intelclinic brought the Neuroon sleep mask to market through it’s very successful Kickstarter campaign (beat its goal by a factor of more than 4). Neuroon is the product and Intelclinic is the company — pretty straightforward. Mattermark lists both records and gives a funding number for Intelclinic and not one for Neuroon (which makes perfect sense). But besides raising $439k on Kickstarter, the company also raised a tiny starter round earlier. Mattermark makes no mention of that although it does pull information from Crunchbase, which does contain information on the round. According to the CEO the employee numbers and the uniques also don’t add up. The company also garnered serious press attention from the likes of: source: Neuroon but Mattermark only mentions one article from 2014 4. Brand24 Brand24 does social media monitoring and analytics for the likes of IKEA, H&M, AirFrance, Intel and many others. Mattermark lists the company’s two websites (one in Polish and one in English) as two different companies. But there’s only one business (just like it has one website for Apple and not the hundreds Apple has registered). In both records Mattermark shows 24 employees: When I asked the CEO how many people work for Brand24 late Friday night he responded: It’s also pretty clear that the company was established in 2010 (but registered as TDB in 2011 according to its business registration documents) but the U.S. entity was probably registered much later. Mattermark makes no mention of that distinction. And the company has taken outside funding, although Mattermark says it received no outside funding. The startup was actually sold (50.49%) to a . strategic partner in 2012 5. Makeena Makeena is a local Boulder, CO company in the consumer app space that is currently raising money. Mattermark says the company has raised $76k: and this matches Angel.co but go to Crunchbase and you’ll see information saying that it’s raised more (which is not necessarily reliable). I know for a fact that the company has raised even more than the $176,460 but the $76k is what Mattermark is reporting. You can also see that the company doesn’t have it’s year Founded filled out but there are signals out there like this: Crunchbase (2013) Twitter (joined March 2012) Gust here (founded in August 2012) and of course on where they list their founding in 2013. AngelList 6. Fido Labs Fido Labs is an exciting company in Silicon Valley that promises breakthroughs in machine learning and deep data processing. There is one Fido Labs and they’ve got a couple domain names and sub-domains for various projects and products, but it’s one business. Mattermark lists 3 different companies but they’re the same entity. and says the company never raised True for all 3 FidoLabs profiles (www.fidolabs.org, fidolabs.com and apps.fidolabs.com) although I know it has and that has been published here: source: AngelList These are serious people doing serious things with data and moving forward and you can’t see any of that looking at Mattermark. 7. Spray Networks Spray is a company that offers a proximity-based messaging service. The startup has raised money from the likes of Mitch Lowe (co-founder of Netflix) and has a couple hundred thousand dollars in funding. The company has 20 employees according to CEO Kamil Kuchta (November 12, 2015). Mattermark lists 13. Mattermark reports is hasn’t raised anything and again it does show duplicates because the company has two domain networks registered (www.spraynetworks.com and getspray.com). So there you have it. 7 companies that I know and would like to analyze and the information I can see on Mattermark is neither credible nor reliable for all 7. All 7 are registered entities. All are live. All have U.S. operations. You can’t make any business decisions based on this information. I understand the vision and I know the intent is pure, but I just don’t see any value crunching bad data to give a Growth Score or a Momentum Score or any other indicator based on information that has nothing to do with reality. So while I’d love to believe that what I’m seeing here (a list of Boulder, CO’s fastest growing companies) is real the truth is that I have no idea if any of this is credible. Of course Crunchbase, Angel List and are also way off base often but if the information out there contradicts each other than that should warrant a closer look, especially since they claim to have they rely on. others thousands of data sources http://mattermark.com/data-crush-producthunt-is-quickly-becoming-the-hot-new-destination-for-sourcing-startup-investment-opportunities/ So what are we seeing? I’m not really sure yet but I’m trying to understand the problem. Right now it’s just like with cooking: You have to start with good ingredients because you really can’t do anything decent with crap even if you dress it up nicely like this: Seared Spam with Tostitos queso-dip mashed potatoes and canned green beans. Topped with a Flamin’ Hot Cheetos and Corn Nut salsa verde. So again, I’d like to reiterate my ask: Am I doing something wrong? Is there a caveat somewhere that says that this is just a toy to play around with or because I have a free trial I get the bad data or is something else going on? To tell you the truth all of that would be fine. Mattermark is attacking a huge problem and nobody expects everything to be perfect from the get-go. But if you’re taking serious money from serious folks in exchange for a serious promise things need to add up. I know that Mattermark has a process in place and of course this is useful but serious mistakes in 7 records in a row is not a reportable problem, it’s a systemic or even a structural one. to update data quality And I know that the company’s very transparent about it’s efforts to collect the information out there. And like I wrote in the beginning: The product doesn’t need to be perfect. But it does need to be real. I’d love your feedback and frankly I’d love to be told that I’m wrong or that I’m not understanding something. I’m even prepared to take down this post if I’m just clueless and I’m doing it wrong. But my gut is telling me that there’s a lot more to this than meets the eye. Jakub Kostecki is founder and CEO of StartupFactCheck.com, which performs due diligence and analysis on early stage investments for the world’s best startup investors. If you’ve found this article to be useful please hit RECOMMEND and SHARE it with your community so I can collect more information about the credibility of information out there on Mattermark.

ROOSTOO

roostoo.com

-- employees

Since n.d.

COMPANY RANKING

ROOSTOO

EVERGREEN INDEX #9239

Representing this company? Click here to claim and customize this page!

Roostoo WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

ROOSTOO

roostoo.com

-- employees

Since n.d.

COMPANY RANKING

ROOSTOO

EVERGREEN INDEX #9239

RELATED COMPANIESRANK

STORIES ABOUT ROOSTOO

Representing this company? Click here to claim and customize this page!

Roostoo WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!