This article gives a breakdown of the new features introduced at the contract level, in both testnet and mainnet environments, which will soon also land on the Slice website in the near future.
Controlled slicers, redesigned
It's now possible to appoint a slicer controller and give it one or more special permissions. These include the ability to:
- Mint or burn new slices on demand
- Transfer slices on behalf of owners (owners cannot transfer them autonomously anymore)
- Add currencies accepted by the slicer
- Add new products on sale (basically substitutes superowners role)
Controllers can thus be given control over multiple aspects of a slicer, and by combining them it's possible to accomodate various use cases - like mint slices programmatically with a smart contract, handle payrolls, manage products on the store, and more.
Slicers can accept all currencies
Besides ETH, Slicers can accept any ERC20 as long as the currency is explicitly accepted by the slicer (otherwise withdraws are not allowed). Accepted currencies can generally be added only by the slicer creator or controller.
This constraint is required as additional logic is performed for each currency during slice transfer to ensure that balances are correctly updated and the sender always receives what is due to them. As such, each added currency increases the cost of transfering slices between addresses.
With the latest update, slicers may optionally accept any currency without the need to its creator or controller. This may be useful if slices are not meant to be transferred often or in other similar scenarios, but it's generally unadvised to create such a slicer if it's meant to be owned by several owners as slice transfer cost may get out of hand.
External relative payments, in ETH and ERC20
When adding a new product, it's possible to send ETH to an external address as an additional product-specific split. Until now, it was only possible to send a pre-defined, not variable amount of ETH to said external address.
In Slice 1.1 you can also send:
- A payment relative to the main product price (ie 10%), which may be calculated dynamically
- A payment with the ERC20 token used for the product purchase
Relative and ERC20 payments further increase the flexibility of the protocol when it comes to product sales.
Product price retrieved from external contract
Product can already be priced in any currency either with a fixed amount or one calculated dynamically from USD or ETH. However, there are situations where products may need to be priced following different rules or parameters.
This is why we introduced support for smart contracts inheriting the ISliceProductPrice interface to be used to calculate prices of Slice products.
Dropping something cool for NFT creators very soon. Keep an eye on this feature!
Exemptions to transfer timelocks
Transfer timelocks prevent slicer owners to transfer slices until a certain day (or forever, making a slicer immutable). In some cases though, it may be needed for some addresses (such as smart contracts) to still be able to transfer slices during the locked period.
Addresses can now be exempted from having slice transfers locked during creation.
This was done for a project launching soon called Blunt Finance, which will use both Slice and Juicebox under the hood to manage a new kind of DAO fundraises.
Other
- This update was implemented on all deployed contracts and comes with a number of performance improvements.
- The Slice subgraph has been updated to reflect latest changes, and has some new perks such as purchase IDs. Check out the latest version here
- Sponsors are now retrieved using Alchemy Transfers API. So easy to implement!
- Various bugs, fixes and improvements were done on slice.so. Take the new version out for a spin!
