Why Metaplex Core has the best shot to be THE standard for tokenized assets
As the former CTO of a fractionalized luxury tokenization company, Artsn.fi, the main challenges for our service were the regulatory concerns and the pricing of creating digital assets, that’s because we decided to fully abstract the blockchain aspect of our product which made fees a direct cost for us.
We initially wanted to use NFTs, but they were too expensive, so we opted for semi-fungible Token2022. This allowed us to enforce “permanent ownership” of assets using token extension while only incurring costs for the Token Accounts.
Recently, after joining Metaplex as a Community Developer, I realized how well-suited Core is for the RWA segment. So I decided to migrate our old smart contract to see how it would change, and the results have been quite pleasing…
But before jumping into the improvements, let’s talk about Core.
What is Core?
Metaplex Core (“Core”) is a new standard created specifically for digital assets. By moving away from the standard SPL-Token Program, Metaplex eliminated the complexity and technical debt of the previous standard (Token Metadata), providing a clean and simple interface for digital assets.
This new implementation uses a single account design, significantly reducing minting costs and optimizing network load by streamlining instruction processes. Additionally, it features a flexible plugin system that allows developers to modify the behavior and functionality of assets.
Let’s talk about the biggest improvement
Security
Leveraging the Oracle Plugin, I’ve implemented a complete Circuit Breaker using just 14 bytes of space.
#[account]
pub struct Protocol {
pub validation: OracleValidation,
pub bump: u8,
}
impl Space for Protocol {
const INIT_SPACE: usize = 8 + 5 + 1;
}The Protocol account can now reject any lifecycle action — such as creating, updating, transferring, or burning assets — when its state is updated using the following instruction:
pub fn update_protocol(&mut self) -> Result<()> {
if (self.protocol.validation == OracleValidation::V1 {
create: ExternalValidationResult::Approved,
transfer: ExternalValidationResult::Approved,
burn: ExternalValidationResult::Approved,
update: ExternalValidationResult::Approved
}) {
self.protocol.validation = OracleValidation::V1 {
create: ExternalValidationResult::Rejected,
transfer: ExternalValidationResult::Rejected,
burn: ExternalValidationResult::Rejected,
update: ExternalValidationResult::Rejected
};
} else {
self.protocol.validation = OracleValidation::V1 {
create: ExternalValidationResult::Approved,
transfer: ExternalValidationResult::Approved,
burn: ExternalValidationResult::Approved,
update: ExternalValidationResult::Approved
};
}
Ok(())
}With this setup, if anything strange is picked on by our systems, setting all ExternalValidationResult values to “Reject” will halt all activities related to all digital assets regardless of the program used.
Regulation
The improvement in this area doesn’t rely on the Permanent Plugin, as similar outcomes can be achieved using the PermanentDelegate Extension and Token2022
The real breakthrough comes with the Appdata Plugin.
For startups that tokenize luxury real-world assets, such as watches, and need to ensure regulatory compliance and authenticity, the AppData Plugin allows for a clear separation of legal responsibility from issuance and verification processes.
Using AppData, we can issue digital assets that represent these luxury items and store an external schema containing authentication details. The data_authority is assigned to a trusted third-party firm, which verifies the authenticity of the assets and then records its findings directly into the AppData schema.
Composability, Integrations & Costs
Before migrating, our process for creating a new type of asset was this:
- Create a Watch Account: This account stored all the general data for the watch, such as the reference number, model, brand, …
- Fractionalization: For each new fractionalized instance of a watch, we would select the Watch Account, create a new Mint account copying the relevant data as on-chain attributes, and then create the associated Token Account (ATA) to mint fractions into the buyer’s wallet.
This approach meant that each fractionalized instance of the same watch had a different mint address, even if it was the same watch being fractionalized multiple times.
With the new setup, we streamline the process significantly:
- Create a Collection: All general data for the watch and associated plugins are stored in a collection account.
- Minting Digital Assets: We mint the digital assets directly, linking them with the collection and incorporating the ID of the fractionalized watch in the name to identify the batch.
This method not only reduces costs, as we now use a single collection account for all assets fractionalized from the same watch (eliminating the need for a separate Watch account and Mint account each time), but also the cost of creating a basic digital asset is comparable to creating an ATA, with the asset costing 0.0029 SOL versus the ATA creation cost of 0.002 SOL.
Additionally, the new setup enhances integration with other protocols, such as marketplaces or lending platforms because they no longer need to group multiple mint addresses under the same page; they can simply reference all NFTs under the same collection.
But we can make it even better…
If you still were not convinced by this article that Core is going to be THE standard for RWA, I have good news for you…
The Metaplex team is always looking for new features to ship, and we usually have a bottom-up approach for those. So if you’re working with Digital Assets and want to help us make this THE standard for Digital Assets, let’s keep in touch!
