# SBT system Analysis Based on ERC3525

By [Ruofan](https://paragraph.com/@ruofan-2) · 2022-11-20

---

Environments
============

Which Blockchain: Polygon

Reason:

*   Cheap gas fee
    
*   Relatively high throughput
    
*   Solidity compatible — developer-friendly
    

Protocols
=========

🐒 ERC721?
----------

Do what mainstream NFT does: develop based on OpenZeppelin standard implementation

[https://github.com/OpenZeppelin](https://github.com/OpenZeppelin)

🤔 ERC 3525?
------------

For detailed information, check out below page:

[https://mirror.xyz/0xA0AFCFD57573C211690aA8c43BeFDfC082680D58/-w3380neddHFU47APGz7o3hzN2zjxhjYhlBRx1cDXiE](https://mirror.xyz/0xA0AFCFD57573C211690aA8c43BeFDfC082680D58/-w3380neddHFU47APGz7o3hzN2zjxhjYhlBRx1cDXiE)

Based on the research, it can realize a value-bounded SBT, which can reflects how many times a ‘Soul’ have contributed to certain types of activities.

For example, as for the report submitting, when a ‘Soul’ firstly submitted a research report, we can issue a new ERC3525 NFT to him/her, with the slot of ‘report-submitting’ type. And after further submitting, we just simply issue some new value this NFT(with **transferValue** method).

With the additional ‘slot’ feature, we can determine a soul’s time of contribution regarding to certain type, and ensure the liquidity to those contribution values(i.e: exchange certain milestone NFTs with certain amount of submitting-report value)

Upgradable Contract
===================

Upgradable contract has the following pros:

*   Fault-torrence to some bug in implementation
    
*   Division of **data storage** & **implementation logic**
    
*   Add downward compatibility features
    

![](https://storage.googleapis.com/papyrus_images/63250075d616243c1ec505e884038eeb459016f07cf00fbb274a9091d0fe7d29.png)

As for implementation, below is a detailed reference:

[https://github.com/AmazingAng/WTF-Solidity/tree/main/47\_Upgrade](https://github.com/AmazingAng/WTF-Solidity/tree/main/47_Upgrade)

Prerequisites for Upgradable Contract will include:

*   **Calldata selector** - As **Proxy** is a static contract, it cannot add more method as the **Upgradable Logic contract** does, it will use fallback method to process all the calling instructions. Therefore, we should use **Calldata selector** to call the functions ‘not exist’ in the Proxy contract
    
*   Some backdoors regarding to using proxy contract(optional)
    

[https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)

It is recommended to use OpenZeppelin’s implementation

[https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/proxy/transparent/TransparentUpgradeableProxy.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/proxy/transparent/TransparentUpgradeableProxy.sol)

Detailed Implementations
========================

1\. Updatable NFT
-----------------

Updatable NFT means NFT’s metadata can change when certain milestones has met. This change is recommended to happen with a change of NFT’s ‘look’(i.e: picture bounded with it). There are many feasible implementations running on chain. A good example of here will be the Organic Crystals:(a crystal coral that can ‘grow’ overtime)

[https://opensea.io/collection/og-crystals](https://opensea.io/collection/og-crystals)

Based on the contract code, it can be inferred the changing of picture is realized by the ‘**setTokenUri**’ method

2\. NFT Lifetime
----------------

A lifetime can help us determine what we need and what we don’t for our application scenario. Regarding to the SBT implementation, we prefer to adopt the ERC3525 protocol to ensure cumulative value associate with an NFT and some liquidity on the value for a direct exchange for certain milestone memorial NFTs. Below is the NFT Lifetime Proposal:

![](https://storage.googleapis.com/papyrus_images/a4022e98bb9740beadff3e06ff846a63d05336166d5f5fbaa62612b3d8fa00c5.png)

*   Create: A soul firstly contributes to a type of activity defined by the community
    
*   Cumulate: A soul **continues** contributing to the same type of activity
    
*   Upgrade: A soul has met some milestone prerequisites
    
*   Value Burnt: A soul exchanges his/her value bounded to the NFT he/she owns for some memorial NFT
    

3\. Modules
-----------

![](https://storage.googleapis.com/papyrus_images/e1b85ffeeff4246093bbbfb74ece1afff742132698223621d076bcc7825dee24.png)

*   **Upgradable Contract for ERC3525 SBT:** core implementation of this project, should effectively check if the ERC3525 implementation is enough for our feature
    

[https://github.com/solv-finance/erc-3525/tree/main/contracts](https://github.com/solv-finance/erc-3525/tree/main/contracts)

*   **Contribution Activity Definations:** should be defined by pd & operators, and developers should translate them to ERC3525 slots, while create, edit is allowed for those configurations
    
*   **Upgradable Conditions: same as Contribution Activity Definations;** one can create and edit these conditions. (View it as CRUD functions on chain).

---

*Originally published on [Ruofan](https://paragraph.com/@ruofan-2/sbt-system-analysis-based-on-erc3525)*