DeFi Anyone Can Confidently Use
Learn about Radix and collect rewards as you journey through Jetty’s quests.
Start Now

Stay updated on the latest Radix news

By clicking “Submit”, you agree to our Privacy policy. We’ll occasionally send you emails about Radix.
Radix Blog Logo
Papers

Papers

White Paper
How Radix is building the future of DeFi

No maths. Read this to learn about how Radix is building the future of DeFi. 30 pages of pure DeFi goodness! - Read now

White Paper
Atomic cross-shard consensus

Math proof by the University of California, Davis - Read now

White Paper
A Breakthrough in Consensus Theory

Learn about Linear Scaling Without Breaking Composability - Read now

Economics
Radix Economics

Same content, less maths, more diagrams - Coming soon

The Radix Tokenomics: XRD and eXRD token details - Read Now

Developers </>
Use Radix
Desktop WalletHardware WalletExplorerInstapassInstabridge
Learn
Knowledge BaseBlogDeFi Download PodcastCareersCommunityEvents
Radix Home
Sign Up For Updates
Blog home
Scrypto & Developers
Product & Roadmap
Tech Blog
Scrypto & Developers
Product & Roadmap
Tech Blog

Scrypto v0.4 is here!

April 27, 2022

Scrypto v0.4 is here, bringing with it our first public test environment for Babylon, a primitive sneak peek of how a website can interact with an on-ledger application, and a shiny new authorization model.  There’s a lot to cover, so let’s jump right in.

Enabling web frontends

Ever since the release of Alexandria, the most commonly asked question by devs has been “How can I connect a website to my Scrypto component?”  With the release of v0.4, we finally have an answer.  It’s rather coarse, employing placeholder versions of tools and libraries which will be greatly improved in the future, but it works!

The system looks something like this:

  • We host a public test environment which runs a copy of the Radix engine simulator and a filesystem-based ledger.  It’s not a network, and there’s no consensus process running.
  • The public test environment exposes a REST API which allows developers to publish code, submit transactions, and perform read requests about ledger state.
  • We offer a Chrome browser extension which behaves like the most basic imaginable wallet.  It can sign transactions and submit them to the test environment.
  • We offer a JavaScript SDK which can assemble transactions and knows how to talk to the browser extension and the REST API.
  • Website developers can import the JavaScript SDK and use it to establish a connection to the browser extension as well as the public test environment.  They can query for information like account balances, build up a transaction from user intent, pass that transaction to the browser extension for signature and submission, and then receive back a result of what happened.

‍

The end-user experience is a far cry from what you can expect later this year, but it gives devs the ability to experiment with building out a critical piece of their dApp - the user interface.  It’s also the first opportunity to compose transactions involving components written and deployed by multiple different people to a shared environment.

With this release, it’s finally possible for devs to come together to build and test the first “mini DeFi ecosystem” on Radix.  Who will be the first?

Solving authorization the right way

Safe, powerful, and easy-to-use authorization is foundational to the success of DeFi, Radix, and Scrypto, and we knew that we needed a greatly improved model from what we initially released in December.

Our biggest design challenge was creating a system that “gets out of the way” so you barely have to think about it 95% of the time, while still allowing complete flexibility for unusual scenarios that require highly complex rulesets.

After months of thinking, tinkering, and listening to feedback from our developer community, we have finally cracked the problem and are releasing the new model.  We can’t wait to see what the creative minds of our community will do with it.

Introducing unified system-level authorization

There are two primary use cases which require robust access control: guarding access to a component method call (e.g., only the owner of this account should be able to withdraw tokens from it), and restricting who is able to manipulate resources in various ways (e.g., minting, burning, changing metadata).  In Scrypto v0.4, the system inherently understands both of these needs, and can “just take care of it” without the user or developer having to be explicit about authorizing these actions each time.

How does it work?  For a particular action (whether method call, or resource action), a developer can set the rules that govern when it is permitted. For example, you might want to specify that “2 of these 3 badges must be present in order to mint more of this token.”  When creating a transaction, required badges can be fetched from wherever they are located (maybe one is in a user’s account, and another is held in some other shared component which in turn needs a different badge to retrieve it), and they are automatically placed in something we call the authorization zone of the transaction worktop.

During a component call from a transaction, the system is always aware of the contents of the authorization zone.  If a called component wants to mint more of a token, it doesn’t have to explicitly specify any badges to do so; it can just attempt the mint action, and the system will determine if the minting rules can be satisfied by the collection of badges present in the authorization zone.

This exact same kind of logic, and same method of specifying the rules, also applies for restricting access to component methods.  If your gumball machine only allows holders of an admin badge to call a collect_coins method to pull the collected money out, that restriction is understood by the system, and callers do not have to explicitly pass in the badge.  If the appropriate admin badge is present in the authorization zone, the call is permitted.  If the badge isn’t present, the system instantly aborts the entire transaction.  Easy peasy.

What are the benefits of the new model?

There are a few big ones!

First and foremost, it allows us to expose the rules to off-ledger tools like wallets in a standard way which they can comprehend.  This enables clear communication to the user on the rules governing methods and resources, and permits clever wallets (like the one we’ll release!) to intrinsically understand whether the user can produce the necessary badges for access, and even present those badges in the transaction automatically.

Second, it’s just easier from a code perspective to not have to be fiddling with the badges directly when doing privileged actions.  You don’t need anything passed in.  You don’t need to specify what is permitting you to perform an action.  You just attempt the action, and it succeeds or aborts as appropriate.  It’s actually harder to explain than it is to use; in practice, it’s all magically delicious.

Finally, this approach means that we can also enable modification of the rules when instantiating a component from a blueprint. Want to use the Radiswap blueprint but have your component restrict the swap method to holders of your membership badge?  No problem.

It’s important to point out that we haven’t lost the primary advantage of our original authorization model: the whole system functions entirely without the need for a concept of “who is calling me.”  The design pattern of access control based upon knowledge of your caller is all but universal in the DLT space, and it’s not a good pattern!  It puts too great a burden on the developer to get it exactly right in a complex system of interoperable smart contracts, and it has led to the loss of hundreds of millions of dollars.  Once a developer gets their first taste of badge-based authorization with Scrypto, there’s no going back.

Details, details, details

Want concrete examples?  Wondering how we prevent authorizing things you didn’t intend?  Curious about how to handle complicated rulesets that require things like branching logic?  There’s a lot of detail we didn’t cover in this summary, so please see the related documentation for the good stuff.

Authorization isn’t the only big change to Scrypto that came with v0.4!  Please see the full release notes if you’re an existing Scrypto developer and want to know why your code suddenly stopped compiling.

Posted by

Russell Harvey
RDX Works CTO

Share this post

Related Articles

Radix Code Audit by Zellic
Foundation Update: A Fork in the Road
Cuttlefish Live on Mainnet
Only on Radix: Real Blockchain Account Deletion

Subscribe to our newsletter

Subscribe to receive the latest Radix updates.
By clicking “Submit”, you agree to our Privacy policy. We’ll occasionally send you emails about Radix.
Discover

Explore more topics

AMA
Community & Ecosystem
Crypto & DeFi
Events
Product & Roadmap
Radix Labs
Radix Report
Scrypto & Developers
Team
Tech Blog
Token
Community & Ecosystem
Token

Token Holder Consultation Is Now Live

May 9, 2025
Community & Ecosystem
Token

Backing Growth: Radix Incentives Campaign Proposal

May 8, 2025
Token
Community & Ecosystem
Crypto & DeFi

Token Holder Consultation: Repurposing the Stablecoin Reserve

May 6, 2025
Community & Ecosystem
Crypto & DeFi
Scrypto & Developers

Radix Code Audit by Zellic

May 2, 2025
Community & Ecosystem

Penrose Findings Overview

April 18, 2025
Token

Unlocking Growth: Proposal to Supercharge Adoption on Radix by Repurposing the Stable Coin Reserve

March 10, 2025
Links
  • BlogRSS
  • PodcastRSS
  • Privacy Notice
  • Careers
  • Radix Brand Pack
Whitepapers
  • DeFi Whitepaper
  • Consensus White Paper
  • Peer Reviewed Consensus Paper
Join the Radix Community
Discord
Facebook
Github
Medium
Reddit
Telegram
Twitter
Youtube
Linkedin
Can’t find what you need? Email us on: hello@radixdlt.com
© Radix Publishing Ltd, 2024. All rights reserved. Radix Publishing Ltd.

By clicking "Allow All", you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. Cookie Policy.

Allow All