DEV Community: Fred Kyung-jin Rezeau

Litemint: Embracing Stellar Protocol 20 and Soroban Smart Contracts

Fred Kyung-jin Rezeau — Tue, 20 Feb 2024 17:23:15 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1759989655280463933-376'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1759989655280463933&theme=dark" }

As the Stellar network embraces a new era with Protocol 20 and Soroban smart contracts, we at Litemint are set to leverage these advancements fully.

$ soroban contract deploy --network mainnet

In sync with Stellar's phased rollout—starting with limited Soroban transaction capacity—we are committing to a parallel strategy for our deployment.

During Phase 1, we aim to test and monitor our auction and royalty smart contracts on mainnet, prioritizing security, network stability, and fee optimization.

With the network moving towards full capacity in Phase 2, we are releasing the new Litemint marketplace and wallet app.

New Litemint App: Zero blockchain babble

Zero blockchain babble is the motto for our new app release, (check out our video on X to see it in action).

Similar to how gamers aren't required to know the game engines powering their favorite titles, our end-users should be able to focus solely on their immersive experience. We recognize that making the underlying technology invisible is crucial to Web3 adoption—and we have achieved just that.

Features designed to ensure a frictionless user journey include:

Passwordless sign-ups and non-custodial wallet creation.
Instant Usability. Craft. Sell. Collect.
Mobile-first, state-of-the-art user interface.
Fully integrated wallet with blockchain abstraction.

The Litemint app will be available on Android, iOS, Windows, Mac, and as a WebApp.

Royalty Smart Contract

Our Royalty smart contract implements multiple royalty payment schemes for non-fungible tokens, including fixed, subscription, and percentage-based models.

A key feature is its ability to enforce royalty payments without isolating NFTs from the Stellar DEX, ensuring full access to the liquidity layer. Our approach ensures that NFT creators and collectors can freely hold and trade their NFTs from any Stellar DEX compatible service, enjoying an unrestricted sales funnel.

Read the full technical article here.

Source code

Auction Smart Contract

Our contract implements timed auctions with support for both open and sealed bid auctions, ascending and descending price mechanisms with linear or compound discount, customizable frequency/rate, buy now option, concurrent and cancellable bids, configurable marketplace commission rate, extendable auctions, easy behaviors plugin via strategy design pattern.

Read the full technical article here.

Source code

Let's Go!

As the Stellar network takes a significant step forward with Protocol 20, Litemint is ready to embrace the new possibilities that Soroban smart contracts bring.

Litemint.io new season is also set to start once our new platform and apps are deployed during phase 2. Keep posted for news on a new epic tournament and make sure you follow us on X for live discussions like this one.

// Detect dark theme var iframe = document.getElementById('tweet-1761691245641183653-69'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1761691245641183653&theme=dark" }

We are fully committed to unlocking new horizons for creators, collectors, and gamers paving the way for unparalleled innovation in the creative economy.

If you have any questions, don't hesitate to reach out. I'm usually active on X @FredericRezeau and Discord where you can find me in the Litemint, Stellar Global and Stellar Developers servers!

Feel free to reach out on GitHub too.

Royalties with Soroban Smart Contracts: An Interoperable On-Chain Solution

Fred Kyung-jin Rezeau — Fri, 29 Dec 2023 17:19:39 +0000

Returning for the second article in our series, this time we are tackling royalties and on-chain payment enforcements.

Royalties play a pivotal role in digital economies, yet the web3 industry still faces many challenges in implementing decentralized royalty payments.

Two key issues stand out:

Centralized control: Echoing Web2, NFT marketplaces maintain significant control over royalty payments. The issues arising from optional royalties (EIP-2981) were discussed during our session on the Future of NFT at Meridian 2022 in Rome—far-reaching implications for both builders and creators and still a lot of work needed here.
Narrowed markets: Specialized smart contract solutions, while being decentralized, often constrict sales and cross-chain bridging opportunities for creators and collectors—also impacting the perception of asset ownership. A prime example is OpenSea's recent decision to discontinue their on-chain Operator Filter. Their blog article provides very insightful details into this issue.

In this article, I present a decentralized solution for enforcing royalty payments, simultaneously ensuring that creators and collectors can openly trade their NFTs—anywhere they want (as this series progresses, we'll explore bridging with Soroban in detail).

Leveraging the first-class citizen assets model of Stellar and Soroban smart contracts, this solution is being integrated into Litemint (source on Github).

How It Works

At its core, the system models an on-chain security interest framework, where a Non-Fungible Token (NFT) is the collateral.

Effectively abstracting the NFT property from the royalty payment process, this approach offers two significant advantages:

Open and Interoperable: The royalty smart contract does not need to take custody of or even interact with the NFT asset. This decoupling allows for complete freedom in issuance and transfer (i.e., eliminating the need for authorization flags). Seamless NFT compatibility with all SDEX-based services is maintained.
Decentralized and Unobtrusive: The process for reclaiming ownership is managed autonomously by the smart contract. This setup provides collectors with a transparent guarantee of ownership, provided their royalty payment obligations are fulfilled. Notably, collecting royalties does not require control over the trade execution of NFTs.

Here's a diagram of the process:

As illustrated above, a repossession lien token is issued to the royalty smart contract. The smart contract is designed to transfer the lien to the NFT creator exclusively when royalty payment obligations are not met. The creator can then execute a lien-dependent pre-authorized transaction to reclaim ownership of the asset.

💡 Tip: Although several strategies can be implemented with recovery depending on specific use cases (from an account_merge operation to a less destructive re-issuance), it should be executed atomically with a pre-auth transaction for predictability.

Understanding Stellar NFTs

Although Stellar provides recommendations, there is no NFT standard on Stellar. This brings to mind the question posed by Mara Bos, Rust team lead, about the necessity of a Rust standard—…Do we need one?.

In the tech world, late arrivals frequently improve upon existing models—they bring effective solutions that simply work. And just like Rust, I see Soroban and Stellar as perfect examples of this.

Contrasting with account-based ledger models like Ethereum, Stellar treats all assets, both native and user-defined, as first-class abstractions. This includes NFTs, as we can model non-fungibility through asset properties, eliminating the need for smart contract-based issuance or separate asset classes.

As illustrated below, on Stellar an NFT is just a regular asset with a single stroop supply amount and no signers. They have similar access to the interoperability layer, including the Layer 1 decentralized exchange (SDEX), cross-currency payments, liquidity pools, and are de facto compatible with any Stellar wallet.

In this ecosystem, using Soroban smart contracts for NFT issuance or trading isn't a prerequisite—thereby avoiding the complexities mentioned previously.

Instead, smart contracts can be effectively leveraged to implement and enforce creators attached royalty terms, coupled with a transparent and decentralized ownership recovery process.

With great ownership comes great responsibility

In the Stellar Ecosystem, as outlined in SEP-1, the conditions field under [CURRENCIES] already serves to communicate specific asset conditions for holders. Royalty NFTs can readily take advantage of this field. We are also introducing accessible tools to assist collectors and buyers in managing their obligations, getting notifications for subscriptions and more.

Getting the Code on GitHub

The code for the Litemint royalty smart contract is located in this GitHub repo (MIT License).

Besides providing an implementation of the system described above, the smart contract also provides the following features:

Percentage-based royalty payments (see compensation_percentage.rs).
Fixed royalty payments (see compensation_fixed.rs).
Subscription royalty payments (see compensation_subscription.rs).
Support for all currencies and markets.
Optional NFT transfer fee.
Configurable grace period and marketplace commission rate.

💡 Tip: The compensation scheme implementation uses the strategy design pattern so you can easily add new ones to fit your requirements.

Go ahead and clone the repository. Then, execute the following command to compile the contract:

$ soroban contract build

Deployment and Configuration

We assume that the following network and identity are pre-configured (soroban config) and funded. Follow this link if you need instructions.

Type	Name	Description
Network	`TESTNET`	Stellar Testnet
Account	`ADMIN`	Contract admin

To deploy the royalty contract, use the following command:

$ soroban contract deploy \
--wasm target/wasm32-unknown-unknown/release/litemint_royalty_contract.wasm \
--source ADMIN --network TESTNET > ID

Configure the ADMIN. Additionally, the marketplace commission rate is set to 2% with this command:

$ soroban contract invoke --id $(cat ID) \
--source ADMIN --network TESTNET \
-- initialize --admin ADMIN \
--commission_rate 2

Further Interaction

Until now in this series, we used the Soroban CLI to interact with contracts. However, for practical applications, you will likely need to interact via the stellar-sdk within your own app, especially if you need to interact with accounts and assets on the Stellar blockchain.

To get you started, the following gist offers a sample script for interacting with the royalty smart contract. It invokes the add_property method, passing a Terms object that lets you define the NFT and various settings like compensation scheme (fixed, percentage, subscription), grace period, and transfer fees. It also shows how to execute the contract and retrieve the updated License state.

Don't hesitate to explore further! You can also access the oracle subscriber interface. Indeed, the Litemint royalty contract gets market price feeds via oracles on Soroban!

Wrapping Up

Two years back, I wrote this article NFT Ownership During The Apocalypse discussing how, with the right approach, NFT ownership can remain verifiable—even if Litemint or Stellar disappear!

Likewise, NFT royalty payments should also work, sans intermediaries, for years to come. Web3 is all about creating a more open, fairer, less centralized environment, empowering creators to set their own rules for distributing their works.

That's a lot of challenges ahead. However, technologies like Soroban smart contracts provide opportunities to tackle them.

I hope you found this enjoyable! Stay tuned for more detailed tutorials showcasing the full range of soroban-kit features!

If you have any questions, don't hesitate to reach out. I'm usually active on X @FredericRezeau and Discord where you can find me in the Litemint, Stellar Global and Stellar Developers servers!

Feel free to reach out on GitHub too.

Happy coding!

Oracles with Soroban Smart Contracts: A Practical and Flexible On-Chain Framework

Fred Kyung-jin Rezeau — Fri, 22 Dec 2023 16:25:55 +0000

The latest release of soroban-kit 0.1.8 is now available, and it brings a set of tools designed to streamline both synchronous and asynchronous cross-contract communication, particularly for building more robust oracle systems with soroban—exciting topic for my first post on dev.to!

In this article, I'm going to walk you through the new soroban-kit::oracle module step-by-step. You will learn how to build a flexible and extensible oracle system leveraging the pub/sub pattern for asynchronous communication between multiple on-chain oracle subscribers and brokers.

We are implementing this system for our Soroban-powered smart contracts on Litemint, specifically for feeding royalty contracts with market prices.

How It Works

soroban-kit 0.1.8 introduces two procedural attribute macros, oracle_broker and oracle_subscriber.

Applying these macros to your contract struct automatically generates a lightweight messaging framework that enables both synchronous and asynchronous cross-contract communication, as demonstrated in the following diagram:

By leveraging the publisher-subscriber pattern, we can enable multiplicity between oracle subscribers, brokers and publishers. Not only this enhances deployment flexibility but also allows for a gradual increase in system resilience and robustness—mitigating the risks associated with reliance on a single point.

The best part is, setting up your contracts for this requires only a single line of code, all thanks to Rust's sophisticated macro system. For those curious about the inner workings and mechanics, take a look at oracle.rs.

💡 Tip: Alternatively, you can run cargo expand command to view the expanded code generated by the macros.

// Implement the oracle broker interface for your contract.
#[contract]
#[oracle_broker(Bytes, Bytes)]
pub struct OracleBrokerContract;

// Implement the oracle subscriber interface for your contract.
#[contract]
#[oracle_subscriber(Bytes, Bytes)]
pub struct OracleSubscriberContract;

These macros also allow you to customize the types for both the topic and the data. We use Bytes in this example but any built-in type and user-defined type is supported, Soroban transparently provides for all our serialization needs!

After setting it up, all that's required is to implement the soroban-kit::oracle::Events trait to manage and process the workflow.

Let's go!

Getting the Code on Github

The code for the example oracle project is located in this GitHub repo.

It consists of 2 smart contracts:

Oracle Broker Contract (see lib.rs)
- Handling sync/async topic-based subscriber requests.
- Handling publishing requests.
- Collecting subscriber fees.
- Managing envelopes for async routing.
- Managing publishers whitelist.
Oracle Subscriber Contract (see lib.rs)
- Routing topic-based data requests to broker contract.
- Handling sync/async responses.
- Managing brokers whitelist.
- Providing data reconciliation.

Note that our example data reconciliation function simply replaces the old data with the new but more elaborate mechanisms can be implemented, including price aggregation, average computation, validation and coalescing of results, based on specific use cases.

First, clone the repository. Then, execute the following command to compile the contracts:

$ soroban contract build

Once compiled, you'll find two oracle contracts ready to deploy in the target directory.

💡 Tip: While they are already compact, using the optimization command (soroban contract optimize) can shrink their sizes even more (to less than 3.5K for the broker contract and 2.5K for the subscriber one):

$ ls -lh broker.optimized.wasm subscriber.optimized.wasm
-rwxrwxrwx 1 3.4K Dec 22 22:29 broker.optimized.wasm
-rwxrwxrwx 1 2.5K Dec 22 22:29 subscriber.optimized.wasm

Step-by-Step Deployment and Setup

For our scenario below, we will need 2 subscribers and 2 brokers.

Remember, you always have the option to deploy additional nodes at any time. soroban-kit::oracle ensures consistency for communication with decoupled, events-driven, interactions between your contracts (as long as the types are consistent, they can communicate).

We assume that the following network and identities are pre-configured (soroban config) and funded. Follow this link if you need instructions.

Type	Name	Description
Network	`TESTNET`	Stellar Testnet
Account	`ADMIN`	Contracts admin
Account	`ALICE`	Subscriber operator
Account	`BOB`	Publisher

To deploy the oracle broker contracts and simultaneously save their IDs, use the following commands:

$ soroban contract deploy \
--wasm target/wasm32-unknown-unknown/release/broker.wasm \
--source ADMIN --network TESTNET > BROKER1

$ soroban contract deploy \
--wasm target/wasm32-unknown-unknown/release/broker.wasm \
--source ADMIN --network TESTNET > BROKER2

Do the same for the oracle subscriber contracts:

$ soroban contract deploy \
--wasm target/wasm32-unknown-unknown/release/subscriber.wasm \
--source ADMIN --network TESTNET > SUBSCRIBER1

$ soroban contract deploy \
--wasm target/wasm32-unknown-unknown/release/subscriber.wasm \
--source ADMIN --network TESTNET > SUBSCRIBER2

Setup the ADMIN for all contracts:

$ soroban contract invoke --id $(cat BROKER1) \
--source ADMIN --network TESTNET -- set_admin --admin ADMIN

$ soroban contract invoke --id $(cat BROKER2) \
--source ADMIN --network TESTNET -- set_admin --admin ADMIN

$ soroban contract invoke --id $(cat SUBSCRIBER1) \
--source ADMIN --network TESTNET -- set_admin --admin ADMIN

$ soroban contract invoke --id $(cat SUBSCRIBER2) \
--source ADMIN --network TESTNET -- set_admin --admin ADMIN

Whitelist the publisher (BOB) for both oracle brokers:

$ soroban contract invoke --id $(cat BROKER1) \
--source ADMIN --network TESTNET -- allow_publisher --publisher BOB

$ soroban contract invoke --id $(cat BROKER2) \
--source ADMIN --network TESTNET -- allow_publisher --publisher BOB

Whitelist the brokers (BROKER1 and BROKER2) for both oracle subscribers:

$ soroban contract invoke --id $(cat SUBSCRIBER1) \
--source ADMIN --network TESTNET -- allow_broker --broker $(cat BROKER1)

$ soroban contract invoke --id $(cat SUBSCRIBER2) \
--source ADMIN --network TESTNET -- allow_broker --broker $(cat BROKER1)

$ soroban contract invoke --id $(cat SUBSCRIBER1) \
--source ADMIN --network TESTNET -- allow_broker --broker $(cat BROKER2)

$ soroban contract invoke --id $(cat SUBSCRIBER2) \
--source ADMIN --network TESTNET -- allow_broker --broker $(cat BROKER2)

Executing a Test Scenario

Everything is now ready! ALICE is initiating data requests for Topic 21 through SUBSCRIBER1 and SUBSCRIBER2 to both BROKER1 and BROKER2.

Here's a deployment diagram to provide a clearer visual representation of the setup:

Here are the commands to do so:

$ soroban contract invoke --id $(cat SUBSCRIBER1) \
--source ALICE --network TESTNET -- request \
--subscriber ALICE --topic 21 --broker $(cat BROKER1)

> null

$ soroban contract invoke --id $(cat SUBSCRIBER2) \
--source ALICE --network TESTNET -- request \
--subscriber ALICE --topic 21 --broker $(cat BROKER1)

> null

$ soroban contract invoke --id $(cat SUBSCRIBER1) \
--source ALICE --network TESTNET -- request \
--subscriber ALICE --topic 21 --broker $(cat BROKER2)

> null

$ soroban contract invoke --id $(cat SUBSCRIBER2) \
--source ALICE --network TESTNET -- request \
--subscriber ALICE --topic 21 --broker $(cat BROKER2)

> null

BOB is setup to publish data exclusively to BROKER2, and note that BROKER1 will not receive this data. Here's the command:

soroban contract invoke --id $(cat BROKER2) \
--source BOB --network TESTNET -- publish --topic 21 \
--publisher BOB --data 21000000

Because both subscribers were connected to BROKER2, they have received and can now serve the data synchronously. Here are some example commands:

$ soroban contract invoke --id $(cat SUBSCRIBER1) \
--source ADMIN --network TESTNET -- get_data --topic 21

> 21000000

$ soroban contract invoke --id $(cat SUBSCRIBER2) \
--source ADMIN --network TESTNET -- get_data --topic 21

> 21000000

Conclusion

Oracles serve as bridges between blockchains and external data sources. There are many key challenges in implementing Oracle services, including decentralization, synchronicity, decoupling and multiplicity.

soroban-kit proposes a lightweight solution for implementing the pub/sub messaging pattern to help address these challenges for cross-contract communication. Allowing you to deploy nodes gradually to achieve resilience and robustness for your oracle system.

I hope you found this enjoyable! Stay tuned for more detailed tutorials showcasing the full range of soroban-kit features!

If you have any questions, don't hesitate to reach out. I'm usually active on X @FredericRezeau and Discord where you can find me in the Litemint, Stellar Global and Stellar Developers servers!

Feel free to reach out on GitHub too.

Happy coding!