It’s always impressive to meet the talented people building in the blockchain ecosystem. This week I got to chat with two of the co-founders at Tenderly, Andrej (CTO) and Bogdan (Distributed Systems Engineer) following their win at the ETHBerlin Zwei hackathon last week for their entry, sol.tty. It was a great chat, and an awesome project, hope that you enjoy learning about it as much as I did. 

Colin Platt (CP): Hey guys, hope that you had a good trip back from Berlin, and were able to rest-up after the week. Thanks for taking the time to speak with me.

Andrej Bencic (AB): Hi, good to talk to you. Yes it was an intense trip, it was a very packed agenda and we were super busy the whole time. It was a really good and was good to meet people you know from the internet in real life.

Bogdan Habic (BH): Yeah, we met a lot of people and I don’t think that I’ve ever shaken so many hands. A great event.

CP: So tell me a bit about yourselves. How did you get into this space?

AB: We’ve worked together for about six years now. We met in high school in Serbia and have been working together ever since. We started doing software development together back then and done several hackathons together.

BH: You could say that the hackathons have become a benchmark of our friendship. If we don’t win our friendship is over.

AB: We’ve started two companies together, while working together at four altogether, doing software engineering.

BH: Guess that because we’ve been working together, sometimes it’s hard to add in the intro. I’m a distributed systems engineer and have always enjoyed working with scaling issues. Previously I’ve been in “traditional” software engineering, with a focus on cloud. I became a fan of cloud because of the ability to leverage it to build huge systems with a small team and make a large impact. The Ethereum ecosystem is interesting because it is very young, and are still working to bring scaling. I became interested with the challenge of how to bring better visibility into the blockchain. Before launching Tenderly we worked together as part of a startup called ManageWP, a WordPress management platform, which got acquired by GoDaddy in 2016.

AB: About a year ago, we entered an Ethereum hackathon. We wanted to build a trustless, public tender project for governments to get bids for projects. That’s where the name “Tenderly” came from. We continued to build the project out after the hackathon, and talked to the people at GovTech Pioneers in Vienna for potential projects, but then discovered two things. First it was hard to talk to governments, and secondly there was a lack of tooling in Ethereum. We really enjoyed building dev tooling more than talking to government procurement teams. We liked the name though, so kept that and open sourced our internal dev tooling.

CP: So tell me about Tenderly.

BH: Tenderly is a smart contract monitoring platform focused on bringing visibility to the development and deployed phases of Ethereum smart contracts. We bring dev tools to help successfully manage deployed smart contracts, as well as help developers deploy faster. Debugging smart contracts is time intensive so we built human readable stack traces for solidity which can cut 30-60 minutes of debugging time. In addition to helping fix errors, which are just a part of the smart contract lifecycle, we also have a platform for monitoring the load on deployed smart contracts, and VMs for extracting data. We can help visualise the full execution cycle of all transactions on smart contracts, which can help developers see unexpected and strange behaviour on a method-by-method basis. This can help understand what is actually happening, and let the developer tell whether the contract is doing what it is “supposed to be doing”, or what it is “meant to be doing”.

AB: There are also tools for monitoring how smart contracts are behaving, who is using them, how money is being spent and how the contract is being used. This helps respond to unexpected behaviour, and identify entities trying to use it in ways that weren’t intended. We don’t just offer templates, the tool is highly configurable because the developer is in a better position to know what needs to be monitored.

CP: Beyond Ethereum, do you work with other blockchain networks currently?

AB: Currently we’re focusing on Ethereum as the ecosystem is the largest, but we’re building a platform to expand with Ethereum and eventually scale out to other platforms. In our view, in a future on ETH 2.0, it will be particularly important to monitor what is going on with smart contracts inside of Ethereum. We’re also believers in sidechains and permissioned chains networks. Projects like Polkadot and Cosmos also interesting for us.

CP: You were just in Berlin for the ETHBerlin Zwei conference, where you were one of the hackathon winners with your entry “sol.tty”. Can you tell us a) how to pronounce sol.tty and b) give us a brief explanation of what it does, and what inspired you to build it?

AB: Haha, I think that we’re going with “solty”, like salty, but with an “o”. We knew we wanted to do something with solidity and thinking of a name I thought of a TTY which is a term from the Unix world. Once we heard how sol.tty sounds, we couldn’t pass on the opportunity for a pun.

BH: Coming from the Web2.0 world we have experience with other tools for other platforms, and one of the things that we saw as missing in Ethereum was a REPL. Right now if you want to test a contract you need to write the contract, deploy it, call it, then destroy it. This can use a lot of gas and cost a lot.

AB: Our work on Tenderly has given us quite a bit of low-level operating knowledge of the EVM, so we decided to try to implement an EVM in the EVM. We spent about 40 hours during the hackathon with a table of the EVM opcodes trying to implement them in solidity. When you run a code it checks against the table and executes the method. You can then use a wallet like Metamask to run sol.tty and spin up your own local version of an EVM to check code before deploying it to the network.

CP: Let’s talk about how it can be used and the problems that sol.tty could solve.

BH: An example of where this might be useful is when you want to write a smart contract to arbitrage across multiple decentralised exchanges. Right now you’d need to query the DEXs, pulling from web3 and then implement the strategy to call the DEXs. But this means that you need to wait for transactions to be mined and the prices may have moved when you go to run your smart contract. With sol.tty you write the strategy in your wallet, ensure it works and execute it directly. In a way this now gives us some of the functionality that exists in Libra’s Move, where there are transactions and mini scripting programs that act as transactions. It allows you to orchestrate multiple smart contracts, and gives you more flexibility.

AB: We also implemented it as an identity contract, so that the functions can be called from a single contract acting on your behalf and allows you to control the originator of the call. This makes it cleaner to write code and add functionality later. It also allows your contract to do arbitrary things where the owner is an onchain entity.

BH: It is really flexibility to the extreme. It allows you to do anything that the EVM can do. We hope that it should open new functionality and allow people to experiment. We’ve looked at how it could be helpful for rapid prototyping without the need to deploy. You just run trials hammer at the end point. This might even be helpful for penetration testing on other contracts. Send a lot of tries at once and see what happens.

CP: So an EVM in an EVM is cool. Could you also do something similar for other VMs?

AB: In theory, and I stress in theory, we could do eWASM in the EVM but it is more complicated, or really go extreme and do a JVM in EVM but there would be lots of issues there and extra functions that wouldn’t really work or be necessary. For the eWASM in the EVM it might be useful for checking new eWASM opcodes to check support on contracts as well as the usefulness of implementing them.

CP: Could you talk to me about some of the challenges of developing sol.tty, and what you learnt?

BH: You can think of the EVM as composed of a few parts, stack, memory, storage and loop logic. Implementing the loop was easy, for-loops with switches. Biggest challenge was working in an environment that already had a stack without blowing up something. In theory it was possible to do it in one stack, but it was easier and more flexible to re-implement everything in memory.

AB: Our second issue was whether we would have corrupted memory. Initially we thought, “nah”, that’s not going to happen, but in the end, of course, we ran into corruption issues. Sectioning memory was something we constantly had to keep in mind.

BH: While implementing opcodes, a tricky problem to get right was positioning all data correctly on our stack. The EVM needs everything to have fixed widths, but sometimes appends values on the left, sometimes on the right. We had to go back to the GETH code to see how it was done. There isn’t a ton of documentation on it, outside of the Yellow paper which was a bit harder to decipher and would have taken too much time, so having a reference implementation was good.

CP: What’s next? Do you plan on further evolving sol.tty?

AB: It would be cool to continue to work on it, doing more optimisation on gas costs and adding more opcodes. It was cool when we arrived back in Serbia to see that we already got PRs for new opcodes. We’re just back so we’ve not given it too much thought but maybe we’ll look for grant funding to keep going.

BH: I’m interested to try having other languages for more defined use cases optimised for exactly what you’d wanted. This could make it easier for someone that doesn’t want to deal with all of solidity and could act as a bridge for what is executed onchain. Right now, without optimisation it isn’t really suited for using frequently because of the additional gas costs, but maybe this is something that could be brought down to say 5% more gas than going directly and might be worth using. It could also be useful for simplifying complex operations like swaps. Lots of transactions are straight-forward but others are a pain.

CP: Any other cool projects that we should know about?

AB: Check out Tenderly! We’re pretty heads-down focused there. Personally, I’m also interested in Uniswap because of its simplicity and flexibility.

BH: Decentralised identifiers are something that interests me personally. I also like the work around onchain wallets like Argent. The Gas Station Network (GSN) Alliance is also quite interesting because you can imagine how it brings adoption to the next level. Combine it with the iOS Shortcuts app to write code that is sent to GSN, and sol.tty. It would allow you to do walletless, gasless transactions from Siri.

CP: Alright, now you’re getting into sci-fi. Thank you so much guys, it was a pleasure talking with you. I wish you the best of luck, hopefully we’ll be hearing a lot more from you soon.

AB: Thank you, it was good chatting with you.

BH: Thanks for reaching out.

Colin Platt here again, time for another blog, exploring some of the topics that Zeth, Shaun and I found interesting and noteworthy. It has been a while since we did a deep dive, happy to be back to it. As always, nothing here should be construed as financial advice, recommendation or endorsement of any project or cryptocurrency.

Just when you thought that crypto had exhausted every possible permutation of three letter acronyms they surprise you once again.

Today we look at one of the latest trends in using tokens to fundraise, IEOs.

Let’s start with a quick explanation of what these things are. Most readers will know what ICOs, or Initial Coin Offers, are: teams selling crypto tokens to investors to finance the development of a project. Generally ICOs have worked somewhat like crowdfunding, where the ICO seller announces the amount of tokens to be sold, a price (in USD or crypto), and a start date for the sale. Some projects opt for more complex processes where the price increases over time, or after a certain amount is sold, still others go through a more complex auction process. One of the main selling points of ICOs as an investment was that they commonly offered investors liquidity shortly after the completion of the token sale. However, things were not always so simple.

Though ICO teams usually had exchange listings as part of their token sale roadmaps, would enter into partnerships during and after the sale it was always a risk that they would have no, or only minor -exchanges willing to list them. Listing on the more prestigious, larger exchanges, usually meant higher returns for early investors and greater liquidity when it came time to sell. Many exchanges understood this and sought fees from ICOs looking to list after a sale, which could often measure in the hundreds of thousands of Dollars.

While exchanges initially found listing fees profitable, they quickly understood that by accepting them, clients would no longer see the fact that listing on a large exchange was a mark of distinguishment, thus degrading the overall perception of the exchange itself. In addition, while generous, these fees could also end up leaving the exchange with large potential legal liabilities should regulators decide to clamp down. In an effort to maintain this source of revenue, their brand perception and try to take the heat off themselves, exchanges pivoted to become involved significantly earlier in the fundraising cycle.

Enter the IEO.

The IEO process looks somewhat similar to the ICO, however with one critical difference. Teams looking to fundraise with a token work with a potential exchange in the early stages, going through due diligence on their idea, team and plan, and structure the details of the fundraise with dedicated teams at the exchanges. During the token sale itself the token uses tools provided by the exchange and accepts funds, which have gone through the normal KYC processes of the exchange. Having provided these services, exchanges can charge a fee in good conscience. And although simply running a token sale through an exchange doesn’t guarantee listing on that exchange, there are reassurances for the exchange that the team would have passed the basic levels as part of that process. More reputable exchanges will generally segregate the IEO team from the teams which decide which tokens get listed, though this is not a universal process.

In addition to third parties raising funds via IEO, the exchanges themselves have used the tools and customers they already have to raise funding. Some examples are Binance Coin (BNB), Bitfinex’s Unus Sed Leo (LEO) -which raised more than $1bn, Huobi Token (HT), as well as more recent FTX token (FTT).

Despite their success, having effectively replaced ICOs, IEOs have not been without their controversies. Investors have complained that many IEOs have given preference to insiders, selling out millions in seconds, or otherwise employed unequal terms that favoured some groups. Teams have reported paying money for the IEO process only to be hit with unanticipated fees, and receiving less than they had expected. As with ICOS, questions around the legality of IEOs still abound. Still others question how real the raises are, pointing to the fact that with ICOs you can at least see the sales via the transactions on the blockchain themselves.

Post launch IEOs have also had questionable returns, despite common jumps on day one, returns have not always fared well. This continues to pose the question about the suitably of IEOs as investments for the retail investing public, which may not have the time to properly research the prospects of the investment, or be able to withstand the risk of capital loss.

Despite this, IEOs present an interesting evolution in the token-based fundraising space, and help answer some of the basic questions, as well as giving some level of assurance about projects. The current incarnation may be ephemeral, ultimately giving way to the next iteration of this trend. It is clear though that fundraising leveraging crypto assets is a trend that is not likely to disappear in the short term.