Regulated Assets are those that mandate the issuer's (or an authorized third party’s, such as a licensed securities exchange) approval for every transaction. Certain regulations require asset issuers to monitor and approve every transaction involving their assets, ensuring specific constraints are met. The Stellar ecosystem, as defined in SEP08 - Regulated Assets, offers an approach that capitalizes on Stellar Classic's capabilities. Drawing inspiration from SEP08 standards, this use case enriches a token contract with an auxiliary asset controller contract, allowing the asset issuer to enforce tailored rules programmatically.
The hosted demo can be accessed at: oififo.com/demos/regulated-asset
SEP08 provides an effective method for creating an Approval Server that evaluates client transactions based on the server's predefined approval criteria. However, these rules operate outside the blockchain. This external operation adds complexity and diminishes transparency for the end user, as the server's code executes off-chain. The advent of Stellar's smart contract platform, Soroban, now offers the opportunity to migrate some of these rules on-chain, ensuring programmable and transparent operations.
Some of the key benefits are:
-
Transparency: With rules executed on-chain, users can have a clear view of the regulations in place, ensuring a more transparent process than off-chain rules.
-
Flexibility: The modular nature of Soroban allows asset issuers to implement a range of custom rules, tailored to the specific requirements of the asset.
-
Security: Leveraging the decentralized and tamper-resistant nature of blockchain, rules and regulations are enforced with greater integrity.
-
Automated Compliance: By moving rules and regulations on-chain, compliance can be automated, reducing manual intervention and the potential for errors.
The current version of this use case showcases several core features, highlighting how Soroban's programmable capabilities can incorporate a range of functionalities into the token.
-
Probation Period: On a user's initial interaction with the regulated asset, either as a sender or a receiver, a probation period begins. This period lasts for a default duration set by the asset issuer. Throughout this period, the asset controller's rules apply to this account. Once the probation ends, the user can engage with the asset as with any standard Soroban token.
-
Outflow Quota: During probation, there's a restriction on the amount an account can send. It must remain below the outflow limit determined by the asset's administrator. This quota resets periodically based on the asset's predefined time span. For instance, if the outflow quota is set at '100' and the reset period at '24h', it implies that an account can dispatch up to 100 units of the asset every 24 hours. Every transaction deducts from the quota, and once depleted, the user must wait for quota renewal before initiating further transactions.
-
Inflow Quota: Analogous to the outflow quota, during probation, there's a cap on the amount an account can receive, defined by the asset administrator. This quota too resets after the asset-specific time period.
Important Both inflow and outflow quotas are managed separatelly.
-
Affiliation(Upcoming): This feature, currently under development, aims to establish specific limits for bi-directional interactions between two accounts.
Follow the steps below to deploy and interact with the Regulated Asset dApp:
soroban-cli v0.9.4
. See https://soroban.stellar.org/docs/getting-started/setup#install-the-soroban-cli
This project is composed of two contracts:
- Regulated Asset: A Soroban token implementation with added capabilities to interact with the asset controller.
- Asset Controller: A Rule-enforcing contract tha defines the constratins to be followed by the asset users.
- In access the
asset-controller
directory, run the commandsoroban contract build
. This will compile the Asset Controller contract and generate the wasm files. - In access the
regulated-asset
directory, run the commandsoroban contract build
. This will compile the Asset Controller contract and generate the wasm files.
- Access the folder
/scripts
. There you'll find a collection of helpers scripts to deploy and test this contract. - Set the parameters under
config.sh
. By default, they come set for testnet with dummy accounts and assets. If this is your first time deploying on testnet, refer to the Deploy on Testnet article as you might need to configure your CLI with the testnet parameters. - Run
init.sh all
to deploy and initialize both contracts according to the defined parameters.
For further details on how to configure and use the helper scripts, refer to ./scripts/README.
One can use the run.sh
helper script to execute the different contract functions. Here below is an example of a user interacting with the contracts.
For further details on how to configure and use the helper scripts, refer to ./scripts/README.
-
The user a send user b 1000 units of the asset.
./run.sh a transfer b 100
-
User a verifies its quota.
./run.sh get ac quota a
-
Admin mints 200 units and sends to user b.
./run.sh admin mint b 200