Roles

SFT tokens have roles, each with its own admin. Admins manage permissions for their roles.

The Super Admin role

When a new CertifiedAssetConnect contract is deployed, an initial admin can be set that is the admin for every role. Initially there are no executors. It is strongly recommended that the initial admin delegates each of the admin roles to more appropriate addresses and renounces its "superadmin" powers as soon as possible.

The Admin Role

An admin of a role appoints/revokes executors and other admins, including themselves. This means that any admin can unilaterally and permanently remove all other admins, or even all admins entirely for their role. Clearly the private keys for admin roles must be handled very securely such as an M of N multisignature setup or even a formal governance contract that can only action the results of onchain voting.

E.g.

DEPOSITOR_ADMIN
WITHDRAWER_ADMIN
CERTIFIER_ADMIN
HANDLER_ADMIN
ERC20TIERER_ADMIN
ERC1155TIERER_ADMIN
ERC20SNAPSHOTTER_ADMIN
CONFISCATOR_ADMIN

The Executor role

The executor of a role merely executes the day to day operations associated with that role. Connectors connect, certifiers certify, etc. There can be many executors assigned to any role, as set by the role admin(s). Executors generally share responsibility over their task, a single rogue connector can poison the contract with forgeries, a single rogue certifier can freeze the system, etc. As it is entirely possible to achieve M of N control over private keys, this is expected to be achieved outside the logic of the contract. A single executor key may represent a group of many off-chain entities. An executor may also be a formal governance contract enforcing arbitrary workflows for actions.

Information is onchain

All the role admins and executors, as well as the configuration that they set is all public information onchain. This allows token holders to always review for themselves how centralised or decentralised a given CertifiedAssetConnect contract is.

Depositor

Connectors "connect" off-chain assets to onchain tokens. I.e. They mint matching 1155 NFTs and ERC20 tokens.

There is a single connect function on the contract that takes an amount of 1155/20 to mint and some data that feeds into audit reports for certifiers to review. Most likely the data would be something like an IPFS hash that can be fetched and processed by scripts rather than literal audit data.

For example, say a connector was minting a barrel of whiskey in a warehouse. The data about the barrel could contain all kinds of information relevant to an audit, but only the LPA (litres of pure alcohol) amount would be used to mint the 1155/20 tokens.

Typically a connector would also be a disconnector but it is not required.

Withdrawer

The opposite of a connector. They "disconnect" off-chain assets by burning onchain assets.

The disconnector must hold both the NFT and enough ERC20 tokens to cover the full amount associated with the NFT in order to complete the burn. This guarantees that the aggregate amounts across all NFTs and issued ERC20 tokens are 1:1 at all times.

Disconnecting an asset is permanent/irreversible but a connector can always reconnect a previously disconnected asset with a new amount and associated audit data. In this way connected assets cannot be changed but they can be burned and re-minted with updated information prior to audit.

Partial disconnections are disallowed so it is recommended to connect assets in the size and configurations that they are typically acquired and disposed of. For example, a real estate fund would be better served connecting/disconnecting houses than entire suburbs.

Typically a disconnector would also be a connector but it is not required.

Certifier

The certifier can call the certify function to either extend or override the current certification period. By default a new certification will only maintain or increase the current certification expiry date, but a certifier may pass an additional parameter to force a specific (potentially shorter or even past) date.

Certifiers are expected to pass in additional data to reference an audit report that justifies their certification.

An audit process would typically look like:

• The certifier runs a script to extract auditable information from the blockchain logs for all connects and disconnects
• The certifier performs a real world audit of the offchain assets against the extract
• The result of the audit is posted onchain with the certify function

Multiple parallel audits are supported as each certifier can submit their own reports without interfering with each other's logs (with the exception of the forced expiry override described above).

If the certification ever expires then all assets are immediately frozen for all participants except handlers. This includes a freeze on connecting and disconnecting and for all admins!

Typically a certifier is only a certifier. They should be an "arms length" participant that can be trusted to be impartial. An impartial entity probably should not hold assets or other privileged roles as this could be seen as a conflict of interest.

Handler

Handlers are the only accounts that can send and receive either the NFT or ERC20 tokens in the event of a system freeze due to lapse in certification.

A handler need not be appointed immediately or ideally ever. In the case that the audit process breaks down and the certification cannot be granted the certifier should provide a remediation plan. The remediation plan should list a minimal set of actions that a handler can take to restore the system to a certifiable state as quickly and directly as possible.

The handler can be either a nominated EOA (externally owned account) or a smart contract. The latter could be more trustworthy as it is purely rules based, but the former may be more practical in a time sensitive situation.

It may be required that the handler is also appointed as a connector and/or disconnector to repair discrepancies in the onchain and off-chain overall asset supply.

Once the system is repaired and certified the handler role should be revoked/renounced.

Tierer

Tierers can define (or remove) standard Rain protocol ITier restrictions on transfers for both the NFT and associated ERC20.

ITier is an interface that allows for up to 8 membership levels (e.g. bronze, silver, gold, etc.) to be assigned efficiently to any address.

One common use case for custodial assets is to handle regulatory requirements such as KYC/AML restrictions. Rain protocol provides a standard Verify contract that is backend-agnostic to allow KYC/AML approvals to feed into ITier contracts.

ITier can also function as a "block list" rather than an "approve list" for more decentralised asset management. For example, USDC adopts this model, allowing all addresses to transfer by default and freezing only accounts explicitly flagged by law enforcement.

If a user already holds tokens and is removed from the requisite tier, either because they lost the tier or the tier contract itself changed, then they can send but not receive tokens.

Tierers do not themselves define the users who can interact with the tokens, rather they define the contracts that do implement access restrictions, and the minimum tier that must be held for access.

A highly centralised system can tightly control and even change their tiering logic over time. A more decentralised system can set up tiering and then renounce the admins, or even completely remove tier restrictions.

ERC20TIERER
ERC1155TIERER
ERC20SNAPSHOTTER

Confiscator

As all offchain assets have some custodian there will be some regulatory environment that the custodian operates within. Typically this implies the possibility of legal actions such as sanctions being placed on token holders. Under extreme circumstances it may not be enough to simply freeze assets by removing the holder from the relevant tier contract. In some cases the assets may need to be confiscated from the token holder then somehow processed (e.g. burned, set aside or redistributed) by the custodian.

There is a confiscator role that can forcibly take frozen tokens, both the ERC20 and ERC1155. This is obviously a highly sensitive role and action so confiscators cannot forcibly take tokens from unfrozen assets. This provides some protection against some malicious actor compromising the confiscator and arbitrarily stealing assets from users. First some attacker must compromise the tier handling before they could manipulate the confiscation process. Ideally the real world entities managing the confiscation and tiering are independent and arms length for maximum security. If there is no tier contract set then the confiscator is free to confiscate any asset from any address, so this is potentially a less secure configuration.

Confiscation is a simple transfer, the confiscator calls the relevant function on the smart contract and the assets are transferred to themselves. Confiscation bypasses normal transfer access requirements so confiscations are still possible during a failed audit. The best defence against a rogue confiscator is a well maintained tier contract.

Questions

I am admin for depositor, do i still need to set myself as deposoitor? admin only allows you to set depositors instead of being one?

Yes, they need to have depositor role to mint. and being admin of depositor is not enough.