Podcast Transcript

Smart Tokens vs REST APIs: TokenScript Explained

Mathew Sweezey Former co-founder, Salesforce Web3 Studio; Smart Token Labs advisor (at recording)

In this August 2023 interview, Mathew Sweezey argues that tokens can deliver portable services, not just represent assets. His car-and-insurance example leads to a practical question from Kevin Riedl: why use smart tokens rather than agree on a REST API? They discuss TokenScript, off-chain data, attestations and metadata profiling. The transcript preserves the argument and its challenges; the sourced answers distinguish a token interface from automatic interoperability or privacy guarantees.

  • Published 02 Aug 2023
  • Runtime 24:10
  • Operator
  • Recorded in English
Smart Tokens vs REST APIs: TokenScript Explained: podcast episode with Mathew Sweezey, Former co-founder, Salesforce Web3 Studio; Smart Token Labs advisor (at recording)
// The short version
  • At 02:28, Sweezey reframes tokenization as tokens acting as applications. At 03:58, he illustrates a car token that exposes vehicle and insurance functions inside another service. The example explains portability and composition, not a confirmed Uber or Apple Wallet integration.
  • At 06:48, he argues that bilateral API integrations become difficult to maintain at scale. At 12:12, Riedl asks why firms cannot standardize a REST API instead. The interview proposes a token-centered interface; it does not demonstrate that APIs or common business semantics disappear.
  • At 13:00, Sweezey introduces Smart Layer and TokenScript. The TokenScript framework documentation describes a runtime and signed files that expose token functions, including off-chain operations. A receiving application still needs compatible support.
  • At 13:24, he describes a contract referring to an external script. ERC-5169 defines scriptURI for that purpose and discusses script integrity and server-API trust. The captions say EIP-6159; the transcript marks that mismatch. A script reference does not mean arbitrary code executes on-chain.
  • At 17:53, Riedl challenges whether public metadata can support unwanted profiling. Sweezey proposes off-chain data and limited disclosure. Neither makes a system automatically compliant. CNIL’s blockchain analysis calls for a specific assessment of personal-data processing; the interview’s blanket GDPR claims remain the speaker’s claims.

Introduction and Smart Token Labs

Watch this part · 0:00

Kevin [Opening jingle: Wavect, the Web3 software company that understands what you want.] Hi everyone, welcome at Wavect. Today with Mathew Sweezey, the former co-founder of the Salesforce Web3 Studio. He's also currently a Web3 investor and advisor for a variety of companies. Today we will talk about why tokenization is actually a game changer. Thank you, Mathew, for being here. It's really a pleasure talking with you. Starting out, I want to give you the opportunity to let us know what you're currently working on, maybe how your day looks, and whatever you want to tell us about yourself.

Mathew Cool, thanks, Kevin. It's great to be here. I spend most of my day working on what I believe is the future of the internet, which is what I believe is called tokenization. I have a very different idea of tokenization. I'm currently advising a company called Smart Token Labs, who is working on a new protocol, helping take that to market, called Smart Layer. We're looking at the missing link between Web2 and Web3: being able to solve existing Web2 problems, such as integration and data sharing, with Web3 utilities.

What are tokens as applications? The car-and-insurance example

Watch this part · 1:15

Kevin Before we get into that, there might be some viewers who have possibly never heard about tokenization. Could you briefly explain what it is, as simply as possible?

Mathew Sure. As simply as possible, tokenization is really just using a token as a new primitive of the internet. Tokens are not a new thing; they've been around a long time. The majority of us know tokens through essentially a currency like Bitcoin or Ethereum. That is a fungible token, meaning it's essentially a digital currency backed up by the blockchain. You then have another type of token, another type of asset or ownership token: a non-fungible token. That just means each of those tokens is unique. It's not like a currency; it's more like a trading card. Those are the two types of core tokens that we know about. Both of those are classified as asset classes. They're usually to define ownership of something. They give you some basic rights and you can take them places and say, “I have this,” or, if it's a currency, you can spend it. Those are too simplistic, and what most people know of and think of as tokenization. When I say tokenization, I mean something very different: literally a new way that we connect the internet. It's not just currency and not just proving ownership that you have something. It's really tokens as applications. Follow this logic and you can understand. Think about a business service or a function. How does one party deliver something to another? Go back to when we first got the internet. We deliver business services first through websites. The first thing you could do through a website was get information. Then we started to deliver service, meaning you would go to a company's website to interact with the company directly, whether that was buy a product, configure a product, or get a service directly. The next wave became applications. We moved those services to applications because it was an easier way to deliver them to the end consumer. Most businesses have a website and an app because those are the easiest ways to deliver those services. The next wave is tokenization of service. This is where it gets tricky, so I'll pull it apart quickly. In the first two examples, the website and the application are a central repository where the individual goes to get the service: centralized. If we're to decentralize that, essentially make those services composable and portable, that's called tokenization. That's a crazy concept. Let me give you an example of what that would look like. Let's say you are a car manufacturer. Every time you create a car, you also create a car ownership token. This is not just to prove that you own the car; this is literally the functionality of the car. This is a smart token able to pull through business functions. You go to Apple Wallet, open your car token and push the button to start your car, or push the button to lock it. You've integrated the insurance token into that token. Let's say you want to drive for Uber. You go to Uber's registration. They say, “Prove that you have a car of a certain type and certain insurance.” You simply present that smart token, and it allows those systems to integrate together. Now let's say Uber says, “You've got the right car and you have insurance, but not the right level of insurance.” Traditionally, that individual would have to go to their insurance application or provider's website to top up their insurance to the correct level for rideshare. In this tokenized scenario, that service is pulled through into that moment. When you've connected that token to Uber's site, you now have business services delivered directly to you in that moment. You click a button, top up your insurance, and Uber sees you have the correct level and you're allowed to be a driver. We've taken those business services out of those centralized places, tokenized them and allowed them to become portable and composable, creating an entirely new user experience for the web.

Why not build the service with centralized APIs?

Watch this part · 5:31

Kevin Love that. Thanks for the example. When I think about the car example, I feel [manufacturer name unclear in captions], if I'm not mistaken, has already integrated an NFT, basically a non-fungible token, into their car for more traceability use cases: whether the car owner did the maintenance as suggested by the manufacturer, and so on. I really believe these use cases, especially proof that you have that insurance, make sense. You also talked about what I think is your special stance: executing actions on top of the NFT or token, whatever standard it follows. I can imagine a lot of people jumping up and thinking, “Why can't we do that in a centralized way, and why is that better?”

Mathew It's a great question. Let's break that apart quickly. The internet currently functions, and we have APIs. We can build integrations. Building an integration in a one-to-one scenario is not complicated. If Uber only had to integrate with one insurance company, that's not that big a problem. They could do that. How many insurance companies are there? Now you see the problem. Any time we try to do integrations at scale, they're hampered by our ability to scale those integrations. We would have to build APIs to every insurance company, then manage all those APIs. If we instead move that to tokenization, we can remove that issue of scale. It's very easy to do these things one-on-one in a Web2 environment through traditional technology. Any time we want to scale those partnerships, that's trick number one: it's very hard to scale. Trick number two is data. Any time I want to pass data to you, there's this thing called GDPR, which means I have to comply with GDPR. What we're doing with tokenization is actually putting the data in the individual's hands, and the individual is becoming the integration point, which is completely GDPR compliant. The individual is bringing their data around. It's not one company sharing via an API with another, which has data privacy issues. It's empowering the individual with their own data so they can take it wherever it needs to be used to create better end-user experiences. Those are the two things that you can't do in a Web2 world.

Must tokenized data live on a public blockchain?

Watch this part · 8:22

Kevin The second part is particularly interesting. I'm curious how you feel we can actually do that. I assume you want this tokenization on a public blockchain: Ethereum, any kind of Layer 2, Polygon or some other sidechain. With public blockchains, data is actually public, right? [Mathew: Correct.] Do you think about integrating some kind of zero-knowledge technology, or what's your approach or thought model when trying to achieve GDPR compliance or better data privacy?

Mathew It's a great question. There are two easy ways to think about this. Number one: not everything has to live on-chain. Just because it's Web3 and tokenized doesn't mean it has to live on a public blockchain. There are decentralized ledgers that are not public. It can still allow these things to happen, and also allows us to create frictionless experiences without wallets. These tokens don't require anybody to even have a wallet. We can put them directly in an email account or into an Apple Wallet. Let's first remove the notion that everything in Web3 has to be on a public blockchain, because it doesn't. The second aspect is that the individual is the data center. They are bringing their own data, which then allows that to be compliant. That's really the answer: it doesn't all have to be on a public blockchain. The third is yes, ZK. That's like a [phrase unclear in captions], but it's even further than ZK. We're thinking about attestations. An attestation is just a proof that you have something. Think of it as the same function: in a traditional scenario, I have a token and hold it in a wallet. I go to use that token, connect my wallet to a site, and the site reads my wallet and sees what tokens I have. That is one scenario, not the only one possible. You can also have an attestation where I go to a site and give a token that proves I have other tokens. It doesn't allow you to see the actual token; it's just a yes or no, a binary, just like a ZK. We can use those to create and share data, so it's all GDPR compliant. But the easy answer is: not everything has to be on a public blockchain.

Why standardize a token rather than a REST API?

Watch this part · 10:54

Kevin That's where ZK and other types of cryptography, other types of mathematics, can really help. Going back to your first argument of data interoperability, I'm curious how you feel. I know what some people would say here: you still have to agree on a blockchain, on the network, on what token standards to use, and so on. You still need to agree on some standards. If you agree on decentralized or centralized standards, it actually doesn't make much difference, just that one thing requires Web3 developers and the other Web2 developers, and one is centralized and one decentralized. In terms of data interoperability, how would you argue to someone coming up with an argument like that?

Mathew I'm not even sure I follow that argument. Can you make it a little clearer?

Kevin Sure, sorry. In general, for example, you have a token, and that's a unified interface. Every insurance company follows the same standard. Car companies, or whoever, can access and use that data in a standardized way. The thing is, you still need to agree on what token standard and what network to use. People could argue: why not agree on some kind of REST API interface instead?

Mathew Got it. Good question. A couple of things here. One is that Smart Token Labs, the company I've been advising, has created Smart Layer to do just this. It is an interface and allows tokens to be interoperable. You can essentially interoperate on-chain, off-chain and cross-chain without having to build those bridges to the different chains. It is an interoperable standard. There are two other things: they've created a standard called TokenScript, which would be the interface and language standard. They've also put forth multiple EIPs, the last being, I believe, EIP-6159 [captioned number; the described client-script proposal corresponds to ERC-5169], which essentially allows a standard for a smart contract to reference and carry through an external script.

Kevin Similar to the xNFTs I heard of a couple of months ago? I'm not sure if you know them. It's not on Ethereum, if I'm not mistaken; I think it was a Solana-type standard. It was in the same direction: you had an NFT with some executable code in it. That's definitely a direction I can imagine a lot of people are targeting.

Enterprise adoption beyond assets and loyalty points

Watch this part · 14:09

Mathew If we want to reach mass scale, here's what we have to do. Currency is cool, but too many people are afraid of it. I used to work with every major Fortune 500 company on their Web3 projects, running the studio at Salesforce. They all want to do Web3. The CEOs believe in Web3 and blockchain. What they don't believe in and are scared of is asset-class tokens, because that creates lots of issues: legal, regulatory, consumer backlash and brand reputation risks. If we imagine these businesses are going to use tokenization in that format, they're not. In fact, a lot have pulled their projects back. Look how many have scaled down NFT projects in recent months. That's just not what they're doing. They're still saying, “We believe this technology is valid.” What they want to use it for is solving existing business problems. Tokenization as an asset doesn't solve an existing business problem; it creates problems to solve. Here, we're saying you have existing problems: how do we integrate and create a better business network? Think about network effects, business efficiencies. Any time technology allows someone to do something quicker, faster, easier, it always wins. Here, we're enabling business networks to share data and create better business experiences and efficiencies. Those are two core problems they're trying to solve. That's why everyone is going to start focusing on tokens as ways to solve existing business problems. That's how we get mainstream adoption. Take that a step further. We don't even have to use the same concepts we've used before, this concept that you have to have a wallet to start. We can use off-chain tokens. We've just done multiple projects where we used off-chain tokens. In the future, we're not going to say “Web3.” Every business uses all types of technology: one, two, three. They still send letters; we don't call them a Web0 company. Just because you use blockchain doesn't make you a Web3 company. It makes you more efficient and allows you to compete better in the market. If we keep those things in mind, that's where we need to go, because that's where the problems exist. Go back to those CEOs and say this is not Web3 as an asset class, not Web3 as tokenized loyalty points. They don't give a [expletive omitted in captions] about that. They care about how to create better end-user experiences and business efficiencies. That's what we're solving, and that's why everyone is going to focus on that aspect of tokenization moving forward.

Can public metadata still reveal private information?

Watch this part · 17:02

Kevin I love it. We've mentioned identity use cases a couple of times and scratched the surface of data privacy. I'm curious about something that already happens. Even though a lot of data might be off-chain, for identity tokens you still have metadata attached: who issued the token, its type, maybe its name and other publicly available data. It's already possible to tag many addresses and have public data. Even with sensitive data off-chain, you might still be able to infer certain things through data science. Since you're actively working on this and heavily involved, have you already thought about that? How are you solving it? Is that something for the future, or not an issue at all? I'd love to know.

Mathew It's a really good question. There are lots of different things here. Number one, whoever creates the token decides how and where to store the data. If they put information like that on a public chain, they're going to have lots of issues. You should never put information like that on-chain publicly. That's why we're talking about off-chain data and databases. We're using cryptography and Web3 technology to verify. You'll only be able to verify if you're asking questions, and there's still a layer where you'd actually be able to take the data. In a scenario where you take a token to company Y to prove you have X and pull in business function, they have a very limited view. They're just going to fire things. They won't be able to see the underlying data, pull it into their database and keep it. We're talking about layers of abstraction. The key is still to ensure that the individual owns the data at the end. If all we create is a way for someone to build a bot, use data science and AI to scrape the web and create user profiles people don't want, we've not done anything good. We're focused on solving those key issues of data ownership. To us, data ownership means the ability for the individual to have the data where they want it and use it how they want. That's step one. Step two is to ensure privacy. That's why we discuss off-chain tokens in combination with on-chain tokens, to prevent use cases where you scrape everything and build user profiles. Last, understand how we're implementing these solutions. Don't require people to connect a wallet. We don't need to connect a wallet to a site to know what's in it and use it. Other technology can let the individual stay anonymous from a wallet-ID perspective, while validating what's in that wallet and getting the needed token functionality. It's a combination of knowing what's possible, making sure businesses know what's safe and how to create these things, and building systems that let consumers maintain their privacy when engaging with and using these tokens.

Project examples and privacy claims

Watch this part · 20:58

Kevin What kind of company, except Smart Token Labs for sure, do you think might get that right really soon?

Mathew I don't think it's going to be that hard. People aren't going to go at this blindly. No company says, “I'm just going to make a tokenization project without talking to people.” As we guide companies through this, we ensure these things happen. We're releasing projects with one of the world's top cricket players. We've done projects for the FIFA World Cup and the Ethereum Foundation. There are lots of big players wanting to do these technologies and implement these systems. They're abiding by those rules. We're seeing privacy maintained, and that's one of the big aspects of the technology and the security we have: privacy.

Three takeaways on tokens and composable services

Watch this part · 21:53

Kevin Love it. From my end, I'm not sure if there's anything you want to share at the end of the podcast. Otherwise, maybe three key takeaways for people to remember? We've discussed a lot of different but closely related topics today, and there's a lot of essence people might want to remember.

Mathew Sure. Three key things to keep in mind. Number one: there's a difference between securitization and tokenization. There is a difference between tokens. They don't always have to be assets; they can go beyond assets to become applications. Step two: as we think about the internet's future, we must think about composable services. We can use tokens for that. Why would we want to? Because we're solving the internet's key problems of integration and data sharing. That's what allows us to solve those things. Third, imagine a new world where we're not just using tokens as currencies, but as applications creating better user experiences. That's the end game. Businesses that learn to use tokenization to create better user experiences will have the same market effects and dominance as those that learned digitization first: Netflix, Salesforce, Amazon. They were the first to deliver services via the web. Then came the app evolution, with Instagram and other app-first businesses. The next wave of businesses that will dominate the next digital landscape hasn't been created, but I guarantee they will be tokenized.

Closing remarks

Watch this part · 23:33

Kevin That's a great ending. Nothing on my side to add. Mathew, thank you for sharing all that. If you want me to put links in the video description, I will add them for everyone watching or listening. Thank you for your time, and thank you for watching.

Mathew Thanks for having me, Kevin.

Kevin Sure thing.

Jingle [Closing jingle: Wavect, the Web3 software company that understands what you want.]

Edited from English automatic captions, with filler and repetition reduced, punctuation added and clear recognition errors corrected. All conversational turns, opening and closing are included; translations follow the edited English. Unclear words and the captioned EIP-6159 number are marked in brackets. The described client-script proposal matches ERC-5169. No independent audio transcription or listening pass was performed. The recording is authoritative. Product, project and adoption claims reflect August 2023 and are attributed to the speaker. Claims of complete GDPR compliance or wallet anonymity are not established by this interview. An attestation is not automatically a zero-knowledge proof, and tokenization does not eliminate APIs, shared semantics or integration work. The car, Uber and insurance flow is an illustrative scenario, not a verified deployed integration.

Questions this episode answers

He means a token that presents usable functions, beyond an ownership record or tradable asset. At 03:58, his car example combines access to vehicle and insurance services. It is a proposed interaction model. Delivering it requires supporting software, service providers and access controls; ownership alone does not make the services work.
No automatic replacement follows from the interview. At 12:12, Kevin asks why businesses cannot agree on a REST interface. Sweezey points to Smart Layer and TokenScript. That shifts how functions are presented to users, while integrations, shared data meanings and provider cooperation still need to be implemented.
TokenScript is a framework for presenting and using token functions through compatible clients. ERC-5169 is a contract interface that locates associated client scripts through scriptURI. At 13:24, the captions give EIP-6159, but the described mechanism matches ERC-5169. Linking a script and running its interface are different responsibilities.
No. At 09:08, Sweezey describes off-chain data, nonpublic ledgers and email or wallet-pass experiences. TokenScript can include off-chain functions. A client-side interface is different from blockchain execution; the implementation must still define issuance, authentication and access to the underlying services.
No. At 10:04, Sweezey describes an attestation that proves a fact without showing the underlying token. That is the disclosure goal of his example, not a property of every attestation. A yes/no response alone does not establish zero knowledge, unlinkability or protection against metadata correlation.
No. At 07:44 and 09:43, Sweezey makes broad compliance claims. Keeping information off-chain can change the design, but it does not settle the lawfulness or privacy of the whole processing activity. The public-metadata question at 17:53 remains relevant. Assess the actual data flows and parties rather than treating token ownership as certification.

Want this kind of thinking applied to your product?

We build MVPs and act as fractional CTOs for founders who'd rather ship than talk.