Milestones
  • 13 Nov 2023
  • 2 Minutes to read
  • Dark
    Light
  • PDF

Milestones

  • Dark
    Light
  • PDF

Article summary

Milestones are big ticket items which require significant work and often have complex dependencies and/or impact upon other parts of the stack.

Items on this page are ordered in expected delivery sequence. However, just because a milestone is lower on the list doesn't mean that work isn't progressing on it. Foundational work for future milestones in the form of research, design, prototyping, or dependency implementation proceeds in parallel with progress on the current milestone.

Documentation & Examples

A lot of what Scrypto and Babylon can already do isn't known because it simply hasn't been well documented yet.  Additionally, the learning journey for a new developer coming to the system doesn't have clear paths based on what they want to do, and lacks a good "guided tour" that takes builders from the basics up through full application deployment and configuration in a step-by-step fashion.  This effort will address both of those shortcomings.

Allowances

The primary authorization pattern of Radix is based around the use of badges to demonstrate the ability that an actor is permitted to perform a certain action. To avoid abuse and unintended privilege escalation, badges can not be "re-used" by anything except what the actor is explicitly presenting them to. However, there are certain scenarios under which it makes sense for an actor to enable a particular action within a transaction, without caring to know who actually performs the action.  This will be supported by the creation of allowances, which are limited-use badges usable by anything within the transaction.

For example, if a creator of an NFT wants to charge an amount every time someone wishes to transfer one of their tokens, they can set the withdrawal rules of their non-fungible resource to require a particular badge to be present in order to withdraw. They can then place the badge permitting the withdrawal into a component which charges 10 ZOMBO to produce an allowance which permits a single withdrawal of a single token. In order to transfer the NFT, the user's transaction must pass the component 10 ZOMBO in order to then be able to withdraw it and send it on to someone else.

Nested/Grouped NFTs

Enable the ability for NFTs to contain other NFTs, or be linked such that they travel together. This enables an enormous host of interesting use cases, but requires careful design to avoid undesirable use patterns (for example, avoiding the ability to circumvent withdrawal rules by placing a restricted NFT into an unrestricted "container" NFT). Design thinking will be shared with the community for feedback as it develops.

Upgradeable Blueprints

Upgradability of smart contracts has been a thorny problem since the dawn of Ethereum, and this milestone is about enabling upgradability which allows creators to select what level of upgradability they desire, while informing potential consumers about what things the creator has the ability to change. To avoid any chance of unwelcome surprises for consumers, this work will not result in already-deployed blueprints and components becoming retroactively upgradeable.


Was this article helpful?

What's Next