Building Smart Contracts with TypeScript

Transcript

Awesome. Hi everybody. Thank you guys so much for coming. Let's Let's get into it. Today we're going to be talking about building smart contracts with TypeScript. So show of hands, who's worked with TypeScript before or JavaScript? Okay, good amount of you. Nice. And what about who's worked with building smart contracts before in Solidity or something similar? Okay, maybe like half the amount, which is good. So we're going to be talking about building smart contracts with TypeScript. So hopefully for those of you who have worked with TypeScript but not built a smart contract, this could be a big unlock for you. So let's jump in.

So I know probably a lot of you are thinking, why why do you want to build smart contracts with TypeScript, you know? Especially JavaScript like it gets memed on a lot. It has a lot of weird interactions. I mean these are some of them. Apparently type of NaN is a number. Apparently NaN is not equal to NaN and math.min is greater than math.max. So it certainly has its quirks. So let's talk a bit more about why we still might want to might want to do this. I mean the first big reason is TypeScript is everywhere, right? Like in the 2025 developer survey, we had JavaScript being used by 66% of developers, which is huge and TypeScript 43.6. So it's got like massive penetration and is super useful broadly

in the industry. We've got 9.3 million new TypeScript JavaScript repos created per year, which is crazy numbers. >> [snorts] >> And it's not just in the wider development community, but we are seeing a huge amount of this in DeFi. So I went through the top 300 DeFi protocols by TVL and 92% of them were using TypeScript or JavaScript somewhere in their stack, right? Which is you know, very vast majority. 98% of them were using it on their front end. Which is huge, but also it begs the question, what are the other 2% doing? Are they writing their front end in Rust?

But unusual. And in 93%, this was surprising to me, are still using it in their smart contract tooling. Even though like tools like Foundry and stuff are getting a lot of traction, we're still seeing some of the larger protocols still using TypeScript and JavaScript. I mean every project has a different tech stack, but it's not uncommon that you might see something like this. Where you know, you have TypeScript on your front end, maybe you got an API, some sort of node API in TypeScript. You've got some sort of scripts. Maybe you're using Hardhat to write your smart contract texts and tests in TypeScript.

And yet your smart contracts are written in Solidity, right? Of course all projects will you know, maybe have some Rust or Python or whatever sprinkled in. It's not this black and white, but you can kind of see immediately the the odd one out here, right? We're even seeing like because of this like program context switching, people are starting to write their tests in Solidity, which almost feels to me like it's going the wrong way. You know, if this progresses, we're going to end up writing our front end in Solidity in a in a few years. So why is this why might this be undesirable, this split? Oh, sorry. First we'll yeah, talk about the the penetration of smart contracts in in DeFi. We can see that Solidity still has like the very vast majority of I guess market share here. We're seeing some Rust and Move

used a lot in some of the let's call them inferior blockchains. We are in an Ethereum conference, so >> [laughter] >> and in Viper, it's awesome to see the second most popular like EVM programming language seeing 1% use. So good that we've got some small amount of diversity there. >> [snorts] >> So context switching tax. I mean I won't go through all these in detail, but there have been quite a good amount of studies to show that context switching is a real decrease in productivity. Especially moving between programming languages does like result in less productivity. You know, your mind kind of stays on the old one and stuff and has been some studies to show that. My favorite one is developers lose an

estimated two to three hours per day to context switching, which is crazy. Especially when you consider that most DeFi developers only work four hours a day. So it's like most of their time, you know? >> [laughter] [snorts] >> Another benefit of you know, if you were to write your smart contracts in TypeScript is for any devs who have worked like kind of jumping between them both, you end up doing this with your types where you have your types in Solidity, but you still need your types on like your front end or API and you have to kind of like convert them between each other. And if you're developing a protocol, the types are changing, so you're having to go in and tinker and I'm sure some devs in this audience have felt that pain. So if they are the same types, you could even have

them in like a shared mono repo or something. It's just small little benefit. But I think one of the benefits is like in the space we want more developers to come and develop smart contracts from outsiders, people who are not in the industry yet, make it more approachable for them. Or people who are in the industry and maybe working in other areas of the tech stack who want to start delivering smart contracts. Now it's a big hurdle to learn a totally new programming language, but like we can see from here, so many developers already know TypeScript and JavaScript. And it's obviously way easier to be writing in a programming language you already know when picking up like a you know, a new project or something like that.

>> [snorts] >> Solidity, I love Solidity. It's great. Not throwing any shade, but for those of you who have worked for it, it can certainly be quite painful. Stack two deep pairs, no generics or templates. Working with arrays is an absolute nightmare. This whole like memory storage call data is a bit of a thing to try and wrap your head around. Having to like declare functions as views or not, you know, manually. Having to optimize for gas, like it's really a nightmare to work with strings. And yeah, it's it's it's fine. And once you get used to it, you know, it's it's not that bad. But certainly if you're coming into the space, this is like quite a a steep learning curve. And for those of you if you remember when you first

learned Solidity, some of these were certainly some pain points. But yeah, Solidity great language, certainly the right tool for the job for you know, probably 95, maybe 99% of of protocols depending on what you're building. But it's nice to explore what what else is out there. So has it been done before, building smart contracts with TypeScript? Yes, Algorand has Algorand TypeScript, which is active and is officially supported. NEAR Protocol has a JavaScript TypeScript SDK, which is has production use. And while we're not seeing any smart contracts written in TypeScript in the EVM ecosystem, we're seeing a lot of tooling, you know, a lot of tooling in TypeScript. So it's kind of you know, weaseling its way into the

space, which is cool. But it does show that it's a a proven concept. It does have real users and and can function in in a real world environment. So what are the downsides? Why wouldn't we want to build smart contracts in TypeScript? Uh block explorer verification is a big one. This is true of I guess any new tooling. Your Etherscans of the world, they're not going to support TypeScript or JavaScript. And so when you deploy your contract it's it's not going to be verified. You're not going to have those cool things where you can you know, look at the views and and function calls.

Auditors, they're not going to know how to audit TypeScript or JavaScript. So they're either going to like charge you an arm and a leg or they're going to decline your offer or they're going to do it and and probably do a bad audit. So it's not great. And you know, as a as a new paradigm, there's not as much tooling and stuff. Whereas Solidity there's a tremendous amount of tooling out there, which is really cool to see. >> [snorts] >> But yeah, with any new tool there's just going to be less support. So let's say you have weighed up these pros and cons and you're thinking, okay. Let's give it a go. How can you actually write smart contracts with TypeScript?

To the best of my knowledge, there is only one way to do that currently, which is Skittles. This is a project I've been working on as like a pet project for three and a half years. It's been in development. And it's now production ready. So so you can use it today. But I'll add some disclaimers to that soon. So how does it work? You're writing native TypeScript. This isn't like a kind of weird variant of TypeScript that's TypeScripty but actually different. It's it's pure TypeScript, so it's natively supported in your IDE. You don't need to add any plugins or anything. You're you're jumping straight in.

You can test it locally. You can use like already well well-established and developed tools like Hardhat, which is a TypeScript smart contract testing tool. Or Mocha Chai, which is normal testing tools that probably many of you have worked with before. And you can deploy it anywhere. So you can deploy it on any EVM chain. It just compiles down to EVM bytecode at the end. One difference I think is it's not really a drop-in replacement for Solidity. It's more of like an abstraction layer on top. So the goal of it is to be easy to use, a bit more kind of lean, a bit more opinionated. And trying to do more things with less code. So the downside

of that is that you have less control. So you can't really get in the nitty-gritty and optimize for gas. So it's like less gas efficient. But the upside is that it's easier to learn. You generally have a smaller surface area of code. It's like we'll look at some examples soon to show you what I mean. I mean some features are like with Solidity, you have to for every single function say whether it's a view or not, like whether you read from it or whether you write to it. With Skittles, that's done automatically. So you just write the function without caring. And it will tell under the hood whether you're mutating state or not. And then it will auto assign those flags. And there's lots of small little UX things that just abstracts away a lot of that those headaches or complexity.

It's also got for those of you who have worked with Solidity, you might know like OpenZeppelin. These are third-party libraries that you can then pull in to like help your development. Things like building ERC-20s and adding permissions to your smart contract. With Skittles, that's all built in. So in you know, a lot of these main libraries and stuff, you can just import them straight away. So, it means you're going out less to bring in things. It's all kind of uh bundled in together. >> [snorts] >> So, if you wanted to try it out, it's just NPX Skittles init. So, it's one command, and that's going to bootstrap a little project. It's going to have an example contract, example tests, uh all the config set up. So, you can try this today, run it on your machine, you know, just have a look at the output. It gives

you a good feel for uh how it works and what it does. And here's the uh here's the cool part about it. It doesn't actually compile from TypeScript directly to EVM bytecode. Instead, it actually transpiles from TypeScript to Solidity, which is kind of like Google Translate. It's like taking one language and and turning it into another. Uh the downside of this is it's a little bit slower cuz it's having to do two steps, but we're talking like, you know, less than a second. And uh but the upside is that you get the Solidity in the middle, which the user doesn't actually notice, but it's saved in a a file, uh which unlocks like quite a few things. And let's look into that.

The first one is when you deploy your contracts, you can actually verify them now because it has that Solidity under the hood, and Skittles will automatically use that Solidity to verify the contracts. So, when somebody goes into Etherscan and looks at your contracts, they won't see the TypeScript code, but they will see some code so they can verify what it's doing, how it works, and they'll see those cool views and functions. So, people can go and like test it out in Etherscan. It helps a lot with auditing cuz now if you're working with an auditor that only works with Solidity, instead of auditing the TypeScript code, they can audit that intermediate step. And so, if they say that Solidity code is 100% fine, then you know your final contract is going to be 100% fine. So, it gets rid of that bottleneck.

And it because it has that intermediate step, it works with all of these Solidity tools. So, if there's some cool Solidity tool that I don't know, look look looks for bugs automatically, it's still going to work with that. So, you're kind of getting the dev experience of TypeScript, but with all the infrastructure and like benefits of Solidity as well. So, this is in the security track. Uh why might it be more or less secure to write in TypeScript? To be honest, right now, it's definitely less secure. Uh the reason is that this is a a new project. It hasn't been audited. It hasn't been battle-tested yet. And compiler or transpiler bugs are a real risk. Uh like we saw with Curve two two years ago or something, uh they had that bug where they had a

bunch of Curve pools exploited, you know, lost a lot of money. And that was a actually a bug with the Viper compiler from like four years earlier or something that went undiscovered for some time. Uh so, that is a real risk right now. Uh I would not be looking to use Skittles to write like large-scale production uh code. Uh this is more of a forward-thinking. Uh but if we were to like, you know, think three or four years ahead, this is continued development, it's got some audits, it's been battle-tested, and theory is it more secure to write with TypeScript than Solidity?

I would probably yes, just because you can do more with less lines of code. And we'll look at some examples of that soon. Because it's this abstraction layer and and like things are kind of abstracted away and like uh when you build stuff, uh you you have a much smaller code base, and there is I mean, read this if you like, but there's a lot of studies that show there is a strong correlation between the number of lines of code and the amount of bugs in that code, and the number of lines of code and the complexity of that code. So, by reducing your code base, reducing the surface area, you're reducing your surface area for risk.

So uh we'll go through some examples of that. This is a Skittles smart contract. It's quite a simple one. Uh you can see it's using classes. A class is what you use to represent a contract. You can see we have our values variable here. So, this is storing stuff. We have a add function, which is adding items to our list, which is writing it to storage. And we have the view at the bottom here, which is returning the the top items the top values. So, we can see how we're doing a filter on items that are greater than 10, and we're sorting it.

So, I think this is, you know, for any TypeScript dev, this is easy to understand. There's a low chance that there's a bug in this. Still possible, but it's quite easy to audit and tell if this is doing what it's expected. Uh this is the like corresponding Solidity code if you were to do the same thing. It's obviously a lot larger. I mean, this is a bit mean because Solidity's known for being bad for lists and strings. So, it's a mean example, but uh you can just see automatically that there is a much higher chance that there is some sneaky bug hiding in here than in that previous code previous code. And similarly here, this is a simple function that's just splitting a string to based on commas to like make it a list. Uh really simple, low chance of bugs. It's the same code trying to

achieve it in Solidity. So, like much more complex to try and achieve some simple uh things. And like I I mean, I couldn't even tell you if there are there's a bug in there. There probably is, to be honest, but uh uh yeah. So, just some illustrations. So, the key takeaways, TypeScript dominates DeFi development. People use TypeScript. Even just from a show of hands in this room, we saw there are much more using uh TypeScript. Context switching between languages is a real productivity loss. It is measurable. Solidity is the right tool for like low-level stuff. You want to get in the weeds, you want to optimize for gas, you want to, you know, really make things perfect. Uh but if you're working on a really simple, lightweight app where gas isn't too much of a concern, then uh

then, you know, you might want something high-level, uh which could be Skittles, uh which bridges that gap by compiling the TypeScript to Solidity. So, you're getting the tech benefits of Solidity, but the UX benefits of TypeScript. And hopefully less code means fewer bugs. Uh So, yeah. That's the uh that's the talk, guys. Uh try it out, you know, look into it, check out the website skittles.dev. I'm Chase Manning. I'm the CTO and co-founder of Bounce Tech. You can check me out on Twitter. And uh yeah, I'll uh open the floor to some questions now if anybody has any.

Thank you. >> [applause] >> YEAH. THANK YOU. UM WHY DIDN'T YOU WORK directly on doing a compiler for TypeScript directly to Yul and in bytecode? Yeah, I actually did. That's how the project first started was it was compiling from uh TypeScript to Yul. Uh and I I I thought that was the right path, and I built that for a while. Uh but it was only later on I realized that there were actually a lot of like downsides to this of of just writing in pure TypeScript, like the kind of

auditability thing, verification. I mean, those could be overcome with time, but if you're a a new project trying to trying to break in, it's it's uh can be a turn-off for people. And so, I I pivoted about halfway through development to switch to compiling to Solidity. And I I personally feel that that will help help with adoption, but uh yeah. That was my thinking. Uh I have one question. Since uh I think Solidity is more like object-oriented programming, and TypeScript could be like more functional-oriented programming. Do you think like that's maybe uh like a switch for developers that maybe that's

also maybe useful at some point because it's like writing pure functions is just like uh easier to debug and uh less bugs. Yeah, true. I mean, yeah, TypeScript and JavaScript do support a kind of object-orient-y approach uh with the classes. So, we do lean into that. We we kind of use this class-based model. So, it is still a bit more object-orientated, I guess. Uh but we we definitely pull on the benefits of TypeScript like uh if you think with Solidity, there's no way to just write a like pure function that just exists as itself at a function as a function, right? Uh with Skittles, you can. So, you can write just a file that just only has a function, no class or anything, and you can test that isolated function,

and you can import that into your Skittles contract and use it. So, I mean, personally, I think I I I prefer functional code personally. I think it is a bit easier to test and has less kind of side effects and unwanted outcomes. Uh so, you can kind of lean into that a little bit more with Skittles than you could with uh with Solidity. Yeah. Yeah sure. >> This is more like a comment, but I think this is like amazing because I think we've seen the same like in just like uh normal programming languages like going like from C# to Java. Like of course, if you write like uh code in C++, sorry, I meant C++ not C# C++ you should like more optimize your manage memory and everything, but at the end, it's just like

more code, more bugs. And then you move like to let's say a high-level programming like Java, which is less optimized, but it's just easier for the developer, but at the end, uh what you want is just less bugs and being able to write better code. So, I think this is like a really good idea, and then yeah, that is on the right track. Thank you. I appreciate that. And yeah, I I think the same. I think they always come from different areas, right? Like running applications on Ethereum, it used to cost whatever, $60 per transaction, right? So, there was a lot of pressure on developers to write very optimized code. And now, I mean, it depends what chain you're using, of course, but a lot of these L2s, you you we're looking at cents. So, even if the contract was twice as expensive or a bit

inefficient, uh I mean, it's not great, but I think people would prefer that for for you fewer bugs, I guess. So, yeah. Yeah, thank you. We've got a 1 minute, maybe one more question, or or should I end it? One more? Okay. Thank you very much. Fantastic presentation. Um how would you say this plays into the future where more and more code is written by AI? Yeah, good question.

Uh I think AI benefits from big training, like big inputs of training data. And there is certainly more code online of TypeScript and JavaScript than there is a Solidity, so the AI would have more training on it, I guess, which in theory should result in it writing better code. And whether the code is written by AI or a human, still the less lines, the more secure. Uh so, in theory it it it should be benefit in that regard as well. And also, uh tokens are expensive, and so, you know, the less input you have for it to read your existing code base, and the less tokens outputted are uh should result in it being cheaper.

Thank you very much. Can't wait to use it. All right, I'll end it there, guys, but I'll hang outside for like 10 minutes if anyone wants to uh uh you know, chat or uh yeah, so. Thank you very much. Cheers.