The first public release of Scrypto happened yesterday as part of the APE presentations in New York. I cloned the latest code drop and immediately jumped into the example code to see if I could quickly spot any changes since the last code drop which was about a month ago. There were indeed!

The first thing that I noticed was that there were a lot more examples. The examples were split into "core" and "defi" directories. The defi examples were very exciting including a number that showed how to clone famous defi apps in rather brief bits of Scrypto code. We will talk about some of those in future blog posts. The core examples included familiar examples like "gumball" and "hello", but there were some new ones too including a couple that employed badges.

Badges are a concept that have been discussed by Radix team members on many occasions over the last year. The idea is to use a token-like resource for the purpose of allowing access to a given capability. On the face of it that doesn't sound very compelling however in my experience creating secure components without badges is very difficult. The last Scrypto test release didn't have them and securing funds in a component (aka smart contract) was a royal pain. You had to build hash tables that kept account addresses available or else create special tokens with a supply of one. All of these options seem awkward in comparison to badges.

The power of badges shines through when you face requirements that call for rather elaborate security logic, But before we go there let's start with a simple case that is implemented in one of the provided examples. The flat_admin code blueprint implements a security scheme where the creator of the component gets a badge to access certain method calls within that component. One of those method calls allows someone with a badge to create another badge of the same type which can be granted to some other trusted account. So now you see the reason that it is called flat_admin. All admins who hold this badge have the exact same privileges as every other badge holder including creating and dispensing more badges.

Now in the real world more complicated access schemes are needed and so issuing a variety of different badges with various types of access authority will likely be the norm. This can get super complicated but with the badge model there is a way to try to keep it as simple as possible by carefully designating which badges have which authority. An account can hold more than one badge of different types and so the authority model can keep all of the access privileges orthogonal.

Now when you use a badge you don't really send it to the contract. Instead a reference to the badge is sent which is sufficient for the contract to tell that you own it. In other words, you are "flashing your badge" and not relinquishing possession of it even temporarily.

Also in the examples is a one called managed_access. This example imports flat_admin and uses it to manage access to a vault of resources held by the component (aka smart contract.) This again shows the power of Scrypto. Security models will be coded as separate blueprints and you will be able to reuse them using one of several different techniques. (We will do deep dives into the techniques for reusing blueprints in future blog posts.)

I am very impressed with the new scrypto release and we will have a lot more to say about it so please follow this blog. You can play with this release yourself as it is in a public repo named radixdlt-scrypto on the radixdlt Github page. If you need help you can join my Rust & Scrypto Forum on discord.

(Photo by Erik Mclean from Pexels)