Skip to content

Service: Smart Dividends ​

The Smart Dividends Service calculates, executes, and records post-closing distributions for tokenized assets. It connects fund performance records with payouts to eligible Investors.

The service supports three distribution models:

  1. Capability A: Periodic Distribution (Batch Model)

    • An administrator-driven process for assets with periodic payouts (e.t., quarterly rent, monthly loan interest). An admin initiates a Distribution event, and the service executes a batch of payout transfers (fiat, crypto, or in-kind) to all investors.
  2. Capability B: Continuous Distribution (Streaming Model)

    • A smart-contract-driven process for assets with continuous yield (e.g., T-bills, MMFs). The smart contract itself is the distribution mechanism, automatically "streaming" new tokens to holders in real-time as yield is generated.
  3. Capability C: Price Appreciation (Growth Model)

    • A smart-contract-driven model where all yield is retained and reinvested within the asset pool. There are no payouts. Instead, the smart contract's internal logic updates a value such as exchangeRate.

The service provides:

  • Automation: Replaces manual spreadsheet calculations with a systematic workflow for calculating and executing pro-rata distributions.

  • Distribution Methods: Supports configured payouts in fiat currency (USD), on-chain stablecoins (USDC), or additional RWA tokens under the "Dividend-Paying Model."

  • Distribution Records: Records each distribution or links it to the corresponding on-chain transaction.

    • (Batch): Generates Payout Line Item records for reporting.

    • (Streaming): Relies on immutable on-chain transactions, visible on any block explorer.

    • (Growth): Relies on a verifiable on-chain exchangeRate or Net Asset Value (NAV) reported by the contract.

  • Integrations: Connects to the Integrated Wallet Solution and evm-api to deliver funds for models A and B or report value for model C.

  • Compliance Checks: Applies the token's configured KYC/AML, jurisdiction, and Investor-type rules to administered payouts. Contract-driven payouts use the rules implemented by the contract.

Core Technical Components & APIs ​

This engine is triggered by administrators and orchestrates payouts by reading from core models and calling execution APIs.

Components for Capability A (Periodic / Batch) ​

  • Primary Models:

    • Distribution Model : The central record for a single payout event (e.g., "Q4 2025 Dividend for Fund X").

    • Payout Line Item : A child record of a Distribution, representing a single investor's calculated share.

    • Fund Model: Read to identify investors and asset terms.

    • Investment Model: Read to determine each investor's pro-rata ownership percentage.

    • Transaction Model: The service uses wallet-api to record fiat payouts. The wallet transaction type vocabulary is deposit, investment, and withdrawal; the business Distribution remains separate, and its exact wallet-record mapping requires the owning payout contract.

    • EVM Transfer Model: Created by this service (via evm-api) to log on-chain crypto payouts.

  • Governing Logic:

    • Distribution Status Lifecycle : Manages the state of a payout event.

    • Pro-rata calculation logic.

  • APIs:

    • distribution-api: Exposed to the Issuer Portal for administrators to create, review, and execute distribution events.

    • investment-api: To fetch the final list of investors and their holdings.

    • wallet-api: To execute fiat payouts to investors' internal Wallets.

    • evm-api: To execute batch on-chain distributions (Stablecoin or In-Kind).

    • notification-api: To send payout alerts to investors.

Components for Capability B (Continuous / Streaming) ​

  • Primary Models:

  • Governing Logic:

    • On-Chain Smart Contract Logic: The distribution logic is embedded in the contract.
  • APIs:

Components for Capability C (Price Appreciation / Growth) ​

  • Primary Models:

  • Governing Logic:

    • On-Chain Smart Contract Logic: The yield-reinvestment logic is embedded in the contract.
  • APIs:

    • evm-api: Used by the Investor Portal to query the contract's current exchangeRate or pricePerShare to display the value of an investor's holdings (e.g., Value = token_balance * exchange_rate).

The Process Lifecycle & Key Capabilities ​

The service's operation is best described by its three distinct process lifecycles.

Capability A: Periodic Distribution (Batch Model) Lifecycle ​

This is an administrator-driven process, perfect for traditional income assets.

  • Phase 1: Event Creation: Admin selects a closed_successfully Offer and initiates a new Distribution event and defines parameters (Total Amount, Payout Type):

    • FIAT (Cash Dividend): To be paid in cash (USD) to investors' Wallets.

    • CRYPTO (Stablecoin Dividend): To be paid in a stablecoin (e.g., USDC) to investors' Crypto Wallets.

    • TOKEN (In-Kind Dividend): To be paid in more of the Fund's own RWA token (as in the "Dividend-Paying Model").

  • Phase 2: Calculation: The service fetches all SUCCESSFULLY_CLOSED Investments for that Fund and their exact number of shares/tokens. The engine calculates each investor's pro-rata share of the total distribution amount and generates Payout Line Items for admin review.

  • Phase 3: Execution: Admin approves. The service loops and calls wallet-api or evm-api to execute each payout:

  • Phase 4: Confirmation: The Distribution is marked COMPLETED. The engine calls the notification-api to send an automated in-app notification and email to all investors confirming they have received a distribution. The new data is made available via API for the Investor Portal's "Distributions" tab.


Capability B: Continuous Distribution (Streaming Model) Lifecycle ​

This is a smart-contract-driven process, configured once at asset creation.

  • Phase 1: Configuration: The RWA Tokenization Engine deploys a specialized "streaming" smart contract.

  • Phase 2: Ongoing Execution: Yield is streamed into the contract treasury. The contract's own logic automatically mints/distributes new tokens to holders in real-time (e.g., "every 10 seconds"). The token price remains stable (e.g., $1.00).

  • Phase 3: Confirmation: Confirmation is simply observing the on-chain state. The Investor Portal calls the evm-api to read the investor's token balance, which visibly increases.


Capability C: Price Appreciation (Growth Model) Lifecycle ​

This is a smart-contract-driven "non-payout" model, configured once at asset creation.

  • Phase 1: Configuration: The RWA Tokenization Engine deploys a specialized "accrual" smart contract.

  • Phase 2: Ongoing Execution: Yield is streamed into the contract treasury. The contract's own logic automatically reinvests this yield. No payouts occur. Instead, the contract's internal exchangeRate or pricePerShare continuously rises. The investor's token balance remains the same.

  • Phase 3: Confirmation: Confirmation is observing the on-chain state. The Investor Portal calls the evm-api to read the contract's current exchange rate.

    • Displayed Value = token_balance * exchange_rate

    • This shows the investor's value growing, even though their token quantity is static.

Exceptions and Model Selection ​

FeatureCapability B: Continuous IncomeCapability A: Periodic IncomeCapability C: Price Appreciation
GoalReal-time, predictable incomeRegular, periodic incomeLong-term capital appreciation
Token PricePegged (e.g., $1.00)Pegged (e.g., $1.00)Increases over time
How You EarnReceive new tokens (streaming)Receive new tokens (in batches)Same tokens become more valuable
On-Chain ActivityContinuous micro-distributionsPeriodic, admin-triggered transfersNo distributions; price math handles accrual
Managed ByThe Smart Contract itselfDistribution & Payout ServiceThe Smart Contract itself
Typical AssetT-Bills, MMFs, Liquid YieldReal Estate, Private Credit, FundsVenture Capital, Art, Accrual Funds
  • Capital Repayments: The Periodic Distribution (Batch Model) can manage returns of capital, such as loan maturity or asset-sale proceeds, as well as returns on capital.

  • Partial Failures: If a single payout fails (e.g., an on-chain transaction runs out of gas), the engine must mark that Payout Line Item as FAILED but continue processing the batch. The main Distribution record will be marked PARTIALLY_COMPLETED, and an alert will be created for an administrator to resolve.

  • Tax Reporting Support: All distribution records and transactions are structured to support the generation of tax documents based on the payout type.