# Spark Docs ## Beware of scams and fake accounts Beware of fake social media accounts and websites that mimic Spark products or services to steal user funds. Always ensure you are only using the official Spark products on the official domains. The legitimate Spark domains are: * [%%SPARK\_FI\_URL%%](https://spark.fi) * [%%SPARK\_FINANCE\_URL%%](https://spark.finance) Any subdomain based on the above domains will also be legitimate. Learn more about our ongoing domain migration [here](/domain-migration). Beware of the following: * Domains that look similar but are not **exactly** the same, it can be a single character or different top-level domain (.com, .net, .scam) * Clickable domains on social media, these can look legitimate on the platform, such as X, but once clicked the user is redirected to a different domain. * People who contact you via social media, including X, Telegram and LinkedIn claiming to be a contributor of Spark. Always verify their identity by asking on the public discord or with someone that you trust. * Websites without https (http does not provide encryption nor verification) * Any website asking you for your seed passphrase (you should not share this with anyone) * Spark does not advertise on social media (e.g. tweets with "Ad" on the top right), on websites or search engines. ## Domain Migration Spark is migrating its web domain from %%SPARK\_FI\_DOMAIN%% to %%SPARK\_FINANCE\_DOMAIN%%. ### Both domains are live today %%SPARK\_FI\_DOMAIN%% and %%SPARK\_FINANCE\_DOMAIN%% are both legitimate, fully functional domains that serve the same Spark products. For example, [%%APP\_SPARK\_FI\_DOMAIN%%](https://app.spark.fi) and [%%APP\_SPARK\_FINANCE\_DOMAIN%%](https://app.spark.finance) both give you access to the same app. Any subdomain of either domain is official. ### What's changing Over time, %%SPARK\_FINANCE\_DOMAIN%% will become Spark's primary domain. %%SPARK\_FI\_DOMAIN%% remains fully supported for the duration of the migration, so you can continue using either domain. ### Staying safe Only %%SPARK\_FI\_DOMAIN%%, %%SPARK\_FINANCE\_DOMAIN%%, and their subdomains are official Spark domains. Any other domain claiming to be Spark is not legitimate. For more on avoiding scams, see [Beware of scams and fake accounts](/beware-of-scams). ## FAQ For product-specific questions, see the FAQ on each product page: * [Spark Savings FAQ](/products/spark-savings#faq) * [SparkLend FAQ](/products/sparklend#faq) * [Spark Liquidity Layer FAQ](/products/spark-liquidity-layer#faq) ### What is Spark? Spark consists of three main products: * **[Savings](/products/spark-savings)**: Earn yield on your stablecoin and ETH holdings via Spark Savings vaults. * **[SparkLend](/products/sparklend)**: A USDS-centric money market protocol, combining liquidity directly from Sky with vertical integrations across DeFi. * **[Spark Liquidity Layer (SLL)](/products/spark-liquidity-layer)**: Direct liquidity provision into DeFi markets across networks. ### What is Spark's Mission? Spark was created to solve a structural problem that has existed since the inception of DeFi: fragmented liquidity, unstable yields, and idle stablecoin capital left underutilized across chains and protocols. Despite years of growth, this issue remained unsolved. Spark operates as a two-sided capital allocator. On the ecosystem side, it borrows from Sky's stablecoin reserves and deploys capital across DeFi, CeFi, and RWAs. This provides deep, consistent liquidity while earning risk-adjusted yield at scale. On the user side, Spark packages that yield into accessible products like Spark Savings vaults (sUSDS, spUSDC, spUSDT, spETH, and more), giving users seamless access to onchain, programmable income that is diversified, fee-free, and composable. Rather than competing with other protocols, Spark powers them. It's not just another DeFi app, it is the core liquidity and yield infrastructure layer for onchain finance. ### What is the Spark Sky Star? Spark is a Sky Star, a part of the Sky Ecosystem. [You can read more about Sky Stars here.](https://forum.skyeco.com/t/sky-has-arrived/24959/14) Spark.fi is a front-end that gives access to the products offered by the Spark Sky Star. ## Getting Started ### Accessing Spark App The Spark App can be accessed at: * [%%APP\_DOMAIN%%](https://app.spark.fi) To enter the site, you must accept the [Terms of Service](https://spark.fi/terms-of-use). ### Application Overview The Spark App consists of four main sections - click on a section title for specific tutorials: 1. [**Savings**](/products/spark-savings/guides/) - The landing page of the application hosts Savings. Savings enables you to earn savings on your assets using Spark Savings Vaults. 2. **Borrow** - Contains three SparkLend sections: 1. [**Borrow stablecoins**](/products/sparklend/guides/borrow-stablecoins), which enables you to borrow supported stablecoins using crypto assets as collateral. This section is focused on stablecoin borrowing only. 2. [**My Portfolio**](/products/sparklend/guides/borrowing-assets) - Shows the state of your borrow and lending position. Here you can also manage lending and borrow positions of any supported asset. 3. [**Markets**](/products/sparklend/guides/overview-of-markets) **-** gives an overview of the total state of the supported lending markets, such as total liquidity and total borrows. Offers detailed information for each market, and the option to enter the markets. 3. **SPK** - Contains three sections: 1. [**Staking**](/staking/) - Enables users to stake SPK tokens to earn rewards. 2. [**Farm**](/user-guides/farming-rewards/) - Enables users to deposit USDS to farm SPK tokens. 3. [**Governance**](/governance/) - Enables users to delegate their voting power to a delegate. 4. [**Swap**](/user-guides/swap/) - Enables users to swap between supported stablecoins at no slippage. In addition, the **More** menu gives access to [**Points**](/points/), [**Rewards**](/rewards/), **Notifications**, and a link to the external Sky **Farms** page. ![](/assets/homepage.webp) *Spark App Landing Page* #### Connecting Your Wallet In order to access the Spark App you must connect a crypto wallet. You do so by clicking “Connect Wallet” in the top right corner of the app, select your wallet of choice, and finalize the connection process for the specific wallet. ![](/assets/connect-wallet-1.webp) *The Connect Wallet Button in the Top Right corner of the Spark App* ![](/assets/connect-wallet-3.webp) *Connect to Spark with your favorite wallet* #### Selecting Network Make sure you are connected to the desired blockchain network. In the top right corner, you are able to change between blockchain networks supported by Spark. The current supported networks are Ethereum, Base, Arbitrum, Gnosis, Optimism, Unichain, Avalanche and Robinhood. ![](/assets/network-1.webp) *Network Selection* ![](/assets/network-2.webp) *Network Selection* #### Sandbox Mode If you wish to test out the Spark Application you can click on the three dots (…) next to Connect Wallet and click on the Sandbox mode. This will give you access to a newly generated test wallet with test funds on a test network, giving you the option to familiarize yourself with the application before spending any real funds. ![](/assets/sandbox-1.webp) *Sandbox Mode* ![](/assets/sandbox-3.webp) *Activate Sandbox* #### Watch Wallet Mode Watch Wallet mode lets you view another wallet exactly as if it were your own. You can browse all positions and data, but you won't be able to perform any actions or interact with the app. To enable Watch Wallet mode, click on the three dots (…) next to Connect Wallet and toggle on Watch Wallet. Enter the wallet address you wish to watch and click Enable. ![](/assets/watch-wallet-mode-1.webp) *Watch Wallet Mode* ![](/assets/watch-wallet-mode-2.webp) *Enter Wallet Address* ## Troubleshooting ### I cannot connect to the platform * Make sure to select the correct network (Ethereum, Base, Arbitrum, Gnosis, Optimism, Unichain, Avalanche or Robinhood). Normally on the wallet provider you can switch the network in the settings option. * On a non-custodial wallet app (e.g. Rabby): * Make sure your wallet is unlocked. * Make sure the correct network is selected. * On custodial wallet app (e.g. Coinbase): * Use the scan QR option to connect. * If you want to access directly from the wallet browser, just go to %%APP\_DOMAIN%%. * Using Wallet Connect: * Use the scan QR code to connect ### Why is my Wallet Blocked? Spark receives blockchain intelligence provided by [TRM Labs](https://www.trmlabs.com/). TRM combines on-chain data and real-world investigations to identify financial crime and other prohibited activities. This data blocks wallets from %%APP\_DOMAIN%% that are associated with certain legally prohibited conduct. If you believe your address has been incorrectly flagged, please contact [legal@sparkfoundation.io](mailto\:legal@sparkfoundation.io). **What information is shared with TRM Labs?** Your address is shared with TRM, but no metadata is tracked or shared. The request from the UI is routed to the SparkLend hosted API, which is used as a proxy endpoint, and the address is passed directly through to the TRM service. Users' IP addresses are not shared with TRM. ### I cannot send transactions Make sure you have enough ETH in your wallet to cover the gas fees. Depending on the network status, the cost of the transactions may vary. #### Enable contract data on Ledger If you are using a Ledger hardware wallet, make sure to select the Ethereum app and enable contract data. To enable contract data: * Connect and unlock your Ledger device. * Open the Ethereum application. * Press the right button to navigate to Settings. * Then press both buttons to validate. * In the Contract data settings, press both buttons to allow contract data in transactions. * The device displays Allowed. ### The site does not load The following steps may solve your problems: * If you are using Brave browser, switch to another browser to see if the issues are related to Brave. If it is related to Brave browser some helpful actions are: * Clearing cache data and cookies for the site * Hard refresh with control + F5 (or cmd + shift + r on macOS) * Disable brave wallet (or the wallet not being used as default, e.g. metamask) or other extensions that might be interfering with proper connection with the wallet * If the site still won't load after taking the steps above, you will have to use the platform in another browser. * Make sure your internet connection is working and stable * Restart the browser and try to connect again * Try to hard refresh the site with control + F5 * Check if there are any updates for your browser or wallet provider. If so, update it to the latest version. ### My transaction is stuck pending confirmation In this situation make sure to not keep sending transactions, as every new transaction will be stuck pending the oldest transaction to be confirmed. You can get rid of the stuck transaction by speeding it up or cancelling it. Depending on the wallet you are using, you may have that option natively. For example, Metamask or Trust Wallet both have the options to cancel or speed up transactions. Alternatively, if your wallet provider doesn't have this option, you can still drop the stuck transaction by sending a 0 ETH transaction, to your address (yourself) using the same nonce (number id) as the stuck transaction. You can inspect the nonce in your stuck transaction in [Etherscan](https://etherscan.io) and use interfaces such as [MyCrypto](https://mycrypto.com/) to send a 0 ETH transaction with a higher gas cost to replace the one that is stuck. Here is a guide about the topic for [MyCrypto](https://support.mycrypto.com/how-to/sending/checking-or-replacing-a-transaction-after-it-has-been-sent). :::info If you still have any questions or issues, feel free to reach out to the Spark team on the official [Discord](https://discord.com/invite/sparkfinance). ::: ## Swapping Tokens In this guide, you will learn how to swap between USDS, USDC and DAI. Spark enables easy conversion between these tokens with no slippage and, under current fee parameters, no protocol fee beyond gas. On Ethereum mainnet, Sky's LitePSM wrapper is the canonical fixed-rate USDC ↔ USDS contract path. Integrators looking to build on that infrastructure can read the [LitePSM developer documentation](/dev/integration-guides/litepsm/). ### How to Swap 1. Navigate to [%%APP\_DOMAIN%%](https://app.spark.fi) and go to the Swap page. ![](/assets/swap/swap-1.webp) *Navigate to the Swap page* 2. Select the tokens and amounts you wish to swap from and to, for example 1000 USDC to 1000 USDS. Click Swap and submit the transactions in the Actions section. ![](/assets/swap/swap-3.webp) *Input Tokens and Amounts* 3. Once you have finalized all the transactions, you have successfully swapped your tokens, in this example USDC to USDS. ![](/assets/swap/swap-4.webp) *Confirmation: USDC Swapped to USDS* ### Converting between Savings Vaults To swap between Savings Vaults such as sUSDS and sUSDC, you must simply withdraw your assets from the Savings Vaults before swapping to the desired token, and depositing into the desired vault. In many cases you can deposit the stablecoin directly into the desired vault, and the stablecoin will be swapped for the Savings Vault token at no slippage or fee. ### FAQ #### What is USDS? USDS is the new version of DAI, issued by [Sky](https://sky.money). USDS is a stablecoin pegged to the US dollar. USDS is not issued or deployed by Spark. USDS enables users to earn additional rewards, such as a higher APY on Savings USDS, and Sky Star token rewards. You can upgrade DAI to USDS at a 1:1 rate on the Swap page. ## Notification Center The Notification Center helps you stay informed about changes to your positions and account activity. You can choose your preferred notification channels and the types of alerts you want to receive. More features will be added soon. ### Overview This guide is divided into four parts: * Signing in to Notification Center * Managing your account * Adding wallets * Managing wallet notification settings ### Sign In 1. Open the **More** menu in the Spark App and select **Notifications**. ![](/assets/notification-center/1-navigate-to-notifications.webp) *Open Notification Center from the More menu* 2. The welcome modal is shown the first time you open Notification Center. Click **Enable notifications** to begin signing in. If you close this modal, it will not be shown again, and you can continue later by clicking **Sign in** on the main Notification Center page. ![](/assets/notification-center/2-notifications-welcome-modal.webp) *Welcome modal for Notification Center* 3. Enter your email address and click **Continue**. ![](/assets/notification-center/3-sign-in-enter-email.webp) *Enter the email address you want to use for notifications* 4. Spark will send a one-time verification code to your email address. Open the email, copy the code, and enter it in the OTP screen. The sender will use the `notifications.spark.fi` domain. ![](/assets/notification-center/5-sign-in-email-otp-code.webp) *Example verification email* ![](/assets/notification-center/6-sign-in-otp-enterd.webp) *Enter the one-time code to finish signing in* 5. After signing in, you will see the main Notification Center view with: * **Account:** Your signed-in email address. * **Telegram:** An optional channel for receiving alerts in chat. * **Wallets:** The wallets you want to monitor. ![](/assets/notification-center/7-notifications-signed-in-first-view.webp) *Notification Center after signing in* ### Manage Your Account 1. To receive alerts in Telegram, click **Connect** in the Telegram panel and follow the Telegram prompt to complete the connection. This step is optional. ![](/assets/notification-center/connect-telegram-progress-dialog.webp) *Connect Telegram to receive alerts in chat* 2. To disconnect Telegram, click **Disconnect** in the Telegram panel and confirm. ![](/assets/notification-center/disconnect-telegram-dialog.webp) *Disconnect Telegram if you no longer want Telegram alerts* 3. To sign out, open the three-dot menu in the **Account** panel and click **Sign out**. ![](/assets/notification-center/account-management-sign-out-option.webp) *Use the Account menu to sign out or manage the notification account* 4. To permanently remove your Notification Center account and saved settings, open the same menu and choose **Delete notification account**, then confirm the deletion. ![](/assets/notification-center/account-deletion-confirmation.webp) *Delete the notification account and its saved settings* 5. At the bottom of Notification Center, you can also use the **Share your feedback** panel to send feedback about the product and your experience using it. ![](/assets/notification-center/share-feedback-panel.webp) *Use the feedback panel to share product feedback* ### Add Wallets 1. In the **Wallets** section, click **Link more wallets** to add a wallet address you want to monitor. 2. Paste a wallet address or click **Use connected** to use the wallet currently connected to the app. Only wallets with active SparkLend positions are supported. ![](/assets/notification-center/link-wallet-address-dialog.webp) *Link a wallet address for monitoring* 3. If the wallet does not have an active SparkLend position, Notification Center will show an error and the wallet will not be added. In that case, try another address. ![](/assets/notification-center/link-wallet-address-error-no-active-position.webp) *Only wallets with active SparkLend positions can be linked* 4. You can link more than one wallet. Each wallet has its own settings and can be managed separately. ![](/assets/notification-center/link-wallet-multiple-linked-wallets.webp) *Notification Center supports multiple linked wallets* 5. To stop monitoring a wallet, click the trash icon next to that wallet and confirm the removal. ### Manage Wallet Settings 1. Once a wallet is linked, expand it to manage its alert preferences: * **Health factor alert:** Turn alerts on or off for that wallet. * **Health factor threshold:** Choose the threshold that should trigger the alert. * **Email address:** Enable or disable email delivery. * **Telegram:** Enable or disable Telegram delivery if Telegram is connected. ![](/assets/notification-center/managing-wallet-notifications-email-channel-active.webp) *Manage per-wallet alert settings and notification channels* 2. Turn on **Health factor alert** for the wallet you want to monitor, then set the threshold that should trigger the alert. 3. Enable the channels you want to use for that wallet. You can use email, Telegram, or both when Telegram is connected. ### Email Examples When you sign in, Spark sends a one-time verification code by email. The sender will use the `notifications.spark.fi` domain. ![](/assets/notification-center/5-sign-in-email-otp-code.webp) *Verification code email used during sign-in* When a linked wallet falls below your configured health factor threshold, Spark sends an alert email with a link to review the position. The sender will also use the `notifications.spark.fi` domain. ![](/assets/notification-center/risky-position-email-alert.webp) *Example health factor alert email* You can also unsubscribe from email notifications from the link included in notification emails. ![](/assets/notification-center/email-unsubscribe-link-ui-confirmation.webp) *Confirmation screen after unsubscribing from email notifications* ### FAQ #### Do I need Telegram to use Notification Center? No. Email notifications work without Telegram. Telegram is optional and can be connected later. #### Can I monitor more than one wallet? Yes. You can link multiple wallets, and each wallet can have its own notification settings. #### Which wallets can be linked? Only wallets with active SparkLend positions are supported. #### What triggers a health factor alert? Alerts are triggered when the wallet's health factor drops below the threshold you configured for that wallet. #### Can I stop email notifications without deleting my account? Yes. You can disable the **Email address** channel for a linked wallet, or use the unsubscribe link in a notification email. ### Important Notification Center emails and related links will come from the `notifications.spark.fi` domain. If you receive a Notification Center email from a different domain, treat it with caution. ## Claiming Rewards ### Tutorial 1. Navigate to the SPK Farm page by clicking on **SPK** in the top navigation bar and selecting **Farm**. ![](/assets/farms-nav.webp) *Navigate to the SPK Farm page* 2. On the SPK Farm page, you can see an overview of how many SPK tokens you have earned, and your deposit. ![](/assets/farms-8.webp) *Overview of your deposit* 3. To claim SPK rewards, click on the **Claim** button. 4. In the **Claim rewards** dialog, you will see a **Transaction overview**, which shows how many SPK tokens you are claiming. To claim the tokens, you must submit the transactions in the **Actions panel**. ![](/assets/farms-10.webp) *The Claim rewards dialog* 5. Once you have submitted the transactions, you will see the following confirmation. ![](/assets/farms-11.webp) *Confirmation for claimed rewards* ## Depositing Into the SPK Farm ### Tutorial 1. Navigate to the SPK Farm page by clicking on **SPK** in the top navigation bar and selecting **Farm**. ![](/assets/farms-nav.webp) *Navigate to the SPK Farm page* 2. On the SPK Farm page, you will see an overview of which tokens can be deposited, and the projected rewards and historical data. ![](/assets/farms-2.webp) *SPK Farm Overview* 3. To deposit, you can either click on the **Deposit** button in the main panel, or in the **Tokens to deposit** section below, the **Deposit** button for the specific asset you wish to deposit. ![](/assets/farms-3.webp) *Tokens available for deposit* ![](/assets/farms-4.webp) *Depositing USDS into the SPK Farm* 4. Submit the transactions in the **Actions panel** to finalize the deposit into the farm. ![](/assets/farms-7.webp) *Confirmation of deposit into the SPK Farm* ## SPK Farming Deposit USDS to earn SPK tokens through the SPK Farm. Visit [%%APP\_DOMAIN%%/spk/farm](https://app.spark.fi/spk/farm) to start earning SPK. :::info Looking for other Sky farms? You can find a link to the external Sky farms page in the Settings menu of the Spark App. ::: ### Learn how to use the SPK Farm Learn how to deposit, claim rewards, and withdraw using the following tutorials: * [Depositing Into the SPK Farm](/user-guides/farming-rewards/depositing-into-farms) * [Claiming Rewards](/user-guides/farming-rewards/claiming-rewards) * [Withdrawing From the SPK Farm](/user-guides/farming-rewards/withdrawing-from-farms) ### SPK Farming FAQ #### What is SPK Farming? You can deposit USDS into the SPK Farm to earn SPK tokens. SPK is the governance token of Spark. Learn how to deposit here: * [Depositing Into the SPK Farm](/user-guides/farming-rewards/depositing-into-farms) #### How much will I earn? You earn SPK tokens based on the amount of USDS you deposit into the farm. On the farm page you will be able to see how many tokens you are earning in real time, and the APY based on the current token price. #### When can I claim rewards? You can claim earned SPK tokens any time you want as they accrue in real time. Learn how to claim rewards here: [Claiming Rewards](/user-guides/farming-rewards/claiming-rewards) #### Are there any withdrawal restrictions? No, deposited funds can always be instantly withdrawn with no liquidity constraint and no fees beyond gas cost. No actor other than the user has access to deposited funds. Learn how to withdraw here: [Withdrawing From the SPK Farm](/user-guides/farming-rewards/withdrawing-from-farms) #### Can I deposit Savings USDS or Savings DAI? You can only deposit USDS, however you are able to convert savings tokens to USDS and deposit into the farm in a single transaction. You are therefore not able to both earn the Sky Savings Rate and earn SPK farming rewards at the same time using the same funds. #### What are the risks? Funds deposited into the SPK Farm are not used in any liquidity pool or staking mechanism, meaning they can always be instantly withdrawn without liquidity constraints and with no fees beyond gas costs. Only the user has access to the deposited funds, ensuring complete control. As a result, there are no market or staking-related risks associated with the deposited funds. However, the value of earned SPK tokens may fluctuate based on the market price. ## Withdrawing From the SPK Farm ### Tutorial 1. Navigate to the SPK Farm page by clicking on **SPK** in the top navigation bar and selecting **Farm**. ![](/assets/farms-nav.webp) *Navigate to the SPK Farm page* 2. On the SPK Farm page, you can see an overview of how many SPK tokens you have earned, and your deposit. ![](/assets/farms-12.webp) *Overview of earned rewards and your deposit* 3. To withdraw your deposit, click on the **Withdraw** button. ![](/assets/farms-13.webp) *Click Withdraw to withdraw your deposit* 4. Finalize your withdrawal by completing the transactions outlined in the **Actions panel**. ![](/assets/farms-16.webp) *Withdrawing USDS* :::info **Note:** When withdrawing your whole deposit, you can also click the toggle to withdraw accrued SPK rewards in the same transaction. ::: 5. Once you have submitted the transactions you will see the following confirmation window. ![](/assets/farms-18.webp) *Confirmation of withdrawal* ## SPK Staking SPK staking enables users to stake their SPK tokens to secure Spark and earn staking rewards in return. Spark leverages [Symbiotic’s](https://symbiotic.fi) staking infrastructure for SPK staking. This guide explains how staking works, how to participate, and important details about rewards and withdrawals. ### What is SPK Staking? SPK staking allows token holders to stake their SPK to secure Spark. In return, stakers earn Spark Points. The staked SPK helps increase the security of the system, by securing Spark token bridges and other future innovations for the protocol. ### How do I stake SPK? To stake SPK tokens: 1. Navigate to the staking page at [%%APP\_DOMAIN%%/spk/staking](https://app.spark.fi/spk/staking) and connect your wallet. Then click "Stake". ![](/assets/staking/staking-0.webp) *Staking page overview. Click "Stake" to start staking.* 2. Input the amount of SPK you wish to stake, and execute the transactions in the Actions pane. ![](/assets/staking/staking-2.webp) *Input the amount of SPK you wish to stake, and execute the transactions in the Actions pane.* 3. Once you have executed the transactions, you will get a confirmation. ![](/assets/staking/staking-3.webp) *Confirmation of the staking transaction.* 4. Rewards will start accruing immediately. ![](/assets/staking/staking-4.webp) *Overview of points earned.* ### What are the rewards? * As soon as you stake SPK, you will start earning points. You can see these points in the Spark App UI and on [https://points.%%SPARK\_DOMAIN%%/](https://points.spark.fi/) * [You can read more about the Spark Points program here](/points). ### How do I withdraw my stake? To queue your staked SPK for a withdrawal: 1. On the staking page, click "Unstake" in the main overview. ![](/assets/staking/staking-4.webp) *Click "Unstake" to queue your staked SPK for a withdrawal.* 2. Specify how much SPK to withdraw and execute the transactions in the UI. Note: There is a minimum withdrawal delay of 2 weeks. The UI will show when the withdrawal can be claimed. ![](/assets/staking/staking-5.webp) *Unstaking dialog* 3. Once the withdrawal is queued, you can see the withdrawal in the main overview. ![](/assets/staking/staking-6.webp) *Withdrawal queue overview* 4. Once the withdrawal delay has passed, you can click "Finalize" to withdraw your SPK. ![](/assets/staking/staking-7.webp) *Finalize withdrawal* 5. Execute the transaction in the UI to finalize the withdrawal. ![](/assets/staking/staking-8.webp) *Finalize withdrawal* 6. Once you have finalized the withdrawal, you can see the SPK in your wallet. #### Withdrawal Process Below is a more detailed explanation of the withdrawal process: * Once you initiate unstaking SPK, the SPK enters a withdrawal queue. * There is a minimum withdrawal delay of 2 weeks. * The delay can extend up to 4 weeks depending on when you withdraw. * The UI will show you when you are able to withdraw SPK to your wallet. * Execute the transaction in the UI to withdraw SPK to your wallet. ### How does the withdrawal delay work? The withdrawal delay is part of the underlying staking infrastructure provided by Symbiotic: * Withdrawals can only happen after the current epoch and the next one are finished. * Each epoch is set to two weeks. * There is always a minimum 2-week withdrawal delay and a maximum of 4 weeks delay depending on when you initiate the withdrawal. **Example:** * User withdraws 7 days into epoch 38. * User cannot withdraw until epoch 39 ends. * Since each epoch is 14 days long, and the user is 7 days into epoch 38 they can withdraw their stake in 21 days (7 days remaining in epoch 38 + 14 days for epoch 39). ### Will I earn Spark points while my stake is in the withdrawal queue? Yes, users in the withdrawal queue will earn Spark points. ### Why is there a withdrawal delay? The withdrawal delay is a security feature that: * Provides guarantees of a certain stake size for predetermined periods. * Ensures systems can rely on stake size for a minimum of 2 weeks in the future. * Prevents potential security issues of large instant withdrawals of stake. ### What is the staked SPK used for? The staked SPK is used to secure token bridges that are part of the Spark Liquidity Layer. Furthermore, the stake may be used to secure other future products of the Spark Ecosystem. ### Staked SPK token (stSPK) When you stake SPK, you will receive a staked SPK token (stSPK). This token is a representation of your stake. Keep this token safe as it is required to withdraw your stake. ### Supported Networks and Token Addresses Below are the only official deployments of staked SPK (stSPK). Beware of scammers and false staked SPK tokens. | Network | Token | Address | | -------- | ----- | --------------------------------------------------------------------------------------------------------------------- | | Ethereum | stSPK | [0xc6132FAF04627c8d05d6E759FAbB331Ef2D8F8fD](https://etherscan.io/address/0xc6132FAF04627c8d05d6E759FAbB331Ef2D8F8fD) | ### What are the risks? Staking involves the risk of slashing. The specific mechanism for slashing depends on the product that is being secured. Once networks are integrated, more information on the mechanics will be made available. ### Can I vote with my staked SPK? Yes, users can vote with their full amount of SPK even when their SPK is staked. ### What platform is used for staking? Spark leverages [Symbiotic](https://symbiotic.fi/) as its staking platform. You can read more about the withdrawal delay and epoch system in their [documentation](https://docs.symbiotic.fi/). ## Spark Savings AVAX Rewards Campaign (Avalanche) :::info **The AVAX campaign ended on March 10, 2026, and the claim window closed on June 10, 2026.** AVAX rewards may be activated elsewhere in the future. Follow [@sparkfinance](https://x.com/sparkfinance) for updates on future campaigns. ::: ### Overview The AVAX Rewards Campaign allowed users to earn **AVAX tokens** by supplying **USDC to spUSDC on Spark Savings on Avalanche**. This program was designed to deepen stablecoin liquidity on Avalanche while maintaining predictable, transparent, and time-based emissions. **Campaign Start Date:** 10 December 2025 **Campaign End Date:** 10 March 2026 (90 days) Reference AVAX price used for emission calibration: **$14.03** (average closing price over the previous 7 days) ### Reward Distribution Rewards were distributed based on the following key factors: * **Weekly distributions of approximately 4,434.94 AVAX** (based on a 7-day average AVAX price of $14.03 and subject to adjustment depending on market conditions and target APY sustainability) * **Total campaign allocation: 57,020.67 AVAX** distributed over 90 days * **Rewards accrued every second** based on the user's proportional share of total **spUSDC on Avalanche** * Emissions streamed continuously at approximately **0.00733 AVAX per second** * Users could claim rewards at any time during the campaign and within the post-campaign claim window ### Campaign Parameters * **Daily Prize Pool:** $8,889 (target emission basis) * **Weekly Emission (USD equivalent):** 62,222 * **Weekly Emission (AVAX):** \~4,434.94 AVAX * **Total Emission (AVAX):** 57,020.67 AVAX * **Net AVAX Reserve Buffer:** 9,979.33 AVAX The reserve buffer was maintained to manage rounding, volatility adjustments, and potential campaign optimization. ### Campaign Details * **Duration:** 10 December 2025 – 10 March 2026 * **Distribution Network:** Avalanche * **Reward Token Distribution Network:** Avalanche only * **Eligible Asset:** spUSDC on Avalanche Rewards were calculated solely based on spUSDC balances on Avalanche. There was a single-chain reward calculation and claim process. ### Claim Process During the claim window, users could claim their rewards at [%%APP\_URL%%/rewards](https://app.spark.fi/rewards). The claim window has since closed, and rewards can no longer be claimed. Rewards were distributed through the SparkRewards contract deployed on Avalanche. ### Token Information #### Reward Token * **Token:** AVAX * **Network:** Avalanche #### Eligible Savings Token * **spUSDC (Avalanche):** [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://snowscan.xyz/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) ### Claim Deadlines * Users had to claim their rewards within **3 months after the campaign ended** (by June 10, 2026). Rewards not claimed within this 3-month window have expired and are no longer claimable. ### Restricted Geographies No country-level restrictions applied. However, the [Spark Terms of Use](https://spark.fi/terms-of-use) still apply, meaning that e.g. sanctioned users are not able to claim rewards. ### Program Design Principles This campaign was structured to: * Drive sustainable USDC liquidity growth on Avalanche * Maintain predictable and transparent emissions * Align incentives with long-term protocol health * Preserve capital efficiency through time-based streaming rewards The structure balanced attractive participant yield with disciplined token distribution and treasury protection. ## Spark Rewards ### What is the Spark Rewards program? The Spark Rewards program offers weekly token rewards to users who participate in campaigns rewarding specific actions that contribute to the growth of the Spark ecosystem. The rewards are sourced from and offered in collaboration with other DeFi projects. The goal is to bring different crypto projects together to make decentralized finance more accessible and useful for everyone. ### What are the rewards? The rewards will mainly be tokens from partners of Spark, this being other DeFi projects or companies that Spark has a partnership with. An example was the [Redstone campaign](/rewards/redstone), which rewarded users who supplied cbBTC into the SparkLend market, which is powered by RedStone oracles. ### How do I earn rewards? Reward campaigns run periodically. To participate, navigate to [%%APP\_DOMAIN%%](https://app.spark.fi) and go to the [Rewards](https://app.spark.fi/rewards) page. ![rewards1.webp](/assets/rewards1.webp) *Navigating to the Rewards page* Here you will see an overview of any currently active campaigns and rewarded actions, and how to get started. If no campaigns are active, the page will say so. As soon as you are participating in a campaign, you will start to accrue rewards. ![](/assets/rewards4.webp) *Active campaigns* ### How do I check my rewards? Your rewards accrue in real time, and you will be able to see accrued rewards in the top panel of Spark App, or on the Rewards page of the app. ![](/assets/rewards5.webp) *Rewards overview* ### How often are rewards distributed? While rewards accrue immediately, rewards are only distributed once per week on Mondays. This means you will be able to see how much you have earned in real time, but will not be able to claim until the rewards are distributed each Monday. The application shows an overview of how much of your rewards can be claimed immediately, and how much is pending the next weekly distribution. ### How do I claim the rewards? You claim the rewards on the Spark App Rewards page. Navigate to [%%APP\_DOMAIN%%/rewards](https://app.spark.fi/rewards) and click "Claim All" on the right hand side and follow the instructions to claim your rewards. ![](/assets/rewards3.webp) *Claiming rewards on the Spark App* ### Do I need to claim each week? No, you do not have to claim rewards each week. Rewards will continue to accrue and accumulate and you can claim multiple weeks rewards in a single transaction. The application shows an overview of how much of your rewards can be claimed immediately, and how much is pending the next weekly distribution. ### Is there a claim deadline? Yes, unclaimed rewards will eventually expire depending on the campaign. However there will always be a grace period between when a campaign ends and when the rewards expire of a few months, so users should have ample time to claim their rewards in time. The unclaimed rewards will be used to further reward active users of Spark. ### Restricted geographies Campaigns might restrict participation of users from specific countries for legal reasons. Check the specific campaign to see the details. ## OP Rewards Campaign :::info **The OP campaign has ended.** OP rewards may be activated elsewhere in the future. Follow [@sparkfinance](https://x.com/sparkfinance) for updates on future campaigns. ::: ### Overview The OP rewards campaign allowed users to earn OP tokens by supplying USDC to sUSDC on Spark Savings across both Optimism Mainnet and Unichain. The campaign ran from June 3rd, 2025 at 01:00 UTC until the end of 2025. ### Reward Distribution Rewards were distributed based on these key factors: * Weekly distributions of approximately 76,525.69 OP tokens (subject to weekly adjustments based on market APY) * Total campaign allocation: 2,000,000 OP tokens over 7 months * Rewards accrued every second based on the user's share of total sUSDC across both chains * Distributions occurred once per week (Every Monday), starting June 10th, 2025 ### Campaign Details * **Campaign Duration:** June 3rd, 2025 – End of 2025 (Approx 7 months) * **Distribution Networks:** * Rewards were distributed on Optimism Mainnet only * Rewards were calculated based on sUSDC holdings on both Optimism Mainnet and Unichain * Single claim process for rewards from both chains on OP Mainnet ### Claim Process * During the claim windows, users could claim their rewards at [%%APP\_URL%%/rewards](https://app.spark.fi/rewards). The final claim window has since closed, and rewards can no longer be claimed. * You can find more information on how rewards claiming works [here](/rewards/). * Claims were processed through the [SparkRewards contract](https://optimistic.etherscan.io/address/0xf94473Bf6EF648638A7b1eEef354fE440721ef41#code) on Optimism Mainnet * The Merkle root contains combined rewards for both chains ### Token Information #### Reward Token * **Token:** OP * **Contract:** [0x4200000000000000000000000000000000000042](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000042) * **Network:** Optimism Mainnet (distribution only) #### Involved Tokens * **sUSDC on Optimism Mainnet:** [0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55](https://optimistic.etherscan.io/address/0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55) * **sUSDC on Unichain:** [0x14d9143BEcC348920b68D123687045db49a016C6](https://unichain.blockscout.com/address/0x14d9143BEcC348920b68D123687045db49a016C6) ### Claim Deadlines * Users had to claim their rewards within 3 months from the end of each epoch. Rewards not claimed within the 3-month window expired and cannot be claimed. * Epochs ran quarterly, with the first epoch starting June 3rd, 2025. The final claim window has closed. ### Restricted Geographies No country restrictions applied. However the [Spark Terms of Use](https://spark.fi/terms-of-use) still apply, meaning that e.g. sanctioned users are not able to claim rewards. ## Redstone Rewards Campaign :::info **The RED campaign has ended on Sept 4, 2025.** RED rewards may be activated elsewhere in the future. Follow [@sparkfinance](https://x.com/sparkfinance) for updates on future campaigns. ::: ### Overview The Redstone rewards campaign allowed users to earn RED tokens by supplying cbBTC on SparkLend (Ethereum Mainnet). The campaign started on April 10, 2025 at 15:00 UTC and ended on Sept 4, 2025. ### Reward Distribution Rewards were distributed based on these key factors: * Weekly distributions of 200,000 RED tokens. * Rewards accrued every second based on the user's share of total cbBTC supplied. * Per second reward share was calculated using this formula: `User Share = (cbBTC Supplied - cbBTC Borrow Amount / cbBTC Liquidation Threshold) / Total cbBTC Supplies` * Borrowing cbBTC reduced the reward allocation * Looping (repeated borrowing and supplying cbBTC) was not rewarded * Distributions occurred once per week (Every Monday), starting April 21st, 2025. ### Campaign Details * Campaign duration: April 10 – Sept 4, 2025 * Network: Ethereum Mainnet * Eligible Asset: cbBTC ### Claim Deadlines * Users had 3 months from issuance to claim their rewards. Rewards not claimed within 3 months expired and cannot be claimed. The claim windows have closed. ### Restricted Geographies Users from the following countries were not able to claim rewards: * USA ## Spark Liquidity Layer The Spark Liquidity Layer (SLL) operates as a non-custodial capital allocator for Spark across DeFi/CeFi and TradFi opportunities. It has been operating without fault since November 2024. At its core, the SLL is designed to ensure that capital movement is constrained, predictable, and bounded under all conditions, including periods of market stress. ### Risk Architecture The key security feature of the SLL is that Spark governance must set approved venues in advance, subject to strict rate limits. The automation wallets can only move funds between these pre-approved venues at the defined rate limits. These constraints ensure that capital cannot be rapidly drained from any single venue, and that allocation changes occur gradually rather than reflexively under stress conditions. This directly addresses a core failure mode observed in recent market events: unconstrained capital movement leading to rapid liquidity depletion and cascading stress across markets. The threat model assumes a `RELAYER` can be fully compromised. Smart-contract constraints are designed to prevent value from moving outside the ALM system, while rate limits, slippage constraints, and emergency freezing bound the damage such a relayer can cause. Even under this assumption, capital remains restricted to predefined venues and rate limits, ensuring no single component can introduce unbounded risk to the system. In concrete contract terms, four mechanisms enforce these properties: * **Whitelist by rate-limit key.** Every action on the controllers is gated by a `keccak256` rate-limit key, typically combined with the target address (vault, pool, aToken, OTC exchange, destination domain). A venue with no governance-configured rate-limit key reverts on first interaction — there is no path to an unapproved address. * **Linear regeneration with a hard ceiling.** Each rate limit has a `maxAmount` (absolute ceiling), a `slope` (tokens-per-second regeneration), and a `lastAmount` consumed at the last action. The current limit is `min(slope · elapsed + lastAmount, maxAmount)`. A compromised relayer's per-window exposure is bounded by the configured ceiling; sustained pressure is bounded by the slope. * **Per-venue slippage floors.** Curve, Uniswap V4, AAVE, and OTC operations require a non-zero `maxSlippage` configured per pool / aToken / exchange. The convention is inverted from common DeFi usage: `0.999e18` means "the resulting value must be at least 99.9% of expected"; a value of `0` disables the integration. * **Bounded OTC exposure.** OTC swaps go through dedicated `OTCBuffer` contracts. Only one outstanding swap per whitelisted exchange can be in flight; a new send is blocked until the prior swap has been claimed back (subject to slippage and a configurable recharge). #### Roles The SLL uses a small set of governance-controlled operational roles: * **`RELAYER`** — can call controller functions to move capital between approved venues. These calls remain constrained by approved integrations, balances, slippage checks where applicable, and rate limits. * **`FREEZER`** — can immediately revoke a compromised `RELAYER` from the controllers via `removeRelayer`, and (where the freezable proxy variant is used) detach a compromised controller from the `ALMProxy` via `removeController`. Governance can then reassign or reissue relayer credentials. #### Monitoring The SLL is actively monitored across several independent layers: * Price movements and collateral valuations across all venues where SLL capital is deployed. * Oracle deviation and liveness tracking, including heartbeat checks and price-deviation thresholds, to detect stale or manipulated feeds. * Utilization rate alerts on sudden spikes that may signal abnormal borrowing activity or liquidity stress at integrated venues. * LTV distribution tracking across active borrower positions in markets where the SLL is allocated, to identify concentration near liquidation thresholds. * Real-time threat detection through third-party security monitoring, with automated alerts routed to on-call team members for immediate response. * Sky ecosystem-level oversight on top of Spark-internal monitoring. Public dashboards: [%%DATA\_DOMAIN%%](https://data.spark.fi), [info.skyeco.com](https://info.skyeco.com). #### Liquidity Backstop The SLL can inject capital into a SparkLend reserve, a Morpho vault curated by Spark, or a Spark Savings vault to support depositor withdrawals while liquidations or redemptions settle through normal channels. This backstop is bounded by approved venues, rate limits, and risk parameters set by governance. #### Where to Verify | Item | Source | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | All Spark contract addresses (canonical) | [Spark Address Registry](/dev/deployments) | | SLL addresses in Sky Atlas | [Spark Liquidity Layer Addresses (A.6.1.1.1.2.6.1.2.1.1.1)](https://sky-atlas.io/#f3885398-6641-437b-a413-276ac48e624a) | | Developer reference | [Spark ALM Controller](/dev/spark-liquidity-layer/spark-alm-controller) | | Audit reports | [Spark Liquidity Layer Audits](/dev/security/security-and-audits#spark-liquidity-layer) | | Current configuration | [Sky Forum — Spark Prime](https://forum.skyeco.com/c/spark-prime/) | | USDS collateral backing composition | [Sky Financial Dashboard](https://financial.skyeco.com/usds/collateral-backing) | #### Atlas Sources The following Sky Atlas sections govern the controls described above: * [A.6.1.1.1.2.6.1](https://sky-atlas.io/#cd70b9f1-1a59-407c-9945-05e52bf5a3b6) — Allocation System Primitive * [A.6.1.1.1.2.6.1.2.1.1](https://sky-atlas.io/#e9d83462-27f2-4bc0-a63a-596dd7c517b4) — Spark Liquidity Layer Architecture * [A.6.1.1.1.2.6.1.2.1.1.1](https://sky-atlas.io/#f3885398-6641-437b-a413-276ac48e624a) — Spark Liquidity Layer Addresses * [A.6.1.1.1.2.2.2](https://sky-atlas.io/#f60887de-a4eb-4e4b-8aa6-e22cf724772a) — Spark Root Edit Primitive ### FAQ #### What integrations are supported by SLL? The ALM Controller currently supports the following integration types: * USDS minting and burning via the Sky allocation system, and 1:1 USDS↔DAI conversion * Mainnet PSM swaps between USDS and USDC; PSM3 deposits and withdrawals on supported L2s * USDC bridging via Circle CCTP, and per-asset OFT bridging via LayerZero * AAVE-compatible lending markets, including SparkLend and Aave v3 * ERC-4626 vaults, including Spark-curated Morpho vaults * Curve stableswap pools (add liquidity, remove liquidity, swaps), restricted to 1:1 stablecoin pools * Uniswap V4 stablecoin pools (mint / increase / decrease positions, swaps), restricted to 1:1 hookless pools with governance-configured tick limits * OTC desks via dedicated `OTCBuffer` contracts (bounded per-exchange outstanding exposure) * Ethena USDe minting and burning, including delegated-signer management; sUSDe cooldown and unstaking * EtherFi weETH staking, withdrawal request, and claim (via a dedicated `WEETHModule` that handles the withdrawal NFT) * Lido wstETH staking, withdrawal request, and claim via the Lido withdrawal queue * Maple Finance redemption requests and cancellations * Superstate USTB subscriptions * SPK farm staking and reward claiming * Spark Vault `take` for funded routes * Generic rate-limited ERC-20 transfers to whitelisted (asset, destination) pairs Additional integrations can be onboarded over time through governance-controlled configuration and controller upgrades. #### What networks are supported by SLL? The following networks are currently supported by the SLL: * Ethereum * Base * Arbitrum * Optimism * Unichain * Avalanche * Robinhood Additional networks will be integrated on a continuous basis. #### What are the liquidity constraints for cross-chain liquidity? The SLL ensures there is always ample liquidity for users to enter or exit Spark Savings vaults on supported networks. Sky aims to keep a substantial portion of [USDS collateral backing](https://financial.skyeco.com/usds/collateral-backing) in cash reserves, providing a healthy buffer for redemptions even at large volumes. #### Why is there a 1-of-2 SAFE authorized on the ALM Controller contract? This SAFE is used as a smart wallet for the SLL automation to enable batching of transactions and rotating of hot wallet keys (the second signer). Funds are not custodied by this wallet, and it is only capable of allocating to governance-approved venues. This is similar to the ALLOCATOR role in the Morpho curation model. #### How are new venues onboarded? A venue becomes usable only when governance sets a non-zero rate limit for the corresponding key (typically `keccak256(LIMIT_, )`). Until that key is configured, every relayer call targeting that venue reverts. New venues are onboarded with conservative rate limits and expanded as operational experience accumulates. #### Where are whitelists enforced in the ALM Controller contract? Every allocation function in the ALM Controller has an associated call to the `RateLimits` contract. This request for a rate limit is keyed on the asset, pool, or destination argument, which provides an implicit whitelist on that parameter. If the target is not whitelisted, the rate limit returns zero and the call reverts. #### Has the Spark Liquidity Layer been audited? Yes, you can find the audit reports here: [Spark Liquidity Layer Audit Reports](/dev/security/security-and-audits#spark-liquidity-layer) #### Who controls the Spark Liquidity Layer? Sky Governance determines the use cases supported by the SLL, such as networks and protocols, as well as the accepted risk parameters for each use case, including rate limits, maximum fund amounts or maximum volumes. ## Spark Savings Spark Savings lets users deposit supported assets into savings vaults to earn a risk-adjusted savings rate. Different vaults use different yield sources and have different operators, mechanics, and risk profiles. Spark currently supports the following Savings Vaults: | Vault | Token | Asset | Yield Source | Operator | Version | | --------------------- | ------- | ----- | ---------------------------------------- | -------- | ------- | | Spark USDC | spUSDC | USDC | Spark Liquidity Layer | Spark | V2 | | Spark USDT | spUSDT | USDT | Spark Liquidity Layer | Spark | V2 | | Spark PYUSD | spPYUSD | PYUSD | Spark Liquidity Layer | Spark | V2 | | Spark ETH | spETH | ETH | Spark Liquidity Layer | Spark | V2 | | Spark USDG | spUSDG | USDG | Spark Liquidity Layer | Spark | V2 | | Savings USDS | sUSDS | USDS | Sky Savings Rate | Sky | — | | Staked USDS | stUSDS | USDS | stUSDS Rate (SKY-collateralized lending) | Sky | — | | Savings USDC (Legacy) | sUSDC | USDC | Sky Savings Rate | Spark | V1 | | Savings DAI (Legacy) | sDAI | DAI | DAI Savings Rate | Sky | — | All Spark Savings vault tokens follow the [ERC-4626 tokenized vault standard](https://eips.ethereum.org/EIPS/eip-4626) — a common interface for yield-bearing vaults where each token represents a share of the underlying assets and accrues yield through an increasing redemption rate. They are transferable, integrable into other DeFi protocols, and continue to accrue yield wherever they are held. Selected savings vaults earn [Spark Points](/points). You can find the currently eligible vaults and campaign details at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). For per-vault contract addresses across all supported networks, see the [Spark Address Registry](/dev/deployments), the [Sky Chainlog](https://chainlog.skyeco.com/), or the [Spark App](https://app.spark.fi/). #### Spark Savings USD Vaults spUSDC, spUSDT, and spPYUSD are V2 vaults fully backed by USDS (see [USDS Collateral Backing](https://financial.skyeco.com/usds/collateral-backing)). Yield is generated via the Spark Liquidity Layer; rates are managed by Spark Governance. spUSDT is available on both Ethereum and Arbitrum, where the deposit asset is USDT (on Arbitrum technically USDT0, the omnichain USDT standard) — both are the same ERC-4626 Spark Savings USDT vault. spUSDG is a V2 vault for USDG (Global Dollar), available on Robinhood Chain, with yield likewise generated via the Spark Liquidity Layer. For the USDT-specific liquidity management framework, see [USDT Strategy](/products/spark-savings/risk-architecture/usdt-strategy). See also [Risk Architecture](#risk-architecture). #### Spark Savings ETH Vault spETH is a V2 vault backed by Spark's balance sheet and insurance. Yield is generated via the Spark Liquidity Layer; rates are managed by Spark Governance. See [Risk Architecture](#risk-architecture). #### Sky Stablecoin Vaults sUSDS and stUSDS are Sky products with rates set by Sky Governance. sUSDS provides direct exposure to the Sky Savings Rate. stUSDS lends USDS to borrowers using SKY tokens as collateral and has a different risk profile — see [Staked USDS](#staked-usds). #### Legacy Vaults sUSDC (V1) deposits USDC into the Sky Savings Rate; sDAI deposits into the DAI Savings Rate. Users are encouraged to migrate to Spark Savings Vaults V2 for enhanced features, though both remain supported as legacy vaults. ### Guides Use these guides for Spark Savings workflows: * [Deposit & Withdraw](/products/spark-savings/guides/tutorial) * [Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents) ### Risk Architecture Spark Savings Vaults V2 (spUSDC, spUSDT, spETH, spPYUSD, spUSDG) generate yield by deploying their underlying assets through the [Spark Liquidity Layer (SLL)](/products/spark-liquidity-layer), which strategically allocates capital across various protocols and yield strategies to optimize returns while maintaining liquidity and managing risk. The Sky vaults (sUSDS, stUSDS) and legacy vaults (sUSDC V1, sDAI) earn from rates set by Sky Governance instead. You can find an overview of the collateral composition for each vault on the [Savings page in the Spark App](https://app.spark.fi/). #### Conservative & Secure Spark Savings V2 vaults allocate conservatively through the SLL: * Minimizes exposure to riskier collateral (e.g., perpetual futures) to protect against market stress * Allocates across a mix of DeFi and RWA yield sources to outperform traditional DeFi lending rates #### Institutional-Grade Liquidity Spark Savings V2 vaults are designed to support institutional-scale activity: * Backed by [Sky's balance sheet](https://financial.skyeco.com/financials/balance-sheet) to facilitate 24/7 withdrawals at any individual depositor's size * Supports large-scale transactions ($100M+) without significant market impact * Leverages the SLL's deep liquidity across integrated protocols #### First Loss Capital USDS (and Spark Savings) has multiple layers of protection for loss events, starting at the Prime level. **Layer 1 – Internal Junior Risk Capital (Prime-level):** Junior Risk Capital is the first capital to absorb losses on investments under the Allocation System. Each Prime is responsible for holding junior capital in its treasury in proportion to its risk-weighted allocations, which serves as a first line of defense in the event the allocation incurs losses. Spark is well-capitalized, with over $35 million in stablecoin equity capital (see live financials on [%%DATA\_DOMAIN%%/financials](https://data.spark.fi/financials), and the [Spark Treasury wallet on Etherscan](https://etherscan.io/address/0x3300f198988e4C9C63F75dF86De36421f06af8c4)). **Layer 2 – Prime-External Junior Risk Capital:** Primes can source additional Junior Risk Capital from other Primes. This risk capital sits at equal preference with the Prime's Internal Junior Risk Capital, helping cover losses related to the Prime's allocation and risk exposures. **Layer 3 – External Senior Risk Capital (srUSDS):** This feature is planned for deployment in the near future. External Senior Risk Capital is provided from the srUSDS smart contract, which allows users to supply USDS to Sky Core to serve as senior risk capital, beginning to absorb losses only after Junior Risk Capital has experienced 100% losses. **Layer 4 – The Surplus Buffer (Internal Senior Risk Capital):** The Sky Protocol Buffer — known as the Surplus Buffer — is an accumulation of stability fees and liquidation penalties held by the protocol to cover bad debt in the event of residual losses. **Layer 5 – Aggregate Surplus Buffer:** After the surplus buffer is exhausted, losses are covered via Sky's Aggregate Surplus Buffer, which allows Sky to encumber the portion of other Primes' Internal Junior Risk Capital that was seeded by Sky to cover critical loss events. **Layer 6 – Token Backstop:** If losses exceed the sources of risk capital above, Sky will mint SKY tokens to recapitalize the protocol and cover any residual bad debt. **Equitable Loss Socialization:** If, and only if, all other sources of Junior Risk Capital and token backstops are exhausted, any residual losses are applied equally across all USDS holders, including Spark Savings stablecoin vaults (which are fully backed by USDS). The Sky ecosystem's multi-layered approach to capital backstops provides high assurance that Spark Savings vault users will not incur losses. Taking the sum of all sources noted above, Spark Savings vaults are covered by several hundred million dollars worth of protection against losses and risk events. #### Liquidity Spark Savings vaults maintain industry-leading levels of instantly available liquidity, making them suitable for institutional use cases. The Spark Savings USDT vault maintains a substantial instant liquidity buffer in SparkLend for redemptions (see the [USDT Strategy](/products/spark-savings/risk-architecture/usdt-strategy) page for the current deployment breakdown), while the Spark Savings USDC vault has capacity for billions of dollars of redemptions via integration with the Sky PSM. Savings Vault contracts maintain a liquidity buffer of up to $10 million to serve typical withdrawal volume via atomic redemptions. For larger-scale withdrawals, Spark offers an asynchronous liquidity intents mechanism allowing users to sign a withdrawal request for any amount, with the withdrawal then fulfilled rapidly via the Spark Liquidity Layer; large withdrawal requests are usually fulfilled within a few minutes. #### Transparency and Third-Party Ratings Spark Savings vaults operate with industry-leading transparency into backing assets and related allocation strategies. Real-time data on Spark and Sky backing is available via various open resources, including: * **Spark Data Dashboard:** [%%DATA\_DOMAIN%%](https://data.spark.fi) * **Sky Info Dashboard:** [info.skyeco.com](https://info.skyeco.com) * **Sky USDS Collateral Backing Dashboard:** [financial.skyeco.com/usds/collateral-backing](https://financial.skyeco.com/usds/collateral-backing) * **Spark App:** [%%APP\_DOMAIN%%](https://app.spark.fi) Additionally, Spark has [secured ratings](/products/spark-savings/risk-architecture/credora-rating) for Spark Savings products from Credora, an independent, leading crypto-native risk ratings provider. #### Incident Response In the event of a potential loss affecting Spark Savings vaults, Spark can put vaults into recovery mode to mitigate risk. Temporarily halting withdrawals ensures that all users receive equal treatment and avoids bank run scenarios. #### Staked USDS stUSDS carries increased risk relative to other Spark Savings vaults, including potential liquidity constraints and lack of automatic liquidations. #### Where to Verify | Item | Source | | ---------------------------------------- | ------------------------------------------------------------------------------- | | Spark Savings vault contracts | [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2) | | Savings Vault Intents contract | [Savings Vault Intents](/dev/savings/savings-vault-intents) | | All Spark contract addresses (canonical) | [Spark Address Registry](/dev/deployments) | | All Sky contract addresses (canonical) | [Sky Chainlog](https://chainlog.skyeco.com/) | | Vault collateral composition | [Spark App](https://app.spark.fi/) | | Spark balance sheet and treasury | [Spark Data Dashboard](https://data.spark.fi) | | Sky backing and capital dashboards | [Sky Info Dashboard](https://info.skyeco.com/) | | USDS collateral backing composition | [Sky Financial Dashboard](https://financial.skyeco.com/usds/collateral-backing) | | Audit reports | [Savings Audits](/dev/security/security-and-audits#savings) | #### Atlas Sources The following Sky Atlas sections govern the capital structure and controls described above: * [A.3.2](https://sky-atlas.io/#55999acf-75fe-4adf-8584-9746ef50d3e4) — Risk Capital * [A.3.2.1.2](https://sky-atlas.io/#be7589f5-32c0-42d2-8d10-38bceb1de28b) — Total Risk Capital and types of capital * [A.3.2.1.2.2.1.2](https://sky-atlas.io/#c201122a-75d2-44fa-b221-4e7c09bf42f2) — Junior Risk Capital loss allocation rules * [A.3.5](https://sky-atlas.io/#3eb6f099-2736-4f62-9cb8-096a8fcca757) — Surplus Buffer and Smart Burn Engine * [A.3.6](https://sky-atlas.io/#4d8b0d82-97da-4041-b185-4b98c2779cbe) — SKY Backstop * [A.6.1.1.1](https://sky-atlas.io/#dee2f5a4-279a-488c-9a9d-9583e3216fbf) — Spark (Prime Agent definition) ### FAQ #### What is the Sky Savings Rate? The Sky Savings Rate (SSR) is a feature of the Sky Protocol that enables any USDS holder to earn a savings rate on their USDS, paid out in USDS. It is funded by borrowing fees accrued by the Sky Protocol and is set by Sky Governance. Spark has no control over the Sky Savings Rate. The current rate is shown on the [Savings page in the Spark App](https://app.spark.fi/savings). The Sky Savings Rate powers the sUSDS and sUSDC (V1) vaults. Spark Savings V2 vaults (spUSDC, spUSDT, spETH, spPYUSD, spUSDG) earn yield through the Spark Liquidity Layer instead. #### How do I deposit into Spark Savings on other networks? On [%%APP\_DOMAIN%%/savings](https://app.spark.fi/savings) you can deposit accepted assets (USDS, USDC, USDT, PYUSD, ETH, USDG, etc.) on any supported network to obtain the corresponding Spark Savings vault token. The Spark Liquidity Layer routes liquidity across networks so deposits and withdrawals work on each supported chain. See [Spark Savings Guides](/products/spark-savings/guides/) for step-by-step workflows. #### How can I exit my Spark Savings position? You can swap your vault tokens (sUSDS, sDAI, stUSDS, sUSDC, spUSDC, spUSDT, spETH, spPYUSD, spUSDG) back into supported stablecoins or ETH on [%%APP\_DOMAIN%%/savings](https://app.spark.fi/savings). The Spark Liquidity Layer ensures ample liquidity for redemptions on all supported networks (stUSDS redemptions can be subject to liquidity constraints — see [Staked USDS](#staked-usds)). For larger withdrawals from spUSDC and spUSDT on Ethereum that exceed the idle liquidity buffer, the app submits a Savings Liquidity Intents request that is typically fulfilled within minutes — see [Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents). #### What's the difference between Spark Savings Vaults V2, V1, and Sky Savings Vaults? Spark Savings Vaults V1 only supported USDC, depositing it into the Sky Savings Rate. V2 expands this to any asset — USDC, USDT, PYUSD, ETH, and more — using the Spark Liquidity Layer to deploy assets across optimized yield strategies. All Spark Savings USD vaults (V1 and V2) are [backed by USDS](https://financial.skyeco.com/usds/collateral-backing), giving them the same underlying risk profile regardless of which stablecoin you deposit. #### Do I need to migrate my funds to Spark Savings Vaults V2? You can continue using your current vaults. #### Where does Spark Savings Vaults V2 allocate my deposits? Spark Savings Vaults V2 deploy your deposits through the Spark Liquidity Layer (SLL), which is designed to generate yield across Spark's entire balance sheet. The SLL strategically allocates assets across various protocols and yield strategies to optimize returns while maintaining liquidity and managing risk. You can see an overview of the collateral composition for each vault on the [Savings page in the Spark App](https://app.spark.fi/). #### How are vault rates determined and how often do they change? **Spark Savings Vaults V2 (spUSDC, spUSDT, spETH, spPYUSD, spUSDG):** * Rates are managed by Spark Governance based on market dynamics and underlying yield strategies **Spark Savings Vaults V1 (sUSDC) - Legacy:** * Rates are set by Sky Governance based on Sky Protocol's revenue from crypto-collateralized loans, U.S. treasury bills, and liquidity provisioning * Changes are made by Sky Governance and updated as needed **Sky Savings Vaults (sUSDS, sDAI):** * Rates are set by Sky Governance based on Sky Protocol's revenue from crypto-collateralized loans, U.S. treasury bills, and liquidity provisioning * Changes are made by Sky Governance and updated as needed #### How does the Spark Liquidity Layer ensure liquidity? The Spark Liquidity Layer is designed to always maintain sufficient liquidity for vault deposits and withdrawals. It does this by: * Keeping a sufficient liquid reserve to cover all expected withdrawals at any given time * Borrowing from [Sky's balance sheet](https://financial.skyeco.com/financials/balance-sheet) and potentially swapping to shore up liquidity in emergency situations * Dynamically managing asset allocations across integrated protocols * Maintaining strategic liquidity reserves This ensures users can always enter and exit vaults, even for large transactions. #### Is there slippage on deposits and withdrawals? When you deposit a token into its native vault, there is **no slippage**. For example: * Depositing **USDC** into **Spark USDC (spUSDC)** or **Savings USDC (sUSDC)** * Depositing **USDT** into **Spark USDT (spUSDT)** * Depositing **USDS** into **Savings USDS (sUSDS)** * Depositing **ETH** into **Spark ETH (spETH)** #### Are vault tokens transferable? Yes, all vault tokens follow the [ERC-4626 tokenized vault standard](https://eips.ethereum.org/EIPS/eip-4626), which extends ERC-20 — so they can be transferred or integrated into other DeFi protocols like any ERC-20 token. Your vault tokens represent your share of the vault and will continue accruing yield wherever they are held. #### Can I withdraw at any time? There are no lockup periods for any of the Savings Vaults. Spark Savings Vaults V2 keep an idle liquidity buffer in the vault for instant withdrawals. For larger withdrawals from **Spark Savings USDC** and **Spark Savings USDT** on **Ethereum Mainnet** that exceed the currently available idle liquidity, the app can submit a Savings Liquidity Intents request to the Spark Liquidity Layer, which is usually fulfilled within a few minutes. [Learn more about Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents). ## SparkLend SparkLend is Spark's permissionless money market for supplying assets, borrowing against collateral, and managing lending positions. It has always been operated conservatively relative to peers, with a narrow collateral set, multi-oracle pricing, strict rate limits, and first-loss capital. ### Guides Use these guides for step-by-step SparkLend workflows: * [Overview of Markets](/products/sparklend/guides/overview-of-markets) * [Supplying Assets](/products/sparklend/guides/supplying-assets) * [Borrowing Assets](/products/sparklend/guides/borrowing-assets) * [Borrow Stablecoins](/products/sparklend/guides/borrow-stablecoins) * [Adjusting Your Position](/products/sparklend/guides/adjusting-your-position) * [Repaying Your Loan](/products/sparklend/guides/repaying-your-loan) * [Liquidations](/products/sparklend/guides/liquidations) * [E-Mode](/products/sparklend/guides/e-mode) * [Isolation Mode](/products/sparklend/guides/isolation-mode) * [Oracles](/products/sparklend/guides/oracles) ### Risk Architecture SparkLend's risk pillars exist in isolation. They are designed to stack, so that a failure in any single component (oracle, issuer, liquidator, market liquidity) does not cascade into bad debt. #### Restricted Collateral Set SparkLend lists a deliberately short set of assets. ETH e-mode collateral is limited to wstETH and rETH. BTC e-mode has been fully removed: the deprecation was publicly noticed on the Sky forum, executed in the June 2026 spell, with remaining positions force-liquidated on June 8, 2026. The removal was done through a publicly telegraphed timeline rather than an immediate parameter flip. #### Supply and Borrow Caps Each listed asset has per-market supply and borrow caps configured by Sky Governance. Supply caps bound total exposure to any single asset, mitigating infinite-mint and oracle-manipulation risk on listed collateral. Borrow caps modulate how much of an asset can be drawn out, capping insolvency risk under stress. Caps integrate with the [Cap Automator](/dev/sparklend/features/supply-borrow-caps) so they scale with on-chain market depth rather than waiting on each governance cycle. #### Minimal Rehypothecation Collateral supplied to SparkLend reserves stays in the reserve. It is not redeployed into external strategies. #### Rate Limits Every cross-module flow into and out of SparkLend is rate-limited at the smart-contract level: deposits, withdrawals, cross-chain bridging, and PSM swaps each have configured rate limits. On top of that, Spark's allocation system enforces per-market debt ceilings and inventory min/max bands. A single depositor or a single adverse event cannot drain the protocol in a single block, and rate limits cap the maximum capital at risk on any single route per unit of time. #### Three-Oracle Median Pricing is aggregated using a three-oracle median that pulls data from RedStone, Chainlink, and Chronicle. When all three return valid, non-stale values, the median is used. When two are valid, their average is used. A single-feed fallback also exists. The outcome is that a compromised or faulty single oracle does not drive SparkLend prices. #### Killswitch Oracle for Pegged Assets For collateral that trades against a hardcoded or exchange-rate price (wstETH, rETH, weETH, cbBTC, WBTC, LBTC), a peg-ratio oracle continuously compares the asset's market price to its underlying. When the deviation breaches a per-asset threshold, the killswitch halts new borrowing on SparkLend, preventing users from posting distressed collateral at a stale "face value" price and walking out with healthy debt. #### Programmatic Liquidity Injection SparkLend's liquidity buffer is not static. The Spark Liquidity Layer automatically moves USDS, USDC, and USDT into and out of SparkLend based on target borrow rates, utilization, and available inventory at other venues. If SparkLend utilization runs high, the SLL tops up idle liquidity to allow withdrawals and liquidations to clear. If a venue elsewhere offers better risk-adjusted yield, idle capital rotates there. This is what it means for Spark to be the largest depositor in its own market: liquidity responds to demand rather than being rationed by utilization alone. #### USDC via USDS Routing A periphery integration can offer USDC delivery from a USDS-denominated position by sourcing USDS and swapping it 1:1 through Sky's mainnet LitePSM wrapper. In that pattern, the debt or source asset remains USDS while the wallet receives USDC. Verify the active SparkLend frontend and periphery contracts before relying on this as a specific transaction path. See the [LitePSM developer documentation](/dev/integration-guides/litepsm/) for the underlying Sky contract mechanics. #### Variable Liquidation Close Factor If a position's Health Factor drops below 1 but stays above 0.95, up to 50% of the position's debt can be covered in a liquidation call. At or below 0.95, up to 100% can be covered. The collateral transferred depends on the debt covered, oracle prices, and the applicable liquidation bonus. See [Liquidations](/products/sparklend/guides/liquidations) for the full mechanics. #### Granular Borrowing Power Control The borrowing power of any asset can be reduced down to 0% without impacting existing borrowers. This lets governance phase out a collateral type or tighten exposure on a live market without forced liquidations as the first response. Liquidating existing positions remains available where the situation requires it. #### Where to Verify | Item | Address or source | | -------------------------------- | ------------------------------------------------------------------------------------ | | Live market parameters | [Spark App](https://app.spark.fi/markets) | | Supply and borrow caps mechanism | [Supply & Borrow Caps](/dev/sparklend/features/supply-borrow-caps) | | Oracle configuration | [Oracles](/products/sparklend/guides/oracles) | | Liquidations | [Liquidations](/products/sparklend/guides/liquidations) | | Cap Automator audits | [SparkLend Cap Automator](/dev/security/security-and-audits#sparklend-cap-automator) | | SparkLend audits | [SparkLend Audits](/dev/security/security-and-audits#sparklend) | | Core contract addresses | [Spark Address Registry](/dev/deployments) | | Source code | [Spark GitHub](https://github.com/sparkdotfi) | #### Atlas Sources The following Sky Atlas sections govern the controls described above: **SparkLend specific:** * [A.6.1.1.1.3.2.1](https://sky-atlas.io/#d9ff0cd2-8999-4d3d-9670-2c7b49c1fe51) — SparkLend (parameters and operational processes) * [A.6.1.1.1.3.2.1.1.1](https://sky-atlas.io/#667abf8c-64a3-4029-b218-e7a6e7000bbd) — SparkLend Risk Parameters Definitions (LTV, Liquidation Threshold, Liquidation Bonus, Reserve Factor, Supply Cap, Borrow Cap, Interest Rate Model, Reserve State, E-Mode, Isolation Mode, Siloed Borrowing, Flash Loans) * [A.6.1.1.1.3.2.1.1.2](https://sky-atlas.io/#cb959917-c29c-4d2f-b151-ded03618357c) — SparkLend Risk Parameters Current Configuration (per-asset values) * [A.6.1.1.1.3.2.1.1.3](https://sky-atlas.io/#6ffdb8ee-b083-40f5-b51b-1c91e954b68b) — SparkLend Cap Automators * [A.6.1.1.1.2.6.1.1.2.1.1](https://sky-atlas.io/#c4a1d0ca-0794-4ad0-9920-7f8a837b6bfa) — SparkLend Mainnet Instances Directory * [A.6.1.1.1.2.6.1.3.1.1](https://sky-atlas.io/#1fdebcff-990a-40ac-8db6-8ef993edd57a) — SparkLend Instance Configuration Documents **Cross-cutting:** * [A.6.1.1.1](https://sky-atlas.io/#dee2f5a4-279a-488c-9a9d-9583e3216fbf) — Spark (Prime Agent definition) * [A.6.1.1.1.2.6.1](https://sky-atlas.io/#cd70b9f1-1a59-407c-9945-05e52bf5a3b6) — Allocation System Primitive * [A.6.1.1.1.2.2.2](https://sky-atlas.io/#f60887de-a4eb-4e4b-8aa6-e22cf724772a) — Spark Root Edit Primitive * [A.3.3](https://sky-atlas.io/#6478afd5-7c3f-4bed-a2b7-9f8ee402bb64) — Asset Liability Management ### FAQ For step-by-step questions on supplying, borrowing, repaying, and liquidations, see the [SparkLend Guides](/products/sparklend/guides/) — in particular the [Supplying Assets FAQ](/products/sparklend/guides/supplying-assets#faq) and [Borrowing Assets FAQ](/products/sparklend/guides/borrowing-assets#faq). #### On which networks is SparkLend supported? SparkLend is currently supported on Ethereum. #### What is the cost of interacting with SparkLend? Interacting with the protocol requires onchain transactions, so users pay the standard transaction fees of the network they are on. Fees depend on network conditions and transaction complexity. #### What is the difference between transparent and variable rate? Transparent rates act as a fixed rate in the short-term, but can change based on Sky Governance. The variable rate is set by supply and demand within SparkLend and changes continuously. #### What is the health factor? The health factor is the ratio of the value of your collateral, multiplied by the liquidation threshold, to the value of your debt. A higher health factor means your position is further from liquidation. If the health factor falls below 1, the position becomes liquidatable. See [Liquidations](/products/sparklend/guides/liquidations) for how to manage and avoid this. ## Adjusting Your Position ### Tutorial Having an active borrow position on Spark requires ongoing monitoring and management. These steps will guide you through how to effectively manage your position and to avoid liquidation. 1. To monitor your Spark position, navigate to the **My portfolio** page. ![](/assets/sparklend/supply-2.webp) *My portfolio* 2. The section **Your position** will show: * The value of the supplied collateral in USD * The value of the borrowed funds in USD. This accrues over time based on the borrow rate. * The maximum that can be borrowed, before violating the Loan-To-Value requirements. **Note:** If you do not have an active position, it will show an empty position, and a button below to create one using the **Easy Borrow Flow**. ![](/assets/sparklend/supply-5.webp) *Your Position: Shows collateral value, loan value, and the max borrow amount* 3. The **My portfolio** page also displays the current Health Factor of the borrow position. * The **Health Factor** is a measure of how close the position is to liquidation based on the current LTV. A Health Factor **below 1** means the position can be liquidated. Users are therefore responsible for keeping a Health Factor above 1, in order to avoid liquidation. The LTV of the position can change over time if the underlying collateral changes in value, and as debt accrues due to interest rates. * **Current Price** shows the current market price of the collateral asset. * If the price of the collateral asset reaches the **Liquidation Price**, the position can be liquidated. **Note:** If you are using more than one collateral type, the current price and liquidation price information is not displayed. ![](/assets/sparklend/supply-8.webp) *The Health Factor for your Spark position* 4. On the **My portfolio page** you have the necessary functionality to adjust your position. * In the **Supply** section you can supply and withdraw assets. [See the steps here](/products/sparklend/guides/supplying-assets). ![](/assets/sparklend/supply-3.webp) *Supply Section* * In the **Supply** section you can also enable or disable assets as collateral. Learn about this [here](/products/sparklend/guides/supplying-assets). * In the **Borrow** section you can borrow or repay assets. [See the steps here](/products/sparklend/guides/borrowing-assets). ![](/assets/sparklend/supply-9.webp) *Borrow Section* For example, if your position is close to liquidation you can either repay some or all of your loan, or supply more collateral. See the [supply assets](/products/sparklend/guides/supplying-assets) and [borrow asset](/products/sparklend/guides/borrowing-assets) sections for the step by step guide. 5. If your position is liquidated, your position will be updated accordingly and automatically. Depending on the exact situation for the liquidation you might still have an open borrow position. [You can read more about liquidations here](/products/sparklend/guides/liquidations). ### FAQ Find relevant FAQs here: * [**Supplying Assets FAQ**](/products/sparklend/guides/supplying-assets#faq) * [**Borrowing Assets FAQ**](/products/sparklend/guides/borrowing-assets#faq) ## Borrow Stablecoins ### Tutorial On the **Borrow Stablecoins** page, you can borrow stablecoins, by supplying crypto assets as collateral. If you wish to borrow other assets than stablecoins, navigate to the **My portfolio** page and follow the [supply assets](/products/sparklend/guides/supplying-assets) and [borrowing assets](/products/sparklend/guides/borrowing-assets) steps instead. 1. Navigate to the **Borrow Stablecoins** page. ![](/assets/sparklend/borrow-1.webp) *Navigating to Borrow stablecoins* ![](/assets/sparklend/borrow-2.webp) *The Borrow Stablecoins page* 2. Under **Supply** you can select the crypto asset in the dropdown menu you wish to supply as collateral for the loan. ![](/assets/sparklend/borrow-3.webp) *Easy Borrow Flow* 3. In the input bar on the left you specify the amount of collateral you wish to supply, denominated in the asset. The dollar value is displayed below. 4. On the right under Borrow, using the dropdown menu you can specify the asset you wish to borrow. ![](/assets/sparklend/borrow-5.webp) *Selection of which asset to borrow.* 5. Click on **Add more +** to add more crypto assets to be used as collateral. This will generate an additional supply bar, where you can select the asset and amount. ![](/assets/sparklend/borrow-4.webp) ![](/assets/sparklend/borrow-6.webp) *Supplying multiple collateral assets* 6. On the right side under **Borrow**, you specify the stablecoin amount you wish to borrow. 7. Below you are able to see the simulated state of the borrow position based on the current price of the collateral assets and the borrow amount. It displays: * **Loan to Value (LTV):** The percentage value of the borrow amount in USD in respect to the collateral amount in USD. * **The LTV slider:** Shows the current LTV percentage and its associated risk level ranging from Conservative to Moderate to Aggressive. You can drag the slider to adjust the borrow amount to specify an LTV percentage, which will adjust the borrow amount above accordingly. * **Liquidation Indicator**: The LTV slider also shows the LTV at which the position can be liquidated. The different collateral assets have a different liquidation LTV. Creating a position with multiple collateral assets will use an aggregate liquidation LTV based on the amount of each collateral. * **Max LTV:** The maximum allowed percentage value of the borrow amount in USD in respect to the collateral amount in USD. * **Borrow rate:** The annual percentage rate (APR) for borrowing. For USDS and DAI, this rate is set by Sky Governance. :::warning **Note:** Crypto assets are volatile so even conservative borrow positions should be monitored on an ongoing basis to prevent unwanted liquidations. [You can read more about liquidations here.](/products/sparklend/guides/liquidations) ::: 8. Once the parameters for the borrow position have been set, you click **Borrow**. 9. This will showcase the *Health Factor*, the *Liquidation Price* and the current *Collateral Pricing* for the position. ![](/assets/sparklend/borrow-7.webp) *The Health Factor Overview* * The **Health Factor** is a measure of how close the position is to liquidation based on the current LTV. A Health Factor **below 1** means the position can be liquidated. Users are responsible for keeping a Health Factor above 1, in order to avoid liquidation. The LTV of the position can change over time if the underlying collateral changes in value, and as debt accrues due to interest rates. * **Current Price** shows the current market price of the collateral asset provided by the price oracle. * If the price of the collateral asset reaches the **Liquidation Price**, the position can be liquidated. :::info **Note:** If you are using more than one collateral type, the current price and liquidation price information is not displayed. ::: 10. The **Actions** section below shows the transactions necessary to create the borrow position. You must click the buttons to sign each transaction with the connected wallet. ![](/assets/sparklend/borrow-8.webp) *Actions Window* * **Token Permit/Approval:** You must approve the supply of the collateral token. * **Supply:** You supply the collateral tokens into the borrow position. * **Borrow:** You borrow the specified amount of assets. 11. Once every step is done, you will have received the borrowed stablecoins in your wallet, and a confirmation and overview of the actions. You can click on **View in dashboard** to view your new position. ![](/assets/sparklend/borrow-9.webp) *Confirmation Window* ### FAQ You can find frequently asked questions relating to supplied collateral and borrowing here: * [**Supplying Assets FAQ**](/products/sparklend/guides/supplying-assets#faq) * [**Borrowing Assets FAQ**](/products/sparklend/guides/borrowing-assets#faq) ## Borrowing Assets ### Tutorial In order to borrow assets, you must first supply assets as collateral. [Click here](/products/sparklend/guides/supplying-assets) for a step by step supply guide. If you wish to borrow stablecoins in a simple manner you can use the [**Borrow Stablecoins**](/products/sparklend/guides/borrow-stablecoins) page. 1. To borrow assets navigate to the **My portfolio** page and scroll down to the **Borrow** section. ![](/assets/sparklend/supply-9.webp) *Borrow Section* 2. The **Borrow** section shows the following information: * The assets that can be borrowed * The available liquidity that can be borrowed * Your current borrow amount * The current borrow interest rate for the specific asset 3. If you are borrowing an asset that is correlated with the supplied collateral type, you can change the **E-Mode** to increase the borrow amount. ![](/assets/sparklend/e-mode.webp) This is available between ETH correlated assets (ETH, wstETH, rETH) and stablecoin correlated assets (USDC, USDT, sDAI, sUSDS, PYUSD), and allows for increased leverage. For example, you can enable E-mode if you are borrowing ETH using wstETH as collateral. If you are borrowing assets not supported in E-mode, you cannot enable E-mode. For example, if you have already borrowed WBTC against ETH, you cannot enable E-mode until this loan has been repaid. [You can read more about E-mode here.](/products/sparklend/guides/e-mode) ![](/assets/sparklend/e-mode-eth.webp) *E-mode Categories* 4. You can borrow an asset by navigating to the asset row, and clicking **Borrow**. 5. In the **Borrow window** you specify the amount you wish to borrow. In the **Transaction overview** it will display the Health Factor of the borrow position. The **Actions** section will guide you through the steps to create the borrow position. ![](/assets/sparklend/borrow-weth.webp) *Borrow Window: WETH* 6. Once you have done all the necessary transactions, you will receive the borrowed assets. Your overall position will be updated, which is reflected in the **Health Factor** and overview in **Your position**. ![](/assets/sparklend/borrow-weth-done.webp) *Confirmation: Borrowing WETH* 7. If you wish to borrow more at a later stage, you simply repeat this process. ### FAQ #### Why would I borrow instead of selling my assets? By borrowing you are able to obtain liquidity without selling your assets. Users are mainly borrowing to leverage their holdings or for new investment opportunities. #### How much can I borrow? The maximum amount you can borrow depends on the value of the collateral you have supplied and the available liquidity. For example, you cannot borrow an asset if there is not enough liquidity or if your health factor does not allow you to. #### What asset do I need to repay? You repay your loan in the same asset you borrowed. For example, if you borrow 1000 DAI you will pay back 1000 DAI + interest accrued. #### What is the difference between transparent and variable rate? Transparent rates act as a fixed rate in the short-term, but will change based on Sky Governance. The variable rate is the rate based on the supply and demand in SparkLend, and will constantly change. #### How much will I pay in interest? The interest rate you pay for borrowing assets depends on the borrowing rate which is derived from the supply and demand ratio of the asset in the case of the variable rate. The interest rate of a variable rate changes constantly. You can find your current borrowing rate at any time in the Borrow section of your Dashboard. #### What is the health factor? The health factor is the ratio of the value of your collateral, multiplied by the liquidation threshold, to the value of your debt. The higher Health Factor value is, the safer the state of your funds are against a liquidation scenario. If the health factor goes below 1, a liquidation of your supplied collateral will be triggered. #### What happens when my health factor is reduced? Depending on the value fluctuation of your supplied collateral, the health factor will increase or decrease. If your health factor increases, it will improve your borrow position by making the liquidation threshold more unlikely to be reached. In the case that the value of your collateral assets against the borrowed assets decreases, the health factor is reduced, causing the risk of liquidation to increase. #### When do I need to pay back the loan? There is no fixed time period to pay back the loan. As long as your position is safe, you can borrow for an undefined period. However, as time passes, the accrued interest will grow making your health factor decrease, which might result in your supplied assets becoming more likely to be liquidated. #### How do I pay back the loan? In order to payback the loan you simply go to the Borrowings section of your dashboard and click on the repay button for the asset you borrowed and want to repay. Select the amount to pay back and confirm the transaction. #### How do I avoid liquidation? In order to avoid the reduction of your health factor leading to liquidation, you can repay the loan or supply more collateral assets in order to increase your health factor. Learn more about liquidations here: * [Liquidations](/products/sparklend/guides/liquidations) #### How can I use permit? The permit function of SparkLend allows you to move your funds from a wallet by simply signing an approval message instead of approving a transaction on the network to avoid gas fees. ## E-Mode #### High Efficiency Mode (E-mode) The E-mode feature maximizes capital efficiency when collateral and borrowed assets have correlated prices. SparkLend currently groups assets into two E-Mode categories: **ETH Correlated** (ETH, wstETH, rETH) and **Stablecoins** (USDC, USDT, sDAI, sUSDS, PYUSD). Assets in the same category are price-correlated, so borrowing within a category unlocks higher collateralization power — for example, supplying wstETH as collateral in E-mode gives you higher borrowing power when borrowing ETH. The exact category membership and risk parameters are set by Sky Governance and can change over time. Some assets shown in a category may be deprecated or frozen while being offboarded — they remain in the category but are no longer recommended for new positions. The SparkLend app shows the categories and each asset's current status. Only assets of the same category (for example stablecoins) can be borrowed in E-mode. E-mode does not restrict the usage of other assets as collateral. Assets outside of the E-mode category can still be supplied as collateral with normal LTV and liquidation parameters. #### How do I enter E-mode? To enter E-Mode, go to **My portfolio** and find the **Borrow** section. Here you will find an **E-Mode Toggle**, which you can click. ![](/assets/sparklend/e-mode.webp) You can then select which E-mode category you wish to choose. ![](/assets/sparklend/e-mode-eth.webp) *Selection of E-Mode Category* You then submit the transactions in the **Actions** section to enable E-Mode. #### How do I exit E-mode? To exit E-mode, go to the **My portfolio** page and navigate to the **Borrow** section. Click on the E-Mode toggle and select No E-mode in the popup window. Carry out the transactions in the **Actions** section to exit E-mode. #### How does E-mode affect my borrowing power? When E-mode is enabled, you will have higher borrowing power over assets of the same E-mode category. ## Feature Overview This page summarises the core SparkLend features that determine how users supply, borrow, and manage positions on the protocol. For step-by-step workflows, follow the links into the relevant guides. ### Lending and Borrowing On SparkLend, users supply assets to liquidity markets where they can be borrowed by other users. Suppliers earn interest on supplied assets, and can use those assets as collateral to borrow other assets. Borrowers pay interest to lenders based on the supply and demand of the borrowed asset. For step-by-step workflows, see: * [Supplying Assets](/products/sparklend/guides/supplying-assets) * [Borrowing Assets](/products/sparklend/guides/borrowing-assets) ### Efficiency Mode (E-Mode) E-Mode allows borrowers to extract higher borrowing power from their collateral when supplied and borrowed assets are correlated in price — typically derivatives of the same underlying asset (e.g. ETH-correlated assets, or USD-pegged stablecoins). See [E-Mode](/products/sparklend/guides/e-mode) for how to enter and exit E-Mode. ### Isolation Mode New assets can be listed as *isolated*. Borrowers supplying an isolated asset as collateral cannot use other assets as collateral at the same time (other supplied assets can still earn yield). Positions in isolation mode can only borrow up to a per-asset debt ceiling. See [Isolation Mode](/products/sparklend/guides/isolation-mode) for the user flow. ### Siloed Borrowing Siloed borrowing allows assets with potentially manipulatable oracles to be listed on SparkLend as a single borrow asset: if a user borrows a siloed asset, they cannot borrow any other asset at the same time. This contains the risk associated with such assets so it cannot impact the overall solvency of the protocol. ### Flash Loans SparkLend supports same-block uncollateralised flash loans of any active reserve where the `flashLoanEnabled` flag is set. The borrowed amount plus a fee must be repaid in the same transaction, or the call reverts. SparkLend exposes two entry points: `flashLoan` (multi-asset) and `flashLoanSimple` (single-asset, gas-efficient). The flash-loan fee is waived for addresses holding `FLASH_BORROWER_ROLE` on the multi-asset variant. Unlike upstream Aave v3, SparkLend does **not** allow opening a borrow position from a flash loan — `flashLoan(..., interestRateModes, ...)` reverts if any `interestRateModes` entry is non-zero. To take on debt, use `borrow()` directly. For technical details and integration patterns, see [Flash Loans](/dev/sparklend/features/flash-loans). ## SparkLend Guides Use these guides to supply assets, borrow against collateral, manage your position, and understand SparkLend market features. For the product overview, risk architecture, and verification sources, start with [SparkLend](/products/sparklend). If you are new to SparkLend, start with the [Feature Overview](/products/sparklend/guides/feature-overview) for a concept-level introduction to lending, E-Mode, isolation mode, and siloed borrowing. ### Core Workflows * [Overview of Markets](/products/sparklend/guides/overview-of-markets) * [Supplying Assets](/products/sparklend/guides/supplying-assets) * [Borrowing Assets](/products/sparklend/guides/borrowing-assets) * [Borrow Stablecoins](/products/sparklend/guides/borrow-stablecoins) * [Adjusting Your Position](/products/sparklend/guides/adjusting-your-position) * [Repaying Your Loan](/products/sparklend/guides/repaying-your-loan) * [Liquidations](/products/sparklend/guides/liquidations) ### Market Features * [E-Mode](/products/sparklend/guides/e-mode) * [Isolation Mode](/products/sparklend/guides/isolation-mode) * [Oracles](/products/sparklend/guides/oracles) ## Isolation Mode Isolation mode allows Sky Governance to list new assets as isolated assets, which have a specific debt ceiling and can only be used as the sole collateral for a position. Whether a given asset is in isolation mode is set by Sky Governance and can change over time as markets are listed or reconfigured; the SparkLend app shows any assets that are currently isolated. The debt ceiling for an isolated asset is represented as the maximum amount in USD that can be borrowed against the user’s collateral. #### How can I enter isolation mode? The steps to entering isolation mode are as follows: 1. From the My portfolio page select an isolated asset to supply. 2. You will then see an information notification explaining that you are entering into isolation mode. 3. Once you have successfully entered isolation mode, you will then be able to supply an isolated asset. 4. You can also borrow assets once in isolation mode; however, you will only be able to borrow stablecoins up to a certain debt ceiling. #### How can I exit isolation mode? To exit isolation mode, you will need to disable the collateralized isolated asset that you have supplied. 1. On the **My portfolio** page in the **Supply** section, click the **Collateral** toggle to disable the isolated asset. 2. Confirm the disabled isolation mode setting. You have now successfully exited isolation mode. ## Liquidations ### What is a liquidation? A liquidation is a process that occurs when a borrower's [Health Factor](/products/sparklend/guides/borrowing-assets#what-is-the-health-factor) (HF) goes below 1 due to their collateral value not properly covering their loan/debt value. This might happen when the collateral decreases in value or the borrowed debt increases in value. In a liquidation up to 100 % (depending on your HF - [see below](#variable-liquidation-close-factor)) of a borrower's debt is covered by seizing the collateral and selling it to repay the debt. #### Variable Liquidation Close Factor The variable liquidation close factor is based on the Health Factor (HF) and allows for partial or full liquidation of the borrow position. If the HF is `< 1` but `> 0.95`, up to 50% of the position's debt can be repaid in a single liquidation. If the HF is at or below `0.95`, up to 100% of the debt can be repaid. ### How much is the liquidation penalty? The liquidation penalty (or bonus for liquidators) depends on the asset used as collateral. The liquidation penalty for each individual asset can be found on the [Markets page](/products/sparklend/guides/overview-of-markets). ### How can I avoid getting liquidated? It's important to monitor your health factor to avoid a liquidation. Keeping your health factor over 2, for example, gives you more of a margin to avoid a liquidation. To avoid liquidation you can raise your health factor by supplying more collateral assets or repaying part of your loan. ### Can I participate in the liquidations ecosystem? Yes, liquidations are open to anyone. Liquidators develop solutions and bots to be the first ones liquidating loans to get the liquidation bonus. You can find more details in the [developers liquidation section](/dev/sparklend/features/liquidations). ## Oracles SparkLend uses oracle price feeds to power its lending markets. Depending on the asset, different types of oracles are used, to ensure the proper pricing and risk management. The oracle price feeds are used to calculate the value of user collateral, and consequently how much a user can borrow, and when the system must liquidate risky positions. ### Oracle Providers SparkLend uses [Chronicle](https://chroniclelabs.org/), [Chainlink](https://chain.link/) and [RedStone](https://www.redstone.finance/) as oracle providers for the lending markets. You can see which Oracle is used for the specific market on the [Markets page](#where-can-i-check-what-oracle-is-being-used). ### Where can I check what Oracle is being used? On the [Spark App](https://app.spark.fi), in the “Borrow” dropdown menu in the top navigation bar, you can select “Markets”. From there, you click “Details” on the specific asset you wish to inspect, and scroll down to **Oracle type** section at the bottom. Here you will see the Oracle type, the current price, and the contract address for the Oracle smart contract. ### Who selects the Oracles? [Sky](https://sky.money) Governance controls which oracles are used by the SparkLend markets. ### Types of Oracles SparkLend uses different types of oracle price feeds depending on the asset and the lending market. #### Market Price A Market Price oracle reflects the live market value of the asset. This means the price the asset is currently being traded at on various exchanges. An example is ETH which uses a Market Price oracle. ![](/assets/sparklend/market-price.webp) *Market Price Oracle for ETH* #### Fixed Price With a Fixed Price oracle, the asset price is set by a contract at a predefined value, adjustable only through Sky governance decisions. For example, stablecoins such as USDS and DAI use a fixed price of 1.00 USD, which does not deviate even if the asset's market price moves away from this value. ![](/assets/sparklend/fixed-price.webp) *Fixed Price Oracle for Dai* #### Underlying Asset Price For an Underlying Asset Price oracle, the asset price is derived from a market price oracle tracking the value of the *underlying asset*, and not the asset itself. For example, a derivative asset such as cbBTC, uses a market price feed for its underlying asset BTC, and not a market price for cbBTC. ![](/assets/sparklend/underlying-asset.webp) *Underlying Asset Price for cbBTC* #### Yielding Fixed For a Yielding Fixed oracle, the asset price is calculated using both an exchange rate and a market price oracle. The exchange rate is a conversion rate of the asset and its underlying asset. An example is yielding assets such as wstETH (Wrapped Staked ETH), which uses the exchange rate between wstETH and its underlying asset WETH (Wrapped ETH), multiplied by the market price of the underlying asset WETH. ![](/assets/sparklend/yielding-fixed.webp) *Yielding Fixed Oracle for wstETH* ### Redundant Oracle Feeds For certain assets SparkLend uses oracle price feeds from Chronicle, Chainlink and RedStone, ensuring that in the unlikely event one price feed should fail, a redundant price feed will automatically be used. Finally, in the extremely unlikely event that price feeds from Chronicle, Chainlink and RedStone should fail at the same time, a Uniswap TWAP (time-weighted average price), is used as a fallback price feed. This ensures maximum protection for SparkLend users. You can see an example of this mechanism above in the Yielding Fixed Oracle used for wstETH. You can check if an asset uses redundant price feeds, by checking if it says "Redundant" in its Oracle type, on the specific Market page. [See here where to check the oracle type.](#where-can-i-check-what-oracle-is-being-used) ## Overview of Markets The **Markets** page displays an overview of the state of the protocol and the supported assets. The displayed data is specific to the selected network, so if you wish to browse another network, use the network toggle in the top right hand corner. ![](/assets/sparklend/markets-nav.webp) *Navigate to Markets Page* The Markets page displays: * The total market size * Total value locked (TVL) * Total borrows ![](/assets/sparklend/markets.webp) *The Markets Page* In the section below it displays the following data for each supported asset: * Total amount supplied * Supply APY * Total amount borrowed * Borrow APY * Status, which indicates certain risk modes for the assets: * Can it be supplied or not * Can it be used as collateral or not * Can it be borrowed or not, or is it in isolation mode ([read more here](/products/sparklend/guides/isolation-mode)). ![](/assets/sparklend/markets-2.webp) *Market Status: Specific for each asset* #### Active, Deprecated, and Frozen Markets The asset list is grouped into three sections: * **Active markets** — assets that are fully supported for supplying and borrowing. * **Deprecated** — markets that remain fully functional, but are no longer recommended for active use. Existing positions continue to work as normal; the protocol simply discourages new activity in these markets. * **Frozen** — assets frozen by Spark community (Sky Governance) decisions. Further supplying, borrowing, and rate swaps are unavailable, but withdrawals and debt repayments are still allowed. Assets can move between these sections over time as Sky Governance adjusts the supported market set, so always check the app for an asset's current status before opening a position. ![](/assets/sparklend/markets-deprecated-frozen.webp) *Deprecated and Frozen market sections* For each asset you can click on the details button to get a more in-depth overview of the metrics for the asset, and its parameters, such as liquidation threshold and penalty, and whether the asset can be used in E-mode. The page also displays which oracle is being used for this asset ([you can read more about this here](/products/sparklend/guides/oracles)). It also displays a more in-depth overview of the interest rate model for the asset. You are also able to supply or borrow the asset directly from this page, using the sidebar on the right. ![](/assets/sparklend/markets-3.webp) *Detailed Asset Overview* ## Repaying Your Loan ### Tutorial 1. To repay your loan, navigate to the **My portfolio** page and find the **Borrow** section. Assets that you have borrowed will show up in the **Your borrow** column. ![](/assets/sparklend/supply-9.webp) *Borrow Section: Click on repay on the right to initiate repayment of loan* 2. To repay your loan, click on the **Repay** button for the specific asset. 3. In the **Repay window**, you specify the amount of borrowed assets you wish to repay. You can choose to fully or partially repay your loan. To fully repay the loan, click on **MAX** in the input bar. ![](/assets/sparklend/repay.webp) *Repay USDS Loan* 4. Based on the specified amount, the transaction overview will display the remaining debt, and the health factor of the position. 5. The **Actions** section will guide you through the necessary transactions to repay the loan. 6. Once you have done all the necessary transactions, the specified amount of assets will be transferred from your wallet and be repaid to the pool. Your overall position will be updated, which is reflected in the **Health Factor** and overview in **Your position**. ![](/assets/sparklend/repay-1.webp) *Successful repayment* ### FAQ You can find more information here: * [**Supplying Assets FAQ**](/products/sparklend/guides/supplying-assets#faq) * [**Borrowing Assets FAQ**](/products/sparklend/guides/borrowing-assets#faq) ## Supplying Assets ### Tutorial In order to borrow assets, you must first supply assets as collateral such as ETH or cbBTC. Supplied assets can be borrowed by other users and therefore earn interest. You can also simply supply assets without borrowing, to earn interest. 1. To supply assets to SparkLend, navigate to the **My portfolio** page. ![](/assets/sparklend/supply-1.webp) *Navigate to My portfolio* ![](/assets/sparklend/supply-2.webp) *My Portfolio Page* 2. Scroll down to the **Supply** section which shows the following information: * **Assets:** The different assets that can be supplied to SparkLend * **In Wallet:** Amount of the specific asset in your wallet, and its value in USD. * **Supply**: Amount of the asset you have supplied to SparkLend. * **APY:** The current annual percentage yield. Supplied assets can be borrowed by other users, and therefore earn yield. ![](/assets/sparklend/supply-3.webp) *Supply Section* 3. You supply assets by clicking on the Supply button for the corresponding asset, which will open the **Supply window**. 4. The **Supply window** will display: * **Amount:** Here you specify the amount of the specific asset you wish to supply. * **Transaction overview:** Shows the supply APY for the asset and whether the asset is enabled as collateral. * **Actions**: An overview of the necessary transactions you must do to create the supply position. ![](/assets/sparklend/supply-4.webp) *Supply Dialog* 5. Once you supply assets, the position will be updated, which is reflected in the Health Factor[^1] and overview in **Your position**. ![](/assets/sparklend/supply-5.webp) *Your Position Overview* 6. You receive spTokens in return which reflect your supply position in Spark. You need these tokens to withdraw your assets from the protocol, so keep them in your wallet. 7. If you wish to supply more assets, for example to increase the *Health Factor* of your borrow position, you simply repeat this process. 8. You can use the **Collateral toggle** to enable or disable an asset as collateral for your borrow position. Disabling an already supplied asset as collateral will impact the Health Factor of your position, as the asset will no longer count towards the collateral value and loan to value. ![](/assets/sparklend/supply-6.webp) *Collateral Toggle: The toggle is green when the asset is enabled as collateral* ![](/assets/sparklend/supply-7.webp) *Disabling an asset as collateral* ### FAQ #### Is there a minimum or maximum supply amount? You can supply any amount you want, there is no minimum or maximum limit. However, it's important to note that for low amounts it is possible that the transaction cost of the process is higher than the expected earnings. It is recommended that you consider this when supplying low amounts. #### Where are my supplied funds stored? Funds are supplied to a non-custodial smart contract. The code of the smart contract is public, open source, formally verified and audited by third party auditors. No centralized entity can access supplied funds. #### How much will I earn? Suppliers receive continuous yield that fluctuates due to market conditions based on: * **The interest rate payment on loans:** Suppliers share the interests paid by borrowers. The higher the utilization of a reserve the higher the yield for suppliers. Each asset has its own market of supply and demand with its own APY (Annual Percentage Yield) which fluctuates over time. You can find the average annual rate over the past 30 days to evaluate the rate evolution, and you can also find more data on the reserve overview of each asset in the home section on the app. #### Can I opt-out my asset from being used as a collateral? Yes. After supplying your assets, you are able to unselect the asset so that it will not be used as collateral. The opt-out is available in the **Supply** section within your dashboard. Simply switch the **Collateral** toggle on the asset you would prefer to opt-out from being used as a collateral. You can withdraw your assets without opting out of using them as collateral, as long as those funds are not actively being lent out or the withdrawal would cause a liquidation on your loans. [^1]: The **Health Factor** is a measure of how close the position is to liquidation based on the current LTV. A Health Factor **below 1** means the position can be liquidated. Users are therefore responsible for keeping a Health Factor above 1, in order to avoid liquidation. The LTV of the position can change over time if the underlying collateral changes in value, and as debt accrues due to interest rates. ## Credora Risk Assessment Spark Savings vaults are subject to independent risk assessments by **Credora**, a DeFi risk analytics provider. Credora assigns a model-driven credit assessment to each Savings vault based on the **Probability of Significant Loss (PSL)**, which estimates the likelihood of a material loss of principal under stressed conditions. Ratings incorporate: * Collateral composition * Liquidity conditions * Smart contract maturity * Governance structure **Current assessments (Credora update as of 29 Jun 2026):** | Vault | Underlying Exposure | PSL | Rating | | ------ | -------------------------------- | ----- | ------ | | ETH | SparkLend ETH lending market | 0.39% | A | | PYUSD | USDS collateral backing | 0.15% | A | | USDC | USDS collateral backing | 0.49% | A- | | USDT | USDS collateral backing | 0.46% | A- | | USDS | USDS collateral backing | 0.52% | A- | | stUSDS | SKY/USDS isolated lending market | 1.03% | B+ | Ratings are model-driven and update when material changes occur in underlying exposures. *** ### Scope and Limitations * Ratings measure incremental credit risk of the vault structure. * Ratings exclude market price volatility of the deposited asset unless explicitly stated. * Ratings are based on publicly observable on-chain data, third-party analytics, and Credora’s proprietary risk models. * Ratings do not constitute investment advice. All ratings, probabilities, and qualitative assessments displayed here are provided by [Credora](https://www.credora.network/) and do not represent Spark’s own analysis. *** ### Data Sources and Methodology Credora ingests **position-level collateral data** and reconciles it against on-chain state across: * Lending markets * Liquidity pools * Reserve assets #### References * [Credora rating methodology](https://docs.redstone.finance/docs/redstone-credora/methodologies/) * [Full Credora rating report](https://reports.credora.io/spark/latest.pdf) ## USDT Strategy Spark Savings USDT (spUSDT) is a non-custodial, permissionless stablecoin savings vault backed by USDS (see [USDS Collateral Backing](https://financial.skyeco.com/usds/collateral-backing)). We surface the USDT liquidity strategy in particular because of the more restrictive liquidity profile in comparison to USDC, and highlight how well it performed during the rsETH incident of April 18th, 2026. This document sets out Spark's standing framework for idle liquidity management, how we approach venue selection, rate-setting, and liquidity buffers across market conditions, with the central goal of deploying capital above the **Minimum Liquidity Requirement (MLR)** efficiently without compromising SparkLend borrower liquidity or depositor redemption capacity. ### Core Principle: Tiered Deployment, Automated Liquidity Defense Spark operates a tiered deployment model. Capital is allocated in priority order from most liquid to least liquid, with an automated planner that withdraws from junior venues first when liquidity tightens. The goal is to keep SparkLend fully liquid at all times while earning a return on every USDT above the MLR buffer. * **SparkLend (Primary Venue).** SparkLend is the default and highest-priority deployment venue. USDT lent here is available on demand and earns the benchmark rate. Spark operates the largest on-chain USDT lending market by size, with cross-collateral capacity no other venue matches. Preserving SparkLend liquidity is non-negotiable - it underpins both depositor safety and borrower UX. * **Morpho Blue Chip Vault (Overflow Deployment).** Capital beyond SparkLend's absorption capacity is deployed into the Spark Morpho vault across blue-chip collateral markets (WBTC, cbBTC, sUSDS, wstETH). * **Duration Products (Capped, Risk-Adjusted).** A limited allocation to fixed-income, duration-bearing products (currently Maple Finance syrupUSDT) captures the yield premium available at the short end of the curve. This tier is intentionally capped. Duration allocation is sized against: (i) redemption lag relative to MLR stress scenarios, (ii) concentration of this allocation as a share of the total product, and (iii) the withdrawal cadence of large depositors. We do not increase this tier unless liquidity buffers and depositor composition clearly support it. * **DEX Liquidity & Stablecoin Inventory Management.** A portion of idle USDT is deployed into DEX liquidity pools as a capital-efficient alternative to holding cash. Spark currently maintains a USDT/sUSDS pool on Curve, which serves a dual purpose: it earns fees on stablecoin flows while acting as an on-chain inventory mechanism, allowing the planner to swap between USDT and USDC/sUSDS programmatically as inventory needs shift. Spark will introduce a USDT pool on Uniswap v4, which provides meaningfully stronger price-making and market-making capability relative to Curve's stable AMM design, enabling tighter spreads and more efficient inventory rebalancing at scale. Proceeds from these pools are deployed into Sky's sUSDS at the Sky Savings Rate (\~3.65% at the time of writing), the effective risk-free rate in the Sky ecosystem, materially reducing cash drag on idle balances without taking on duration or counterparty risk beyond the Sky stack. ### Rate-Setting Philosophy Spark sets spUSDT savings rates against three inputs: P\&L sustainability across the full deposit base, depositor composition, and on-chain borrow demand. Rates are adjusted to reflect what deployment yields can support. When borrow demand softens, rates move accordingly. We price for the full book, not the marginal depositor. The automated planner enforces a rate-response feedback loop: as liquidity approaches MLR thresholds, rates rise automatically to attract deposits and incentivise borrower repayment. The system replaces excess idle buffers that are not required as insurance. ### How We Respond to Market Stress The rsETH / KelpDAO incident in April 2026 produced $196M+ in Aave bad debt and a $13.2B DeFi TVL drawdown in 48 hours. Spark Savings USDT remained fully liquid throughout (see [What Changed and Why](#what-changed-and-why) below). The incident produced several durable changes to how we think about stress management: **Conservative MLR anchoring.** MLR is sized to the largest single-depositor exposure. During stress, large depositors run liquidity checks and make partial withdrawals. Spark's approach is to hold enough idle USDT in Spark Savings at all times to absorb these without triggering rate spikes that squeeze borrowers. **Duration risk is asymmetric.** In stress, the venues that fail first are duration products with redemption lags. Spark sizes duration allocations to ensure that even a full Morpho exit plus partial Maple redemption leaves SparkLend borrowers unaffected. Duration allocation is sized against the downside, not the yield. **Avoid over-deployment into yield at the cost of liquidity.** The implicit lesson from Aave's experience with rsETH is that reaching for yield through concentrated, leveraged, or bridge-backed collateral creates contagion pathways. Spark's collateral profile, blue-chip only, conservative LTV, rate-limited supply caps, is a structural risk differentiator, not just a positioning choice. ### Case Study: Rate Management Framework Spark's planner dynamically manages spUSDT supply rates against the liquidity position. When liquidity falls below a set threshold of MLR, the planner withdraws from Morpho. When it falls below the critical threshold of MLR, rates rise automatically to incentivize borrower repayment and new deposits. Meanwhile, the strategy can also set a benchmark rate target for both SparkLend and Morpho to maintain SparkLend's borrower depth as the primary cross-collateral venue, while using Morpho as an overflow deployment sink. ### Deployment Snapshot (May 5, 2026) | Venue | Allocation | Rate / Yield | Liquidity Profile | | :--------------------- | :---------------------- | :--------------------- | :----------------------------------- | | SparkLend USDT | \~$488M active borrows | 2.75% benchmark | Instant - on-demand | | SparkLend Idle | \~$156M idle in market | 0% (buffer) | Instant - MLR buffer | | Morpho Blue Chip Vault | \~$36M | 2.5-2.75% | Junior; withdrawn first under stress | | Maple syrupUSDT | $76M | 4.5% (capped) | 2-7 day redemption lag | | Idle | \~$734M (transitioning) | 3.65% via sUSDS (USDC) | Basis risk; managed manually | ### What Changed and Why * **Spark Savings USDT was the only major lending venue that remained fully liquid.** Spark held $400M+ in idle USDT throughout the crisis, never breaking below liquidity requirements. SparkLend TVL grew +50% in the days following the incident as the capital fled Aave to Spark. This validated maintaining a conservative idle buffer and not over-deploying into duration. * **On-chain borrow demand dropped sharply post-incident.** Post-incident borrower demand on SparkLend/Morpho collapsed. The on-chain USDT borrow market went from $642M peak borrow (April 26) to \~$488M by early May. Morpho asset spreads were cut post-incident to maximize Morpho deployment of otherwise-idle USDT. * **SLL USDT inventory wound down entirely.** The $150-250M USDT SLL inventory buffer (held ready for rapid cross-chain deployment) was wound down to zero. With borrower demand soft, holding large SLL inventory generated pure drag. The team will shift to more capital-efficient allocation strategies as indicated above. * **syrupUSDT capped; duration risk managed carefully.** Maple initially sought $100-175M at 2-week duration, which would have meant return compression at scale. Spark capped at $76M. ## Spark Savings Guides Spark Savings guides cover user workflows. For the product overview, vault listing, risk architecture, and verification sources, start with [Spark Savings](/products/spark-savings). ### Workflows * [Deposit & Withdraw](/products/spark-savings/guides/tutorial) * [Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents) For larger withdrawals from **Spark Savings USDC** and **Spark Savings USDT** on **Ethereum Mainnet**, see the [Savings Liquidity Intents guide](/products/spark-savings/guides/liquidity-intents). ## Savings Liquidity Intents Savings Liquidity Intents let users request larger withdrawals from Spark Savings when the amount exceeds the idle liquidity currently available in the vault. Initially, this flow is available only on **Ethereum Mainnet** for **Spark Savings USDC** and **Spark Savings USDT**. Spark Savings vaults keep a portion of assets as instantly withdrawable liquidity. In the app, this is shown as **Idle** in the **Liquidity** tab. This idle liquidity acts as the minimum withdrawal buffer kept in the vault. When users withdraw from that buffer, the Spark Liquidity Layer refills it again. For larger withdrawals that exceed the currently available idle liquidity, the app can use Savings Liquidity Intents and submit an asynchronous withdrawal request that is usually fulfilled within a few minutes. ### Check available idle liquidity 1. Navigate to the **Savings** page in the [Spark App](https://app.spark.fi/) and select the **USDC** or **USDT** vault. ![](/assets/savings/savings-liquidity-intents-view.webp) *Savings page* 2. Open the **Liquidity** tab to see how vault liquidity is allocated. The amount labeled **Idle** is the liquidity currently available for instant withdrawals. ![](/assets/savings/savings-liquidity-intents-idle-liquidity.webp) *Idle liquidity* ### Request a larger withdrawal 1. Click the **Withdraw** button in the main vault panel. 2. In the withdraw window, the withdrawal asset is preselected for supported vaults. Enter the amount you want to withdraw. 3. If the withdrawal will use Savings Liquidity Intents, the dialog will show that the request uses the asynchronous withdrawal process powered by the Spark Liquidity Layer. ![](/assets/savings/savings-liquidity-intents-withdraw-dialog.webp) *Withdraw with Savings Liquidity Intents* 4. Complete the actions shown in the **Actions** section and confirm the request in your wallet. 5. After submission, the app will show a confirmation screen. This confirms that the withdrawal request was created. The Spark Liquidity Layer still needs to fulfill it before the funds arrive in your wallet. ![](/assets/savings/savings-liquidity-intents-success.webp) *Withdrawal request submitted* 6. After you close the dialog, the request will appear in the **Requested withdrawal** table on the Savings page with a **Pending** status and an estimated completion time. ![](/assets/savings/savings-liquidity-intents-pending-request.webp) *Pending withdrawal request* 7. Once the request is fulfilled, the withdrawn funds are transferred to your wallet automatically. ### Cancel a withdrawal request 1. Withdrawal requests cannot be cancelled during the first hour after submission. During that period, the **Cancel** button is disabled in the **Requested withdrawal** table. ![](/assets/savings/savings-liquidity-intents-cancellation-disabled.webp) *Cancellation unavailable during the first hour* 2. If the Spark Liquidity Layer has not fulfilled the request within one hour, the **Cancel** button becomes available. ![](/assets/savings/savings-liquidity-intents-cancellation-enabled.webp) *Cancellation available after one hour* 3. Click **Cancel** and confirm the cancellation request in the dialog. ![](/assets/savings/savings-liquidity-intents-cancellation-dialog.webp) *Cancel withdrawal request* 4. After the transaction is confirmed, the app will show a success screen confirming that the withdrawal request has been cancelled. ![](/assets/savings/savings-liquidity-intents-cancellation-confirmation.webp) *Withdrawal request cancelled* ## Deposit & Withdraw From Spark Savings In this tutorial, you will learn how to deposit and withdraw assets from Spark Savings. ### Deposit Savings 1. To earn yield on your assets navigate to the **Savings** page at [%%APP\_DOMAIN%%](https://app.spark.fi). Make sure you are connected to the network you wish to use. ![](/assets/savings/savings-v2-1.webp) *Savings Page* 2. To the left, you can see which Savings Vaults are available. Each vault displays its current Annual Percentage Yield (APY). Click on any vault to see more details, such as the collateral composition and supported assets, or to deposit. You can also see the TVL, users, deposit cap and available liquidity in the top bar. 3. When you select a vault, you'll see: * Current and historical rates * Savings rate, collateral composition, risk assessment and more * Supported deposit assets ![](/assets/savings/savings-rate-card.webp) *Savings Rate* ![](/assets/savings/collateral-composition-card.webp) *Collateral Composition* ![](/assets/savings/liquidity-card.webp) *Liquidity* ![](/assets/savings/risk-rating-card.webp) *Risk Rating* 4. To deposit, click the **Deposit** button for your selected vault. ![](/assets/savings/savings-v2-2.webp) *Deposit Window* 5. In the deposit window, specify: * The asset you want to deposit (if the vaults support multiple assets for deposits) * The amount you wish to deposit To finalize the deposit, execute the transactions in the **Actions** section. 6. Once you complete the transactions, your assets will be deposited and you'll receive vault tokens (e.g., spUSDC, spUSDT, spETH, sUSDS, etc.) representing your share of the vault. ![](/assets/savings/savings-v2-3.webp) *Confirmation: Savings Deposit* 7. Your vault tokens are ERC-4626 shares: their quantity stays the same in your wallet, but each share is worth more underlying asset over time as the Vault Savings Rate (VSR) accrues. You need these tokens to withdraw your deposits and accrued yield in the future, so keep them safe in your wallet. 8. After your deposit, you'll see your balance grow in real time as yield accrues. You can also see your projected earnings in the **1-year Projection** section. ![](/assets/savings/savings-v2-8.webp) *Accruing Yield* ### Withdraw Savings 1. When you wish to withdraw from a vault, click the **Withdraw** button for your selected vault. In the withdraw window, the withdrawal asset is preselected for supported vaults. Enter the amount you wish to withdraw. ![](/assets/savings/savings-v2-6.webp) *Withdraw from Savings* 2. The UI will show you: * The amount you'll receive * Transaction steps in the **Actions** section **Note:** Spark Savings Vaults V2 keep an idle liquidity buffer for instant withdrawals. For larger withdrawals from **Spark Savings USDC** and **Spark Savings USDT** on **Ethereum Mainnet** that exceed the currently available idle liquidity, the app may use **Savings Liquidity Intents**, which submit an asynchronous withdrawal request to the Spark Liquidity Layer. These requests are usually fulfilled within a few minutes. [Learn more about Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents). 3. Execute the transactions in the **Actions** section. Once complete, your vault tokens will be burned and you'll receive your specified asset along with all accrued yield. ![](/assets/savings/savings-v2-7.webp) *Confirmation: Withdrawal from Savings* ## Spark Points The Spark Points program enables users to earn Spark Points by participating in campaigns that reward certain user actions that contribute to the growth of the Spark ecosystem. ### How do I earn Spark Points? You earn Spark Points by participating in points campaigns. Navigate to the Spark Points page at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points) to find an overview of active campaigns and how you can participate. As soon as you participate in a points campaign you will start accruing points. 1. Navigate to the [Points page](https://app.spark.fi/points). ![](/assets/points-landing.webp) *Navigate to the points page* 2. Put in a referral code if you have one. You can read more about [referral codes below](#referral-boost). If you do not have a code, simply click “I don’t have an invite code” to skip this. ![points-3.webp](/assets/points-3.webp) *Insert referral code or skip* 3. Start participating by following the campaign actions. ![points-4.webp](/assets/points-4.webp) *Choose a campaign to participate in* 4. Invite others, by using your referral code or link to earn even more points! ![referral-1.webp](/assets/referral-1.webp) *Invite others using your referral code* 5. Check your ranking in the leaderboard at [https://points.%%SPARK\_DOMAIN%%/](https://points.spark.fi/) or simply watch your points accrue over time. ![points-5.webp](/assets/points-5.webp) *Spark Points Leaderboard* ### Seasons The Spark Points program is divided into seasons. Each season has a different set of campaigns and rewards. * Season 1: May 14, 2025 to August 12, 2025 * Season 2: August 12, 2025 to December 12, 2025 * Season 3: December 12, 2025 to April 13, 2026 * Season 4: April 13, 2026 to August 12, 2026. ### Campaigns You can find the active campaigns and how to participate at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). ### Points Accrual Points accrue per second based on your participation in the rewarded actions. You can track your points at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). ### Referral Boost The Spark Points program includes a referral program. If a user signs up using your referral code, you will earn extra points on top of all the points your referrals earn. You can find the current referral boost at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). To get your referral code, simply click on the “Invite” button on the Referral boost action, and share the link with your friends. ![referral-1.webp](/assets/referral-1.webp) *Invite others using your referral code* ### Loyalty Boost Users who participated in the previous season and continue into the current season can receive a one-time **loyalty bonus** based on the points they earned in the previous season. You can find the qualification details for the current season's loyalty bonus at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). ### Leaderboard At [https://points.%%SPARK\_DOMAIN%%/](https://points.spark.fi/) you will find a leaderboard of the highest Spark points earners. Use your referral code to earn more points, and climb the leaderboards! ## Earn Spark Points on Pendle :::info **The Pendle campaign ended on August 12, 2025.** ::: The Pendle Campaign enabled users to earn Spark Points by holding YT-USDS tokens or by providing liquidity into the PT-USDS/USDS pool on Pendle. ### Points Distribution #### YT-USDS Users earned Spark Points every day for each YT-USDS they were holding in their wallet. #### Providing PT-USDS/USDS liquidity Users earned Spark Points every day for each USDS (SY-USDS) that they were providing as liquidity in the Pendle pool. **Note:** This means LPs were only earning Spark points on the USDS part of the liquidity position. However, this was in addition to any yield LPs may have earned from Pendle. ### Campaign Duration The Pendle Campaign ran from May 14 to August 12, 2025. ### How to Participate During the campaign, users could participate as follows: 1. Navigate to [%%APP\_DOMAIN%%/points](https://app.spark.fi/points) and connect your wallet. ![](/assets/points-landing.webp) *Navigate to the points page, and connect wallet* 2. Optional: Use a referral code if you have one. Otherwise, skip this step by clicking “I don’t have an invite code”. ![points-3.webp](/assets/points-3.webp) *Insert referral code or skip* 3. Navigate to the [Pendle pool](https://app.pendle.finance/trade/pools/0x1d7d382ea7ceabb8d7c14ef066124d2e575698f8/zap/in) by clicking “Buy” and acquire either YT-USDS tokens, or provide liquidity into the PT-USDS/USDS pool. ![points-4.webp](/assets/points-4.webp) *Navigate to the Pendle pool, and purchase YT-USDS or provide liquidity* 4. Points accrued immediately and could be tracked at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). ![points-5.webp](/assets/points-5.webp) *Overview of accrued points* 5. Users who invited friends with their referral code earned a share of the points those users earned. You can still track your position in the leaderboards at [points.%%SPARK\_DOMAIN%%](https://points.spark.fi) ![referral-1.webp](/assets/referral-1.webp) *Generate Referral Code* ## Earn Spark Points by Staking SPK The SPK Staking Campaign enables users to earn Spark Points by staking SPK tokens on the Spark app. ### Points Distribution #### SPK Staking Users earn Spark Points every day for each SPK token they are staking on the Spark app. You can find the current campaign details at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). ### How to Participate 1. Navigate to [%%APP\_DOMAIN%%/points](https://app.spark.fi/points) and connect your wallet. ![](/assets/points-landing.webp) *Navigate to the points page, and connect wallet* 2. Optional: Use a referral code if you have one. Otherwise, skip this step by clicking "I don't have an invite code". ![points-3.webp](/assets/points-3.webp) *Insert referral code or skip* 3. Navigate to the SPK staking section on the Spark app and stake your SPK tokens. ![](/assets/staking/staking-1.webp) *Navigate to the staking section and stake your SPK tokens* ![](/assets/staking/staking-2.webp) 4. You will start accruing points immediately which you will be able to track at [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). Note: It might take a few minutes for your points score to be displayed. ![points-5.webp](/assets/points-5.webp) *Overview of accrued points* 5. Invite your friends using your referral code to earn even more points. For each user who signs up using your referral code, you will earn a share of the points that user earns. To get your referral code, simply click on the "Invite" button on the Referral boost action, and share the link with your friends. You can track your position in the leaderboards at [points.%%SPARK\_DOMAIN%%](https://points.spark.fi) ![referral-1.webp](/assets/referral-1.webp) *Generate Referral Code* | 0 | Table of content | | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Date of notification** | 16/04/2025 | | **2** | **Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114** | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper. | | **3** | **Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114** | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. | | **4** | **Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper may lose its value in part or in full, may not always be transferable and may not be liquid. | | **5** | **Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114** | FALSE | | **6** | **Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.
The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. | | **SUMMARY** | | | | **7** | **Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114** | Warning

This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.

The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.

This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. | | **8** | **Characteristics of the crypto-asset** | SPK (the "***Token***") will be launched as an ERC-20 token on the Ethereum blockchain. The Token will provide its holders with a set of rights within Spark (the "***Project***"), a decentralised finance application. Token holders will be able to stake their Tokens and earn protocol rewards. It is anticipated that staked Tokens will be used to secure one or more components of the Project, such as, for example, the SkyLink Bridge.

It is also anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. | | **09** | | Not applicable | | **10** | **Key information about the offer to the public or admission to trading** | Spark Foundation (the "***Foundation***") seeks admission of the Token to trading on multiple trading platforms (the "***Exchanges***") in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. | | **Part I – Information on risks** | | | | **I.1** | **Offer-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted. Additionally, the Token's underlying protocol and governance structure may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Project's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.

| | **I.2** | **Issuer-Related Risks** | Not applicable, as the only purpose of the Issuer is to issue and distribute the Token. | | **I.3** | **Crypto-Assets-related Risks** | | | **I.4** | **Project Implementation-Related Risks** | | | **I.5** | **Technology-Related Risks** | | | **I.6** | **Mitigation measures** | Not applicable | | **Part A - Information about the offeror or the person seeking admission to trading** | | | | **A.1** | **Name** | Spark Foundation | | **A.2** | **Legal form** | Foundation company limited by guarantee without share capital | | **A.3** | **Registered address** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.4** | **Head office** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.5** | **Registration Date** | 05/02/2025 | | **A.6** | **Legal entity identifier** | Not available | | **A.7** | **Another identifier required pursuant to applicable national law** | 418210 | | **A.8** | **Contact telephone number** | 001 345-749-9601 | | **A.9** | **E-mail address** | Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) | | **A.10** | **Response Time (Days)** | Fourteen (14) days | | **A.11** | **Parent Company** | Not applicable | | **A.12** | **Members of the Management body** | **Glenn Kennedy** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
**Marc Piano** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.13** | **Business Activity** | To support, promote, and advance the development, adoption, security, and growth of Spark. | | **A.14** | **Parent Company Business Activity** | Not applicable | | **A.15** | **Newly Established** | TRUE | | **A.16** | **Financial condition for the past three years** | Not applicable | | **A.17** | **Financial condition since registration** | The Foundation will be capitalised as needed to fulfil its mandate of supporting the Spark ecosystem. It has no debt and being a brand new company, should have no material liabilities as of the date of this whitepaper. | | **Part B - Information about the issuer, if different from the offeror or person seeking admission to trading** | | | | **B.1** | **Issuer different from offeror or person seeking admission to trading** | TRUE | | **B.2** | **Name** | SPK Company Ltd. | | **B.3** | **Legal form** | Company limited by shares | | **B.4** | **Registered address** | Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands | | **B.5** | **Head office** | Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands | | **B.6** | **Registration Date** | 19/02/2025 | | **B.7** | **Legal entity identifier** | Not available | | **B.8** | **Another identifier required pursuant to applicable national law** | 2170013 | | **B.9** | **Parent Company** | Spark Foundation | | **B.10** | **Members of the Management body** | The sole director of the Issuer is **Spark Foundation**
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **B.11** | **Business Activity** | The only purpose is to issue and distribute the Token. | | **B.12** | **Parent Company Business Activity** | See Section A.13. | | **Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | | | | **C.1** | **Name** | Not applicable | | **C.2** | **Legal form** | Not applicable | | **C.3** | **Registered address** | Not applicable | | **C.4** | **Head office** | Not applicable | | **C.5** | **Registration Date** | Not applicable | | **C.6** | **Legal entity identifier of the operator of the trading platform** | Not applicable | | **C.7** | **Another identifier required pursuant to applicable national law** | Not applicable | | **C.8** | **Parent Company** | Not applicable | | **C.9** | **Reason for Crypto-Asset White Paper Preparation** | Not applicable | | **C.10** | **Members of the Management body** | Not applicable | | **C.11** | **Operator Business Activity** | Not applicable | | **C.12** | **Parent Company Business Activity** | Not applicable | | **C.13** | **Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable | | **C.14** | **Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable | | **Part D - Information about the crypto-asset project** | | | | **D.1** | **Crypto-asset project name** | Spark | | **D.2** | **Crypto-assets name** | Spark | | **D.3** | **Abbreviation** | SPK | | **D.4** | **Crypto-asset project description** | The Project is a DeFi protocol which emerged from Sky, previously known as MakerDAO, and serves as a 'Sky Star', a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. | | **D.5** | **Details of all natural or legal persons involved in the implementation of the crypto-asset project** | **SPK Company, Ltd.** c/o SHRM Trustee (BVI) Ltd. Trinity Chambers PO Box 4301 Road Town, Tortola, British Virgin Islands
**Spark Foundation** c/o Leeward Management Limited Suite 3119, 9 Forum Lane Camana Bay, George Town, Grand Cayman KY1-9006, Cayman Islands | | **D.6** | **Utility Token Classification** | FALSE | | **D.7** | **Key Features of Goods/Services for Utility Token Projects** | Not applicable | | **D.8** | **Plans for the token** | **Rewards:** Soon after the token generation event, a portion of the Token allocation will be used for airdrops to reward early supporters of the Project as well as its early users. Tokens may also be used in the future to reward users who use the Project.
**Staking in exchange for Rewards:** Token holders who stake the Token will receive protocol rewards. It is anticipated that staked Tokens will be used to secure one or more components of the Project, such as, for example, the SkyLink Bridge. Unstaking may be subject to a cooldown period.
**Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. | | **D.9** | **Resource Allocation** | Allocated resources include technical resources from developers, legal and compliance resources from counsel, and financial resources by means of grants from Sky's DAO. | | **D.10** | **Planned Use of Collected Funds or Crypto-Assets** | Not applicable | | **Part E - Information about the offer to the public of crypto-assets or their admission to trading** | | | | **E.1** | **Public Offering or Admission to trading** | ATTR | | **E.2** | **Reasons for Public Offer or Admission to trading** | The Foundation seeks admission of the Token to trading on multiple Exchanges in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. | | **E.3** | **Fundraising Target** | Not applicable | | **E.4** | **Minimum Subscription Goals** | Not applicable | | **E.5** | **Maximum Subscription Goal** | Not applicable | | **E.6** | **Oversubscription Acceptance** | Not applicable | | **E.7** | **Oversubscription Allocation** | Not applicable | | **E.8** | **Issue Price** | Not applicable | | **E.9** | **Official currency or any other crypto-assets determining the issue price** | Not applicable | | **E.10** | **Subscription fee** | Not applicable | | **E.11** | **Offer Price Determination Method** | Not applicable | | **E.12** | **Total Number of Offered/Traded Crypto-Assets** | Not applicable | | **E.13** | **Targeted Holders** | ALL | | **E.14** | **Holder restrictions** | The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange.
The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. | | **E.15** | **Reimbursement Notice** | Not applicable | | **E.16** | **Refund Mechanism** | Not applicable | | **E.17** | **Refund Timeline** | Not applicable | | **E.18** | **Offer Phases** | Not applicable | | **E.19** | **Early Purchase Discount** | Not applicable | | **E.20** | **Time-limited offer** | Not applicable | | **E.21** | **Subscription period beginning** | Not applicable | | **E.22** | **Subscription period end** | Not applicable | | **E.23** | **Safeguarding Arrangements for Offered Funds/Crypto-Assets** | Not applicable | | **E.24** | **Payment Methods for Crypto-Asset Purchase** | Not applicable | | **E.25** | **Value Transfer Methods for Reimbursement** | Not applicable | | **E.26** | **Right of Withdrawal** | Not applicable | | **E.27** | **Transfer of Purchased Crypto-Assets** | Not applicable | | **E.28** | **Transfer Time Schedule** | Not applicable | | **E.29** | **Purchaser's Technical Requirements** | Technical requirements will be specified by the Exchanges and may include the following: A compatible digital wallet or account on supported Exchange; Internet access; A device (computer or mobile) to manage digital wallet/private key and/or account on exchange to carry out transactions | | **E.30** | **Crypto-asset service provider (CASP) name** | Not applicable | | **E.31** | **CASP identifier** | Not applicable | | **E.32** | **Placement form** | NTAV | | **E.33** | **Trading Platforms name** | **OKX**: [https://www.okx.com/](https://www.okx.com/)
**Binance**: [https://www.binance.com/](https://www.binance.com/)
**Upbit**: [https://upbit.com/](https://upbit.com/)
**Coinbase**: [https://www.coinbase.com/](https://www.coinbase.com/)
**Bybit**: [https://www.bybit.com/](https://www.bybit.com/)
**Gate.io**: [https://www.gate.io/](https://www.gate.io/)
**Bithumb**: [https://www.bithumb.com/](https://www.bithumb.com/)
**KuCoin**: [https://www.kucoin.com/](https://www.kucoin.com/)
**Kraken**: [https://www.kraken.com/](https://www.kraken.com/)
**Bitget**: [https://www.bitget.com/](https://www.bitget.com/)
**HTX**: [https://www.htx.com/](https://www.htx.com/)
**Crypto.com**: [https://crypto.com/](https://crypto.com/)
**Bitvavo**: [https://bitvavo.com/](https://bitvavo.com/)
**Bitkub**: [https://www.bitkub.com/](https://www.bitkub.com/)
**MEXC**: [https://www.mexc.com/](https://www.mexc.com/)
**Coinone**: [https://coinone.co.kr/](https://coinone.co.kr/)
**Bitstamp**: [https://www.bitstamp.net/](https://www.bitstamp.net/)
**Revolut**: [https://www.revolut.com/](https://www.revolut.com/)
**Paribu**: [https://www.paribu.com/](https://www.paribu.com/)
**Pintu**: [https://pintu.co.id/](https://pintu.co.id/)
**LBank**: [https://www.lbank.info/](https://www.lbank.info/)
**Bitpanda**: [https://www.bitpanda.com/](https://www.bitpanda.com/)
**Ourbit**: [https://www.ourbit.com/](https://www.ourbit.com/)
**Hashkey**: [https://www.hashkey.com/](https://www.hashkey.com/)
**Bitfinex**: [https://www.bitfinex.com/](https://www.bitfinex.com/)
**CoinDCX**: [https://coindcx.com/](https://coindcx.com/)
**BTSE**: [https://www.btse.com/](https://www.btse.com/)
**BitMEX**: [https://www.bitmex.com/](https://www.bitmex.com/)
**XT.COM**: [https://www.xt.com/](https://www.xt.com/)
**Bilaxy**: [https://www.bilaxy.com/](https://www.bilaxy.com/)
**AscendEX**: [https://ascendex.com/](https://ascendex.com/)
**CoinList**: [https://coinlist.co/](https://coinlist.co/)
**BingX**: [https://www.bingx.com/](https://www.bingx.com/)
**BitMart**: [https://www.bitmart.com/](https://www.bitmart.com/)
**CoinW**: [https://www.coinw.com/](https://www.coinw.com/)
**WhiteBIT**: [https://whitebit.com/](https://whitebit.com/)
**Bitrue**: [https://www.bitrue.com/](https://www.bitrue.com/)
**Phemex**: [https://phemex.com/](https://phemex.com/)
**WazirX**: [https://wazirx.com/](https://wazirx.com/)
**WOO X**: [https://woo.org/](https://woo.org/)
**Poloniex**: [https://poloniex.com/](https://poloniex.com/)
| | **E.34** | **Trading Platforms Market Identifier Code (MIC)** | Not applicable | | **E.35** | **Trading Platforms Access** | The Exchanges are accessible via their respective websites. | | **E.36** | **Involved costs** | Not applicable | | **E.37** | **Offer Expenses** | Not applicable | | **E.38** | **Conflicts of Interest** | Not applicable | | **E.39** | **Applicable law** | This white paper is being published solely for purposes of admission to trading, not an offer to the public of the Token. However, subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. | | **E.40** | **Competent court** | See Section E.39. | | **Part F - Information about the crypto-assets** | | | | **F.1** | **Crypto-Asset Type** | Crypto-asset other than an asset-referenced token or e-money token | | **F.2** | **Crypto-Asset Functionality** | According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA.
The Token qualifies as a crypto-asset within the meaning of MiCA, as it is a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT").
The Token displays the following functionalities: **Staking in exchange for Rewards:** Token holders who stake the Token will receive protocol rewards. It is anticipated that staked Tokens will be used to secure one or more components of the Project. Unstaking may be subject to a cooldown period. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. | | **F.3** | **Planned Application of Functionalities** | At the time of publication of this whitepaper, the Foundation anticipates the following: the staking feature described in Section F.2 and in other parts of this whitepaper will be available for the Token holders following the Token Generation Event (***'TGE'***); and the governance feature described in Section F.2 and in other parts of this whitepaper will evolve over time by the governance community and development team. Any governance rights granted to Token holders will be subject to any rules applicable to the Project's governance, including but not limited to the Sky Atlas. | | **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** | | | | **F.4** | **Type of white paper** | OTHR | | **F.5** | **The type of submission** | NEWT | | **F.6** | **Crypto-Asset Characteristics** | See Section 8. | | **F.7** | **Commercial name or trading name** | Spark | | **F.8** | **Website of the issuer** | Neither the Foundation nor the Issuer have a website.
The website of the Project is [%%SPARK\_URL%%/](https://spark.fi/) | | **F.9** | **Starting date of offer to the public or admission to trading** | 28/05/2025 | | **F.10** | **Publication date** | 19/05/2025 | | **F.11** | **Any other services provided by the issuer** | Neither the Foundation nor the Issuer provide any other services not covered by Regulation (EU) 2023/1114. | | **F.12** | **Identifier of operator of the trading platform** | Not applicable | | **F.13** | **Language or languages of the white paper** | English | | **F.14** | **Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available** | SPK | | **F.15** | **Functionally Fungible Group Digital Token Identifier, where available** | Not applicable | | **F.16** | **Voluntary data flag** | FALSE | | **F.17** | **Personal data flag** | TRUE | | **F.18** | **LEI eligibility** | Not available | | **F.19** | **Home Member State** | Malta | | **F.20** | **Host Member States** | The admission to trading of the Token is passported in the following countries:
Austria
Belgium
Bulgaria
Croatia
Cyprus
Czech
Germany
Denmark
Estonia
Spain
Finland
France
Greece
Hungary
Iceland
Ireland
Italy
Latvia
Liechtenstein
Lithuania
Luxembourg
Netherlands
Norway
Poland
Portugal
Romania
Slovakia
Slovenia
Sweden | | **Part G - Information on the rights and obligations attached to the crypto-assets** | | | | **G.1** | **Purchaser Rights and Obligations** | The Token enables its holders to interact with the Project that operates autonomously and without the Foundation having an operative role. As a result, the Foundation, to the fullest extent permitted by applicable laws, disclaims all warranties, whether express or implied. This includes but is not limited to, implied warranties of merchantability and fitness for a particular purpose.
Moreover, to the fullest extent permissible by applicable laws, the Foundation is not liable for any damages arising from the holding, use, transfer, or interactions involving Tokens and the Project.
This limitation applies to all forms of damages, including direct, indirect, incidental, punitive, and consequential damages. | | **G.2** | **Exercise of Rights and obligations** | **Governance Rights:** To exercise any governance rights which become available to Token holders, Token holders must hold the Token and timely delegate or vote with their Tokens in accordance with any rules applicable to the Project's governance at that time, including but not limited to the Sky Atlas. **Staking in exchange for Rewards:** To earn 'protocol rewards, Token holders must stake their Tokens. | | **G.3** | **Conditions for modifications of rights and obligations** | Neither the Foundation nor the Issuer has the ability to unilaterally modify the rights or obligations attached to the Token. However, the functionalities or rights attaching to the Token may be affected by changes made to the Project by the governance community and development team. These protocol-level changes may impact on the ways in which the Token can be used. Holders are encouraged to monitor official protocol channels for updates, including but not limited to the Project's website ([%%SPARK\_URL%%/](https://spark.fi/)). | | **G.4** | **Future Public Offers** | The Issuer does not intend to offer the Token to the public in the future. | | **G.5** | **Issuer Retained Crypto-Assets** | 0 | | **G.6** | **Utility Token Classification** | FALSE | | **G.7** | **Key Features of Goods/Services of Utility Tokens** | Not applicable | | **G.8** | **Utility Tokens Redemption** | No redemption | | **G.9** | **Non-Trading request** | TRUE | | **G.10** | **Crypto-Assets purchase or sale modalities** | Not applicable | | **G.11** | **Crypto-Assets Transfer Restrictions** | The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through "private sales" are subject to restrictions as per the terms of sale. | | **G.12** | **Supply Adjustment Protocols** | Sky governance will control the Token's mint and burn functionality. Therefore, modifications to the Token's supply can only occur via a vote of Sky governance. | | **G.13** | **Supply Adjustment Mechanisms** | See Section G.12. | | **G.14** | **Token Value Protection Schemes** | Not applicable | | **G.15** | **Token Value Protection Schemes Description** | FALSE | | **G.16** | **Compensation Schemes** | FALSE | | **G.17** | **Compensation Schemes Description** | Not applicable | | **G.18** | **Applicable law** | Subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. | | **G.19** | **Competent court** | See Section G.18. | | **Part H – Information on the underlying technology** | | | | **H.1** | **Distributed ledger technology** | The Token will be launched on the Ethereum blockchain. | | **H.2** | **Protocols and technical standards** | The Token will be launched on the Ethereum blockchain under the ERC-20 standard to guarantee industry-standard compatibility. | | **H.3** | **Technology Used** | As an ERC-20 token, the Token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the Token through their own non-custodial wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API. | | **H.4** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a Proof of Stake ("PoS") consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. | | **H.5** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.
Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:
**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and
**Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included. | | **H.6** | **Use of Distributed Ledger Technology** | FALSE | | **H.7** | **DLT Functionality Description** | Not applicable | | **H.8** | **Audit** | FALSE | | **H.9** | **Audit outcome** | Not applicable | | **Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts** | | | | **J.01** | **Name** | Spark Foundation | | **J.02** | **Relevant legal entity identifier** | Not available | | **J.03** | **Name of the crypto-asset** | SPK | | **J.04** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a PoS consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. | | **J.05** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.
Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:
**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and
**Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included. | | **J.06** | **Beginning of the Period to which the Disclosed Information Relates** | 03/03/2024 | | **J.07** | **End of the Period to which the Disclosed Information Relates** | 03/03/2025 | | **Mandatory key indicator on energy consumption** | | | | **J.08** | **Energy Consumption** | 6,049,441.70 kWh | | **Sources and methodologies** | | | | **J.09** | **Energy Consumption Sources and Methodologies** | The estimated energy consumption provided in Section J.08 has been calculated using the CCRI Crypto Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)).
Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token's first year by the Ethereum blockchain. | | 0 | Table of content | Date of notification
Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114
SUMMARY
Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114
Characteristics of the crypto-asset
Key information about the offer to the public or admission to trading
Part I – Information on risks
Offer-Related Risks
Issuer-Related Risks
Crypto-Assets-related Risks
Project Implementation-Related Risks
Technology-Related Risks
Mitigation measures
Part A - Information about the offeror or the person seeking admission to trading
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier
Another identifier required pursuant to applicable national law
Contact telephone number
E-mail address
Response Time (Days)
Parent Company
Members of the Management body
Business Activity
Parent Company Business Activity
Newly Established
Financial condition for the past three years
Financial condition since registration
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading
Issuer different from offeror or person seeking admission to trading
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier
Another identifier required pursuant to applicable national law
Parent Company
Members of the Management body
Business Activity
Parent Company Business Activity
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier of the operator of the trading platform
Another identifier required pursuant to applicable national law
Parent Company
Reason for Crypto-Asset White Paper Preparation
Members of the Management body
Operator Business Activity
Parent Company Business Activity
Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D - Information about the crypto-asset project
Crypto-asset project name
Crypto-assets name
Abbreviation
Crypto-asset project description
Details of all natural or legal persons involved in the implementation of the crypto-asset project
Utility Token Classification
Key Features of Goods/Services for Utility Token Projects
Plans for the token
Resource Allocation
Planned Use of Collected Funds or Crypto-Assets
Part E - Information about the offer to the public of crypto-assets or their admission to trading
Public Offering or Admission to trading
Reasons for Public Offer or Admission to trading
Fundraising Target
Minimum Subscription Goals
Maximum Subscription Goal
Oversubscription Acceptance
Oversubscription Allocation
Issue Price
Official currency or any other crypto-assets determining the issue price
Subscription fee
Offer Price Determination Method
Total Number of Offered/Traded Crypto-Assets
Targeted Holders
Holder restrictions
Reimbursement Notice
Refund Mechanism
Refund Timeline
Offer Phases
Early Purchase Discount
Time-limited offer
Subscription period beginning
Subscription period end
Safeguarding Arrangements for Offered Funds/Crypto-Assets
Payment Methods for Crypto-Asset Purchase
Value Transfer Methods for Reimbursement
Right of Withdrawal
Transfer of Purchased Crypto-Assets
Transfer Time Schedule
Purchaser's Technical Requirements
Crypto-asset service provider (CASP) name
CASP identifier
Placement form
Trading Platforms name
Trading Platforms Market Identifier Code (MIC)
Trading Platforms Access
Involved costs
Offer Expenses
Conflicts of Interest
Applicable law
Competent court
Part F - Information about the crypto-assets
Crypto-Asset Type
Crypto-Asset Functionality
Planned Application of Functionalities
A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
Type of white paper
The type of submission
Crypto-Asset Characteristics
Commercial name or trading name
Website of the issuer
Starting date of offer to the public or admission to trading
Publication date
Any other services provided by the issuer
Identifier of operator of the trading platform
Language or languages of the white paper
Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available
Functionally Fungible Group Digital Token Identifier, where available
Voluntary data flag
Personal data flag
LEI eligibility
Home Member State
Host Member States
Part G - Information on the rights and obligations attached to the crypto-assets
Purchaser Rights and Obligations
Exercise of Rights and obligations
Conditions for modifications of rights and obligations
Future Public Offers
Issuer Retained Crypto-Assets
Utility Token Classification
Key Features of Goods/Services of Utility Tokens
Utility Tokens Redemption
Non-Trading request
Crypto-Assets purchase or sale modalities
Crypto-Assets Transfer Restrictions
Supply Adjustment Protocols
Supply Adjustment Mechanisms
Token Value Protection Schemes
Token Value Protection Schemes Description
Compensation Schemes
Compensation Schemes Description
Applicable law
Competent court
Part H – Information on the underlying technology
Distributed ledger technology
Protocols and technical standards
Technology Used
Consensus Mechanism
Incentive Mechanisms and Applicable Fees
Use of Distributed Ledger Technology
DLT Functionality Description
Audit
Audit outcome
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
Name
Relevant legal entity identifier
Name of the crypto-asset
Consensus Mechanism
Incentive Mechanisms and Applicable Fees
Beginning of the Period to which the Disclosed Information Relates
End of the Period to which the Disclosed Information Relates
Mandatory key indicator on energy consumption
Energy Consumption
Sources and methodologies
Energy Consumption Sources and Methodologies | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Date of notification** | 2025-05-23 | | **2** | **Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114** | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission of trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper. | | **3** | **Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114** | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. | | **4** | **Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper may lose its value in part or in full, may not always be transferable and may not be liquid. | | **5** | **Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114** | FALSE | | **6** | **Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. | | **SUMMARY** | | | | **7** | **Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114** | Warning

This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.

The admission to trading of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.

This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. | | **8** | **Characteristics of the crypto-asset** | SPK (the "***Token***") will be launched as an ERC-20 token on the Ethereum blockchain. The Token will provide its holders with a set of rights within Spark (the "***Project***"), a decentralised finance application. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Project or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.

It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. | | **09** | | Not applicable | | **10** | **Key information about the offer to the public or admission to trading** | Spark Foundation (the "***Foundation***") seeks admission of the Token to trading on multiple trading platforms (the "***Exchanges***") in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. | | **Part I – Information on risks** | | | | **I.1** | **Offer-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted. Additionally, the Token's underlying protocol and governance structure may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Project's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.

**Regulatory Compliance Risks**: Evolving regulatory landscapes could impact the Token's classification, trading status, or market acceptance. Changes in regulatory requirements may necessitate modifications to the Project's operation, structure, or governance.
**Market Volatility**: The Token may be subject to extreme price fluctuations, influenced by speculation, market sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders.
**Liquidity Risks**: The ability to buy and sell Tokens depends on trading activity on decentralised exchanges ("***DEXs***") and, if applicable, centralised exchanges ("***CEXs***"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss.
**Risk of Trading Platforms**: When Token holders trade on Exchanges, neither the Issuer nor the Foundation acts as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Foundation for their operations, services, or outcomes.
**Risk of Delisting**: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value.
**Risk of Bankruptcy**: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens.
**Blockchain and Smart Contract Dependency**: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security.
**Governance and Economic Model Risks**: While no inflationary events are currently anticipated, Sky governance will retain the power to mint new Tokens in the future.
**Legal Risks**: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the value of the Token.
**Reputational Risks**: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities—could damage the Project's reputation and, by extension, impact the value and acceptance of the Token.
**Technology Management Risks**: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure.
**Concentration and Conflicts of Interest**: Concentration of Token holdings may lead to governance decisions that favour the interests of one or more specific holders rather than the interests of the community, potentially affecting the value of the Token.
**Decentralised Governance Risk**: The majority of the Token supply will be managed by decentralised governance, including Sky governance and Spark governance. Risks associated with decentralised governance, including without limitation the risk of capture, may negatively impact the value of the Token.
**Industry Competition Risks**: The Project faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token.
**Unanticipated Risks**: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section. | | **I.2** | **Issuer-Related Risks** | The Issuer's sole function is to issue and distribute the Tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.

**Operational Risk**: This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures.
**Decentralized Governance Risk**: Furthermore, all post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Issuer has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of the Tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. | | **I.3** | **Crypto-Assets-related Risks** | **Market Volatility Risks**: It is anticipated that the Token's value will be highly volatile and may fluctuate due to market speculation, investor sentiment, regulatory developments, and technological advancements. External factors, such as shifting trends in the crypto industry, changes in demand for blockchain services, or macroeconomic conditions, could contribute to extreme price fluctuations, potentially leading to total depreciation.
**Liquidity Risks**: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire or sell the Token.
**Adoption and Project Demand Risks**: The long-term success of the Token is dependent on widespread adoption of the Project. Adoption is influenced by various external factors, including user demand, competitive market conditions, and organic community-driven expansion. The Foundation has no control over the pace of adoption, and there is no guarantee that the Project will gain sufficient traction to sustain its economic model.
**Blockchain Dependency Risks**: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness.
**Transaction Costs:** While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token.
**Security Risks**:
***Smart Contract Vulnerabilities***: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality.
***Private Key Management***: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible.
**Scam and Fraud Risks**: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Foundation or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud.
**Community and Narrative Risks**: The Token's success is closely tied to community interest and the broader crypto narrative. Market trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption.
**Regulatory and Compliance Risks**:
***Evolving Legal Frameworks***: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality.
***Jurisdictional Restrictions***: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users.
**Technological Obsolescence Risks**: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility.
**Software Weakness Risks**: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free.
**Unanticipated Risks**: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or market conditions, potentially affecting the Token's security, functionality, or value. | | **I.4** | **Project Implementation-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. Additionally, the success and sustainability of the Project rely on various external factors, including market conditions, regulatory developments, and technological advancements.

**Technical Development Risks**:
***Smart Contract Issues***: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms.

***Blockchain Dependency***: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the Project's implementation and functionality.
***Risk of Security Weaknesses in Core Infrastructure***: The Project relies on open-source software, which may be modified by third parties. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Project may negatively impact the Token's usability.
***Bugs in Core Blockchain Code***: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities.
**Regulatory and Compliance Risks:**
***Regulatory Actions in One or More Jurisdictions***: The Token and the underlying Project could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage.
***Evolving Laws and Regulations***: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the Project and the Token.
***Governance Risk***: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable governance outcomes.
**Operational Risks**:
***Resource Allocation***: The Project's success depends on the team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones.
**Market Adoption Risks**:
***Competitive Environment***: The crypto-asset market is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption.
***Community Engagement Risks***: The success of the Token depends heavily on community-driven marketing and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability.
**Timeline and Milestone Risks**:
***Delayed Milestones***: Key milestones may face delays due to technical, operational, or funding challenges.
***CEX Listing Risks***: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market access.
**Ecosystem Risks**:
***Dependence on External Parties***: The Project relies on infrastructure providers and other third-party service providers. Any failure or delay from third-parties could disrupt implementation plans.
**Technology and Software Risks**:
***Risk of Software Weakness***: Blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality.
***Dependency on Underlying Technology***: The Project relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities.
***Risk of Technological Disruption***: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets.
**Network Security Risks**:
***Network Attacks and Cybersecurity Threats***: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("***DDoS***") attacks. These threats could disrupt network operations and compromise security.
***Blockchain Network Attacks***: The Network may be subject to mining attacks, including double-spend attacks, reorganisations, majority mining power attacks, "selfish-mining" attacks, and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts.
**Privacy and Anonymity Risks**:
***Public Ledger Transparency***: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams.
**Economic and Governance Risks**:
***Incentive Model Risks***: Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards.
**Software Weakness Risks**:
***Unforeseen Bugs and Security Vulnerabilities***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.
**Unanticipated Risks**:
***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. | | **I.5** | **Technology-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist.
**Blockchain Dependency Risks**:
***Network Downtime and Congestion***: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities.
***Scalability Challenges***: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability.
***Settlement and Transaction Finality Risks***: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets.
**Smart Contract Risks**:
***Immutability Risks***: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections.
***Security Exploits***: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution.
**Wallet and Storage Risks**:
***Private Key Management***: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone.
***Compatibility Issues***: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token.
**Ecosystem Dependency Risks**:
***DEX and CEX Integration Issues***: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or de-listings from these platforms could limit liquidity, disrupt trading, and reduce market accessibility.
***Reliance on Third-Party Services***: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token.
**Software and Project Risks**:
***Risk of Attacks and Forks***: The underlying blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security.
***Risk of Technological Disruption***: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers.
***Dependency on Underlying Technology***: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency.
***Unforeseen Vulnerabilities in Blockchain***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.
**Privacy and Anonymity Risks**:
***Public Ledger Transparency***: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities.
***Exposure to Fraud and Targeted Attacks***: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks.
**Economic and Project Viability Risks**:
***Incentive Model Risks***: Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or changes to rewards.
**Unanticipated Risks**:
***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. | | **I.6** | **Mitigation measures** | To address the range of risks associated with the Token, the Project has implemented multiple mitigation strategies across technical, operational, and governance layers.

Smart Contract Audits: All critical smart contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [Security and Audits](/dev/security/security-and-audits).
Progressive rollout: The Token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience.
Decentralised Governance: The Token's governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks.
Transparent communication: Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions.
Liquidity support and listings: While no guarantee is provided, the Issuer and the Foundation may collaborate with market participants to encourage liquidity provision and exchange listings where feasible.
Regulatory Alignment: The Project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.

These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with the Tokens or the broader Spark ecosystem. | | **Part A - Information about the offeror or the person seeking admission to trading** | | | | **A.1** | **Name** | Spark Foundation | | **A.2** | **Legal form** | Foundation company limited by guarantee without share capital | | **A.3** | **Registered address** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.4** | **Head office** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.5** | **Registration Date** | 2025-02-05 | | **A.6** | **Legal entity identifier** | Not available | | **A.7** | **Another identifier required pursuant to applicable national law** | 418210 | | **A.8** | **Contact telephone number** | 001 345-749-9601 | | **A.9** | **E-mail address** | Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) | | **A.10** | **Response Time (Days)** | Fourteen (14) days | | **A.11** | **Parent Company** | Not applicable | | **A.12** | **Members of the Management body** | **Glenn Kennedy**
Director
Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands

**Marc Piano**
Director
Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.13** | **Business Activity** | To support, promote, and advance the development, adoption, security, and growth of Spark. | | **A.14** | **Parent Company Business Activity** | Not applicable | | **A.15** | **Newly Established** | TRUE | | **A.16** | **Financial condition for the past three years** | Not applicable | | **A.17** | **Financial condition since registration** | The Foundation will be capitalised as needed to fulfil its mandate of supporting the Spark ecosystem. It has no debt and being a brand new company, should have no material liabilities as of the date of this whitepaper. | | **Part B - Information about the issuer, if different from the offeror or person seeking admission to trading** | | | | **B.1** | **Issuer different from offeror or person seeking admission to trading** | TRUE | | **B.2** | **Name** | SPK Company Ltd. | | **B.3** | **Legal form** | Company limited by shares | | **B.4** | **Registered address** | SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301,
Road Town, Tortola,
British Virgin Islands | | **B.5** | **Head office** | SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301,
Road Town, Tortola,
British Virgin Islands | | **B.6** | **Registration Date** | 2025-02-19 | | **B.7** | **Legal entity identifier** | Not available | | **B.8** | **Another identifier required pursuant to applicable national law** | 2170013 | | **B.9** | **Parent Company** | Spark Foundation | | **B.10** | **Members of the Management body** | The sole director of the Issuer is **Spark Foundation**

The directors of Spark Foundation are Glenn Kennedy and Marc Piano

Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **B.11** | **Business Activity** | The only purpose is to issue and distribute the Token. | | **B.12** | **Parent Company Business Activity** | See Section A.13. | | **Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | | | | **C.1** | **Name** | Not applicable | | **C.2** | **Legal form** | Not applicable | | **C.3** | **Registered address** | Not applicable | | **C.4** | **Head office** | Not applicable | | **C.5** | **Registration Date** | Not applicable | | **C.6** | **Legal entity identifier of the operator of the trading platform** | Not applicable | | **C.7** | **Another identifier required pursuant to applicable national law** | Not applicable | | **C.8** | **Parent Company** | Not applicable | | **C.9** | **Reason for Crypto-Asset White Paper Preparation** | Not applicable | | **C.10** | **Members of the Management body** | Not applicable | | **C.11** | **Operator Business Activity** | Not applicable | | **C.12** | **Parent Company Business Activity** | Not applicable | | **C.13** | **Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable | | **C.14** | **Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable | | **Part D - Information about the crypto-asset project** | | | | **D.1** | **Crypto-asset project name** | Spark | | **D.2** | **Crypto-assets name** | Spark | | **D.3** | **Abbreviation** | SPK | | **D.4** | **Crypto-asset project description** | The Project is a DeFi protocol which emerged from Sky, previously known as MakerDAO, and serves as a 'Sky Star', a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. | | **D.5** | **Details of all natural or legal persons involved in the implementation of the crypto-asset project** | **SPK Company, Ltd.**
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands

**Spark Foundation**
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane
Camana Bay, George Town, Grand Cayman KY1-9006, Cayman Islands | | **D.6** | **Utility Token Classification** | FALSE | | **D.7** | **Key Features of Goods/Services for Utility Token Projects** | Not applicable | | **D.8** | **Plans for the token** | **Rewards:** Soon after the token generation event, a portion of the Token allocation will be used for airdrops to reward early supporters of the Project as well as its early users. Tokens may also be used in the future to reward users who use the Project.
**Staking in exchange for Rewards:** Token holders may be given the option to stake their Tokens to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and the Foundation anticipates that rewards, if any, will reflect the level of engagement and the function being supported.
**Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3.
**Future Outlook:** As the the Project grows, the Tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals.
**Vision:** The vision for the Tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. | | **D.9** | **Resource Allocation** | Allocated resources include technical resources from developers, legal and compliance resources from counsel, and financial resources by means of grants from Sky's DAO. | | **D.10** | **Planned Use of Collected Funds or Crypto-Assets** | Not applicable | | **Part E - Information about the offer to the public of crypto-assets or their admission to trading** | | | | **E.1** | **Public Offering or Admission to trading** | ATTR | | **E.2** | **Reasons for Public Offer or Admission to trading** | The Foundation seeks admission of the Token to trading on multiple Exchanges in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. | | **E.3** | **Fundraising Target** | Not applicable | | **E.4** | **Minimum Subscription Goals** | Not applicable | | **E.5** | **Maximum Subscription Goal** | Not applicable | | **E.6** | **Oversubscription Acceptance** | Not applicable | | **E.7** | **Oversubscription Allocation** | Not applicable | | **E.8** | **Issue Price** | Not applicable | | **E.9** | **Official currency or any other crypto-assets determining the issue price** | Not applicable | | **E.10** | **Subscription fee** | Not applicable | | **E.11** | **Offer Price Determination Method** | Not applicable | | **E.12** | **Total Number of Offered/Traded Crypto-Assets** | Not applicable | | **E.13** | **Targeted Holders** | ALL | | **E.14** | **Holder restrictions** | The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange.

The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. | | **E.15** | **Reimbursement Notice** | Not applicable | | **E.16** | **Refund Mechanism** | Not applicable | | **E.17** | **Refund Timeline** | Not applicable | | **E.18** | **Offer Phases** | Not applicable | | **E.19** | **Early Purchase Discount** | Not applicable | | **E.20** | **Time-limited offer** | Not applicable | | **E.21** | **Subscription period beginning** | Not applicable | | **E.22** | **Subscription period end** | Not applicable | | **E.23** | **Safeguarding Arrangements for Offered Funds/Crypto-Assets** | Not applicable | | **E.24** | **Payment Methods for Crypto-Asset Purchase** | The methods available for purchasing the Token depend on the functionality and policies of the Exchanges or other third-party platforms through which the Token is admitted to trading. Accepted payment methods may include fiat currencies, other crypto-assets, or stablecoins, subject to the configuration and offerings of each respective platform. | | **E.25** | **Value Transfer Methods for Reimbursement** | Not applicable | | **E.26** | **Right of Withdrawal** | Not applicable | | **E.27** | **Transfer of Purchased Crypto-Assets** | Not applicable | | **E.28** | **Transfer Time Schedule** | Not applicable | | **E.29** | **Purchaser's Technical Requirements** | To access and trade the Tokens following their admission to trading, purchasers must meet certain technical requirements. These requirements are primarily determined by the centralized Exchanges where the Tokens are listed, and may include the following:

A device (computer or mobile) capable of securely accessing and operating an account on an Exchange;
A stable internet connection to interact with the Exchange interface and execute transactions;
The ability to receive and store Tokens within the exchange account infrastructure, as provided by the Exchange;

Where trading takes place on decentralized exchanges (DEXs), or where tokens are withdrawn to self-custodied wallets, additional technical requirements apply:

Access to a compatible digital wallet capable of interacting with the Token's blockchain (e.g., Ethereum for ERC-20 Tokens);
Secure management of private keys and recovery phrases;
The ability to sign transactions and pay applicable network (gas) fees on the Ethereum blockchain.

The Foundation does not provide technical infrastructure such as exchange access, custody services, or wallets. It is the responsibility of the purchaser to ensure that all relevant technical requirements are met in order to receive and transact with the Tokens. | | **E.30** | **Crypto-asset service provider (CASP) name** | Not applicable | | **E.31** | **CASP identifier** | Not applicable | | **E.32** | **Placement form** | NTAV | | **E.33** | **Trading Platforms name** | **OKX**: [https://www.okx.com/](https://www.okx.com/)
**Binance**: [https://www.binance.com/](https://www.binance.com/)
**Upbit**: [https://upbit.com/](https://upbit.com/)
**Coinbase**: [https://www.coinbase.com/](https://www.coinbase.com/)
**Bybit**: [https://www.bybit.com/](https://www.bybit.com/)
**Gate.io**: [https://www.gate.io/](https://www.gate.io/)
**Bithumb**: [https://www.bithumb.com/](https://www.bithumb.com/)
**KuCoin**: [https://www.kucoin.com/](https://www.kucoin.com/)
**Kraken**: [https://www.kraken.com/](https://www.kraken.com/)
**Bitget**: [https://www.bitget.com/](https://www.bitget.com/)
**HTX**: [https://www.htx.com/](https://www.htx.com/)
**Crypto.com**: [https://crypto.com/](https://crypto.com/)
**Bitvavo**: [https://bitvavo.com/](https://bitvavo.com/)
**Bitkub**: [https://www.bitkub.com/](https://www.bitkub.com/)
**MEXC**: [https://www.mexc.com/](https://www.mexc.com/)
**Coinone**: [https://coinone.co.kr/](https://coinone.co.kr/)
**Bitstamp**: [https://www.bitstamp.net/](https://www.bitstamp.net/)
**Revolut**: [https://www.revolut.com/](https://www.revolut.com/)
**Paribu**: [https://www.paribu.com/](https://www.paribu.com/)
**Pintu**: [https://pintu.co.id/](https://pintu.co.id/)
**LBank**: [https://www.lbank.info/](https://www.lbank.info/)
**Bitpanda**: [https://www.bitpanda.com/](https://www.bitpanda.com/)
**Ourbit**: [https://www.ourbit.com/](https://www.ourbit.com/)
**Hashkey**: [https://www.hashkey.com/](https://www.hashkey.com/)
**Bitfinex**: [https://www.bitfinex.com/](https://www.bitfinex.com/)
**CoinDCX**: [https://coindcx.com/](https://coindcx.com/)
**BTSE**: [https://www.btse.com/](https://www.btse.com/)
**BitMEX**: [https://www.bitmex.com/](https://www.bitmex.com/)
**XT.COM**: [https://www.xt.com/](https://www.xt.com/)
**Bilaxy**: [https://www.bilaxy.com/](https://www.bilaxy.com/)
**AscendEX**: [https://ascendex.com/](https://ascendex.com/)
**CoinList**: [https://coinlist.co/](https://coinlist.co/)
**BingX**: [https://www.bingx.com/](https://www.bingx.com/)
**BitMart**: [https://www.bitmart.com/](https://www.bitmart.com/)
**CoinW**: [https://www.coinw.com/](https://www.coinw.com/)
**WhiteBIT**: [https://whitebit.com/](https://whitebit.com/)
**Bitrue**: [https://www.bitrue.com/](https://www.bitrue.com/)
**Phemex**: [https://phemex.com/](https://phemex.com/)
**WazirX**: [https://wazirx.com/](https://wazirx.com/)
**WOO X**: [https://woo.org/](https://woo.org/)
**Poloniex**: [https://poloniex.com/](https://poloniex.com/) | | **E.34** | **Trading Platforms Market Identifier Code (MIC)** | Not applicable | | **E.35** | **Trading Platforms Access** | The Exchanges are accessible via their respective websites. | | **E.36** | **Involved costs** | Not applicable | | **E.37** | **Offer Expenses** | Not applicable | | **E.38** | **Conflicts of Interest** | Not applicable | | **E.39** | **Applicable law** | This white paper is being published solely for purposes of admission to trading, not an offer to the public of the Token. However, subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. | | **E.40** | **Competent court** | See Section E.39. | | **Part F - Information about the crypto-assets** | | | | **F.1** | **Crypto-Asset Type** | Crypto-asset other than an asset-referenced token or e-money token | | **F.2** | **Crypto-Asset Functionality** | According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA.

The Token qualifies as a crypto-asset within the meaning of MiCA, as it is a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT").

The Token displays the following functionalities:

**Rewards and Incentive Structures:** The Token is intended to support the long-term functionality, security, and decentralization of the Spark ecosystem through various incentive mechanisms. Token holders may have the opportunity to engage in network activities such as staking, which is designed to enhance protocol resilience and performance. Staking may be associated with specific components of the protocol, for example, cross-chain infrastructure or network security mechanisms, and may require time-bound commitments or minimum engagement thresholds.
The Foundation anticipates that rewards, where applicable, will be designed to reflect the level and nature of participation, as determined by the parameters of the relevant mechanism. All such mechanisms, including staking terms and reward structures, remain subject to further refinement through governance processes and technical development.
**Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. Overall: The Token is designed primarily as a token for use within the Spark ecosystem, enabling holders to participate in governance, access reward and incentive programs, and interact with protocol features as they evolve over time. | | **F.3** | **Planned Application of Functionalities** | At the time of publication of this whitepaper, the Foundation anticipates the following:
the rewards and incentive structures described in Section F.2 and in other parts of this whitepaper will be made available for the Token holders progressively following the Token Generation Event ('TGE'); and
the governance feature described in Section F.2 and in other parts of this whitepaper will also evolve over time by the governance community and development team. Any governance rights granted to Token holders will be subject to any rules applicable to the Project's governance, including but not limited to the Sky Atlas. | | **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** | | | | **F.4** | **Type of white paper** | OTHR | | **F.5** | **The type of submission** | MODI | | **F.6** | **Crypto-Asset Characteristics** | See Section 8. | | **F.7** | **Commercial name or trading name** | Spark | | **F.8** | **Website of the issuer** | Neither the Foundation nor the Issuer have a website.
The website of the Project is [%%SPARK\_URL%%/](https://spark.fi/) | | **F.9** | **Starting date of offer to the public or admission to trading** | 2025-05-28 | | **F.10** | **Publication date** | 2025-06-03 | | **F.11** | **Any other services provided by the issuer** | Neither the Foundation nor the Issuer provide any other services not covered by Regulation (EU) 2023/1114. | | **F.12** | **Identifier of operator of the trading platform** | Not applicable | | **F.13** | **Language or languages of the white paper** | English | | **F.14** | **Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available** | SPK | | **F.15** | **Functionally Fungible Group Digital Token Identifier, where available** | Not applicable | | **F.16** | **Voluntary data flag** | FALSE | | **F.17** | **Personal data flag** | TRUE | | **F.18** | **LEI eligibility** | FALSE | | **F.19** | **Home Member State** | Malta | | **F.20** | **Host Member States** | The admission to trading of the Token is passported in the following countries: Austria
Belgium
Bulgaria
Croatia
Cyprus
Czech Republic
Germany
Denmark
Estonia
Spain
Finland
France
Greece
Hungary
Iceland
Ireland
Italy
Latvia
Liechtenstein
Lithuania
Luxembourg
Netherlands
Norway
Poland
Portugal
Romania
Slovakia
Slovenia
Sweden | | **Part G - Information on the rights and obligations attached to the crypto-assets** | | | | **G.1** | **Purchaser Rights and Obligations** | The Token enables its holders to interact with the Project that operates autonomously and without the Foundation having an operative role. As a result, the Foundation, to the fullest extent permitted by applicable laws, disclaims all warranties, whether express or implied. This includes but is not limited to, implied warranties of merchantability and fitness for a particular purpose.
Moreover, to the fullest extent permissible by applicable laws, the Foundation is not liable for any damages arising from the holding, use, transfer, or interactions involving Tokens and the Project.
This limitation applies to all forms of damages, including direct, indirect, incidental, punitive, and consequential damages. | | **G.2** | **Exercise of Rights and obligations** | Any rights associated with the Tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the Token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in any functionality associated with the Token shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.

The obligations of the Token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. | | **G.3** | **Conditions for modifications of rights and obligations** | Neither the Foundation nor the Issuer has the ability to unilaterally modify the rights or obligations attached to the Token. However, the functionalities or rights attaching to the Token may be affected by changes made to the Project by the governance community and development team. These protocol-level changes may impact on the ways in which the Token can be used. Holders are encouraged to monitor official protocol channels for updates, including but not limited to the Project's website ([%%SPARK\_URL%%/](https://spark.fi/)mica). | | **G.4** | **Future Public Offers** | The Issuer has submitted a white paper for the offering of the Tokens to the public. The white paper will be accessible at %%SPARK\_URL%%/mica upon the end of the notification period. | | **G.5** | **Issuer Retained Crypto-Assets** | 0 | | **G.6** | **Utility Token Classification** | FALSE | | **G.7** | **Key Features of Goods/Services of Utility Tokens** | Not applicable | | **G.8** | **Utility Tokens Redemption** | No redemption | | **G.9** | **Non-Trading request** | TRUE | | **G.10** | **Crypto-Assets purchase or sale modalities** | Not applicable | | **G.11** | **Crypto-Assets Transfer Restrictions** | The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through "private sales" are subject to restrictions as per the terms of sale. | | **G.12** | **Supply Adjustment Protocols** | FALSE | | **G.13** | **Supply Adjustment Mechanisms** | Sky governance will control the Token's mint and burn functionality. Therefore, modifications to the Token's supply can only occur via a vote of Sky governance. | | **G.14** | **Token Value Protection Schemes** | FALSE | | **G.15** | **Token Value Protection Schemes Description** | Not applicable | | **G.16** | **Compensation Schemes** | FALSE | | **G.17** | **Compensation Schemes Description** | Not applicable | | **G.18** | **Applicable law** | Subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. | | **G.19** | **Competent court** | See Section G.18. | | **Part H – Information on the underlying technology** | | | | **H.1** | **Distributed ledger technology** | The Token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The Token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. | | **H.2** | **Protocols and technical standards** | The Token conforms to the ERC-20 token standard and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. | | **H.3** | **Technology Used** | As an ERC-20 token, the Token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the Token through their own non-custodial wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API. | | **H.4** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a Proof of Stake ("PoS") consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. | | **H.5** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.

Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:

**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and
**Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.

Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. | | **H.6** | **Use of Distributed Ledger Technology** | FALSE | | **H.7** | **DLT Functionality Description** | Not applicable | | **H.8** | **Audit** | FALSE | | **H.9** | **Audit outcome** | Not applicable | | **Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts** | | | | **J.01** | **Name** | Spark Foundation | | **J.02** | **Relevant legal entity identifier** | Not available | | **J.03** | **Name of the crypto-asset** | SPK | | **J.04** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a PoS consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. | | **J.05** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.

Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:

**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and
**Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.

Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. | | **J.06** | **Beginning of the Period to which the Disclosed Information Relates** | 03/03/2024 | | **J.07** | **End of the Period to which the Disclosed Information Relates** | 03/03/2025 | | **Mandatory key indicator on energy consumption** | | | | **J.08** | **Energy Consumption** | 6,049,441.70 kWh | | **Sources and methodologies** | | | | **J.09** | **Energy Consumption Sources and Methodologies** | The estimated energy consumption provided in Section J.08 has been calculated using the CCRI Crypto Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)).

Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token's first year by the Ethereum blockchain. | ## SPK Company Ltd. - SPK Token White paper Version 1.0 - May 2025 Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area. Date of notification: 2025-05-09 Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token. Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper. ### Table of Contents * [**Important Notice**](#important-notice) * [**Warning**](#warning) * [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset) * [Key information about the offer to the public](#key-information-about-the-offer-to-the-public) * [**Part I – Information on Risks**](#part-i--information-on-risks) * [I.1 Offer-Related Risks](#i1-offer-related-risks) * [I.2 Issuer-Related Risks](#i2-issuer-related-risks) * [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks) * [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks) * [I.5 Technology-Related Risks](#i5-technology-related-risks) * [I.6 Mitigation measures](#i6-mitigation-measures) * [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset) * [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading) * [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform) * [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project) * [D.8 Plans for the token](#d8-plans-for-the-token) * [D.9 Resource Allocation](#d9-resource-allocation) * [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets) * [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public) * [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer) * [Refund Mechanism](#refund-mechanism) * [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets) * [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets) * [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology) * [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts) ### IMPORTANT NOTICE Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time. This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid. The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council. The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. ### WARNING This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. ### Characteristics of the crypto-asset SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper. ### Key information about the offer to the public This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror. The total number of SPK tokens available through this offer is capped at 680,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration. The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees. This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur. The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation. ### PART I – INFORMATION ON RISKS #### I.1 Offer-Related Risks Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities. The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens. Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable. Trading venues, whether decentralised or centralised, pose operational and counterparty risks. Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes. Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free. Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations. #### I.2 Issuer-Related Risks The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community. This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures. Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. #### I.3 Crypto-Assets-related Risks As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free. SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner. The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints. Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens. Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information. SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets. Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations. #### I.4 Project Implementation-Related Risks The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks. Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds. Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed. The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests. Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish. In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality. Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project. #### I.5 Technology-Related Risks SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability. Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors. Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes. Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible. Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems. Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility. The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network. In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience. #### I.6 Mitigation measures To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers. * **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [Security and Audits](/dev/security/security-and-audits). * **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience. * **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks. * **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions. * **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible. * **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA. These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem. ### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET #### A.1 Name SPK Company Ltd. #### A.2 Legal Form Company limited by shares #### A.3 Registered address SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301. #### A.4 Head office Road Town, Tortola,
British Virgin Islands #### A.5 Registration Date 2025-02-19 #### A.6 Legal entity identifier Not available #### A.7 Another identifier required pursuant to applicable national law 2170013 #### A.8/9/10 Contacting the Offeror The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days. Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) Telephone number: +1 345-749-9601 Email address: The Offeror does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### A.11 Parent Company Spark Foundation #### A.12 Identity of the management body The sole director of the Offeror is Spark Foundation The directors of Spark Foundation are Glenn Kennedy and Marc Piano Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands #### A.13 Business activity The only purpose is to issue and distribute the Token. #### A.14 Parent Company Business Activity To support, promote, and advance the development, adoption, security, and growth of Spark. #### A.15 Newly Established true #### A.16 Financial condition for the past three years The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. #### A.17 Financial condition since registration The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. ### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity. ### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper. ### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT #### D.1 Crypto-asset project name Spark #### D.2 Crypto-asset name Spark #### D.3 Abbreviation SPK #### D.4 Crypto-asset project description The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. #### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands

Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification false #### D.7 Key Features of Goods/Services for Utility Token Projects Not applicable #### D.8 Plans for the token The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth. ##### **Community-Driven Distribution** SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement. These distribution channels are permissionless, performance-based and structured to encourage use among committed participants. ##### **Protocol Utility and Staking** SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported. ##### **Incentive structures** The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement. ##### **Governance Engagement** SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs. ##### **Future Outlook** As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals. The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. #### D.9 Resource Allocation The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives. A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding. In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships. The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time. #### D.10 Planned Use of Collected Funds or Crypto-Assets The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E. ### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC #### E.1 Public Offering OTPC #### E.2 Reasons for Public Offer The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions. Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18. The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration. #### E.3 Fundraising target Not applicable #### E.4 Minimum Subscription Goal Not applicable #### E.5 Maximum Subscription Goal Not applicable #### E.6 Oversubscription Acceptance false #### E.7 Oversubscription Allocation Not applicable #### E.8 Issue Price €0 #### E.9 Official currency or any other crypto-assets determining the issue price Not applicable #### E.10 Subscription fee €0 #### E.11 Offer Price Determination Method The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens. #### E.12 Total Number of Offered Crypto-Assets 680,000,000 SPK tokens #### E.13 Targeted Holders ALL #### E.14 Holder restrictions The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions. Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited. #### E.15 Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled. #### E.16 Refund Mechanism Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs. Retail holders may exercise their right of withdrawal by following the process available at [www.%%SPARK\_DOMAIN%%/mica](https://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded. Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned. ##### **Return of Tokens and Reimbursement** The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party. The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed. #### E.17 Refund Timeline The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter. #### E.18 Offer Phases The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window. ##### **Phase 1**: This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration. ##### **Phase 2**: This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window. ##### **Phase 3**: This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury. All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window. Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [%%SPARK\_DOMAIN%%](https://spark.fi/), prior to the commencement of the relevant claiming window. This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website. In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases. #### E.19 Early Purchase Discount Not applicable. #### E.20 Time-limited offer false #### E.21 Subscription period beginning Not applicable #### E.22 Subscription period end Not applicable #### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets Not applicable #### E.24 Payment Methods for Crypto-Asset Purchase The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity. #### E.25 Value Transfer Methods for Reimbursement No reimbursement shall be due. #### E.26 Right of Withdrawal In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism. #### E.27 Transfer of Purchased Crypto-Assets Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface. Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper. #### E.28 Transfer Time Schedule SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror. #### E.29 Purchaser’s Technical Requirement To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token. The wallet must support: * Secure storage of private keys and recovery phrases; * On-chain interaction with smart contracts (e.g., for claiming SPK tokens) * The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH. The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to: * Secure their private keys; * Ensure uninterrupted access to their wallet; * Ensure the wallet address used for claiming is correct and under their exclusive control. Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility. #### E.30 Crypto-asset service provider (CASP) name Not applicable #### E.31 CASP identifier Not applicable #### E.32 Placement form NTAV #### E.33 Trading Platforms name Not applicable #### E.34 Trading Platforms Market Identifier Code (MIC) Not applicable #### E.35 Trading Platforms Access Not applicable #### E.36 Involved costs Not applicable #### E.37 Offer Expenses No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens. Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror. All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror. #### E.38 Conflicts of Interest Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise. #### E.39 Applicable law This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA. #### E.40 Competent court Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules. ### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS #### F.1 Crypto-Asset Type Crypto-asset other than an asset-referenced token or e-money token. #### F.2 Crypto-Asset Functionality SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework. SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper. SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity. #### F.3 Planned Application of Functionalities At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering: * **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO. * **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract. * **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services. All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12. **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** #### F.4 Type of white paper OTHR #### F.5 The type of submission NEWT #### F.6 Crypto-asset Characteristics See Part D and Section F.2. #### F.7 Commercial name or trading Spark / SPK token name #### F.8 Website of the issuer The Issuer does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### F.9 Starting date of offer to the public or admission to trading 2025-06-10 #### F.10 Publication date 2025-06-09 #### F.11 Any other services provided by the issuer The Offeror does not offer any other services covered by MiCA #### F.12 Identifier of operator of the trading platform Not applicable #### F.13 Language or languages of the white paper English #### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available SPK #### F.15 Functionally Fungible Group Digital Token Identifier, where available Not applicable #### F.16 Voluntary data flag false #### F.17 Personal data flag true #### F.18 LEI eligibility false #### F.19 Home Member State Denmark #### F.20 Host Member States The offer to the public of SPK tokens is passported to the following countries: * Austria * Belgium * Bulgaria * Croatia * Cyprus * Czech Republic * Estonia * Finland * France * Germany * Greece * Hungary * Iceland * Ireland * Italy * Latvia * Liechtenstein * Lithuania * Luxembourg * Malta * Netherlands * Norway * Poland * Portugal * Romania * Slovakia * Slovenia * Spain * Sweden ### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS #### G.1 Purchaser Rights and Obligations Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein. SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA. SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper. #### G.2 Exercise of Rights and obligations The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem. The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. #### G.3 Conditions for modifications of rights and obligations The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives. The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable. #### G.4 Future Public Offers At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA. #### G.5 Issuer Retained Crypto-Assets 0 #### G.6 Utility Token Classification false #### G.7 Key Features of Goods/Services of Utility Tokens Not applicable #### G.8 Utility Token Redemption Not Applicable #### G.9 Non-Trading request true #### G.10 Crypto-Assets purchase or sale modalities Not applicable #### G.11 Crypto-Assets Transfer Restrictions The Offeror does not impose any transfer restrictions. #### G.12 Supply Adjustment Protocols false #### G.13 Supply Adjustment Mechanisms SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations. However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures. #### G.14 Token Value Protection Scheme false #### G.15 Token Value Protection Schemes Description Not applicable #### G.16 Compensation Schemes false #### G.17 Compensation Schemes Description Not applicable #### G.18 Applicable law This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands. #### G.19 Competent court Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules. ### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY #### H.1 Distributed ledger technology SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. #### H.2 Protocols and technical SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. #### H.3 Technology Used As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API. #### H.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### H.5 Incentive Mechanisms and Applicable Fees SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**:\ This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### H.6 Use of Distributed Ledger Technology false #### H.7 DLT Functionality Description Not applicable #### H.8 Audit false #### H.9 Audit outcome Not applicable #### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS #### General information #### S.1 Name SPK Company Ltd #### S.2 Relevant legal entity identifier *Identifier stated to in section A* Not available #### S.3 Name of the crypto-asset *Name of the crypto-asset as stated to in section A* Spark / SPK #### S.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### S.5 Incentive Mechanisms and Applicable Fees *Incentive mechanisms to secure transactions and any fees applicable as stated in section H.* SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**: This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### S.6 Beginning of the period to which the disclosed information relates 2024-05-08 #### S.7 End of the period to which the disclosure relates 2025-05-08 #### **Mandatory key indicator on energy consumption** #### S.8 Energy consumption *Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year* 4,871,148.30 kWh #### **Sources and methodologies** #### S.9 Energy consumption *Sources and methodologies used in relation to the information reported above* The estimated energy consumption provided in Section sources and S.8 has been calculated using the CCRI Crypto methodologies Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)). Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token’s first year by the Ethereum blockchain. ## SPK Company Ltd. - SPK Token White paper Version 2.0 - June 2025 Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area. Date of notification: 2025-06-11 Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token. Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper. ### Table of Contents * [**Important Notice**](#important-notice) * [**Warning**](#warning) * [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset) * [Key information about the offer to the public](#key-information-about-the-offer-to-the-public) * [**Part I – Information on Risks**](#part-i--information-on-risks) * [I.1 Offer-Related Risks](#i1-offer-related-risks) * [I.2 Issuer-Related Risks](#i2-issuer-related-risks) * [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks) * [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks) * [I.5 Technology-Related Risks](#i5-technology-related-risks) * [I.6 Mitigation measures](#i6-mitigation-measures) * [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset) * [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading) * [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform) * [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project) * [D.8 Plans for the token](#d8-plans-for-the-token) * [D.9 Resource Allocation](#d9-resource-allocation) * [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets) * [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public) * [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer) * [Refund Mechanism](#refund-mechanism) * [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets) * [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets) * [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology) * [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts) ### IMPORTANT NOTICE Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time. This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid. The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council. The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. ### WARNING This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. ### Characteristics of the crypto-asset SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper. ### Key information about the offer to the public This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror. The total number of SPK tokens available through this offer is capped at 710,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration. The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees. This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur. The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation. ### PART I – INFORMATION ON RISKS #### I.1 Offer-Related Risks Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities. The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens. Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable. Trading venues, whether decentralised or centralised, pose operational and counterparty risks. Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes. Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free. Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations. #### I.2 Issuer-Related Risks The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community. This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures. Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. #### I.3 Crypto-Assets-related Risks As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free. SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner. The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints. Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens. Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information. SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets. Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations. #### I.4 Project Implementation-Related Risks The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks. Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds. Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed. The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests. Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish. In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality. Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project. #### I.5 Technology-Related Risks SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability. Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors. Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes. Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible. Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems. Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility. The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network. In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience. #### I.6 Mitigation measures To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers. * **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [Security and Audits](/dev/security/security-and-audits). * **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience. * **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks. * **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions. * **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible. * **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA. These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem. ### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET #### A.1 Name SPK Company Ltd. #### A.2 Legal Form Company limited by shares #### A.3 Registered address SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301. #### A.4 Head office Road Town, Tortola,
British Virgin Islands #### A.5 Registration Date 2025-02-19 #### A.6 Legal entity identifier Not available #### A.7 Another identifier required pursuant to applicable national law 2170013 #### A.8/9/10 Contacting the Offeror The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days. Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) Telephone number: +1 345-749-9601 Email address: The Offeror does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### A.11 Parent Company Spark Foundation #### A.12 Identity of the management body The sole director of the Offeror is Spark Foundation The directors of Spark Foundation are Glenn Kennedy and Marc Piano Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands #### A.13 Business activity The only purpose is to issue and distribute the Token. #### A.14 Parent Company Business Activity To support, promote, and advance the development, adoption, security, and growth of Spark. #### A.15 Newly Established true #### A.16 Financial condition for the past three years The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. #### A.17 Financial condition since registration The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. ### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity. ### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper. ### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT #### D.1 Crypto-asset project name Spark #### D.2 Crypto-asset name Spark #### D.3 Abbreviation SPK #### D.4 Crypto-asset project description The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. #### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands

Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification false #### D.7 Key Features of Goods/Services for Utility Token Projects Not applicable #### D.8 Plans for the token The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth. ##### **Community-Driven Distribution** SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement. These distribution channels are permissionless, performance-based and structured to encourage use among committed participants. ##### **Protocol Utility and Staking** SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported. ##### **Incentive structures** The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement. ##### **Governance Engagement** SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs. ##### **Future Outlook** As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals. The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. #### D.9 Resource Allocation The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives. A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding. In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships. The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time. #### D.10 Planned Use of Collected Funds or Crypto-Assets The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E. ### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC #### E.1 Public Offering OTPC #### E.2 Reasons for Public Offer The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions. Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18. The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration. #### E.3 Fundraising target Not applicable #### E.4 Minimum Subscription Goal Not applicable #### E.5 Maximum Subscription Goal Not applicable #### E.6 Oversubscription Acceptance false #### E.7 Oversubscription Allocation Not applicable #### E.8 Issue Price €0 #### E.9 Official currency or any other crypto-assets determining the issue price Not applicable #### E.10 Subscription fee €0 #### E.11 Offer Price Determination Method The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens. #### E.12 Total Number of Offered Crypto-Assets 710,000,000 SPK tokens #### E.13 Targeted Holders ALL #### E.14 Holder restrictions The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions. Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited. #### E.15 Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled. #### E.16 Refund Mechanism Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs. Retail holders may exercise their right of withdrawal by following the process available at [www.%%SPARK\_DOMAIN%%/mica](https://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded. Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned. ##### **Return of Tokens and Reimbursement** The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party. The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed. #### E.17 Refund Timeline The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter. #### E.18 Offer Phases The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window. ##### **Phase 1**: This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration. ##### **Phase 2**: This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window. ##### **Phase 3**: This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury. All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window. Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [%%SPARK\_DOMAIN%%](https://spark.fi/), prior to the commencement of the relevant claiming window. This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website. In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases. #### E.19 Early Purchase Discount Not applicable. #### E.20 Time-limited offer false #### E.21 Subscription period beginning Not applicable #### E.22 Subscription period end Not applicable #### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets Not applicable #### E.24 Payment Methods for Crypto-Asset Purchase The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity. #### E.25 Value Transfer Methods for Reimbursement No reimbursement shall be due. #### E.26 Right of Withdrawal In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism. #### E.27 Transfer of Purchased Crypto-Assets Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface. Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper. #### E.28 Transfer Time Schedule SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror. #### E.29 Purchaser’s Technical Requirement To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token. The wallet must support: * Secure storage of private keys and recovery phrases; * On-chain interaction with smart contracts (e.g., for claiming SPK tokens) * The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH. The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to: * Secure their private keys; * Ensure uninterrupted access to their wallet; * Ensure the wallet address used for claiming is correct and under their exclusive control. Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility. #### E.30 Crypto-asset service provider (CASP) name Not applicable #### E.31 CASP identifier Not applicable #### E.32 Placement form NTAV #### E.33 Trading Platforms name Not applicable #### E.34 Trading Platforms Market Identifier Code (MIC) Not applicable #### E.35 Trading Platforms Access Not applicable #### E.36 Involved costs Not applicable #### E.37 Offer Expenses No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens. Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror. All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror. #### E.38 Conflicts of Interest Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise. #### E.39 Applicable law This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA. #### E.40 Competent court Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules. ### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS #### F.1 Crypto-Asset Type Crypto-asset other than an asset-referenced token or e-money token. #### F.2 Crypto-Asset Functionality SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework. SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper. SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity. #### F.3 Planned Application of Functionalities At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering: * **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO. * **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract. * **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services. All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12. **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** #### F.4 Type of white paper OTHR #### F.5 The type of submission MODI #### F.6 Crypto-asset Characteristics See Part D and Section F.2. #### F.7 Commercial name or trading Spark / SPK token name #### F.8 Website of the issuer The Issuer does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### F.9 Starting date of offer to the public or admission to trading 2025-06-17 #### F.10 Publication date 2025-06-20 #### F.11 Any other services provided by the issuer The Offeror does not offer any other services covered by MiCA #### F.12 Identifier of operator of the trading platform Not applicable #### F.13 Language or languages of the white paper English #### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available SPK #### F.15 Functionally Fungible Group Digital Token Identifier, where available Not applicable #### F.16 Voluntary data flag false #### F.17 Personal data flag true #### F.18 LEI eligibility false #### F.19 Home Member State Denmark #### F.20 Host Member States The offer to the public of SPK tokens is passported to the following countries: * Austria * Belgium * Bulgaria * Croatia * Cyprus * Czech Republic * Estonia * Finland * France * Germany * Greece * Hungary * Iceland * Ireland * Italy * Latvia * Liechtenstein * Lithuania * Luxembourg * Malta * Netherlands * Norway * Poland * Portugal * Romania * Slovakia * Slovenia * Spain * Sweden ### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS #### G.1 Purchaser Rights and Obligations Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein. SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA. SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper. #### G.2 Exercise of Rights and obligations The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem. The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. #### G.3 Conditions for modifications of rights and obligations The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives. The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable. #### G.4 Future Public Offers At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA. #### G.5 Issuer Retained Crypto-Assets 0 #### G.6 Utility Token Classification false #### G.7 Key Features of Goods/Services of Utility Tokens Not applicable #### G.8 Utility Token Redemption Not Applicable #### G.9 Non-Trading request true #### G.10 Crypto-Assets purchase or sale modalities Not applicable #### G.11 Crypto-Assets Transfer Restrictions The Offeror does not impose any transfer restrictions. #### G.12 Supply Adjustment Protocols false #### G.13 Supply Adjustment Mechanisms SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations. However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures. #### G.14 Token Value Protection Scheme false #### G.15 Token Value Protection Schemes Description Not applicable #### G.16 Compensation Schemes false #### G.17 Compensation Schemes Description Not applicable #### G.18 Applicable law This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands. #### G.19 Competent court Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules. ### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY #### H.1 Distributed ledger technology SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. #### H.2 Protocols and technical SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. #### H.3 Technology Used As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API. #### H.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### H.5 Incentive Mechanisms and Applicable Fees SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**:\ This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### H.6 Use of Distributed Ledger Technology false #### H.7 DLT Functionality Description Not applicable #### H.8 Audit false #### H.9 Audit outcome Not applicable #### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS #### General information #### S.1 Name SPK Company Ltd #### S.2 Relevant legal entity identifier *Identifier stated to in section A* Not available #### S.3 Name of the crypto-asset *Name of the crypto-asset as stated to in section A* Spark / SPK #### S.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### S.5 Incentive Mechanisms and Applicable Fees *Incentive mechanisms to secure transactions and any fees applicable as stated in section H.* SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**: This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### S.6 Beginning of the period to which the disclosed information relates 2024-05-08 #### S.7 End of the period to which the disclosure relates 2025-05-08 #### **Mandatory key indicator on energy consumption** #### S.8 Energy consumption *Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year* 4,871,148.30 kWh #### **Sources and methodologies** #### S.9 Energy consumption *Sources and methodologies used in relation to the information reported above* The estimated energy consumption provided in Section sources and S.8 has been calculated using the CCRI Crypto methodologies Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)). Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token’s first year by the Ethereum blockchain. ## SPK Company Ltd. - SPK Token White paper Version 3.0 - July 2025 Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area. Date of notification: 2025-06-11 Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token. Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper. ### Table of Contents * [**Important Notice**](#important-notice) * [**Warning**](#warning) * [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset) * [Key information about the offer to the public](#key-information-about-the-offer-to-the-public) * [**Part I – Information on Risks**](#part-i--information-on-risks) * [I.1 Offer-Related Risks](#i1-offer-related-risks) * [I.2 Issuer-Related Risks](#i2-issuer-related-risks) * [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks) * [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks) * [I.5 Technology-Related Risks](#i5-technology-related-risks) * [I.6 Mitigation measures](#i6-mitigation-measures) * [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset) * [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading) * [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform) * [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project) * [D.8 Plans for the token](#d8-plans-for-the-token) * [D.9 Resource Allocation](#d9-resource-allocation) * [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets) * [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public) * [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer) * [Refund Mechanism](#refund-mechanism) * [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets) * [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets) * [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology) * [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts) ### IMPORTANT NOTICE Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time. This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid. The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council. The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. ### WARNING This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. ### Characteristics of the crypto-asset SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper. ### Key information about the offer to the public This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror. The total number of SPK tokens available through this offer is capped at 910,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration. The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees. This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur. The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation. ### PART I – INFORMATION ON RISKS #### I.1 Offer-Related Risks Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities. The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens. Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable. Trading venues, whether decentralised or centralised, pose operational and counterparty risks. Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes. Any future increase in the total supply of SPK - including the newly approved expansion from 710 million to 910 million tokens - will proportionally reduce each existing holder’s relative stake and may exert downward pressure on the token’s market value. Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free. Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations. #### I.2 Issuer-Related Risks The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community. This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures. Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. #### I.3 Crypto-Assets-related Risks As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free. SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner. The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints. Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens. Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information. SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets. Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations. #### I.4 Project Implementation-Related Risks The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks. Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds. Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed. The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests. Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish. In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality. Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project. #### I.5 Technology-Related Risks SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability. Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors. Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes. Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible. Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems. Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility. The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network. In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience. #### I.6 Mitigation measures To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers. * **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [Security and Audits](/dev/security/security-and-audits). * **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience. * **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks. * **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions. * **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible. * **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA. These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem. ### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET #### A.1 Name SPK Company Ltd. #### A.2 Legal Form Company limited by shares #### A.3 Registered address SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301. #### A.4 Head office Road Town, Tortola,
British Virgin Islands #### A.5 Registration Date 2025-02-19 #### A.6 Legal entity identifier Not available #### A.7 Another identifier required pursuant to applicable national law 2170013 #### A.8/9/10 Contacting the Offeror The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days. Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) Telephone number: +1 345-749-9601 Email address: The Offeror does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### A.11 Parent Company Spark Foundation #### A.12 Identity of the management body The sole director of the Offeror is Spark Foundation The directors of Spark Foundation are Glenn Kennedy and Marc Piano Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands #### A.13 Business activity The only purpose is to issue and distribute the Token. #### A.14 Parent Company Business Activity To support, promote, and advance the development, adoption, security, and growth of Spark. #### A.15 Newly Established true #### A.16 Financial condition for the past three years The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. #### A.17 Financial condition since registration The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. ### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity. ### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper. ### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT #### D.1 Crypto-asset project name Spark #### D.2 Crypto-asset name Spark #### D.3 Abbreviation SPK #### D.4 Crypto-asset project description The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. #### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands

Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification false #### D.7 Key Features of Goods/Services for Utility Token Projects Not applicable #### D.8 Plans for the token The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth. ##### **Community-Driven Distribution** SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement. These distribution channels are permissionless, performance-based and structured to encourage use among committed participants. ##### **Protocol Utility and Staking** SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported. ##### **Incentive structures** The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement. ##### **Governance Engagement** SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs. ##### **Future Outlook** As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals. The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. #### D.9 Resource Allocation The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives. A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding. In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships. The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time. #### D.10 Planned Use of Collected Funds or Crypto-Assets The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E. ### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC #### E.1 Public Offering OTPC #### E.2 Reasons for Public Offer The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions. Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18. The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration. #### E.3 Fundraising target Not applicable #### E.4 Minimum Subscription Goal Not applicable #### E.5 Maximum Subscription Goal Not applicable #### E.6 Oversubscription Acceptance false #### E.7 Oversubscription Allocation Not applicable #### E.8 Issue Price €0 #### E.9 Official currency or any other crypto-assets determining the issue price Not applicable #### E.10 Subscription fee €0 #### E.11 Offer Price Determination Method The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens. #### E.12 Total Number of Offered Crypto-Assets 910,000,000 SPK tokens #### E.13 Targeted Holders ALL #### E.14 Holder restrictions The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions. Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited. #### E.15 Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled. #### E.16 Refund Mechanism Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs. Retail holders may exercise their right of withdrawal by following the process available at [www.%%SPARK\_DOMAIN%%/mica](https://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded. Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned. ##### **Return of Tokens and Reimbursement** The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party. The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed. #### E.17 Refund Timeline The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter. #### E.18 Offer Phases The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window. ##### **Phase 1**: This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration. ##### **Phase 2**: This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window. ##### **Phase 3**: This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury. All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window. Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [%%SPARK\_DOMAIN%%](https://spark.fi/), prior to the commencement of the relevant claiming window. This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website. In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases. #### E.19 Early Purchase Discount Not applicable. #### E.20 Time-limited offer false #### E.21 Subscription period beginning Not applicable #### E.22 Subscription period end Not applicable #### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets Not applicable #### E.24 Payment Methods for Crypto-Asset Purchase The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity. #### E.25 Value Transfer Methods for Reimbursement No reimbursement shall be due. #### E.26 Right of Withdrawal In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism. #### E.27 Transfer of Purchased Crypto-Assets Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface. Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper. #### E.28 Transfer Time Schedule SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror. #### E.29 Purchaser’s Technical Requirement To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token. The wallet must support: * Secure storage of private keys and recovery phrases; * On-chain interaction with smart contracts (e.g., for claiming SPK tokens) * The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH. The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to: * Secure their private keys; * Ensure uninterrupted access to their wallet; * Ensure the wallet address used for claiming is correct and under their exclusive control. Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility. #### E.30 Crypto-asset service provider (CASP) name Not applicable #### E.31 CASP identifier Not applicable #### E.32 Placement form NTAV #### E.33 Trading Platforms name Not applicable #### E.34 Trading Platforms Market Identifier Code (MIC) Not applicable #### E.35 Trading Platforms Access Not applicable #### E.36 Involved costs Not applicable #### E.37 Offer Expenses No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens. Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror. All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror. #### E.38 Conflicts of Interest Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise. #### E.39 Applicable law This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA. #### E.40 Competent court Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules. ### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS #### F.1 Crypto-Asset Type Crypto-asset other than an asset-referenced token or e-money token. #### F.2 Crypto-Asset Functionality SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework. SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper. SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity. #### F.3 Planned Application of Functionalities At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering: * **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO. * **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract. * **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services. All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12. **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** #### F.4 Type of white paper OTHR #### F.5 The type of submission MODI #### F.6 Crypto-asset Characteristics See Part D and Section F.2. #### F.7 Commercial name or trading Spark / SPK token name #### F.8 Website of the issuer The Issuer does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### F.9 Starting date of offer to the public or admission to trading 2025-06-17 #### F.10 Publication date 2025-06-20 #### F.11 Any other services provided by the issuer The Offeror does not offer any other services covered by MiCA #### F.12 Identifier of operator of the trading platform Not applicable #### F.13 Language or languages of the white paper English #### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available SPK #### F.15 Functionally Fungible Group Digital Token Identifier, where available Not applicable #### F.16 Voluntary data flag false #### F.17 Personal data flag true #### F.18 LEI eligibility false #### F.19 Home Member State Denmark #### F.20 Host Member States The offer to the public of SPK tokens is passported to the following countries: * Austria * Belgium * Bulgaria * Croatia * Cyprus * Czech Republic * Estonia * Finland * France * Germany * Greece * Hungary * Iceland * Ireland * Italy * Latvia * Liechtenstein * Lithuania * Luxembourg * Malta * Netherlands * Norway * Poland * Portugal * Romania * Slovakia * Slovenia * Spain * Sweden ### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS #### G.1 Purchaser Rights and Obligations Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein. SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA. SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper. #### G.2 Exercise of Rights and obligations The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem. The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. #### G.3 Conditions for modifications of rights and obligations The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives. The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable. #### G.4 Future Public Offers At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA. #### G.5 Issuer Retained Crypto-Assets 0 #### G.6 Utility Token Classification false #### G.7 Key Features of Goods/Services of Utility Tokens Not applicable #### G.8 Utility Token Redemption Not Applicable #### G.9 Non-Trading request true #### G.10 Crypto-Assets purchase or sale modalities Not applicable #### G.11 Crypto-Assets Transfer Restrictions The Offeror does not impose any transfer restrictions. #### G.12 Supply Adjustment Protocols false #### G.13 Supply Adjustment Mechanisms SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations. However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures. #### G.14 Token Value Protection Scheme false #### G.15 Token Value Protection Schemes Description Not applicable #### G.16 Compensation Schemes false #### G.17 Compensation Schemes Description Not applicable #### G.18 Applicable law This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands. #### G.19 Competent court Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules. ### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY #### H.1 Distributed ledger technology SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. #### H.2 Protocols and technical SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. #### H.3 Technology Used As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API. #### H.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### H.5 Incentive Mechanisms and Applicable Fees SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**:\ This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### H.6 Use of Distributed Ledger Technology false #### H.7 DLT Functionality Description Not applicable #### H.8 Audit false #### H.9 Audit outcome Not applicable #### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS #### General information #### S.1 Name SPK Company Ltd #### S.2 Relevant legal entity identifier *Identifier stated to in section A* Not available #### S.3 Name of the crypto-asset *Name of the crypto-asset as stated to in section A* Spark / SPK #### S.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### S.5 Incentive Mechanisms and Applicable Fees *Incentive mechanisms to secure transactions and any fees applicable as stated in section H.* SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**: This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### S.6 Beginning of the period to which the disclosed information relates 2024-05-08 #### S.7 End of the period to which the disclosure relates 2025-05-08 #### **Mandatory key indicator on energy consumption** #### S.8 Energy consumption *Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year* 4,871,148.30 kWh #### **Sources and methodologies** #### S.9 Energy consumption *Sources and methodologies used in relation to the information reported above* The estimated energy consumption provided in Section sources and S.8 has been calculated using the CCRI Crypto methodologies Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)). Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token’s first year by the Ethereum blockchain. | 0 | Table of content | Date of notification
Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114
SUMMARY
Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114
Characteristics of the crypto-asset
Key information about the offer to the public or admission to trading
Part I – Information on risks
Offer-Related Risks
Issuer-Related Risks
Crypto-Assets-related Risks
Project Implementation-Related Risks
Technology-Related Risks
Mitigation measures
Part A - Information about the offeror or the person seeking admission to trading
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier
Another identifier required pursuant to applicable national law
Contact telephone number
E-mail address
Response Time (Days)
Parent Company
Members of the Management body
Business Activity
Parent Company Business Activity
Newly Established
Financial condition for the past three years
Financial condition since registration
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading
Issuer different from offeror or person seeking admission to trading
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier
Another identifier required pursuant to applicable national law
Parent Company
Members of the Management body
Business Activity
Parent Company Business Activity
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier of the operator of the trading platform
Another identifier required pursuant to applicable national law
Parent Company
Reason for Crypto-Asset White Paper Preparation
Members of the Management body
Operator Business Activity
Parent Company Business Activity
Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D - Information about the crypto-asset project
Crypto-asset project name
Crypto-assets name
Abbreviation
Crypto-asset project description
Details of all natural or legal persons involved in the implementation of the crypto-asset project
Utility Token Classification
Key Features of Goods/Services for Utility Token Projects
Plans for the token
Resource Allocation
Planned Use of Collected Funds or Crypto-Assets
Part E - Information about the offer to the public of crypto-assets or their admission to trading
Public Offering or Admission to trading
Reasons for Public Offer or Admission to trading
Fundraising Target
Minimum Subscription Goals
Maximum Subscription Goal
Oversubscription Acceptance
Oversubscription Allocation
Issue Price
Official currency or any other crypto-assets determining the issue price
Subscription fee
Offer Price Determination Method
Total Number of Offered/Traded Crypto-Assets
Targeted Holders
Holder restrictions
Reimbursement Notice
Refund Mechanism
Refund Timeline
Offer Phases
Early Purchase Discount
Time-limited offer
Subscription period beginning
Subscription period end
Safeguarding Arrangements for Offered Funds/Crypto-Assets
Payment Methods for Crypto-Asset Purchase
Value Transfer Methods for Reimbursement
Right of Withdrawal
Transfer of Purchased Crypto-Assets
Transfer Time Schedule
Purchaser's Technical Requirements
Crypto-asset service provider (CASP) name
CASP identifier
Placement form
Trading Platforms name
Trading Platforms Market Identifier Code (MIC)
Trading Platforms Access
Involved costs
Offer Expenses
Conflicts of Interest
Applicable law
Competent court
Part F - Information about the crypto-assets
Crypto-Asset Type
Crypto-Asset Functionality
Planned Application of Functionalities
A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
Type of white paper
The type of submission
Crypto-Asset Characteristics
Commercial name or trading name
Website of the issuer
Starting date of offer to the public or admission to trading
Publication date
Any other services provided by the issuer
Identifier of operator of the trading platform
Language or languages of the white paper
Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available
Functionally Fungible Group Digital Token Identifier, where available
Voluntary data flag
Personal data flag
LEI eligibility
Home Member State
Host Member States
Part G - Information on the rights and obligations attached to the crypto-assets
Purchaser Rights and Obligations
Exercise of Rights and obligations
Conditions for modifications of rights and obligations
Future Public Offers
Issuer Retained Crypto-Assets
Utility Token Classification
Key Features of Goods/Services of Utility Tokens
Utility Tokens Redemption
Non-Trading request
Crypto-Assets purchase or sale modalities
Crypto-Assets Transfer Restrictions
Supply Adjustment Protocols
Supply Adjustment Mechanisms
Token Value Protection Schemes
Token Value Protection Schemes Description
Compensation Schemes
Compensation Schemes Description
Applicable law
Competent court
Part H – Information on the underlying technology
Distributed ledger technology
Protocols and technical standards
Technology Used
Consensus Mechanism
Incentive Mechanisms and Applicable Fees
Use of Distributed Ledger Technology
DLT Functionality Description
Audit
Audit outcome
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
Name
Relevant legal entity identifier
Name of the crypto-asset
Consensus Mechanism
Incentive Mechanisms and Applicable Fees
Beginning of the Period to which the Disclosed Information Relates
End of the Period to which the Disclosed Information Relates
Mandatory key indicator on energy consumption
Energy Consumption
Sources and methodologies
Energy Consumption Sources and Methodologies | | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Date of notification** | 2025-08-20 | | **2** | **Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114** | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission of trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper. | | **3** | **Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114** | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. | | **4** | **Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper may lose its value in part or in full, may not always be transferable and may not be liquid. | | **5** | **Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114** | FALSE | | **6** | **Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. | | **SUMMARY** | | | | **7** | **Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114** | Warning

This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.

The admission to trading of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.

This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. | | **8** | **Characteristics of the crypto-asset** | SPK (the "***Token***") will be launched as an ERC-20 token on the Ethereum blockchain. The Token will provide its holders with a set of rights within Spark (the "***Project***"), a decentralised finance application. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Project or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.

It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. | | **09** | | Not applicable | | **10** | **Key information about the offer to the public or admission to trading** | Spark Foundation (the "***Foundation***") seeks admission of the Token to trading on multiple trading platforms (the "***Exchanges***") in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. | | **Part I – Information on risks** | | | | **I.1** | **Offer-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted. Additionally, the Token's underlying protocol and governance structure may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Project's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.

**Regulatory Compliance Risks**: Evolving regulatory landscapes could impact the Token's classification, trading status, or market acceptance. Changes in regulatory requirements may necessitate modifications to the Project's operation, structure, or governance.
**Market Volatility**: The Token may be subject to extreme price fluctuations, influenced by speculation, market sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders.
**Liquidity Risks**: The ability to buy and sell Tokens depends on trading activity on decentralised exchanges ("***DEXs***") and, if applicable, centralised exchanges ("***CEXs***"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss.
**Risk of Trading Platforms**: When Token holders trade on Exchanges, neither the Issuer nor the Foundation acts as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Foundation for their operations, services, or outcomes.
**Risk of Delisting**: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value.
**Risk of Bankruptcy**: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens.
**Blockchain and Smart Contract Dependency**: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security.
**Governance and Economic Model Risks**: While no inflationary events are currently anticipated, Sky governance will retain the power to mint new Tokens in the future.
**Legal Risks**: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the value of the Token.
**Reputational Risks**: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities—could damage the Project's reputation and, by extension, impact the value and acceptance of the Token.
**Technology Management Risks**: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure.
**Concentration and Conflicts of Interest**: Concentration of Token holdings may lead to governance decisions that favour the interests of one or more specific holders rather than the interests of the community, potentially affecting the value of the Token.
**Decentralised Governance Risk**: The majority of the Token supply will be managed by decentralised governance, including Sky governance and Spark governance. Risks associated with decentralised governance, including without limitation the risk of capture, may negatively impact the value of the Token.
**Industry Competition Risks**: The Project faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token.
**Unanticipated Risks**: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section. | | **I.2** | **Issuer-Related Risks** | The Issuer's sole function is to issue and distribute the Tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.

**Operational Risk**: This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures.
**Decentralized Governance Risk**: Furthermore, all post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Issuer has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of the Tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. | | **I.3** | **Crypto-Assets-related Risks** | **Market Volatility Risks**: It is anticipated that the Token's value will be highly volatile and may fluctuate due to market speculation, investor sentiment, regulatory developments, and technological advancements. External factors, such as shifting trends in the crypto industry, changes in demand for blockchain services, or macroeconomic conditions, could contribute to extreme price fluctuations, potentially leading to total depreciation.
**Liquidity Risks**: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire or sell the Token.
**Adoption and Project Demand Risks**: The long-term success of the Token is dependent on widespread adoption of the Project. Adoption is influenced by various external factors, including user demand, competitive market conditions, and organic community-driven expansion. The Foundation has no control over the pace of adoption, and there is no guarantee that the Project will gain sufficient traction to sustain its economic model.
**Blockchain Dependency Risks**: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness.
**Transaction Costs:** While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token.
**Security Risks**:
***Smart Contract Vulnerabilities***: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality.
***Private Key Management***: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible.
**Scam and Fraud Risks**: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Foundation or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud.
**Community and Narrative Risks**: The Token's success is closely tied to community interest and the broader crypto narrative. Market trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption.
**Regulatory and Compliance Risks**:
***Evolving Legal Frameworks***: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality.
***Jurisdictional Restrictions***: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users.
**Technological Obsolescence Risks**: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility.
**Software Weakness Risks**: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free.
**Unanticipated Risks**: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or market conditions, potentially affecting the Token's security, functionality, or value. | | **I.4** | **Project Implementation-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. Additionally, the success and sustainability of the Project rely on various external factors, including market conditions, regulatory developments, and technological advancements.

**Technical Development Risks**:
***Smart Contract Issues***: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms.

***Blockchain Dependency***: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the Project's implementation and functionality.
***Risk of Security Weaknesses in Core Infrastructure***: The Project relies on open-source software, which may be modified by third parties. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Project may negatively impact the Token's usability.
***Bugs in Core Blockchain Code***: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities.
**Regulatory and Compliance Risks:**
***Regulatory Actions in One or More Jurisdictions***: The Token and the underlying Project could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage.
***Evolving Laws and Regulations***: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the Project and the Token.
***Governance Risk***: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable governance outcomes.
**Operational Risks**:
***Resource Allocation***: The Project's success depends on the team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones.
**Market Adoption Risks**:
***Competitive Environment***: The crypto-asset market is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption.
***Community Engagement Risks***: The success of the Token depends heavily on community-driven marketing and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability.
**Timeline and Milestone Risks**:
***Delayed Milestones***: Key milestones may face delays due to technical, operational, or funding challenges.
***CEX Listing Risks***: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market access.
**Ecosystem Risks**:
***Dependence on External Parties***: The Project relies on infrastructure providers and other third-party service providers. Any failure or delay from third-parties could disrupt implementation plans.
**Technology and Software Risks**:
***Risk of Software Weakness***: Blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality.
***Dependency on Underlying Technology***: The Project relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities.
***Risk of Technological Disruption***: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets.
**Network Security Risks**:
***Network Attacks and Cybersecurity Threats***: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("***DDoS***") attacks. These threats could disrupt network operations and compromise security.
***Blockchain Network Attacks***: The Network may be subject to mining attacks, including double-spend attacks, reorganisations, majority mining power attacks, "selfish-mining" attacks, and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts.
**Privacy and Anonymity Risks**:
***Public Ledger Transparency***: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams.
**Economic and Governance Risks**:
***Incentive Model Risks***: Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards.
**Software Weakness Risks**:
***Unforeseen Bugs and Security Vulnerabilities***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.
**Unanticipated Risks**:
***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. | | **I.5** | **Technology-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist.
**Blockchain Dependency Risks**:
***Network Downtime and Congestion***: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities.
***Scalability Challenges***: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability.
***Settlement and Transaction Finality Risks***: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets.
**Smart Contract Risks**:
***Immutability Risks***: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections.
***Security Exploits***: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution.
**Wallet and Storage Risks**:
***Private Key Management***: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone.
***Compatibility Issues***: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token.
**Ecosystem Dependency Risks**:
***DEX and CEX Integration Issues***: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or de-listings from these platforms could limit liquidity, disrupt trading, and reduce market accessibility.
***Reliance on Third-Party Services***: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token.
**Software and Project Risks**:
***Risk of Attacks and Forks***: The underlying blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security.
***Risk of Technological Disruption***: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers.
***Dependency on Underlying Technology***: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency.
***Unforeseen Vulnerabilities in Blockchain***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.
**Privacy and Anonymity Risks**:
***Public Ledger Transparency***: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities.
***Exposure to Fraud and Targeted Attacks***: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks.
**Economic and Project Viability Risks**:
***Incentive Model Risks***: Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or changes to rewards.
**Unanticipated Risks**:
***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. | | **I.6** | **Mitigation measures** | To address the range of risks associated with the Token, the Project has implemented multiple mitigation strategies across technical, operational, and governance layers.

Smart Contract Audits: All critical smart contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [Security and Audits](/dev/security/security-and-audits).
Progressive rollout: The Token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience.
Decentralised Governance: The Token's governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks.
Transparent communication: Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions.
Liquidity support and listings: While no guarantee is provided, the Issuer and the Foundation may collaborate with market participants to encourage liquidity provision and exchange listings where feasible.
Regulatory Alignment: The Project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.

These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with the Tokens or the broader Spark ecosystem. | | **Part A - Information about the offeror or the person seeking admission to trading** | | | | **A.1** | **Name** | Spark Foundation | | **A.2** | **Legal form** | Foundation company limited by guarantee without share capital | | **A.3** | **Registered address** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.4** | **Head office** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.5** | **Registration Date** | 2025-02-05 | | **A.6** | **Legal entity identifier** | Not available | | **A.7** | **Another identifier required pursuant to applicable national law** | 418210 | | **A.8** | **Contact telephone number** | 001 345-749-9601 | | **A.9** | **E-mail address** | Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) | | **A.10** | **Response Time (Days)** | Fourteen (14) days | | **A.11** | **Parent Company** | Not applicable | | **A.12** | **Members of the Management body** | **Glenn Kennedy**
Director
Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands

**Marc Piano**
Director
Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **A.13** | **Business Activity** | To support, promote, and advance the development, adoption, security, and growth of Spark. | | **A.14** | **Parent Company Business Activity** | Not applicable | | **A.15** | **Newly Established** | TRUE | | **A.16** | **Financial condition for the past three years** | Not applicable | | **A.17** | **Financial condition since registration** | The Foundation will be capitalised as needed to fulfil its mandate of supporting the Spark ecosystem. It has no debt and being a brand new company, should have no material liabilities as of the date of this whitepaper. | | **Part B - Information about the issuer, if different from the offeror or person seeking admission to trading** | | | | **B.1** | **Issuer different from offeror or person seeking admission to trading** | TRUE | | **B.2** | **Name** | SPK Company Ltd. | | **B.3** | **Legal form** | Company limited by shares | | **B.4** | **Registered address** | SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301,
Road Town, Tortola,
British Virgin Islands | | **B.5** | **Head office** | SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301,
Road Town, Tortola,
British Virgin Islands | | **B.6** | **Registration Date** | 2025-02-19 | | **B.7** | **Legal entity identifier** | Not available | | **B.8** | **Another identifier required pursuant to applicable national law** | 2170013 | | **B.9** | **Parent Company** | Spark Foundation | | **B.10** | **Members of the Management body** | The sole director of the Issuer is **Spark Foundation**

The directors of Spark Foundation are Glenn Kennedy and Marc Piano

Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands | | **B.11** | **Business Activity** | The only purpose is to issue and distribute the Token. | | **B.12** | **Parent Company Business Activity** | See Section A.13. | | **Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | | | | **C.1** | **Name** | Not applicable | | **C.2** | **Legal form** | Not applicable | | **C.3** | **Registered address** | Not applicable | | **C.4** | **Head office** | Not applicable | | **C.5** | **Registration Date** | Not applicable | | **C.6** | **Legal entity identifier of the operator of the trading platform** | Not applicable | | **C.7** | **Another identifier required pursuant to applicable national law** | Not applicable | | **C.8** | **Parent Company** | Not applicable | | **C.9** | **Reason for Crypto-Asset White Paper Preparation** | Not applicable | | **C.10** | **Members of the Management body** | Not applicable | | **C.11** | **Operator Business Activity** | Not applicable | | **C.12** | **Parent Company Business Activity** | Not applicable | | **C.13** | **Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable | | **C.14** | **Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable | | **Part D - Information about the crypto-asset project** | | | | **D.1** | **Crypto-asset project name** | Spark | | **D.2** | **Crypto-assets name** | Spark | | **D.3** | **Abbreviation** | SPK | | **D.4** | **Crypto-asset project description** | The Project is a DeFi protocol which emerged from Sky, previously known as MakerDAO, and serves as a 'Sky Star', a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. | | **D.5** | **Details of all natural or legal persons involved in the implementation of the crypto-asset project** | **SPK Company, Ltd.**
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands

**Spark Foundation**
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane
Camana Bay, George Town, Grand Cayman KY1-9006, Cayman Islands | | **D.6** | **Utility Token Classification** | FALSE | | **D.7** | **Key Features of Goods/Services for Utility Token Projects** | Not applicable | | **D.8** | **Plans for the token** | **Rewards:** Soon after the token generation event, a portion of the Token allocation will be used for airdrops to reward early supporters of the Project as well as its early users. Tokens may also be used in the future to reward users who use the Project.
**Staking in exchange for Rewards:** Token holders may be given the option to stake their Tokens to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and the Foundation anticipates that rewards, if any, will reflect the level of engagement and the function being supported.
**Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3.
**Future Outlook:** As the the Project grows, the Tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals.
**Vision:** The vision for the Tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. | | **D.9** | **Resource Allocation** | Allocated resources include technical resources from developers, legal and compliance resources from counsel, and financial resources by means of grants from Sky's DAO. | | **D.10** | **Planned Use of Collected Funds or Crypto-Assets** | Not applicable | | **Part E - Information about the offer to the public of crypto-assets or their admission to trading** | | | | **E.1** | **Public Offering or Admission to trading** | ATTR | | **E.2** | **Reasons for Public Offer or Admission to trading** | The Foundation seeks admission of the Token to trading on multiple Exchanges in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. | | **E.3** | **Fundraising Target** | Not applicable | | **E.4** | **Minimum Subscription Goals** | Not applicable | | **E.5** | **Maximum Subscription Goal** | Not applicable | | **E.6** | **Oversubscription Acceptance** | Not applicable | | **E.7** | **Oversubscription Allocation** | Not applicable | | **E.8** | **Issue Price** | Not applicable | | **E.9** | **Official currency or any other crypto-assets determining the issue price** | Not applicable | | **E.10** | **Subscription fee** | Not applicable | | **E.11** | **Offer Price Determination Method** | Not applicable | | **E.12** | **Total Number of Offered/Traded Crypto-Assets** | Not applicable | | **E.13** | **Targeted Holders** | ALL | | **E.14** | **Holder restrictions** | The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange.

The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. | | **E.15** | **Reimbursement Notice** | Not applicable | | **E.16** | **Refund Mechanism** | Not applicable | | **E.17** | **Refund Timeline** | Not applicable | | **E.18** | **Offer Phases** | Not applicable | | **E.19** | **Early Purchase Discount** | Not applicable | | **E.20** | **Time-limited offer** | Not applicable | | **E.21** | **Subscription period beginning** | Not applicable | | **E.22** | **Subscription period end** | Not applicable | | **E.23** | **Safeguarding Arrangements for Offered Funds/Crypto-Assets** | Not applicable | | **E.24** | **Payment Methods for Crypto-Asset Purchase** | The methods available for purchasing the Token depend on the functionality and policies of the Exchanges or other third-party platforms through which the Token is admitted to trading. Accepted payment methods may include fiat currencies, other crypto-assets, or stablecoins, subject to the configuration and offerings of each respective platform. | | **E.25** | **Value Transfer Methods for Reimbursement** | Not applicable | | **E.26** | **Right of Withdrawal** | Not applicable | | **E.27** | **Transfer of Purchased Crypto-Assets** | Not applicable | | **E.28** | **Transfer Time Schedule** | Not applicable | | **E.29** | **Purchaser's Technical Requirements** | To access and trade the Tokens following their admission to trading, purchasers must meet certain technical requirements. These requirements are primarily determined by the centralized Exchanges where the Tokens are listed, and may include the following:

A device (computer or mobile) capable of securely accessing and operating an account on an Exchange;
A stable internet connection to interact with the Exchange interface and execute transactions;
The ability to receive and store Tokens within the exchange account infrastructure, as provided by the Exchange;

Where trading takes place on decentralized exchanges (DEXs), or where tokens are withdrawn to self-custodied wallets, additional technical requirements apply:

Access to a compatible digital wallet capable of interacting with the Token's blockchain (e.g., Ethereum for ERC-20 Tokens);
Secure management of private keys and recovery phrases;
The ability to sign transactions and pay applicable network (gas) fees on the Ethereum blockchain.

The Foundation does not provide technical infrastructure such as exchange access, custody services, or wallets. It is the responsibility of the purchaser to ensure that all relevant technical requirements are met in order to receive and transact with the Tokens. | | **E.30** | **Crypto-asset service provider (CASP) name** | Not applicable | | **E.31** | **CASP identifier** | Not applicable | | **E.32** | **Placement form** | NTAV | | **E.33** | **Trading Platforms name** | **OKX**: [https://www.okx.com/](https://www.okx.com/)
**Binance**: [https://www.binance.com/](https://www.binance.com/)
**Upbit**: [https://upbit.com/](https://upbit.com/)
**Coinbase**: [https://www.coinbase.com/](https://www.coinbase.com/)
**Bybit**: [https://www.bybit.com/](https://www.bybit.com/)
**Gate.io**: [https://www.gate.io/](https://www.gate.io/)
**Bithumb**: [https://www.bithumb.com/](https://www.bithumb.com/)
**KuCoin**: [https://www.kucoin.com/](https://www.kucoin.com/)
**Kraken**: [https://www.kraken.com/](https://www.kraken.com/)
**Bitget**: [https://www.bitget.com/](https://www.bitget.com/)
**HTX**: [https://www.htx.com/](https://www.htx.com/)
**Crypto.com**: [https://crypto.com/](https://crypto.com/)
**Bitvavo**: [https://bitvavo.com/](https://bitvavo.com/)
**Bitkub**: [https://www.bitkub.com/](https://www.bitkub.com/)
**MEXC**: [https://www.mexc.com/](https://www.mexc.com/)
**Coinone**: [https://coinone.co.kr/](https://coinone.co.kr/)
**Bitstamp**: [https://www.bitstamp.net/](https://www.bitstamp.net/)
**Revolut**: [https://www.revolut.com/](https://www.revolut.com/)
**Paribu**: [https://www.paribu.com/](https://www.paribu.com/)
**Pintu**: [https://pintu.co.id/](https://pintu.co.id/)
**LBank**: [https://www.lbank.info/](https://www.lbank.info/)
**Bitpanda**: [https://www.bitpanda.com/](https://www.bitpanda.com/)
**Ourbit**: [https://www.ourbit.com/](https://www.ourbit.com/)
**Hashkey**: [https://www.hashkey.com/](https://www.hashkey.com/)
**Bitfinex**: [https://www.bitfinex.com/](https://www.bitfinex.com/)
**CoinDCX**: [https://coindcx.com/](https://coindcx.com/)
**BTSE**: [https://www.btse.com/](https://www.btse.com/)
**BitMEX**: [https://www.bitmex.com/](https://www.bitmex.com/)
**XT.COM**: [https://www.xt.com/](https://www.xt.com/)
**Bilaxy**: [https://www.bilaxy.com/](https://www.bilaxy.com/)
**AscendEX**: [https://ascendex.com/](https://ascendex.com/)
**CoinList**: [https://coinlist.co/](https://coinlist.co/)
**BingX**: [https://www.bingx.com/](https://www.bingx.com/)
**BitMart**: [https://www.bitmart.com/](https://www.bitmart.com/)
**CoinW**: [https://www.coinw.com/](https://www.coinw.com/)
**WhiteBIT**: [https://whitebit.com/](https://whitebit.com/)
**Bitrue**: [https://www.bitrue.com/](https://www.bitrue.com/)
**Phemex**: [https://phemex.com/](https://phemex.com/)
**WazirX**: [https://wazirx.com/](https://wazirx.com/)
**WOO X**: [https://woo.org/](https://woo.org/)
**Poloniex**: [https://poloniex.com/](https://poloniex.com/) | | **E.34** | **Trading Platforms Market Identifier Code (MIC)** | Not applicable | | **E.35** | **Trading Platforms Access** | The Exchanges are accessible via their respective websites. | | **E.36** | **Involved costs** | Not applicable | | **E.37** | **Offer Expenses** | Not applicable | | **E.38** | **Conflicts of Interest** | Not applicable | | **E.39** | **Applicable law** | This white paper is being published solely for purposes of admission to trading, not an offer to the public of the Token. However, subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. | | **E.40** | **Competent court** | See Section E.39. | | **Part F - Information about the crypto-assets** | | | | **F.1** | **Crypto-Asset Type** | Crypto-asset other than an asset-referenced token or e-money token | | **F.2** | **Crypto-Asset Functionality** | According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA.

The Token qualifies as a crypto-asset within the meaning of MiCA, as it is a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT").

The Token displays the following functionalities:

**Rewards and Incentive Structures:** The Token is intended to support the long-term functionality, security, and decentralization of the Spark ecosystem through various incentive mechanisms. Token holders may have the opportunity to engage in network activities such as staking, which is designed to enhance protocol resilience and performance. Staking may be associated with specific components of the protocol, for example, cross-chain infrastructure or network security mechanisms, and may require time-bound commitments or minimum engagement thresholds.
The Foundation anticipates that rewards, where applicable, will be designed to reflect the level and nature of participation, as determined by the parameters of the relevant mechanism. All such mechanisms, including staking terms and reward structures, remain subject to further refinement through governance processes and technical development.
**Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. Overall: The Token is designed primarily as a token for use within the Spark ecosystem, enabling holders to participate in governance, access reward and incentive programs, and interact with protocol features as they evolve over time. | | **F.3** | **Planned Application of Functionalities** | At the time of publication of this whitepaper, the Foundation anticipates the following:
the rewards and incentive structures described in Section F.2 and in other parts of this whitepaper will be made available for the Token holders progressively following the Token Generation Event ('TGE'); and
the governance feature described in Section F.2 and in other parts of this whitepaper will also evolve over time by the governance community and development team. Any governance rights granted to Token holders will be subject to any rules applicable to the Project's governance, including but not limited to the Sky Atlas. | | **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** | | | | **F.4** | **Type of white paper** | OTHR | | **F.5** | **The type of submission** | MODI | | **F.6** | **Crypto-Asset Characteristics** | See Section 8. | | **F.7** | **Commercial name or trading name** | Spark | | **F.8** | **Website of the issuer** | Neither the Foundation nor the Issuer have a website.
The website of the Project is [%%SPARK\_URL%%/](https://spark.fi/) | | **F.9** | **Starting date of offer to the public or admission to trading** | 2025-05-28 | | **F.10** | **Publication date** | 2025-06-03 | | **F.11** | **Any other services provided by the issuer** | Neither the Foundation nor the Issuer provide any other services not covered by Regulation (EU) 2023/1114. | | **F.12** | **Identifier of operator of the trading platform** | Not applicable | | **F.13** | **Language or languages of the white paper** | English | | **F.14** | **Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available** | SPK | | **F.15** | **Functionally Fungible Group Digital Token Identifier, where available** | Not applicable | | **F.16** | **Voluntary data flag** | FALSE | | **F.17** | **Personal data flag** | TRUE | | **F.18** | **LEI eligibility** | FALSE | | **F.19** | **Home Member State** | Malta | | **F.20** | **Host Member States** | The admission to trading of the Token is passported in the following countries: Austria
Belgium
Bulgaria
Croatia
Cyprus
Czech Republic
Germany
Denmark
Estonia
Spain
Finland
France
Greece
Hungary
Iceland
Ireland
Italy
Latvia
Liechtenstein
Lithuania
Luxembourg
Netherlands
Norway
Poland
Portugal
Romania
Slovakia
Slovenia
Sweden | | **Part G - Information on the rights and obligations attached to the crypto-assets** | | | | **G.1** | **Purchaser Rights and Obligations** | The Token enables its holders to interact with the Project that operates autonomously and without the Foundation having an operative role. As a result, the Foundation, to the fullest extent permitted by applicable laws, disclaims all warranties, whether express or implied. This includes but is not limited to, implied warranties of merchantability and fitness for a particular purpose.
Moreover, to the fullest extent permissible by applicable laws, the Foundation is not liable for any damages arising from the holding, use, transfer, or interactions involving Tokens and the Project.
This limitation applies to all forms of damages, including direct, indirect, incidental, punitive, and consequential damages. | | **G.2** | **Exercise of Rights and obligations** | Any rights associated with the Tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the Token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in any functionality associated with the Token shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.

The obligations of the Token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. | | **G.3** | **Conditions for modifications of rights and obligations** | Neither the Foundation nor the Issuer has the ability to unilaterally modify the rights or obligations attached to the Token. However, the functionalities or rights attaching to the Token may be affected by changes made to the Project by the governance community and development team. These protocol-level changes may impact on the ways in which the Token can be used. Holders are encouraged to monitor official protocol channels for updates, including but not limited to the Project's website ([%%SPARK\_URL%%/](https://spark.fi/)mica). | | **G.4** | **Future Public Offers** | The Issuer has submitted a white paper for the offering of the Tokens to the public. The white paper will be accessible at %%SPARK\_URL%%/mica upon the end of the notification period. | | **G.5** | **Issuer Retained Crypto-Assets** | 0 | | **G.6** | **Utility Token Classification** | FALSE | | **G.7** | **Key Features of Goods/Services of Utility Tokens** | Not applicable | | **G.8** | **Utility Tokens Redemption** | No redemption | | **G.9** | **Non-Trading request** | TRUE | | **G.10** | **Crypto-Assets purchase or sale modalities** | Not applicable | | **G.11** | **Crypto-Assets Transfer Restrictions** | The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through "private sales" are subject to restrictions as per the terms of sale. | | **G.12** | **Supply Adjustment Protocols** | FALSE | | **G.13** | **Supply Adjustment Mechanisms** | Sky governance will control the Token's mint and burn functionality. Therefore, modifications to the Token's supply can only occur via a vote of Sky governance. | | **G.14** | **Token Value Protection Schemes** | FALSE | | **G.15** | **Token Value Protection Schemes Description** | Not applicable | | **G.16** | **Compensation Schemes** | FALSE | | **G.17** | **Compensation Schemes Description** | Not applicable | | **G.18** | **Applicable law** | Subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. | | **G.19** | **Competent court** | See Section G.18. | | **Part H – Information on the underlying technology** | | | | **H.1** | **Distributed ledger technology** | The Token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The Token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. | | **H.2** | **Protocols and technical standards** | The Token conforms to the ERC-20 token standard and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. | | **H.3** | **Technology Used** | As an ERC-20 token, the Token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the Token through their own non-custodial wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API. | | **H.4** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a Proof of Stake ("PoS") consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. | | **H.5** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.

Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:

**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and
**Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.

Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. | | **H.6** | **Use of Distributed Ledger Technology** | FALSE | | **H.7** | **DLT Functionality Description** | Not applicable | | **H.8** | **Audit** | FALSE | | **H.9** | **Audit outcome** | Not applicable | | **Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts** | | | | **S.01** | **Name** | Spark Foundation | | **S.02** | **Relevant legal entity identifier** | Not available | | **S.03** | **Name of the crypto-asset** | SPK | | **S.04** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a PoS consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. | | **S.05** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.

Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:

**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and
**Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.

Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. | | **S.06** | **Beginning of the Period to which the Disclosed Information Relates** | 2024/05/08 | | **S.07** | **End of the Period to which the Disclosed Information Relates** | 2025/05/08 | | **Mandatory key indicator on energy consumption** | | | | **S.08** | **Energy Consumption** | 6,490,000 kWh | | **Sources and methodologies** | | | | **S.09** | **Energy Consumption Sources and Methodologies** | "For the calculation of energy consumption, a bottom-up approach, as described in the CBNSI methodology, is used. In this approach, Ethereum network nodes are considered the central factor determining total energy demand. Hardware assumptions are based on empirical findings from public information sources, open-source network crawlers, and analytical tools developed by CCAF. The main determinants for estimating the hardware used within the network are the operational requirements of the Ethereum client software. The electricity consumption of the relevant hardware configurations has been measured in certified test laboratories, as set out in the referenced methodology.

CBNSI's model estimates the average power demand of the Ethereum consensus layer on a daily basis, using observed Beacon node counts, client software distribution, and typical hardware profiles. The model then annualises these daily figures to produce an annual electricity consumption estimate.

Secondary cross-check: The CBNSI figures are consistent in order of magnitude with the Digiconomist – Ethereum Energy Consumption Index, which applies a separate estimation methodology.

Reference period: Please refer to S.6 and S.7.

Calculation for SPK token: As SPK is an ERC-20 token on the Ethereum network, the token's share of total network electricity consumption may be approximated by the proportion of total Ethereum gas usage attributable to SPK-related transactions in the reference period. This pro-rata value is calculated as:

`Espk = Ethereum x SPK_gas_used / Total_Ethereum_gas_used`

Since the SPK token has only recently been created, the energy consumption figure relates to the previous calendar year and serves as an estimate of what may be consumed during the SPK token's first year of operation on the Ethereum blockchain. | | **S.10** | **Renewable energy consumption (%)** | "Based on the CBNSI methodology and the geographical distribution of Ethereum validator nodes, approximately 40.0 % (0.400) of the electricity used for the validation of transactions and the maintenance of the integrity of the Ethereum distributed ledger originates from renewable energy sources.

This percentage is calculated by weighting the renewable share of the electricity grid in each country/region hosting validator nodes according to the proportion of validators located there. Regional renewable share data is sourced from official statistics (e.g., Eurostat for the EU, U.S. Energy Information Administration for the United States, and equivalent agencies for other regions)." | | **S.11** | **Energy consumption per transaction (kWh/transaction)** | "Based on the total annual energy consumption disclosed in J.8 (6,490,000 kWh) and the total number of Ethereum transactions in the reference period (468,000,000, source: Etherscan), the average energy consumption per transaction is:

`kWh/tx = 6,490,000 / 468,000,000 = 0.0139 kWh/tx`

This represents the average network-wide figure and is not limited to the SPK-related transactions." | | **S.12** | **Scope 1 greenhouse gas emissions (tCO₂e/year)** | "For the Ethereum proof-of-stake network, scope 1 greenhouse gas emissions – defined as direct emissions from owned or controlled sources – are negligible, as validators do not burn fossil fuels on-site for consensus operations.

Accordingly, the annualised scope 1 greenhouse gas emissions for the reference period are reported as 0tCO₂e/year." | | **S.13** | **Scope 2 greenhouse gas emissions (tCO₂e/year)** | "Based on the total annual energy consumption disclosed in J.8 (6 490 000 kWh) and an average grid emission factor of 0.35 kg CO₂e/kWh (source: European Environment Agency – EU residual mix 2023), the estimated annualised scope 2 greenhouse gas emissions are:

`6,490,000 x 0.35kgCO2e ≈ 2,271,500kgCO2e/year)`
`(≈ 2,272 tCO2e/year)`

Scope 2 emissions represent indirect emissions from the generation of purchased electricity consumed by Ethereum validators.

Scope 1 emissions for the Ethereum proof-of-stake network are negligible and reported as zero in J.12." | | **S.14** | **Total greenhouse gas emissions per transaction (kgCO₂e/transaction)** | "Total annual GHG emissions (scope 1 + scope 2) are 2,272 tCO₂e/year (see J.12–J.13). Based on 468,000,000 Ethereum transactions in the reference period, the average emissions per transaction are:

`kgCO2e/tx = 2,272,000 kgCO2e / 468,000,000 tx`
`kgCO2e/tx ≈ 0.00485 kgCO2e/tx`" | | **S.15** | **Sources of data** | "Primary source: Cambridge Centre for Alternative Finance (CCAF) – Cambridge Blockchain Network Sustainability Index (CBNSI) – Ethereum.

Secondary source: Digiconomist – Ethereum Energy Consumption Index (cross-check).

Emissions factor source: European Environment Agency – EU residual mix 2023." | | **S.16** | **Methodologies applied** | "The energy consumption figures are calculated using CBNSI's "bottom-up" methodology: network node counts, client software distribution, and typical hardware configurations are combined to estimate total network electricity demand. Hardware power draw values are obtained from certified laboratory tests. Daily estimates are annualised using a 7-day moving average. Emissions are calculated by multiplying total electricity consumption by the average grid emission factor for the geographical distribution of nodes. Renewable share is derived from the renewable percentage of the relevant grid mixes. Transaction counts are obtained from on-chain data (Etherscan API).

For SPK, as an ERC-20 token on Ethereum, energy consumption and emissions are expressed at the network level; a pro-rata allocation based on SPK's share of total Ethereum gas usage can also be provided for illustrative purposes." | ## SPK Company Ltd. - SPK Token White paper Version 4.0 - August 2025 Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area. Date of notification: 2025-08-20 Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token. Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper. ### Table of Contents * [**Important Notice**](#important-notice) * [**Warning**](#warning) * [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset) * [Key information about the offer to the public](#key-information-about-the-offer-to-the-public) * [**Part I – Information on Risks**](#part-i--information-on-risks) * [I.1 Offer-Related Risks](#i1-offer-related-risks) * [I.2 Issuer-Related Risks](#i2-issuer-related-risks) * [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks) * [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks) * [I.5 Technology-Related Risks](#i5-technology-related-risks) * [I.6 Mitigation measures](#i6-mitigation-measures) * [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset) * [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading) * [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform) * [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project) * [D.8 Plans for the token](#d8-plans-for-the-token) * [D.9 Resource Allocation](#d9-resource-allocation) * [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets) * [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public) * [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer) * [Refund Mechanism](#refund-mechanism) * [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets) * [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets) * [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology) * [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts) ### IMPORTANT NOTICE Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time. This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid. The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council. The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. ### WARNING This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. ### Characteristics of the crypto-asset SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper. ### Key information about the offer to the public This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror. The total number of SPK tokens available through this offer is capped at 910,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration. The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees. This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur. The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation. ### PART I – INFORMATION ON RISKS #### I.1 Offer-Related Risks Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities. The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens. Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable. Trading venues, whether decentralised or centralised, pose operational and counterparty risks. Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes. Any future increase in the total supply of SPK - including the newly approved expansion from 710 million to 910 million tokens - will proportionally reduce each existing holder’s relative stake and may exert downward pressure on the token’s market value. Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free. Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations. #### I.2 Issuer-Related Risks The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community. This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures. Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. #### I.3 Crypto-Assets-related Risks As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free. SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner. The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints. Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens. Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information. SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets. Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations. #### I.4 Project Implementation-Related Risks The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks. Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds. Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed. The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests. Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish. In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality. Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project. #### I.5 Technology-Related Risks SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability. Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors. Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes. Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible. Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems. Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility. The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network. In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience. #### I.6 Mitigation measures To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers. * **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [Security and Audits](/dev/security/security-and-audits). * **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience. * **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks. * **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions. * **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible. * **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA. These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem. ### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET #### A.1 Name SPK Company Ltd. #### A.2 Legal Form Company limited by shares #### A.3 Registered address SHRM Trustees (BVI) Limited of Trinity Chambers,
PO Box 4301. #### A.4 Head office Road Town, Tortola,
British Virgin Islands #### A.5 Registration Date 2025-02-19 #### A.6 Legal entity identifier Not available #### A.7 Another identifier required pursuant to applicable national law 2170013 #### A.8/9/10 Contacting the Offeror The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days. Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) Telephone number: +1 345-749-9601 Email address: The Offeror does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### A.11 Parent Company Spark Foundation #### A.12 Identity of the management body The sole director of the Offeror is Spark Foundation The directors of Spark Foundation are Glenn Kennedy and Marc Piano Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands #### A.13 Business activity The only purpose is to issue and distribute the Token. #### A.14 Parent Company Business Activity To support, promote, and advance the development, adoption, security, and growth of Spark. #### A.15 Newly Established true #### A.16 Financial condition for the past three years The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. #### A.17 Financial condition since registration The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them. ### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity. ### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper. ### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT #### D.1 Crypto-asset project name Spark #### D.2 Crypto-asset name Spark #### D.3 Abbreviation SPK #### D.4 Crypto-asset project description The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. #### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands

Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification false #### D.7 Key Features of Goods/Services for Utility Token Projects Not applicable #### D.8 Plans for the token The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth. ##### **Community-Driven Distribution** SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement. These distribution channels are permissionless, performance-based and structured to encourage use among committed participants. ##### **Protocol Utility and Staking** SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported. ##### **Incentive structures** The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement. ##### **Governance Engagement** SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs. ##### **Future Outlook** As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals. The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. #### D.9 Resource Allocation The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives. A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding. In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships. The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time. #### D.10 Planned Use of Collected Funds or Crypto-Assets The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E. ### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC #### E.1 Public Offering OTPC #### E.2 Reasons for Public Offer The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions. Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18. The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration. #### E.3 Fundraising target Not applicable #### E.4 Minimum Subscription Goal Not applicable #### E.5 Maximum Subscription Goal Not applicable #### E.6 Oversubscription Acceptance false #### E.7 Oversubscription Allocation Not applicable #### E.8 Issue Price €0 #### E.9 Official currency or any other crypto-assets determining the issue price Not applicable #### E.10 Subscription fee €0 #### E.11 Offer Price Determination Method The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens. #### E.12 Total Number of Offered Crypto-Assets 910,000,000 SPK tokens #### E.13 Targeted Holders ALL #### E.14 Holder restrictions The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions. Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited. #### E.15 Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled. #### E.16 Refund Mechanism Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs. Retail holders may exercise their right of withdrawal by following the process available at [www.%%SPARK\_DOMAIN%%/mica](https://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded. Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned. ##### **Return of Tokens and Reimbursement** The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party. The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed. #### E.17 Refund Timeline The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter. #### E.18 Offer Phases The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window. ##### **Phase 1**: This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration. ##### **Phase 2**: This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window. ##### **Phase 3**: This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury. All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window. Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [%%SPARK\_DOMAIN%%](https://spark.fi/), prior to the commencement of the relevant claiming window. This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website. In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases. #### E.19 Early Purchase Discount Not applicable. #### E.20 Time-limited offer false #### E.21 Subscription period beginning Not applicable #### E.22 Subscription period end Not applicable #### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets Not applicable #### E.24 Payment Methods for Crypto-Asset Purchase The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity. #### E.25 Value Transfer Methods for Reimbursement No reimbursement shall be due. #### E.26 Right of Withdrawal In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism. #### E.27 Transfer of Purchased Crypto-Assets Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface. Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper. #### E.28 Transfer Time Schedule SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror. #### E.29 Purchaser’s Technical Requirement To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token. The wallet must support: * Secure storage of private keys and recovery phrases; * On-chain interaction with smart contracts (e.g., for claiming SPK tokens) * The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH. The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to: * Secure their private keys; * Ensure uninterrupted access to their wallet; * Ensure the wallet address used for claiming is correct and under their exclusive control. Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility. #### E.30 Crypto-asset service provider (CASP) name Not applicable #### E.31 CASP identifier Not applicable #### E.32 Placement form NTAV #### E.33 Trading Platforms name Not applicable #### E.34 Trading Platforms Market Identifier Code (MIC) Not applicable #### E.35 Trading Platforms Access Not applicable #### E.36 Involved costs Not applicable #### E.37 Offer Expenses No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens. Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror. All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror. #### E.38 Conflicts of Interest Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise. #### E.39 Applicable law This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA. #### E.40 Competent court Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules. ### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS #### F.1 Crypto-Asset Type Crypto-asset other than an asset-referenced token or e-money token. #### F.2 Crypto-Asset Functionality SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework. SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper. SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity. #### F.3 Planned Application of Functionalities At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering: * **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO. * **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract. * **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services. All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12. **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** #### F.4 Type of white paper OTHR #### F.5 The type of submission MODI #### F.6 Crypto-asset Characteristics See Part D and Section F.2. #### F.7 Commercial name or trading Spark / SPK token name #### F.8 Website of the issuer The Issuer does not have a website. The website of the project is [%%SPARK\_URL%%/](https://spark.fi/). #### F.9 Starting date of offer to the public or admission to trading 2025-06-17 #### F.10 Publication date 2025-06-20 #### F.11 Any other services provided by the issuer The Offeror does not offer any other services covered by MiCA #### F.12 Identifier of operator of the trading platform Not applicable #### F.13 Language or languages of the white paper English #### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available SPK #### F.15 Functionally Fungible Group Digital Token Identifier, where available Not applicable #### F.16 Voluntary data flag false #### F.17 Personal data flag true #### F.18 LEI eligibility false #### F.19 Home Member State Denmark #### F.20 Host Member States The offer to the public of SPK tokens is passported to the following countries: * Austria * Belgium * Bulgaria * Croatia * Cyprus * Czech Republic * Estonia * Finland * France * Germany * Greece * Hungary * Iceland * Ireland * Italy * Latvia * Liechtenstein * Lithuania * Luxembourg * Malta * Netherlands * Norway * Poland * Portugal * Romania * Slovakia * Slovenia * Spain * Sweden ### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS #### G.1 Purchaser Rights and Obligations Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein. SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA. SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper. #### G.2 Exercise of Rights and obligations The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem. The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. #### G.3 Conditions for modifications of rights and obligations The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives. The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable. #### G.4 Future Public Offers At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA. #### G.5 Issuer Retained Crypto-Assets 0 #### G.6 Utility Token Classification false #### G.7 Key Features of Goods/Services of Utility Tokens Not applicable #### G.8 Utility Token Redemption Not Applicable #### G.9 Non-Trading request true #### G.10 Crypto-Assets purchase or sale modalities Not applicable #### G.11 Crypto-Assets Transfer Restrictions The Offeror does not impose any transfer restrictions. #### G.12 Supply Adjustment Protocols false #### G.13 Supply Adjustment Mechanisms SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations. However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures. #### G.14 Token Value Protection Scheme false #### G.15 Token Value Protection Schemes Description Not applicable #### G.16 Compensation Schemes false #### G.17 Compensation Schemes Description Not applicable #### G.18 Applicable law This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands. #### G.19 Competent court Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules. ### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY #### H.1 Distributed ledger technology SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. #### H.2 Protocols and technical SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. #### H.3 Technology Used As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API. #### H.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### H.5 Incentive Mechanisms and Applicable Fees SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**:\ This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### H.6 Use of Distributed Ledger Technology false #### H.7 DLT Functionality Description Not applicable #### H.8 Audit false #### H.9 Audit outcome Not applicable #### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS #### General information #### S.1 Name SPK Company Ltd #### S.2 Relevant legal entity identifier *Identifier stated to in section A* Not available #### S.3 Name of the crypto-asset *Name of the crypto-asset as stated to in section A* Spark / SPK #### S.4 Consensus Mechanism The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks. #### S.5 Incentive Mechanisms and Applicable Fees *Incentive mechanisms to secure transactions and any fees applicable as stated in section H.* SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper. The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees. Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components: * **Base fee**: This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation. * **Priority fee (tip)**:\ This is paid to the validator that successfully proposes the block in which the transaction is included. Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. #### S.6 Beginning of the period to which the disclosed information relates 2024-05-08 #### S.7 End of the period to which the disclosure relates 2025-05-08 #### **Mandatory key indicator on energy consumption** #### S.8 Energy consumption *Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year* 6,490,000 kWh #### **Sources and methodologies** #### S.9 Energy Consumption Sources and Methodologies *Sources and methodologies used in relation to the information reported above* For the calculation of energy consumption, a bottom-up approach, as described in the CBNSI methodology, is used. In this approach, Ethereum network nodes are considered the central factor determining total energy demand. Hardware assumptions are based on empirical findings from public information sources, open-source network crawlers, and analytical tools developed by CCAF. The main determinants for estimating the hardware used within the network are the operational requirements of the Ethereum client software. The electricity consumption of the relevant hardware configurations has been measured in certified test laboratories, as set out in the referenced methodology. CBNSI's model estimates the average power demand of the Ethereum consensus layer on a daily basis, using observed Beacon node counts, client software distribution, and typical hardware profiles. The model then annualises these daily figures to produce an annual electricity consumption estimate. Secondary cross-check: The CBNSI figures are consistent in order of magnitude with the Digiconomist – Ethereum Energy Consumption Index, which applies a separate estimation methodology. Reference period: Please refer to S.6 and S.7. Calculation for SPK token: As SPK is an ERC-20 token on the Ethereum network, the token's share of total network electricity consumption may be approximated by the proportion of total Ethereum gas usage attributable to SPK-related transactions in the reference period. This pro-rata value is calculated as: `Espk = Ethereum x SPK_gas_used / Total_Ethereum_gas_used` Since the SPK token has only recently been created, the energy consumption figure relates to the previous calendar year and serves as an estimate of what may be consumed during the SPK token's first year of operation on the Ethereum blockchain. #### S.10 Renewable energy consumption (%) Based on the CBNSI methodology and the geographical distribution of Ethereum validator nodes, approximately 40.0 % (0.400) of the electricity used for the validation of transactions and the maintenance of the integrity of the Ethereum distributed ledger originates from renewable energy sources. This percentage is calculated by weighting the renewable share of the electricity grid in each country/region hosting validator nodes according to the proportion of validators located there. Regional renewable share data is sourced from official statistics (e.g., Eurostat for the EU, U.S. Energy Information Administration for the United States, and equivalent agencies for other regions). #### S.11 Energy consumption per transaction (kWh/transaction) Based on the total annual energy consumption disclosed in S.8 (4,871,148.30 kWh) and the total number of Ethereum transactions in the reference period (468,000,000, source: Etherscan), the average energy consumption per transaction is: `kWh/tx = 4,871,148.30 / 468,000,000 = 0.0104 kWh/tx` This represents the average network-wide figure and is not limited to the SPK-related transactions. #### S.12 Scope 1 greenhouse gas emissions (tCO₂e/year) For the Ethereum proof-of-stake network, scope 1 greenhouse gas emissions – defined as direct emissions from owned or controlled sources – are negligible, as validators do not burn fossil fuels on-site for consensus operations. Accordingly, the annualised scope 1 greenhouse gas emissions for the reference period are reported as 0tCO₂e/year. #### S.13 Scope 2 greenhouse gas emissions (tCO₂e/year) Based on the total annual energy consumption disclosed in S.8 (4,871,148.30 kWh) and an average grid emission factor of 0.35 kg CO₂e/kWh (source: European Environment Agency – EU residual mix 2023), the estimated annualised scope 2 greenhouse gas emissions are: `4,871,148.30 x 0.35kgCO2e ≈ 1,704,902kgCO2e/year` `(≈ 1,705 tCO2e/year)` Scope 2 emissions represent indirect emissions from the generation of purchased electricity consumed by Ethereum validators. Scope 1 emissions for the Ethereum proof-of-stake network are negligible and reported as zero in S.12. #### S.14 Total greenhouse gas emissions per transaction (kgCO₂e/transaction) Total annual GHG emissions (scope 1 + scope 2) are 1,705 tCO₂e/year (see S.12–S.13). Based on 468,000,000 Ethereum transactions in the reference period, the average emissions per transaction are: `kgCO2e/tx = 1,705,000 kgCO2e / 468,000,000 tx` `kgCO2e/tx ≈ 0.00364 kgCO2e/tx` #### S.15 Sources of data Primary source: Cambridge Centre for Alternative Finance (CCAF) – Cambridge Blockchain Network Sustainability Index (CBNSI) – Ethereum. Secondary source: Digiconomist – Ethereum Energy Consumption Index (cross-check). Emissions factor source: European Environment Agency – EU residual mix 2023. #### S.16 Methodologies applied The energy consumption figures are calculated using CBNSI's "bottom-up" methodology: network node counts, client software distribution, and typical hardware configurations are combined to estimate total network electricity demand. Hardware power draw values are obtained from certified laboratory tests. Daily estimates are annualised using a 7-day moving average. Emissions are calculated by multiplying total electricity consumption by the average grid emission factor for the geographical distribution of nodes. Renewable share is derived from the renewable percentage of the relevant grid mixes. Transaction counts are obtained from on-chain data (Etherscan API). For SPK, as an ERC-20 token on Ethereum, energy consumption and emissions are expressed at the network level; a pro-rata allocation based on SPK's share of total Ethereum gas usage can also be provided for illustrative purposes. ## **Markets in Crypto-Assets (MiCA) Information** ### **White Papers for SPK Token** | | Version | Notified To | Published On | Download | Machine- Readable Version | | :---------------------------------------------------------------------------------------------- | :------ | :--------------------- | :----------- | :-------------------------------------------------------------------------------------------- | :------------------------ | | Spark Foundation’s white paper seeking admission to trade | 1.0 | Malta, on 2025-04-16 | N/A | [Link](https://drive.google.com/file/d/1-w3NyktWcfsID-E6EeWY_78XIC-B1OHg/view?usp=drive_link) | [Link](/mica/1) | | Spark Foundation’s white paper seeking admission to trade, as amended on May 22, 2025\* | 2.0 | Malta, on 2025-05-22 | 2025-06-12 | [Link](https://drive.google.com/file/d/1fwESrD0BMvATXyohfHxfq1agHccHTQSc/view?usp=drive_link) | [Link](/mica/2) | | Spark Foundation’s white paper seeking admission to trade, as amended on August 20, 2025\* | 3.0 | Malta, on 2025-08-20 | 2025-08-30 | [Link](https://drive.google.com/file/d/1dDOLPJE33FR7akOiaP9FBFRRhhvx4FTu/view) | [Link](/mica/6) | | SPK Company Ltd.’s white paper for an offer of crypto-assets | 1.0 | Denmark, on 2025-05-09 | 2025-06-12 | [Link](https://drive.google.com/file/d/16YVjMmJI73_PSIUt0_JP0crmDqP3ZBJT/view?usp=sharing) | [Link](/mica/3) | | SPK Company Ltd.’s white paper for an offer of crypto-assets, as amended on June 11, 2025\*\* | 2.0 | Denmark, on 2025-06-11 | 2025-06-21 | [Link](https://drive.google.com/file/d/1m81OUa2vDchqAAteA9-jl7scToXkZsQr/view) | [Link](/mica/4) | | SPK Company Ltd.’s white paper for an offer of crypto-assets, as amended on July 25, 2025\*\*\* | 3.0 | Denmark, on 2025-07-25 | 2025-08-11 | [Link](https://drive.google.com/file/d/18mFAtaPNKSCuBsq-MH56ebkJC6AN2JPM/view) | [Link](/mica/5) | | SPK Company Ltd.’s white paper for an offer of crypto-assets, as amended on August 20, 2025 | 4.0 | Denmark, on 2025-08-20 | 2025-08-30 | [Link](https://drive.google.com/file/d/1mKp0dh-QicU1RQhIr8r3nHlAq89zbO6e/view?usp=drive_link) | [Link](/mica/7) | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. \*Key material updates include a revised disclaimer and warning notice specifically addressing admission to trading, clarification of staking provisions to accurately reflect their conditional nature dependent on governance and technical developments, updated corporate address details, inclusion of clear references to the separate Offer White Paper, and corrections to token classification and technical requirements. Additionally, statements regarding public token offerings and supply adjustment protocols have been corrected for regulatory accuracy. \*\*The key material update is increasing the total number of offered tokens from 680,000,000 SPK to 710,000,000 SPK. \*\*\*The key material update is increasing the total number of offered tokens from 710,000,000 SPK to 910,000,000 SPK. ### **Contact Information** #### Regarding admission to trading of the SPK token: * **Name:** Spark Foundation * **Registered Address:** Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands * **Phone:** +1 345-749-9601 * **Email:** [mica@sparkfoundation.io](mailto\:mica@sparkfoundation.io) #### Regarding the offer of the SPK token: * **Name:** SPK Company Ltd. * **Registered Address:** SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands * **Phone:** +1 345-749-9601 * **Email:** [mica@sparkfoundation.io](mailto\:mica@sparkfoundation.io) Right of Withdrawal Retail Holders’ Right of Withdrawal Retail purchasers are entitled to a **14-day cooling-off period** during which they may withdraw from the purchase without fee or penalty. The procedural details are set out in **Part E (items E.16 & E.17)** of the White Paper. ### **Circulating Supply** To see SPK’s current circulating supply, visit [%%DATA\_URL%%/spk](https://data.spark.fi/spk). ## Referral Codes Spark assigns integrator partners a unique 3-digit **referral code** (a `uint16` in the range 100–999) that you embed in your integration so deposits coming from your product are attributed back to you. ### How it works The Spark Vault `deposit` function has an overload that accepts a referral code: ```text deposit(uint256 assets, address receiver, uint16 referral) returns (uint256 shares) ``` Pass your assigned code as the third argument when calling `deposit`. Deposits made with a code emit a `Referral(uint16 indexed referral, address indexed owner, uint256 assets, uint256 shares)` event — a reliable, tamper-proof on-chain signal of the TVL originating from your integration. Everything else about the integration stays the same — see the [Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2#deposit) and the [deposit examples](/integrators/spark-vaults-v2-examples#deposit) for the standard flow in viem, ethers, and Solidity. If you do not have a referral code, use the two-argument `deposit(assets, receiver)` overload. ### What a referral code unlocks * **Attribution & reporting.** Every referral code gets a dedicated [reporting dashboard](/integrators/reporting-dashboard) that maps deposits and TVL back to your code, so you can track the performance of your integration over time. * **Partnerships & campaigns.** Some integrator partnerships unlock additional benefits on top of the standard vault rate, plus co-marketing and incentive campaigns tied to your integration's performance. These are activated through the same referral code, so the integration work is one-and-done. ### Getting a code Referral codes are issued by the Spark team. :::tip[Contact us] If you are building an integration and want to request a referral code or discuss a partnership, fill out the [partner form](https://docs.google.com/forms/d/e/1FAIpQLSezdKGi98dUIBn-1jLbyJIqVB_S5XDs2esoK0IdAwWHc95pfA/viewform) or reach out on the [Spark Discord](https://discord.com/invite/sparkfinance). ::: ## Reporting Dashboard Every [referral code](/integrators/referral-codes) gets a dedicated reporting dashboard so you can track the performance of your integration over time. ### What it covers * **Time-weighted TVL (TW-TVL)** — the core metric for campaign performance and incentive eligibility. * **Total active users** — unique depositors attributed to your referral code. * **Average deposit size** — distribution across your user base. * **Daily inflows / outflows** — net flow trends over time. * **User-level data** — per-wallet balances, entry dates, and activity. ### Getting set up Dashboards are provisioned by Spark upon request. :::tip[Request a dashboard] Reach out via the [partner form](https://docs.google.com/forms/d/e/1FAIpQLSezdKGi98dUIBn-1jLbyJIqVB_S5XDs2esoK0IdAwWHc95pfA/viewform) to get your dashboard set up. ::: ## Spark Savings for Integrators Deposit your USDC and earn savings yield with Spark **Spark Savings Vaults** are ERC-4626 yield-bearing vaults that let anyone deposit a stablecoin and earn a continuously compounding savings rate, backed by the Sky ecosystem and the Spark Liquidity Layer. Deposits mint a savings token (e.g. `spUSDC`, `spUSDT`) whose value grows every second at the vault savings rate — no staking, no lockups, withdraw any time. This section is for teams who want to bring that yield into their own product: a wallet, an exchange, a treasury tool, or any app where users hold stablecoins. A full integration combines both of the pieces below. ### The two building blocks :::tip[On-chain contracts — move funds] Spark Vaults are standard [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) vaults. Call `deposit` / `mint` to enter a position and `withdraw` / `redeem` to exit — the same interface across every supported vault. The **[Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2)** walks through each flow, with copy-paste **[examples](/integrators/spark-vaults-v2-examples)** in viem, ethers, and Solidity. For large redemptions that exceed idle liquidity, [Savings Vault Intents](/dev/savings/savings-vault-intents) provide a request-based withdrawal flow. ::: :::tip[Savings Data API — display data] The **[Savings Data API](/integrators/savings-api-reference)** is a read-only REST API exposing current and historic savings data for the vaults — savings rate, TVL, depositors, available liquidity, and collateral composition. Use it to render rates and dashboards in your UI without running your own indexer or on-chain calls. The machine-readable OpenAPI spec is published at [`https://api.spark.fi/openapi.json`](https://api.spark.fi/openapi.json). ::: ### Comprehensive enough to build from a single prompt These docs are written to be self-contained — for human and LLM readers alike. The ERC-4626 flows, the Savings Data API, and the machine-readable [OpenAPI spec](https://api.spark.fi/openapi.json) give a coding assistant everything it needs to scaffold a working integration without any extra context. As a quick proof point, we handed these docs to ChatGPT and asked it to build a small Spark Savings app. It produced a working result in a single shot: :::tip[See it for yourself] **[Building a Spark Savings app in one prompt →](https://chatgpt.com/share/6a1d7b92-eefc-83eb-ab2c-682d327c1abd)** A shared ChatGPT session that turns these docs into a functioning savings app — no hand-holding, no SDK. ::: ### Savings data, ready to present The Savings Data API gives you live and historical data about each vault — savings rates, balances, the assets backing the vault, the liquidity behind it, and more — so you can present Spark Savings to your users however you like. The views below are just a few examples of what that data can power.
USDC and USDT savings rate cards showing live APY
Live savings rates per vault
Savings rate plotted over time
Rates and TVL over time
Collateral composition breakdown of the savings backing
The assets backing the vault
Available liquidity broken down by source
Available liquidity by source
See the [Savings Data API Reference](/integrators/savings-api-reference) for the full set of data and endpoints. ### Deposits and withdrawals, on-chain Because the vaults are ERC-4626, moving funds in and out takes only a handful of standard calls — read a balance, deposit, withdraw, redeem. The [Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2) covers every flow, with full [examples](/integrators/spark-vaults-v2-examples) in viem, ethers, and Solidity. ### Large withdrawals via Savings Liquidity Intents Each Spark Savings vault keeps an idle liquidity buffer for instant withdrawals. For redemptions that exceed that buffer, integrators submit a **Savings Liquidity Intent** — an on-chain request that the [Spark Liquidity Layer](/products/spark-liquidity-layer) picks up off-chain, prepares liquidity for, and fulfills atomically by calling `redeem` on the user's behalf. The user keeps custody of their vault shares until fulfillment, and every step in the lifecycle emits an on-chain event, so the full state of any request is easy to follow from a node or indexer. This is how the Spark Liquidity Layer keeps deposits productively deployed across the Spark balance sheet while still providing liquidity on demand. The mechanism is in production and has already served billions of dollars in large withdrawals. * **[Savings Liquidity Intents guide](/products/spark-savings/guides/liquidity-intents)** — user-facing flow and what to expect in the app. * **[Savings Vault Intents contract reference](/dev/savings/savings-vault-intents)** — full contract behavior, request lifecycle, and configuration. * **[Savings Vault Intents in the integration guide](/integrators/spark-vaults-v2#savings-vault-intents)** — code-level usage alongside the standard ERC-4626 flows. ### Where to go next * **[Savings Data API Reference](/integrators/savings-api-reference)** — interactive reference for the read-only data endpoints. * **[Spark Vaults Smart Contracts Integration Guide](/integrators/spark-vaults-v2)** — read balances, deposit, withdraw, and request large withdrawals. * **[Examples](/integrators/spark-vaults-v2-examples)** — full snippets in viem, ethers, and Solidity. * **[Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents)** — request-based flow for redemptions larger than the idle buffer. ### Why a data API and a smart contracts guide, not an SDK We deliberately ship a read-only data API and a smart contracts integration guide instead of an SDK. The reasoning: * **Spark Vaults are standard ERC-4626.** Once you know `deposit`, `withdraw`, `redeem`, `balanceOf`, and `assetsOf`, there is nothing else to learn — the contract is the surface area. An SDK would mostly re-wrap an interface every EVM tool already supports out of the box. * **You keep your stack.** Call the vaults directly with whatever you already trust — viem, ethers, wagmi, raw JSON-RPC, or a non-JS language. The data API is plain HTTP, so it works the same way from anywhere. * **Easier to migrate.** EVM tooling moves fast. ERC-4626 callsites are trivial to port between libraries; an SDK pins you to one stack and tends to fragment across them (a viem build, an ethers build, a React wrapper, and so on). * **One less dependency.** No SDK means one fewer package to version, audit, and update alongside your own release cycle. import { SavingsApiReference } from '../../components/SavingsApiReference' {/* The interactive reference is rendered client-side by Scalar, so it is absent from the static HTML. This visually-hidden link keeps the machine-readable OpenAPI spec discoverable in the server-rendered markup (for crawlers, LLMs, and screen readers) without showing a redundant link to sighted users. */}

Machine-readable OpenAPI specification:{' '} [https://api.%%SPARK\_DOMAIN%%/openapi.json](https://api.spark.fi/openapi.json)

## Spark Vaults Smart Contracts Examples These examples show common Spark Vaults flows in viem `2.51.0`, ethers `6.16.0`, and Solidity. The examples use the mainnet spUSDC vault: ```text Vault: 0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d Asset: 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 SavingsVaultIntents: 0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf ``` :::info USDT has non-standard allowance behavior: changing an existing non-zero allowance directly to another non-zero allowance can revert. For USDT deposits, reset allowance to `0` before setting the new allowance, or use an approval helper that handles this pattern. ::: ### Setup :::code-group ```ts [viem] import { createPublicClient, createWalletClient, custom, http, parseAbi, parseUnits } from 'viem' import { mainnet } from 'viem/chains' const vault = '0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d' const asset = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48' const intents = '0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf' const erc20Abi = parseAbi([ 'function approve(address spender, uint256 value) returns (bool)', ]) const vaultAbi = parseAbi([ 'function balanceOf(address account) view returns (uint256 shares)', 'function assetsOf(address owner) view returns (uint256 assets)', 'function convertToAssets(uint256 shares) view returns (uint256 assets)', 'function deposit(uint256 assets, address receiver) returns (uint256 shares)', 'function withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares)', 'function redeem(uint256 shares, address receiver, address owner) returns (uint256 assets)', ]) const intentsAbi = parseAbi([ 'function request(address vault, uint256 shares, address recipient, uint256 deadline) returns (uint256 requestId)', 'function cancel(address vault) returns (uint256 requestId)', 'function withdrawRequests(address account, address vault) view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline)', 'function vaultConfig(address vault) view returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)', 'function maxDeadlineDuration() view returns (uint256)', ]) const publicClient = createPublicClient({ chain: mainnet, transport: http(), }) const walletClient = createWalletClient({ chain: mainnet, transport: custom(window.ethereum), }) const [account] = await walletClient.getAddresses() ``` ```ts [ethers] import { BrowserProvider, Contract, parseUnits } from 'ethers' const vault = '0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d' const asset = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48' const intents = '0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf' const erc20Abi = [ 'function approve(address spender, uint256 value) returns (bool)', ] const vaultAbi = [ 'function balanceOf(address account) view returns (uint256)', 'function assetsOf(address owner) view returns (uint256)', 'function convertToAssets(uint256 shares) view returns (uint256)', 'function approve(address spender, uint256 value) returns (bool)', 'function deposit(uint256 assets, address receiver) returns (uint256)', 'function withdraw(uint256 assets, address receiver, address owner) returns (uint256)', 'function redeem(uint256 shares, address receiver, address owner) returns (uint256)', ] const intentsAbi = [ 'function request(address vault, uint256 shares, address recipient, uint256 deadline) returns (uint256)', 'function cancel(address vault) returns (uint256)', 'function withdrawRequests(address account, address vault) view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline)', 'function vaultConfig(address vault) view returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)', 'function maxDeadlineDuration() view returns (uint256)', ] const provider = new BrowserProvider(window.ethereum) const signer = await provider.getSigner() const account = await signer.getAddress() const assetContract = new Contract(asset, erc20Abi, signer) const vaultContract = new Contract(vault, vaultAbi, signer) const intentsContract = new Contract(intents, intentsAbi, signer) ``` ```solidity [Solidity] interface IERC20 { function approve(address spender, uint256 value) external returns (bool); } interface ISparkVault { function balanceOf(address account) external view returns (uint256 shares); function assetsOf(address owner) external view returns (uint256 assets); function convertToAssets(uint256 shares) external view returns (uint256 assets); function deposit(uint256 assets, address receiver) external returns (uint256 shares); function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares); function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets); } interface ISavingsVaultIntents { function request( address vault, uint256 shares, address recipient, uint256 deadline ) external returns (uint256 requestId); function cancel(address vault) external returns (uint256 requestId); function withdrawRequests(address account, address vault) external view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline); function vaultConfig(address vault) external view returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets); function maxDeadlineDuration() external view returns (uint256); } ``` ::: ### Read Balance in Assets :::code-group ```ts [viem] const assets = await publicClient.readContract({ address: vault, abi: vaultAbi, functionName: 'assetsOf', args: [account], }) ``` ```ts [ethers] const assets = await vaultContract.assetsOf(account) ``` ```solidity [Solidity] function assetBalanceOf(ISparkVault vault, address account) external view returns (uint256) { return vault.assetsOf(account); } ``` ::: ### Deposit :::code-group ```ts [viem] const depositAssets = parseUnits('1000', 6) const approveDepositHash = await walletClient.writeContract({ address: asset, abi: erc20Abi, functionName: 'approve', args: [vault, depositAssets], }) await publicClient.waitForTransactionReceipt({ hash: approveDepositHash }) const depositHash = await walletClient.writeContract({ address: vault, abi: vaultAbi, functionName: 'deposit', args: [depositAssets, account], }) await publicClient.waitForTransactionReceipt({ hash: depositHash }) ``` ```ts [ethers] const depositAssets = parseUnits('1000', 6) await (await assetContract.approve(vault, depositAssets)).wait() await (await vaultContract.deposit(depositAssets, account)).wait() ``` ```solidity [Solidity] function deposit(ISparkVault vault, IERC20 asset, uint256 assets, address receiver) external { asset.approve(address(vault), assets); vault.deposit(assets, receiver); } ``` ::: ### Withdraw :::code-group ```ts [viem] const withdrawHash = await walletClient.writeContract({ address: vault, abi: vaultAbi, functionName: 'withdraw', args: [parseUnits('100', 6), account, account], }) await publicClient.waitForTransactionReceipt({ hash: withdrawHash }) ``` ```ts [ethers] await (await vaultContract.withdraw(parseUnits('100', 6), account, account)).wait() ``` ```solidity [Solidity] function withdraw(ISparkVault vault, uint256 assets, address receiver, address owner) external { vault.withdraw(assets, receiver, owner); } ``` ::: ### Withdraw Everything :::code-group ```ts [viem] const allShares = await publicClient.readContract({ address: vault, abi: vaultAbi, functionName: 'balanceOf', args: [account], }) const redeemHash = await walletClient.writeContract({ address: vault, abi: vaultAbi, functionName: 'redeem', args: [allShares, account, account], }) await publicClient.waitForTransactionReceipt({ hash: redeemHash }) ``` ```ts [ethers] const allShares = await vaultContract.balanceOf(account) await (await vaultContract.redeem(allShares, account, account)).wait() ``` ```solidity [Solidity] function withdrawEverything(ISparkVault vault, address receiver, address owner) external { uint256 shares = vault.balanceOf(owner); vault.redeem(shares, receiver, owner); } ``` ::: ### Submit Intent :::code-group ```ts [viem] const intentShares = parseUnits('1000000', 6) const requestedDeadline = BigInt(Math.floor(Date.now() / 1000) + 7 * 24 * 60 * 60) const maxDeadlineDuration = await publicClient.readContract({ address: intents, abi: intentsAbi, functionName: 'maxDeadlineDuration', }) const maxDeadline = BigInt(Math.floor(Date.now() / 1000)) + maxDeadlineDuration const deadline = requestedDeadline > maxDeadline ? maxDeadline : requestedDeadline const [whitelisted, minIntentAssets, maxIntentAssets] = await publicClient.readContract({ address: intents, abi: intentsAbi, functionName: 'vaultConfig', args: [vault], }) const intentAssets = await publicClient.readContract({ address: vault, abi: vaultAbi, functionName: 'convertToAssets', args: [intentShares], }) if (!whitelisted) throw new Error('Vault is not supported for intents') if (intentAssets < minIntentAssets) throw new Error('Intent amount is below minimum') if (intentAssets > maxIntentAssets) throw new Error('Intent amount is above maximum') const approveIntentHash = await walletClient.writeContract({ address: vault, abi: erc20Abi, functionName: 'approve', args: [intents, intentShares], }) await publicClient.waitForTransactionReceipt({ hash: approveIntentHash }) const requestHash = await walletClient.writeContract({ address: intents, abi: intentsAbi, functionName: 'request', args: [vault, intentShares, account, deadline], }) await publicClient.waitForTransactionReceipt({ hash: requestHash }) ``` ```ts [ethers] const intentShares = parseUnits('1000000', 6) const requestedDeadline = BigInt(Math.floor(Date.now() / 1000) + 7 * 24 * 60 * 60) const maxDeadlineDuration = await intentsContract.maxDeadlineDuration() const maxDeadline = BigInt(Math.floor(Date.now() / 1000)) + maxDeadlineDuration const deadline = requestedDeadline > maxDeadline ? maxDeadline : requestedDeadline const [whitelisted, minIntentAssets, maxIntentAssets] = await intentsContract.vaultConfig(vault) const intentAssets = await vaultContract.convertToAssets(intentShares) if (!whitelisted) throw new Error('Vault is not supported for intents') if (intentAssets < minIntentAssets) throw new Error('Intent amount is below minimum') if (intentAssets > maxIntentAssets) throw new Error('Intent amount is above maximum') await (await vaultContract.approve(intents, intentShares)).wait() await (await intentsContract.request(vault, intentShares, account, deadline)).wait() ``` ```solidity [Solidity] function submitIntent( ISparkVault vault, ISavingsVaultIntents intents, uint256 shares, address recipient, uint256 deadline ) external { uint256 maxDeadline = block.timestamp + intents.maxDeadlineDuration(); require(deadline <= maxDeadline, "deadline-too-far"); (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets) = intents.vaultConfig(address(vault)); uint256 assets = vault.convertToAssets(shares); require(whitelisted, "unsupported-vault"); require(assets >= minIntentAssets, "intent-below-min"); require(assets <= maxIntentAssets, "intent-above-max"); IERC20(address(vault)).approve(address(intents), shares); intents.request(address(vault), shares, recipient, deadline); } ``` ::: ### Read or Cancel Intent :::code-group ```ts [viem] const pendingRequest = await publicClient.readContract({ address: intents, abi: intentsAbi, functionName: 'withdrawRequests', args: [account, vault], }) const cancelHash = await walletClient.writeContract({ address: intents, abi: intentsAbi, functionName: 'cancel', args: [vault], }) await publicClient.waitForTransactionReceipt({ hash: cancelHash }) ``` ```ts [ethers] const pendingRequest = await intentsContract.withdrawRequests(account, vault) await (await intentsContract.cancel(vault)).wait() ``` ```solidity [Solidity] function readIntent(ISavingsVaultIntents intents, address account, address vault) external view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline) { return intents.withdrawRequests(account, vault); } function cancelIntent(ISavingsVaultIntents intents, address vault) external { intents.cancel(vault); } ``` ::: ## Spark Vaults Smart Contracts Integration Guide import { PublicDownloadLink } from '../../components/PublicDownloadLink' This guide shows how to integrate the Spark Vaults smart contracts for common user flows: reading balances, depositing, withdrawing, withdrawing everything, and requesting large withdrawals through Savings Vault Intents. For a full contract reference, supported functions, roles, and events, see [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2). For the intent contract reference, see [Savings Vault Intents](/dev/savings/savings-vault-intents). ### Supported Mainnet Vaults The table below lists the vaults supported by the [Savings Data API](/integrators/savings-api-reference). Other Spark Savings vaults exist on-chain (see [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2)) but are not supported by the Data API. | Vault | Protocol | Underlying asset | Vault address | | ------ | -------- | ---------------- | --------------------------------------------------------------------------------------------------------------------- | | spUSDC | Spark | USDC | [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://etherscan.io/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) | | spUSDT | Spark | USDT | [0xe2e7a17dFf93280dec073C995595155283e3C372](https://etherscan.io/address/0xe2e7a17dFf93280dec073C995595155283e3C372) | | sUSDT | Sky | USDT | [0x74cb54e082411cfCAEADb00a0765625B10410DAa](https://etherscan.io/address/0x74cb54e082411cfCAEADb00a0765625B10410DAa) | All Spark-related addresses are tracked in the [Spark Address Registry](https://github.com/sparkdotfi/spark-address-registry). Download the SparkVault ABI to interact with Spark Vaults. ### Core Concepts Spark Vaults are ERC-4626 vaults. A user deposits an underlying asset, such as USDC or USDT, and receives vault shares, such as spUSDC or spUSDT. The user's share balance does not automatically increase. Instead, each share becomes redeemable for more underlying assets over time as the vault accrues yield. This means integrations usually show balances in underlying asset terms, not only in share terms. For example, if a user holds spUSDC, the most useful display balance is their current USDC value: ```text asset balance = assetsOf(user) ``` `assets` are denominated in the underlying token's decimals. For the mainnet USDC and USDT vaults above, that means 6-decimal units. `shares` are denominated in the vault token's decimals, which match the underlying asset for these vaults. ### Vault Functions #### Read Balance in Assets ```text balanceOf(address account) returns (uint256 shares) assetsOf(address owner) returns (uint256 assets) ``` Use `assetsOf(owner)` to show a user's current balance in underlying asset terms. #### Deposit ```text deposit(uint256 assets, address receiver) returns (uint256 shares) deposit(uint256 assets, address receiver, uint16 referral) returns (uint256 shares) previewDeposit(uint256 assets) returns (uint256 shares) maxDeposit(address receiver) returns (uint256 assets) ``` The user approves the vault to spend the underlying asset, then calls `deposit`. The vault transfers the underlying asset from the caller and issues vault shares to `receiver`. Use `previewDeposit(assets)` when quoting expected shares, and `maxDeposit(receiver)` when checking remaining deposit capacity. The `referral` overload is optional. Integrators can use it when Spark has assigned them a referral code for attribution or campaigns — see [Referral Codes](/integrators/referral-codes) for how to get one and what it enables. If you do not have a referral code, use the two-argument `deposit(assets, receiver)` function. :::info USDT has non-standard allowance behavior: changing an existing non-zero allowance directly to another non-zero allowance can revert. For USDT deposits, reset allowance to `0` before setting the new allowance, or use an approval helper that handles this pattern. ::: #### Withdraw ```text withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares) previewWithdraw(uint256 assets) returns (uint256 shares) maxWithdraw(address owner) returns (uint256 assets) ``` Use `withdraw` when the user wants a specific amount of underlying assets back. The vault burns enough shares from `owner` and sends `assets` underlying tokens to `receiver`. Withdrawals depend on the vault's current idle liquidity. The vault can deploy assets through the Spark Liquidity Layer, so `totalAssets()` can be higher than the underlying token balance currently held by the vault. If `maxWithdraw(owner)` is smaller than the amount the user wants to withdraw, the user has two options: * Withdraw in smaller chunks. Spark's offchain infrastructure normally refills vault idle liquidity shortly after withdrawals. * Use [Savings Vault Intents](#savings-vault-intents) for a single request that will be fulfilled after liquidity is prepared. #### Withdraw Everything ```text balanceOf(address account) returns (uint256 shares) maxRedeem(address owner) returns (uint256 shares) redeem(uint256 shares, address receiver, address owner) returns (uint256 assets) ``` Use `redeem(balanceOf(owner), receiver, owner)` when the user wants to withdraw their full vault position. Before showing a one-click "withdraw all" action, compare `balanceOf(owner)` with `maxRedeem(owner)`. If `maxRedeem(owner)` is lower than the user's full share balance, the vault does not currently have enough idle liquidity to withdraw everything immediately. In that case, the user can withdraw in chunks as liquidity is refilled, or submit a Savings Vault Intent. ### Savings Vault Intents Savings Vault Intents is a separate mainnet contract for large withdrawals: ```text SavingsVaultIntents: 0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf ``` [View the contract on Etherscan](https://etherscan.io/address/0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf). Download the SavingsVaultIntents ABI to interact with the intents contract. Use intents when a user wants to withdraw more than the vault can immediately satisfy from its current idle balance. The user creates an onchain withdrawal request for a vault and a share amount. Spark's offchain infrastructure monitors these requests, prepares liquidity for the target vault, and fulfills the request automatically by calling the intent contract. The intent contract does not custody the user's shares when the request is created. The user keeps their vault shares until fulfillment. To allow fulfillment, the user must approve the intent contract to spend the requested vault shares. When a request is fulfilled, the intent contract calls `redeem(shares, recipient, account)` on the vault. The underlying assets are sent directly to `recipient`, and the request emits `RequestFulfilled(account, vault, requestId)`. Each user can have one active request per vault. Calling `request` again for the same `(user, vault)` replaces the previous request and returns a new `requestId`. A user can cancel their active request with `cancel(vault)`, which emits `RequestCancelled(account, vault, requestId)`. If the deadline passes before fulfillment, the request is no longer fulfillable. The user's shares remain in their wallet because they were never escrowed. The user can cancel the expired request or submit a replacement request with a new deadline. #### Intent Functions ```text request(address vault, uint256 shares, address recipient, uint256 deadline) returns (uint256 requestId) cancel(address vault) returns (uint256 requestId) withdrawRequests(address account, address vault) returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline) vaultConfig(address vault) returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets) maxDeadlineDuration() returns (uint256 seconds) ``` `request` creates or replaces the user's active request for a vault. `recipient` receives the underlying assets when the request is fulfilled. `deadline` is the latest timestamp at which the request can be fulfilled. The deadline cannot be more than `maxDeadlineDuration()` seconds in the future. `withdrawRequests(account, vault)` returns the currently active request for an account and vault. Use it to show pending request status in an interface. Only whitelisted vaults and request sizes within `minIntentAssets` and `maxIntentAssets` are supported. If the requested share amount converts to an asset amount below `minIntentAssets` or above `maxIntentAssets`, the transaction will be rejected. ### Examples See [Spark Vaults Smart Contracts Examples](/integrators/spark-vaults-v2-examples) for viem, ethers, and Solidity recipes. ## How to Delegate or Vote This guide will explain how you can participate in Spark Governance by delegating your voting power or voting directly. ### Voting Power Your voting power is the sum of the SPK tokens in your wallet and your staked SPK tokens. ### Delegation **Note:** You can **only** delegate your voting power to **whitelisted delegates**. This means you cannot delegate to an arbitrary address. The Governance page at [%%APP\_DOMAIN%%/spk/governance](https://app.spark.fi/spk/governance) will guide you through the process of delegating to a whitelisted delegate. If you delegate to another address through the Snapshot interface, the voting power is not counted. You might see non whitelisted delegates in the Snapshot UI, due to their global delegation, but they do not have any voting power beyond their own token holdings. Delegating increases the Spark points you earn. You can find the campaign details here: [%%APP\_DOMAIN%%/points](https://app.spark.fi/points). ### How to Delegate Your Voting Power 1. Navigate to [%%APP\_DOMAIN%%/spk/governance](https://app.spark.fi/spk/governance) and connect your wallet, then click "Delegate". ![](/assets/gov/gov-1.webp) *Delegate page view* 2. Select the delegate you wish to delegate to, and click “Delegate” in the Actions section of the window. ![](/assets/gov/gov-3.webp) *Select the delegate you wish to delegate to* 3. That’s it, your SPK voting power has now been delegated! ![](/assets/gov/gov-4.webp) ### Changing delegation or undelegating 1. If you wish to change your existing delegation to another delegate you can simply click “Delegate” in the Voting power delegation section of the governance page. ![](/assets/gov/gov-5.webp) *Change your delegation* 2. This will open the Delegation window, and select the delegate you wish to delegate to instead. ![](/assets/gov/gov-6.webp) 3. You also have the option to undelegate in this window, meaning not delegate your voting power to anyone. This window can also be opened by clicking the three dots next to your existing delegation. Undelegating will enable you to vote directly with your SPK. 4. Once you have decided on who to delegate to, or undelegate entirely, click “Delegate” in the Actions section. 5. Now your delegation should be updated. ### How to vote with your own holdings If you do not delegate your SPK voting power, you can vote directly with your holdings on [https://snapshot.box/#/s\:sparkfi.eth](https://snapshot.box/#/s\:sparkfi.eth) * Once you connect your wallet, Snapshot should display your voting power (sum of the SPK tokens in your wallet and your staked SPK tokens) * Review the proposals, and vote! ## Spark Governance ### **Overview** Spark's governance system defines how Spark operates and evolves. The governance process centers around updating the Spark Agent artifact in the Sky Atlas, which controls key protocol parameters including budgets, risk settings, asset onboarding, protocol integrations in the Spark Liquidity Layer, and new chain deployments. The governance process creates Atlas Root Edit Proposals to modify the Spark Agent artifact, ensuring all protocol changes are transparent and aligned with the Sky Atlas. ### **Key Participants** #### **SPK Token Holders** SPK token holders are the foundation of Spark governance. They can: * Vote directly on proposals using their SPK tokens * Delegate their voting power to trusted delegates * Participate in all governance decisions affecting the protocol #### **Delegates** Delegates are trusted community members who: * Vote on behalf of users who have delegated their SPK tokens * Represent the interests of their delegators in governance decisions * Must be whitelisted to receive delegated voting power *Note: The delegate application process is currently not open as the system is in its bootstrapping phase. Users can choose from existing whitelisted delegates.* #### **Spark Risk Council (SRC)** The Spark Risk Council serves as the protocol's risk assessment body: * **Purpose**: Identifies, assesses, and mitigates risks in governance proposals * **Mandate**: Reviews proposals for potential risks and can prevent malicious or high-risk proposals from proceeding to community vote * **Review Scope**: * Security vulnerabilities and operational attack vectors * Market and treasury risks * Economic risks * Alignment with the Sky Atlas and Spark governance framework #### **Operational Facilitator** The Operational Facilitator ensures smooth governance operations by: * Verifying proposals align with the Sky Atlas * Preparing and scheduling Snapshot polls for approved proposals * Managing the weekly governance cycle timeline ### **Governance Process** #### **1. Proposal Submission** All governance proposals must be submitted as forum posts in the [Spark Prime section](https://forum.skyeco.com/c/spark-prime/) of the Sky forum. Only eligible proposers can submit proposals: * Holders of 1% of total SPK supply (100 million SPK tokens) * Nested contributors (such as Phoenix Labs) #### **2. Weekly Governance Cycle** Spark governance operates on a structured weekly cycle: * **Cycle Start**: Every Monday * **Submission Deadline**: Friday 8:00 AM UTC * **Late Submissions**: After the deadline, inclusion in the current cycle is at the Operational Facilitator's discretion #### **3. Review Process** #### **Spark Risk Council Review** * **Duration**: 1 week from the start of the governance cycle * **Authority**: Can reject proposals that pose substantial risks or are malicious * **Outcome**: Posts a forum review stating whether the proposal is rejected or can proceed to voting #### **Operational Facilitator Review** * **Focus**: Ensures proposals align with the Sky Atlas * **Requirement**: Both SRC approval and Operational Facilitator approval needed to proceed to voting #### **4. Community Voting** Once approved by both reviewers, proposals proceed to Snapshot voting: * **Platform**: Snapshot (off-chain voting) * **Duration**: 3 days * **Approval Threshold**: More than 50% of votes in favor (excluding abstentions) * **Voting Options**: Vote directly with SPK tokens or through delegated voting power ### **How to Participate** #### **Direct Voting** 1. Hold SPK tokens in your wallet 2. Connect to Snapshot when voting opens at [https://snapshot.box/#/s\:sparkfi.eth](https://snapshot.box/#/s\:sparkfi.eth) 3. Cast your vote directly on proposals #### **Delegation** 1. Choose a whitelisted delegate who represents your interests. You can do this at %%APP\_URL%%/spk/governance or on Snapshot at [https://snapshot.box/#/s\:sparkfi.eth/delegates](https://snapshot.box/#/s\:sparkfi.eth/delegates) 2. Delegate your SPK voting power to a specific delegate. 3. Your delegate will vote on your behalf in future proposals *Important: Only delegation to whitelisted addresses counts toward voting power. Delegation to non-whitelisted addresses will not grant voting power.* ### **Implementation Process** #### **Successful Proposals** When a proposal passes community voting: 1. **Atlas Update**: The Sky Atlas is updated with the approved changes 2. **Code Implementation**: If technical changes are needed, a Spark Spell is created with the required modifications 3. **Execution**: The Spark Spell is executed through the established Sky Spell process #### **Failed Proposals** Proposals that do not meet the approval threshold are not implemented and do not proceed to Atlas updates. ### **Additional Resources** * [Sky Atlas](https://sky-atlas.io/) — see the Root Edit Proposal Submission (Spark Governance Process) artifact * [SPK Token Information](/governance/spk-token) * [Spark Prime Forum](https://forum.skyeco.com/c/spark-prime/) ### **FAQ** #### **Who can submit governance proposals?** Only holders of 1% of the total SPK supply (100 million tokens) or nested contributors like Phoenix Labs can submit proposals. This threshold ensures proposers have significant stake in the protocol's success. #### **How long does the governance process take?** The complete process takes approximately 2-3 weeks: * Proposal submission before cycle starts (up to 1 week) * 1 week for reviews (SRC + Operational Facilitator) * 3 days for community voting * Additional time for implementation if the proposal passes #### **Can I change my vote after submitting it?** Yes, votes can be changed during the voting period before it closes. #### **What happens if I delegate my tokens but disagree with my delegate's vote?** You can revoke your delegation at any time and vote directly, or switch to a different delegate whose views better align with yours. However, your voting power for each proposal is determined by your SPK balance and delegation at the time the poll is created, not when you cast your vote. #### **How do I become a delegate?** The delegate application process is currently closed as the governance system is in its bootstrapping phase. #### **What types of changes require governance approval?** All significant protocol changes that impact the risk profile of the protocol require governance approval, including: * Risk parameter adjustments * Onboarding new assets * Protocol integrations * New chain deployments :::info **The SPK airdrop has concluded.** The final claiming date was December 17, 2025, and airdropped SPK can no longer be claimed. Do not trust any websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens. ::: ## SPK Token SPK is the native governance and staking token of Spark. Designed with a long-term vision for sustainability, decentralization, and ecosystem alignment, SPK enables protocol governance, protocol security via staking, and reward distribution to participants. ### Governance SPK is the governance token of Spark. SPK is used for signaling and sentiment checks via Snapshot voting. For more information on Spark Governance, please see the [Spark Governance](/governance) page. ### Staking SPK can be staked and, in the future, staked SPK may be used to validate and secure products and services in the Spark ecosystem. Staked SPK earns rewards in the form of Spark Points. Symbiotic is also rewarding SPK stakers with points through its protocol. [You can read more about staking here](/staking). ### SPK Farming You can earn SPK by depositing USDS into the SPK Farm at [%%APP\_DOMAIN%%/spk/farm](https://app.spark.fi/spk/farm). Learn more about SPK Farming in the [SPK Farming guide](/user-guides/farming-rewards/). ### Has SPK been airdropped yet? Yes, the SPK token has been airdropped. The final claiming date for the pre-farming rewards and the airdrop was December 17th, 2025. Do not trust any other websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens. ### Supported Networks and Token Addresses For official SPK deployment addresses on each supported network, see the [SPK Developer Docs](/dev/spk/). Beware of scammers and false SPK tokens. ### How can I bridge SPK between networks? You can bridge SPK between networks using [Stargate](https://stargate.finance/?srcChain=ethereum\&srcToken=0xc20059e0317DE91738d13af027DfC4a50781b066\&dstChain=bsc\&dstToken=0xAfF2e841851700D1Fc101995Ee6b81Ae21Bb87D7). Confirm you are using the correct token addresses. **Note:** The Stargate Bridge is only for Ethereum/BSC bridging. ### Audits You can find security audits for the SPK token [here](https://github.com/sky-ecosystem/endgame-toolkit/tree/e6c3a783614748717b4cb8d671c907a1feb71121/audits). ### What will the total supply of SPK be? 10 billion SPK tokens were minted at genesis.\* 35% of the SPK tokens were allocated to the Spark ecosystem and team (23% ecosystem, 12% team) to support the growth of Spark. The Sky ecosystem will receive 65% of the genesis tokens, which Sky will distribute through a 10 year SPK farming campaign. More details on this below. \*Sky retains the ability to mint additional SPK tokens under extreme circumstances. Learn more in the [Sky Atlas](https://sky-atlas.io/#A.2.9.2.2.2.2.6). The SPK supply is allocated as follows: | **Category** | **Allocation** | **Token Amount** | **Vesting Schedule** | **Addresses** | | ------------------- | -------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sky Farming (Users) | 65% | 6,500,000,000 SPK | Distributed by Sky over 10 years | Sky Pause Proxy (controlled by the DAO): [0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB](https://etherscan.io/address/0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB) | | Ecosystem | 23% | 2,300,000,000 SPK | 17% of the tokens available at TGE (mid-term Treasury and Airdrops-Legacy)
6% available one year after TGE (long-term Treasury). | Mid-term Treasury: [0x089693ed9d9a5ac907bd1a1565867646ffaabcd6](https://etherscan.io/address/0x089693ed9d9a5ac907bd1a1565867646ffaabcd6)
Airdrops-Legacy: [0x6FE588FDCC6A34207485cc6e47673F59cCEDF92B](https://etherscan.io/address/0x6FE588FDCC6A34207485cc6e47673F59cCEDF92B)
Long-term Treasury: [0x46dce51a3f4cbEa91F3A1BBD48Ca5079397d5847](https://etherscan.io/address/0x46dce51a3f4cbEa91F3A1BBD48Ca5079397d5847) | | Team | 12% | 1,200,000,000 SPK | 12-month 25% cliff, then 3-year vesting of remaining 75% | subDAO proxy (controlled by the DAO): [0x3300f198988e4C9C63F75dF86De36421f06af8c4](https://etherscan.io/address/0x3300f198988e4C9C63F75dF86De36421f06af8c4) | The chart below contains the distribution schedule for SPK: **Distribution Schedule** ![](/assets/distribution-schedule.webp) ### SPK Allocation #### Sky Farming (users) SPK farming is offered by the Sky ecosystem. Through Sky’s token farms, users can stake USDS to farm SPK. The SPK distribution follows the rules set forth in the [Sky Atlas](https://sky-atlas.io/#A.2.9.2.2.2.1.2.2.2), which states that SPK will be distributed by Sky through these farms on the following schedule: | | Yearly Amount of SPK (in millions) | Total Amount of SPK (in millions) | | ------- | ---------------------------------- | --------------------------------- | | Year 1 | 1625.00 | 1,625.00 | | Year 2 | 1625.00 | 3,250.00 | | Year 3 | 812.50 | 4,062.50 | | Year 4 | 812.50 | 4,875.00 | | Year 5 | 406.25 | 5,281.25 | | Year 6 | 406.25 | 5,687.50 | | Year 7 | 203.13 | 5,890.63 | | Year 8 | 203.13 | 6,093.75 | | Year 9 | 203.13 | 6,296.88 | | Year 10 | 203.13 | 6,500.00 | Below is a visual representation of the SPK distribution schedule from Sky. ![spk-distribution.webp](/assets/spk-distribution.webp) #### Ecosystem 23% of the tokens are allocated to the Spark ecosystem to support its growth. #### Team The team allocation is designed to ensure long-term alignment with the core contributors building and supporting Spark. ### Additional Resources Integrators can find technical documentation for SPK here: * [SPK Developer Docs](/dev/spk/) ## Spark Developer Documentation :::info This section of the documentation is intended for developers looking to learn more about, build on top of, or develop tooling for Spark. For more general information, please go to [User Guides](/user-guides/getting-started). ::: The Spark Developer portal is your resource for all developer documentation relating to Spark. Here you will find smart contract documentation, in-depth concepts and explanations, code audits and security processes. #### Spark Products **Spark** is on a mission to empower the USDS ecosystem, as part of the [Sky Ecosystem](https://sky.money). Spark consists of three main product categories: * **SparkLend**: The USDS and DAI centric money market protocol. Combining the best liquidity directly from Sky and vertically integrating with the best DeFi protocols. * **Savings**: Earn savings on your stablecoin holdings. * **Spark Liquidity Layer:** Direct liquidity provision into DeFi markets. You will find documentation for all of these products in the following sections. :::info **The SPK airdrop has concluded.** Claiming closed on December 17, 2025. Do not trust any websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens. ::: ## SPK Token ### Overview SPK is the governance token of Spark. You can read more about the token [here](/governance/spk-token). ### Supported Networks and Token Addresses | Network | Token | Address | | -------- | ----- | --------------------------------------------------------------------------------------------------------------------- | | Ethereum | SPK | [0xc20059e0317DE91738d13af027DfC4a50781b066](https://etherscan.io/address/0xc20059e0317DE91738d13af027DfC4a50781b066) | | BSC | SPK | [0xAfF2e841851700D1Fc101995Ee6b81Ae21Bb87D7](https://bscscan.com/address/0xAfF2e841851700D1Fc101995Ee6b81Ae21Bb87D7) | | Base | SPK | [0x692A07f2306a3bba739e5281A26A5a97C6D7A6cA](https://basescan.org/address/0x692A07f2306a3bba739e5281A26A5a97C6D7A6cA) | ### Contract Details * Contract Name: SDAO.sol * Contract Source: [SDAO Code Repository](https://github.com/sky-ecosystem/endgame-toolkit/blob/master/src/SDAO.sol) #### Variables * **`name`**: Spark * **`symbol`**: SPK * **`version`**: 1 * **`decimals`**: 18 * **`totalSupply`**: An unsigned integer representing the total supply of the token. It keeps track of the total number of tokens in circulation. * **`balanceOf`**: A mapping that associates an address with its corresponding token balance. It allows for looking up the balance of a specific address. * **`allowance`**: A nested mapping that associates an owner address with a spender address and their approved token allowance. It allows an owner to specify how many tokens a specific spender is allowed to transfer on their behalf. * **`nonces`**: A mapping that associates an address with its corresponding permit nonce. It is used for the EIP712 permit functionality, allowing an address to sign permit messages with a unique nonce. #### ERC20 token functionality The contract implements the functions specified in the ERC-20 interface. * **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer. * **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer. * **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval. * **`increaseAllowance`**: Increases the allowance granted to a specific spender by adding the **`addedValue`** to the current allowance. It returns a boolean value indicating the success of the operation. * **`decreaseAllowance`**: Decreases the allowance granted to a specific spender by subtracting the **`subtractedValue`** from the current allowance. It returns a boolean value indicating the success of the operation. * **`permit`**: This function allows the owner to approve a permit for the spender to spend a specific amount of tokens on their behalf, using a signature for authorization. #### Upgradeability The contract is not upgradeable. #### Events emitted * **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens. * **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer. ### Additional resources * [SPK User Guide](/governance/spk-token) ## DebtToken Debt tokens are interest-accruing tokens that are minted and burned on `borrow` and `repay`, representing the debt owed by the token holder. There are 2 types of debt tokens: * ***Stable Debt Tokens*****:** represent a debt to the protocol with stable interest rate. * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/StableDebtToken.sol) :::danger Stable Debt Tokens are not currently being used in SparkLend, they are a legacy piece of technology that will be fully deprecated at some point in the future. ::: Stable-rate borrowing remains in the contracts (the `STABLE_BORROWING_ENABLED` flag on the reserve configuration can still be toggled). It is set to `false` for every reserve on the live SparkLend deployment, so `StableDebtToken` balances stay at zero. * ***Variable Debt Tokens*****:** represent a debt to the protocol with variable interest rate. * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/VariableDebtToken.sol) :::info Debt tokens are not transferable. ::: The *s/vToken* value is pegged 1:1 to the value of underlying borrowed asset and represents the current total amount owed to the protocol i.e. principal debt + interest accrued. ### EIP20 Methods Although debt tokens are modelled on the ERC20/EIP20 standard, they are non-transferrable. Therefore they do not implement any of the standard ERC20/EIP20 functions relating to `transfer()` and `allowance()`. Following are the standard EIP20 methods that are implemented for the debt tokens: #### balanceOf `function balanceOf(address account)` Returns the most up to date accumulated debt (principal+interest) of the user. #### totalSupply `function totalSupply()` Returns the most up to date total debt accrued by all protocol users for that specific type *(stable or variable rate)* of debt token. #### decimals `function decimals()` Returns decimals of the token contract. #### symbol `function symbol()` Returns the symbol of the token contract. #### name `function name()` Returns the name of the token contract. ### EIP712 Methods #### DOMAIN\_SEPARATOR `function DOMAIN_SEPARATOR()` Get the domain separator for the token at current chain. #### nonces `function nonces(address owner)` Returns the nonce value for address specified as parameter. This is the nonce used when calling `permit()` ```jsx const token = new Contract(debtTokenAddress, debtToken.abi, provider); await token.nonces(user); ``` ### SparkLend Specific Methods #### Shared View Methods Below are the view methods available for both type, stable and variable, of debt tokens. ##### POOL `function POOL()` Returns the address of the associated Pool for the debt token. ##### borrowAllowance `function borrowAllowance(address fromUser, address toUser)` Returns the amount of debt that `fromUser` has approved `toUser` to borrow against `fromUser`'s collateral. Set with `approveDelegation(toUser, amount)`. ##### UNDERLYING\_ASSET\_ADDRESS `function UNDERLYING_ASSET_ADDRESS()` Returns the underlying asset of the debt token. ##### getIncentivesController `function getIncentivesController()` Returns the address of the Incentives Controller contract #### Shared Write Methods Below are the write methods available for both type, stable and variable, of debt tokens. ##### approveDelegation `function approveDelegation(address delegatee, uint256 amount)` Sets the `amount` of allowance for `delegatee` to borrow of a particular debt token. ##### delegationWithSig `function delegationWithSig(address delegator, address delegatee, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)` Sets the `value` of allowance for `delegatee` to borrow of a particular debt token via permit function. ##### setIncentivesController `function setIncentivesController(IAaveIncentivesController controller)` Sets a new Incentives Controller. :::danger Only Pool Admin can call this method. To update Incentives Controller on main Spark market, Governance Proposal must be submitted. ::: #### Stable Debt Token Methods ##### getAverageStableRate `function getAverageStableRate()` Returns the average stable rate across all the stable rate debt in the protocol as `uint256`. ##### getUserLastUpdated `function getUserLastUpdated(address user)` Returns the timestamp of the last action taken by `user` as `uint40`. ##### getUserStableRate `function getUserStableRate(address user)` Returns the stable rate of `user` as `uint256`. ##### getSupplyData `function getSupplyData()` Returns the principal, the total supply, the average stable rate and the timestamp for the last update. Return Values | Type | Description | | ------- | --------------------------------------------------------------------------------- | | uint256 | The principal stable debt issued | | uint256 | The total stable debt for the reserve across all users. Based on avg stable rate. | | uint256 | The average stable debt rate across all users. | | uint40 | The timestamp of the last update on total supply of stable debt token. | ##### getTotalSupplyAndAvgRate `function getTotalSupplyAndAvgRate()` Returns the total supply and average stable rate of the token. Return Values | Type | Description | | ------- | ------------------------------------------------------------------ | | uint256 | total debt token supply. (includes principal + cumulated interest) | | uint256 | average stable rate | ##### getTotalSupplyLastUpdated `function getTotalSupplyLastUpdated()` Returns the timestamp of the last update of the total supply in `uint40`. ##### principalBalanceOf `function principalBalanceOf(address user)` Returns the principal debt balance of the user since the last burn/mint action. #### Variable Debt Token Methods ##### scaledBalanceOf `function scaledBalanceOf(address user)` Returns the scaled debt balance of `user`. The scaled balance is the sum of all the updated stored balance divided by the reserve's variable borrow index at the moment of the update. ##### getScaledUserBalanceAndSupply `function getScaledUserBalanceAndSupply(address user)` Returns the scaled balance of the user and the scaled total supply. ##### scaledTotalSupply `function scaledTotalSupply()` Returns the scaled total supply of the debt token. Represents sum(debt/index) ##### getPreviousIndex `function getPreviousIndex(address user)` Returns last index interest that was accrued to the user's balance (expressed in ray). ## DelegationAwareSpToken * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/DelegationAwareAToken.sol) `DelegationAwareAToken` is a subclass of `AToken` used by reserves whose underlying token exposes the COMP `IDelegationToken.delegate(address)` interface. Like every AToken on SparkLend, it is deployed with a Spark-branded symbol. These tokens are enabled to delegate the voting power of the underlying asset to a different address. *DelegationAwareSpToken* enables/implements all the methods available for spTokens with additional `delegateUnderlyingTo` method. Refer to the [*spToken*](/dev/sparklend/tokens/sptoken) docs for full list of contract API #### delegateUnderlyingTo `function delegateUnderlyingTo(address delegatee)` Delegates voting power of the underlying asset to a `delegatee` address. The underlying asset must implement `function delegate(address delegatee)` (e.g. UNI, AAVE). If the underlying does not implement this, the call reverts. :::danger This method can only be called by `POOL_ADMIN.` ::: ## spToken (AToken contract) * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/AToken.sol) ### What it is When a user calls `Pool.supply(asset, amount, …)`, the corresponding **AToken** is minted to the recipient. Each reserve has its own AToken proxy, deployed by `PoolConfigurator.initReserves`. On SparkLend, the AToken for each reserve is deployed with a Spark-branded symbol like `spUSDS`, `spDAI`, `spWETH`. The contract type is `AToken`; "spToken" is shorthand for "the AToken deployed for a SparkLend reserve". Holders of an spToken hold a 1:1 claim on the underlying, plus all accrued supply-side interest. ATokens are standard ERC-20 tokens with two key extensions: 1. **Rebasing balance.** `balanceOf(user)` returns `scaledBalanceOf(user) * liquidityIndex / 1e27`, where `liquidityIndex` is the cumulative supply rate for the reserve. As the reserve accrues interest, balances rise without explicit minting. 2. **Pool-coupled transfers.** Every transfer calls back into `Pool.finalizeTransfer`, which revalidates the sender's health factor and updates the collateral-enabled bitmap on both sides. ### Lifecycle (Pool-only) | Method | Caller | Effect | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | `mint(caller, onBehalfOf, amount, index)` | `Pool` (via `SupplyLogic.executeSupply`) | Mints scaled balance to `onBehalfOf`. Returns `true` if this is the recipient's first supply. | | `burn(from, receiverOfUnderlying, amount, index)` | `Pool` (via `SupplyLogic.executeWithdraw`, `BorrowLogic.executeRepay` with `useATokens=true`, `LiquidationLogic._burnCollateralATokens`) | Burns scaled balance and transfers underlying to `receiverOfUnderlying` (unless `receiverOfUnderlying == address(this)`, used for repay-with-ATokens). | | `mintToTreasury(amount, index)` | `Pool.mintToTreasury` | Mints accrued reserve-factor income to the treasury address. | | `transferOnLiquidation(from, to, value)` | `Pool` (via `LiquidationLogic._liquidateATokens`) | Transfer that skips the `finalizeTransfer` health-factor revalidation. | | `transferUnderlyingTo(target, amount)` | `Pool` (via `BorrowLogic.executeBorrow` and `FlashLoanLogic`) | Sends underlying out of the AToken to fund a borrow or flash loan. | | `handleRepayment(user, onBehalfOf, amount)` | `Pool` (after repay) | No-op by default; provides an override point for AToken subclasses (e.g. yield strategies). | ### EIP-2612 permit ```solidity function permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external ``` ATokens implement permit using the typehash `Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)`. The domain separator is bound to the token's `name()` and the chain id. `DOMAIN_SEPARATOR()` and `nonces(address)` are exposed on the token. ### View methods specific to AToken | Method | Returns | | ------------------------------------- | ------------------------------------------------------------------------ | | `POOL()` | The `IPool` this AToken is bound to. | | `UNDERLYING_ASSET_ADDRESS()` | The underlying ERC-20 backing the AToken. | | `RESERVE_TREASURY_ADDRESS()` | Treasury address that receives the reserve-factor portion of interest. | | `scaledBalanceOf(user)` | The user's scaled balance (`balance / liquidityIndex`). | | `scaledTotalSupply()` | Sum of all scaled balances. | | `getScaledUserBalanceAndSupply(user)` | Returns `(scaledBalanceOf, scaledTotalSupply)` in one call. | | `getPreviousIndex(user)` | Last liquidity index at which the user's balance was updated. | | `getIncentivesController()` | Address of the `IAaveIncentivesController` used for rewards bookkeeping. | | `DOMAIN_SEPARATOR()` | EIP-712 domain separator for `permit`. | | `nonces(address)` | Permit nonce for an account. | ### Admin methods ```solidity function setIncentivesController(IAaveIncentivesController newController) external onlyPoolAdmin ``` Replaces the incentives controller used by this AToken. Restricted to holders of `POOL_ADMIN_ROLE` on `ACLManager`. ```solidity function rescueTokens(address token, address to, uint256 amount) external onlyPoolAdmin ``` Recovers stray ERC-20s sent directly to the AToken contract. **Cannot** be used on the AToken's own underlying asset — that would break the AToken's 1:1 backing. ### FAQ #### How does an spToken (AToken) accrue yield? Every state-changing call into the reserve (`supply`, `withdraw`, `borrow`, `repay`, `liquidationCall`, `flashLoanSimple`) updates the reserve's `liquidityIndex`. `AToken.balanceOf` returns the user's scaled balance multiplied by the current index, so balances increase passively over time. #### Can I transfer spTokens? Yes — they are standard ERC-20 with one caveat: transferring out reduces your collateral. The transfer is followed by a `finalizeTransfer` callback that reverts if your health factor would drop below `1e18`. #### Do unclaimed rewards transfer with the spToken? No. Rewards accrued before the transfer remain with the sender's address inside the incentives controller. The recipient starts accruing rewards from the transfer onward. ## RewardsController All reward types enabled in SparkLend are managed by RewardsDistributor. This is the contract used to check rewards data, user’s rewards balance and for claiming the rewards. ### Source Code * [RewardsController](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/rewards/RewardsController.sol) * [RewardsDistributor](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/rewards/RewardsDistributor.sol) ### Structs #### AssetData | Name | Type | | --------------------- | ----------------------------- | | rewards | mapping(address ⇒ RewardData) | | availableRewards | mapping(uint128 ⇒ address) | | availableRewardsCount | uint128 | | decimals | uint8 | #### RewardData | Name | Type | | ------------------- | ---------------------------- | | emissionPerSecond | uint88 | | index | uint104 | | lastUpdateTimestamp | uint32 | | distributionEnd | uint32 | | usersData | mapping(address => UserData) | ### View Methods #### getRewardsData `getRewardsData (asset, reward)` Get the data of the reward emitted for the asset. **Call Params** | Name | Type | Description | | ------ | ------- | ------------------------------------------------------------------------ | | asset | address | address of the a/s/v Tokens for which incentive information is requested | | reward | address | address of the reward token | **Return Value** | Type | Description | | ------- | --------------------------------------------------------------- | | uint256 | index of the reward token | | uint256 | total reward tokens awarded per second for the given asset pool | | uint256 | unix timestamp of last time the emissions were updated | | uint256 | unix timestamp of when the emissions will end | #### getRewardsByAsset `getRewardsByAsset (asset)` Get list of rewards activated for the asset Call Params | Name | Type | Description | | ----- | ------- | ------------------------------------------------------------------------ | | asset | address | address of the a/s/vTokens for which incentive rewards list is requested | Return Value | Type | Description | | ---------- | ------------------------------------------------------------ | | address\[] | list of reward token addresses activated for the given asset | ### Write Methods #### claimRewards `claimRewards (assets, amount, to, reward)` Claims single reward type specified by `reward` for the list of assets. Rewards are received by `to` address. Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------------------------------------ | | assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses | | amount | uint256 | amount to claim, expressed in wei. Pass MAX\_UINT to claim entire unclaimed reward balance | | to | address | address which will receive the reward tokens | | reward | address | address of the reward token being claimed. e.g. wstETH | #### claimRewardsOnBehalf `claimRewardsOnBehalf (assets, amount, user, to, reward)` Claims single reward type specified by `reward` for the given list of assets on behalf of the `user`. Rewards are received by `to` address. :::info The `msg.sender` must be an authorised claimer set using `setClaimer()` method, via Governance Vote. ::: Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------------------------------------ | | assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses | | amount | uint256 | amount to claim, expressed in wei. Pass MAX\_UINT to claim entire unclaimed reward balance | | user | address | address of user who’s rewards are being claimed | | to | address | address which will receive the reward tokens | | reward | address | address of the reward token being claimed. e.g. wstETH | #### claimRewardsToSelf `claimRewardsToSelf (assets, amount, reward)` Claims single reward type accrued by the `msg.sender` specified by `reward` for the given list of assets. Rewards are received by `msg.sender` . Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------------------------------------ | | assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses | | amount | uint256 | amount to claim, expressed in wei. Pass MAX\_UINT to claim entire unclaimed reward balance | | reward | address | address of the reward token being claimed. e.g. wstETH | #### claimAllRewards `claimAllRewards (assets, to)` Claims all rewards for the list of assets. Rewards are received by `to` address. Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------------------------------- | | assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses | | to | address | address which will receive the reward tokens | #### claimAllRewardsOnBehalf `claimAllRewardsOnBehalf (assets, user, to)` Claims all rewards for the given list of assets on behalf of the `user`. Rewards are received by `to` address. :::info The `msg.sender` must be an authorised claimer set using `setClaimer()` method, via Governance Vote. ::: Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------------------------------- | | assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses | | user | address | address of user who’s rewards are being claimed | | to | address | address which will receive the reward tokens | #### claimAllRewardsToSelf `claimAllRewardsToSelf (assets)` Claims all rewards accrued by `msg.sender` for the given list of assets. Rewards are received by `msg.sender` . Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------------------------------- | | assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses | ## UiIncentiveDataProviderV3 * [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/UiIncentiveDataProviderV3.sol) Contract that returns an array of all reserve incentives or user claimable rewards within a particular market, used by the [SparkLend Interface](https://github.com/sparkdotfi/spark-interface/) to display incentives data. The [SparkLend Utilities SDK](https://github.com/sparkdotfi/spark-utilities#data-formatting-methods) includes an interface to make calls to this contract, and functions to format the response for frontend use-cases. ### Data Structures ##### AggregatedReserveIncentiveData | Name | Type | Description | | --------------- | ------------- | -------------------------------------------------------------------------------------------------------------- | | underlyingAsset | address | Address of the asset supplied/borrowed in Pool | | aIncentiveData | IncentiveData | Details of rewards distributed for supplying to SparkLend Pool i.e. rewards for spToken holders. | | vIncentiveData | IncentiveData | Details of rewards distributed for variable debt borrowed from SparkLend Pool i.e. rewards for vToken holders. | | sIncentiveData | IncentiveData | Details of rewards distributed for stable debt borrowed from SparkLend Pool i.e. rewards for sToken holders. | ##### IncentiveData | Name | Type | Description | | -------------------------- | ------------- | ------------------------------------------------------------------------------ | | tokenAddress | address | Address of corresponding a/s/vToken. | | incentiveControllerAddress | address | Address of Rewards Controller | | rewardsTokenInformation | RewardInfo\[] | Array of details for all reward tokens that are available for given a/s/vToken | ##### RewardInfo | Name | Type | Description | | ----------------------------- | ------- | ---------------------------------------------------------------------------------------------------- | | rewardTokenSymbol | string | Symbol of Reward Token | | rewardTokenAddress | address | Address of Reward Token | | rewardOracleAddress | address | Price Oracle for Reward token | | emissionPerSecond | uint256 | Reward Token emitted per second | | incentivesLastUpdateTimestamp | uint256 | Unix timestamp of last update made on asset’s reward token. | | tokenIncentivesIndex | uint256 | Latest distribution index of the reward token | | emissionEndTimestamp | uint256 | Unix timestamp of when the Incentive emission of given reward token ends for the corresponding asset | | rewardPriceFeed | int256 | Latest answer/price from reward token price oracle | | rewardTokenDecimals | uint8 | Decimals of reward token | | precision | uint8 | Decimals of asset token (a/s/vToken) | | priceFeedDecimals | uint8 | Decimals of price provided by oracle | ##### UserReserveIncentiveData | Name | Type | Description | | ------------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------ | | underlyingAsset | address | Address of the asset supplied/borrowed in Pool | | aTokenIncentivesUserData | UserIncentiveData | Details of user rewards received for supplying to SparkLend Pool i.e. rewards for spToken. | | vTokenIncentivesUserData | UserIncentiveData | Details of user rewards received for borrowing at variable rate from SparkLend Pool i.e. rewards for vToken. | | sTokenIncentivesUserData | UserIncentiveData | Details of user rewards received for borrowing at stable rate from SparkLend Pool i.e. rewards for sToken. | ##### UserIncentiveData | Name | Type | Description | | -------------------------- | ----------------- | ----------------------------------------------------------------------------------- | | tokenAddress | address | Address of corresponding a/s/vToken. | | incentiveControllerAddress | address | Address of Rewards Controller for reward claim tx | | userRewardsInformation | UserRewardInfo\[] | Array of details for all reward tokens accrued/claimed by user for given a/s/vToken | ##### UserRewardInfo | Name | Type | Description | | ------------------------ | ------- | -------------------------------------------------- | | rewardTokenSymbol | string | Symbol of Reward Token | | rewardOracleAddress | address | Price Oracle for Reward token | | rewardTokenAddress | address | Address of Reward Token | | userUnclaimedRewards | uint256 | User’s unclaimed rewards | | tokenIncentivesUserIndex | uint256 | Latest user distribution index | | rewardPriceFeed | int256 | Latest answer/price from reward token price oracle | | priceFeedDecimals | uint8 | Decimals of price provided by oracle | | rewardTokenDecimals | uint8 | Decimals of reward token | ### Methods ##### getReservesIncentivesData `function getReservesIncentivesData(IPoolAddressesProvider provider)` Returns `AggregatedReserveIncentiveData[]` for the pool associated with given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider). ##### getUserReservesIncentivesData `function getUserReservesIncentivesData(IPoolAddressesProvider provider, address user)` Returns `UserReserveIncentiveData[]` for the given `user` for the pool associated with given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider). ##### getFullReservesIncentiveData `function getFullReservesIncentiveData(IPoolAddressesProvider provider, address user)` Returns both `AggregatedReserveIncentiveData[]` and `UserReserveIncentiveData[]` for the given `user` for the pool associated with given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider). ## UiPoolDataProviderV3 * [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/UiPoolDataProviderV3.sol) Contract that returns an array of all reserve or user data for a particular market, used by the [SparkLend Interface](https://github.com/sparkdotfi/spark-interface) to display Markets and Dashboard data. The [SparkLend Utilities SDK](https://github.com/sparkdotfi/spark-utilities#data-formatting-methods) includes an interface to make calls to this contract, and functions to format the response for frontend use-cases. ### Data Structures #### AggregatedReserveData View fields of `AggregatedReserveData` defined at [Github](https://github.com/aave/aave-v3-periphery/blob/ed38b6719d4bbd9d17dfbd6b9849326a0bdeea2c/contracts/misc/interfaces/IUiPoolDataProviderV3.sol#L8). #### UserReserveData | Name | Type | Description | | ------------------------------- | ------- | ----------------------------------------------------------------------------------------------- | | underlyingAsset | address | Address of the underlying asset supplied/borrowed | | scaledSpTokenBalance | uint256 | Scaled spToken balance.

scaledBalance = balance / liquidityIndex | | usageAsCollateralEnabledOnUser | bool | true if supplied asset is enabled to be used as collateral | | stableBorrowRate | uint256 | Stable rate at which underlying asset is borrowed by the user. 0 ⇒ no debt | | scaledVariableDebt | uint256 | Scaled variable debt balance.

scaledBalance = balance / variableBorrowIndex | | principalStableDebt | uint256 | Principal amount borrowed at stable rate | | stableBorrowLastUpdateTimestamp | uint256 | unix timestamp of last update on user’s stable borrow position. | #### BaseCurrencyInfo Info data struct for base currency of the SparkLend market. | Name | Type | Description | | --------------------------------- | ------- | --------------------------------------------------- | | marketReferenceCurrencyUnit | uint256 | Reference aka base currency of the SparkLend market | | marketReferenceCurrencyPriceInUsd | int256 | Price of reference aka base currency in USD | | networkBaseTokenPriceInUsd | int256 | Price of native token of the network/chain in USD | | networkBaseTokenPriceDecimals | uint8 | Decimals of native token of the network/chain | ### Methods #### getReservesList `function getReservesList(IPoolAddressesProvider provider)` Returns the list of initialised reserves in the Pool associated with the given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider). #### getReservesData `function getReservesData(IPoolAddressesProvider provider)` Returns `BaseCurrencyInfo` of the Pool and `AggregatedReserveData[]` for all the initialised reserves in the Pool associated with the given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider). #### getUserReservesData `function getUserReservesData(IPoolAddressesProvider provider, address user)` Returns `UserReserveData[]` for all user reserves in the Pool associated with the given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider). ## WalletBalanceProvider * [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/WalletBalanceProvider.sol) Implements a logic of getting multiple tokens balance for one user address. :::info For getting ETH (native chain token) balance use `MOCK_ETH_ADDRESS = 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`. ::: ### Methods #### balanceOf `function balanceOf(address user, address token)` Returns the balance of the token for user (ETH included with `MOCK_ETH_ADDRESS`). #### batchBalanceOf `function batchBalanceOf(address[] calldata users, address[] calldata tokens)` Returns balances for a list of `users` and `tokens` (ETH included with `MOCK_ETH_ADDRESS`). #### getUserWalletBalances `function getUserWalletBalances(address provider, address user)` Provides balances of user wallet for all reserves available on the pool ## WETHGateway * [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/WrappedTokenGatewayV3.sol) The WETH Gateway contract is a helper that wraps and unwraps ETH as needed when interacting with the protocol. ### Write Methods #### depositETH **`function depositETH(address pool, address onBehalfOf, uint16 referralCode)`** Supplies the `msg.value` amount of ETH (or native chain token) into the SparkLend pool, minting the same amount of corresponding spWETH and transferring them to the `onBehalfOf` address. :::info Ensure that the `depositETH()` transaction also includes the amount of ETH you are supplying in the `msg.value`. ::: Call Params | Name | Type | Description | | ------------ | ------- | -------------------------------------------------------------------------------------------------- | | pool | address | Address of the targeted pool. | | onBehalfOf | address | Address that will receive the spWETH. Use `msg.sender` if the tokens should be sent to the caller. | | referralCode | uint16 | Unique code for third-party referral program integration.
Use `0` if no referral applies. | #### withdrawETH **`function withdrawETH(address pool, uint256 amount, address to)`** Withdraws `amount` of the WETH (or wrapped native chain token), unwraps it and transfers ETH (or native chain token) to the `to` address. 💡 Ensure you set the relevant `spToken` allowance, before calling this function, so the `WETHGateway` contract can transfer the associated spWETH. Call Params | Name | Type | Description | | ------ | ------- | --------------------------------------------------------------------------------------------------- | | pool | address | Address of the targeted pool. | | amount | uint256 | Amount to withdraw, expressed in wei units. Use `type(uint256).max` to withdraw the entire balance. | | to | address | Address that will receive the unwrapped ETH. | #### repayETH **`function repayETH(address pool, uint256 amount, uint256 rateMode, address onBehalfOf)`** Repays `amount` of ETH debt for `onBehalfOf` using the specified `rateMode`. :::info Ensure that the `repayETH()` transaction also includes the amount of ETH you are repaying in the `msg.value`. ::: | Parameter Name | Type | Description | | -------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | pool | address | Address of the targeted underlying lending pool. | | amount | uint256 | Amount to repay, expressed in wei units.
Use `uint(-1)` to repay the entire debt, but only when the repayment is not executed on behalf of a third party.
When repaying on behalf of another user, it is recommended to send an *amount* slightly higher than the current borrowed amount. | | rateMode | uint256 | Type of debt being repaid.
Stable: 1, Variable: 2 | | onBehalfOf | address | Address for which the debt is being repaid.
Use `msg.sender` if not repaying on behalf of another user. | #### borrowETH **`function borrowETH(address pool, uint256 amount, uint256 interestRateMode, uint16 referralCode)`** Borrows `amount` of WETH with `interestRateMode`, sending the `amount` of unwrapped WETH to `msg.sender`. Call Params | Name | Type | Description | | ---------------- | ------- | ---------------------------------------------------------------------------------------------- | | pool | address | Address of the targeted pool. | | amount | uint256 | Amount to borrow, expressed in wei units. | | interestRateMode | uint256 | Type of borrow debt.
Stable: 1, Variable: 2 | | referralCode | uint16 | Unique code for third-party referral program integration.
Use `0` if no referral applies. | #### withdrawETHWithPermit `function withdrawETHWithPermit(address pool, uint256 amount, address to, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS)` Withdraws `amount` of the WETH (or wrapped native chain token) without a separate approval tx. The ETH (or native chain token) is sent to the `to` address. Call Params | Name | Type | Description | | -------- | ------- | --------------------------------------------------------------------------- | | pool | address | address of the targeted pool | | amount | uint256 | amount of spWETH that will be burnt to withdraw ETH (or native chain token) | | to | address | address that will receive the ETH (or native chain token) | | deadline | uint256 | unix timestamp till which the signature is valid | | permitV | uint8 | Signature parameter v | | permitR | bytes32 | Signature parameter r | | permitS | bytes32 | Signature parameter s | #### emergencyTokenTransfer `function emergencyTokenTransfer(address token, address to, uint256 amount)` Method for ERC20 recovery in case of stuck tokens due direct transfers to the contract address. :::info Can be called only by the owner of the contract i.e. Sky Governance ::: #### emergencyEtherTransfer `function emergencyEtherTransfer(address to, uint256 amount)` Method for ETH (or native chain token) recovery in case of stuck ETH due selfdestruct or transfer ether to pre-computated contract address before deployment. :::info Can be called only by the owner of the contract i.e. Sky Governance. ::: #### View #### getWETHAddress **`function getWETHAddress()`** Returns the WETH address used by the WETHGateway. ### ABI
WETHGateway ABI ``` [ { "inputs": [ { "internalType": "address", "name": "weth", "type": "address" }, { "internalType": "address", "name": "owner", "type": "address" } ], "stateMutability": "nonpayable", "type": "constructor" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "previousOwner", "type": "address" }, { "indexed": true, "internalType": "address", "name": "newOwner", "type": "address" } ], "name": "OwnershipTransferred", "type": "event" }, { "stateMutability": "payable", "type": "fallback" }, { "inputs": [ { "internalType": "address", "name": "pool", "type": "address" } ], "name": "authorizePool", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "pool", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "uint256", "name": "interesRateMode", "type": "uint256" }, { "internalType": "uint16", "name": "referralCode", "type": "uint16" } ], "name": "borrowETH", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "pool", "type": "address" }, { "internalType": "address", "name": "onBehalfOf", "type": "address" }, { "internalType": "uint16", "name": "referralCode", "type": "uint16" } ], "name": "depositETH", "outputs": [], "stateMutability": "payable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "to", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "emergencyEtherTransfer", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "token", "type": "address" }, { "internalType": "address", "name": "to", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "emergencyTokenTransfer", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "getWETHAddress", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "owner", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "renounceOwnership", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "pool", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "uint256", "name": "rateMode", "type": "uint256" }, { "internalType": "address", "name": "onBehalfOf", "type": "address" } ], "name": "repayETH", "outputs": [], "stateMutability": "payable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "newOwner", "type": "address" } ], "name": "transferOwnership", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "pool", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "address", "name": "to", "type": "address" } ], "name": "withdrawETH", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "pool", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "address", "name": "to", "type": "address" }, { "internalType": "uint256", "name": "deadline", "type": "uint256" }, { "internalType": "uint8", "name": "permitV", "type": "uint8" }, { "internalType": "bytes32", "name": "permitR", "type": "bytes32" }, { "internalType": "bytes32", "name": "permitS", "type": "bytes32" } ], "name": "withdrawETHWithPermit", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "stateMutability": "payable", "type": "receive" } ] ```
## Credit Delegation Credit delegation allows a supplier to supply funds in the protocol to earn interest, and delegate borrowing power (i.e. their credit) to other users. The enforcement of the loan and its terms are agreed upon between the supplier and borrowers, which can be either off-chain via legal agreements or on-chain via smart contracts. This enables: * The supplier (aka delegator) to earn extra yield on top of the yield they already earn from the protocol, * The borrowers (aka delegatees) to access an uncollateralized loan. :::warning Borrow by *delegatee* must be consistent with *delegator* [eMode](/dev/sparklend/features/efficiency-mode-emode) category.\ For eg. if a delegator eMode category is `STABLECOINS`, then * the *delegatee* can only borrow `STABLECOINS` eMode category assets on behalf of the delegator. * in case the *delegator* approves credit to the *delegatee* for a non-`STABLECOINS` category asset (an asset in a different category), then the borrow would revert. ::: :::danger The *delegatee* cannot abuse credit approval to liquidate *delegator* i.e. if the borrow puts *delegator's* position in HF \< `HEALTH_FACTOR_LIQUIDATION_THRESHOLD`, then borrow will fail. ::: ### Approving the delegation The [`approveDelegation()`](/dev/sparklend/tokens/debttoken#approvedelegation) or [`delegationWithSig()`](/dev/sparklend/tokens/debttoken#delegationwithsig) must be called by the supplier (delegator), approving the borrower (delegatee) a certain amount. This is done for each debt token that needs to be delegated. :::info The delegator does not need to already have supplied funds in the protocol to `approveDelegation()`. However, **before** the delegatee executes `borrow()`, there must be sufficient collateral supplied by delegator in the protocol. ::: ### Borrowing the credit The borrower (delegatee) calls the [`borrow()`](/dev/sparklend/core-contracts/pool#borrow) method on the `Pool`, using the supplier's (delegator's) address in final parameter `onBehalfOf`. The borrower's available credit is reduced by the borrowed amount. ### Repaying the credit Anyone can repay the debt *OnBehalf* of the user, by calling one of the methods - [repay()](/dev/sparklend/core-contracts/pool#repay) or [repayWithPermit()](/dev/sparklend/core-contracts/pool#repaywithpermit). The supplier (aka creditor) can also use [repayWithATokens()](/dev/sparklend/core-contracts/pool#repaywithatokens) method to repay debt with their *spTokens* of the underlying debt asset in the same pool. ## Efficiency Mode (eMode) The High Efficiency mode feature (or "eMode") is designed to maximise capital efficiency when collateral and borrowed assets are correlated in price. The `RISK_ADMINS` and `POOL_ADMIN`, set by Sky Governance, can configure a maximum of 255 eMode categories, with each `EModeCategory` having following *risk management parameters*: * LTV (Loan to value) * Liquidation threshold * Liquidation bonus * A custom price oracle (optional) The custom price oracle is consumed in liquidation pricing only when both the user and the asset are in the same e-mode category (`LiquidationLogic._getConfigurationData`). :::info 💡 Category 0 is reserved as the default non-eMode category. All the assets listed on SparkLend, by default have category 0 (which indicates the standard operational mode). ::: All Assets listed on SparkLend can be set to any of the pre-configured `eModeCategory` by the `RISK_ADMINS` or `POOL_ADMIN`. :::info The correct categorisation is not enforced on-chain and needs to be maintained by the `RISK_ADMINS` and `POOL_ADMINS` selected via the Sky Governance vote. ::: eMode also offers the possibility of introducing a specific price oracle for a certain category. ### How it works? If the user has supplied liquidity to the protocol, the user `eMode` category is set to 0 by default. The protocol allows user to set the user eMode category to any of the `eModeCategories` configured by the `PoolConfigurator` given the following conditions hold true: * all the borrowed assets of the user are in the chosen category. * changing eMode doesn’t leave user position under-collateralised ## Flash Loans Flash loans let smart contracts borrow any active reserve for a single transaction. The contract must repay the borrowed amount plus a fee before the transaction ends, or the entire transaction reverts. :::info Flash loans are an advanced primitive. Calling them safely requires a thorough understanding of EVM execution, reentrancy, and your protocol's own state assumptions. ::: ### Two entry points | Function | Reserves per call | Fee waiver for `FLASH_BORROWER_ROLE` | Allows opening debt | | ----------------- | ----------------- | --------------------------------------------------- | ------------------------ | | `flashLoan` | One or many | Yes (when `msg.sender` holds `FLASH_BORROWER_ROLE`) | No (see deviation below) | | `flashLoanSimple` | Exactly one | No | No | `flashLoanSimple` is cheaper for the common case and skips the multi-asset bookkeeping. ### SparkLend deviation from upstream Aave v3 Upstream Aave v3 allows `flashLoan` callers to convert any leg of the loan into a stable or variable debt position by passing a non-zero `interestRateModes[i]`. **SparkLend disables this.** `FlashLoanLogic.executeFlashLoan` reverts with `FLASHLOAN_INTO_BORROW_DEPRECATED` if any element of `interestRateModes` is non-zero (`contracts/protocol/libraries/logic/FlashLoanLogic.sol`). The revert is an `if/else` branch in the post-callback settlement loop, not upfront validation: the receiver's `executeOperation` runs first, and the transaction reverts when the offending leg is settled. To take on debt, call `Pool.borrow()` directly. Flash loans must repay in-transaction, full stop. ### Per-reserve preconditions `ValidationLogic.validateFlashloanSimple` (called for every flashed asset) checks: 1. The reserve is **not paused** (`RESERVE_PAUSED`). 2. The reserve is **active** (`RESERVE_INACTIVE`). 3. The reserve has the **flash-loan-enabled** flag set (`FLASHLOAN_DISABLED`, error code `91`). The flag is bit 63 of the reserve configuration and is toggled by `PoolConfigurator.setReserveFlashLoaning(asset, enabled)`. ### Fees The flash-loan fee is split between the LPs of the borrowed reserve and the protocol treasury. Both shares are bps and are governance-set via `PoolConfigurator.updateFlashloanPremiumTotal` and `updateFlashloanPremiumToProtocol`. Current values can be read from `Pool.FLASHLOAN_PREMIUM_TOTAL()` and `Pool.FLASHLOAN_PREMIUM_TO_PROTOCOL()`. For `flashLoan` (multi-asset), the **total** fee is waived for `msg.sender`s holding `FLASH_BORROWER_ROLE` on the `ACLManager`. For `flashLoanSimple`, the fee is **never** waived. ### Execution flow ![Flash-loan (simple) execution sequence: the receiver contract calls flashLoanSimple on Pool; Pool validates, transfers the underlying out via the AToken, calls executeOperation on the receiver, then pulls amount plus premium back via safeTransferFrom and emits FlashLoan](/assets/diagrams/sparklend-flashloan-simple.svg) For the multi-asset variant, the pre-callback transfer and post-callback settlement loop over every entry of `assets`. The callback signature is `executeOperation(address[] assets, uint256[] amounts, uint256[] premiums, address initiator, bytes params) returns (bool)`. ### Receiver contract requirements Your receiver contract must: 1. Implement `IFlashLoanReceiver` (multi-asset) or `IFlashLoanSimpleReceiver` (single-asset). The `executeOperation` callback must return `true`; returning `false` reverts with `INVALID_FLASHLOAN_EXECUTOR_RETURN` (error code `13`). 2. Hold or acquire `amount + premium` of the borrowed asset **before** `executeOperation` returns. 3. Grant `Pool` an ERC20 allowance for `amount + premium` of the borrowed asset before returning from `executeOperation`. The `Pool` performs `safeTransferFrom` to settle. If `Pool` cannot pull `amount + premium`, the transaction reverts. :::danger Do not leave residual approvals to `Pool` or balances on a flash-loan receiver contract — both have been used for griefing attacks in published incidents. ::: ### Callers * **EOA**: deploy a contract that implements the receiver interface and call `flashLoan` / `flashLoanSimple` on `Pool` with that contract's address as `receiverAddress`. * **Different contract**: same pattern; the receiver address is the one implementing `executeOperation`. * **Same contract**: pass `address(this)` as `receiverAddress`. The same contract initiates and receives, then settles. ## Isolation Mode Isolation mode allows new assets to be listed as ***Isolated***. These assets have a specific debt ceiling and can only be used to borrow stablecoins that have been permitted by Sky Governance to be borrowable in isolation mode. :::info Debt Ceiling for an *Isolated Asset* is represented as the maximum amount in USD that can be borrowed against the collateral with two decimals of precision. ::: The on-chain encoding uses `DEBT_CEILING_DECIMALS = 2`, so a ceiling of `$1,000` is stored as `100_000`. ### Supply Isolated Asset A user can supply an *Isolated Asset* just like any other asset using the `supply()` method in `Pool.sol`. The default behaviour depends on the following conditions: | Use as Collateral | Condition | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Enabled | Enabled automatically only when `msg.sender` holds `ISOLATED_COLLATERAL_SUPPLIER_ROLE` on `ACLManager`. Otherwise the user can call `setUserUseReserveAsCollateral` after supplying, provided no other collateral is enabled. | | Disabled | If any other asset is currently enabled as collateral. | :::info If the user has other assets enabled as collateral, they can still supply an *Isolated Asset* to capture yield, but they will not be able to use it as collateral. ::: ### Borrow in Isolated Mode Borrowers using an *Isolated Asset* as collateral can only use that particular asset as collateral and can only borrow assets that are *borrowable in isolation mode,* i.e. have `BORROWABLE_IN_ISOLATION_MASK` bit set in reserve configuration. :::info A borrower in Isolation Mode cannot enable any other assets, including other isolated assets, as collateral. ::: ### Exit Isolation Mode Users can turn off isolation mode by disabling the isolated asset as collateral. This can only be done if the user has no outstanding debt. A user must use the `repay()` method in `Pool.sol` to pay off all debt before exiting Isolation Mode. ## Liquidations The health of the SparkLend is dependent on the 'health' of the collateralised positions within the protocol, also known as the 'health factor'. When the 'health factor' of an account's total loans is below 1, anyone can make a `liquidationCall()` to the [`Pool`](/dev/sparklend/core-contracts/pool#liquidationcall) contract, pay back part of the debt owed and receive discounted collateral in return (also known as the liquidation bonus). This incentivises third parties to participate in the health of the overall protocol, by acting in their own interest (to receive the discounted collateral) and as a result, ensure borrows are sufficiently collateralized. There are multiple ways to participate in liquidations: 1. By calling the liquidationCall() directly in the [Pool](/dev/sparklend/core-contracts/pool#liquidationcall) contract. 2. By creating your own automated bot or system to liquidate loans. :::warning For liquidation calls to be profitable, you must take into account the gas cost involved in liquidating the loan. If a high gas price is used, then the liquidation may be unprofitable for you. See the [Calculating profitability](#calculating-profitability-vs-gas-cost) section for more details. ::: :::info SparkLend allows 100% of debt (i.e. `MAX_LIQUIDATION_CLOSE_FACTOR`) to be liquidated in single `liquidationCall()` if:\ `HF <= CLOSE_FACTOR_HF_THRESHOLD = 0.95` ::: ### Prerequisites When making a `liquidationCall()`, you must: * Know the account (i.e. the Ethereum address: `user`) whose health factor is below 1. * Know the valid debt amount and asset (i.e. `debtToCover` & `debtAsset`) * If the HF is above `CLOSE_FACTOR_HF_THRESHOLD = 0.95`, then only a maximum of 50% (i.e. `DEFAULT_LIQUIDATION_CLOSE_FACTOR`) of the debt can be liquidated per valid `liquidationCall()` * If the HF is at or below `CLOSE_FACTOR_HF_THRESHOLD = 0.95`, then up to 100% (i.e. `MAX_LIQUIDATION_CLOSE_FACTOR`) of the debt can be liquidated in single valid `liquidationCall()` * You can set the `debtToCover` to `uint(-1)` and the protocol will proceed with the highest possible liquidation allowed by the close factor. * You must already have sufficient balance of the debt asset, which will be used by the `liquidationCall` to pay back the debt. You can use `flashLoan` for liquidations 😉 * Know the collateral asset `collateralAsset` you are closing, i.e. the asset that the user has `backing` their outstanding loan that you will receive as a `bonus`. * Whether you want to receive *spTokens* or the underlying asset after a successful `liquidationCall()` . ### Getting accounts to liquidate :::warning "User Account" in SparkLend refers to a single Ethereum address that has interacted with the protocol. This can be an externally owned account or contract. ::: Only user accounts that have HF \< 1 can be liquidated. There are multiple ways you can get the health factor: #### On Chain 1. To gather user account data from on-chain data, one way would be to monitor emitted events from the protocol and keep an up to date index of user data locally. 1. Events are emitted each time a user interacts with the protocol (supply, borrow, repay, withdraw etc.) 2. When you have the user's address, you can simply call [`getUserAccountData()`](/dev/sparklend/core-contracts/pool#getuseraccountdata), to read the user's current healthFactor. If the HF \< 1, then the account can be liquidated. ### Executing the liquidation call Once you have the account(s) to liquidate, you will need to calculate the amount of collateral that can be liquidated: 1. Use [`getUserReserveData()`](/dev/sparklend/core-contracts/aavedataprovider#getuserreservedata) 2. Max debt that can be cleared by single liquidation call is given by the `DEFAULT_LIQUIDATION_CLOSE_FACTOR`(when `CLOSE_FACTOR_HF_THRESHOLD = 0.95 < HF < 1`) or `MAX_LIQUIDATION_CLOSE_FACTOR` (when `HF <= CLOSE_FACTOR_HF_THRESHOLD = 0.95`) 1. `debtToCover = (userStableDebt + userVariableDebt) * LiquidationCloseFactor` 2. You can pass `uint(-1)`, i.e. `MAX_UINT`, as the `debtToCover` to liquidate the maximum amount allowed. 3. Max amount of collateral that can be liquidated to cover debt is given by the current *liquidationBonus* for the reserves that have `usageAsCollateralEnabled` as true. 1. `maxAmountOfCollateralToLiquidate = (debtAssetPrice * debtToCover * liquidationBonus)/ collateralPrice` ### Calculating profitability vs gas cost One way to calculate the profitability is the following: 1. Store and retrieve each collateral's relevant details such as address, decimals used and liquidation bonus. 2. Get the user's collateral balance (AToken balance via `IERC20(aTokenAddress).balanceOf(user)`). 3. Get the asset's price according to the SparkLend's oracle contract using [`getAssetPrice()`](/dev/sparklend/core-contracts/aaveoracle#getassetprice). 4. The liquidator's bonus is approximately the USD value of `debtToCover * (liquidationBonus - 1)` — the liquidation bonus factor is greater than 1 (e.g. `1.05` for a 5% bonus), so the collateral received is worth more than the debt repaid. 5. The maximum cost of your transaction will be you gas price multiplied by the amount of gas used. You should be able to get a good estimation of the gas amount used by calling `estimateGas` via your web3 provider. 6. Your approximate profit will be the value of the collateral bonus (4) minus the cost of your transaction (5). ### Appendix #### How is health factor calculated? The health factor is calculated from the user's total collateral, i.e. all reserves for which `usageAsCollateral` is enabled, balance (in USD) multiplied by the liquidation threshold percentage for all the user's outstanding assets, divided by the user's total borrow balance across all reserves (in USD). This can be calculated both off-chain and on-chain, see [SparkLend-utilities](https://github.com/sparkdotfi/spark-utilities/blob/cdf8a8bf87c8848a2f0865c58defbd04e0871171/packages/math-utils/src/pool-math.ts#L169) and [GenericLogic Library](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/libraries/logic/GenericLogic.sol) respectively for reference. #### How is liquidation bonus determined? Liquidation bonuses for all the assets are evaluated and determined based on each asset's liquidity risk and updated via Sky Governance process. ## Repay with spTokens The `repayWithATokens` function on `Pool` lets a user repay their own debt directly from their AToken balance of the same asset — no underlying transfer, no allowance to `Pool` required. The on-chain contract type is `AToken`. On SparkLend, the AToken for each reserve is deployed with a Spark-branded symbol like `spUSDS` or `spDAI`. "Repaying with spTokens" and "repaying with ATokens" refer to the same call. ### Signature ```solidity function repayWithATokens(address asset, uint256 amount, uint256 interestRateMode) external returns (uint256) ``` | Param | Type | Description | | ------------------ | --------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `asset` | `address` | Underlying debt asset. | | `amount` | `uint256` | Underlying amount to credit toward debt, or `type(uint256).max` to repay up to the caller's full AToken balance without leaving dust. | | `interestRateMode` | `uint256` | `1` for stable debt, `2` for variable debt. | Returns the actual amount repaid. ### Caller constraints * `msg.sender` repays **their own** debt. There is no `onBehalfOf` parameter — `BorrowLogic.executeRepay` is called with `onBehalfOf = msg.sender` and `useATokens = true` (`Pool.sol`). * The caller must hold at least `amount` of the reserve's AToken; the AToken is burned in place of pulling underlying. * The debt being repaid must exist in the same `interestRateMode`. ### Example ```ts import { Contract, ethers } from "ethers"; const pool = new Contract(POOL_ADDRESS, poolAbi, signer); // Repay up to the full DAI variable debt using the caller's spDAI (AToken) balance. await pool.repayWithATokens( "0x6B175474E89094C44Da98b954EedeAC495271d0F", // DAI underlying ethers.constants.MaxUint256, 2 // variable ); ``` ## Siloed Borrowing This feature allows assets with potentially manipulatable oracles (for example illiquid Uni V3 pairs) to be listed on SparkLend as single borrow asset i.e. if user borrows siloed asset, they cannot borrow any other asset. This helps mitigating the risk associated with such assets from impacting the overall solvency of the protocol. :::info [Risk or Pool admin](/dev/sparklend/core-contracts/aclmanager#roles), selected by Sky Governance, can call [`setSiloedBorrowing`](/dev/sparklend/core-contracts/poolconfigurator#reserve-risk-parameters--onlyriskorpooladmins) to set an asset in *Siloed Borrowing* mode. Enabling siloed borrowing on an asset requires the reserve to have zero outstanding debt at the time of the call (`PoolConfigurator.setSiloedBorrowing`). ::: ### Supply Siloed Assets A user can supply a *Siloed Asset* just like any other asset using [`supply()`](/dev/sparklend/core-contracts/pool#supply) method in `pool.sol`. Note that siloed assets are typically listed without collateral usage (LTV 0) — this is configured separately from the siloed borrowing flag — in which case the supplied amount will not add to the total collateral balance of the user. #### Borrow Siloed Assets :::danger User borrowing a *siloed asset* will **not** be allowed to borrow any other asset. ::: User can borrow *Siloed Assets* using [`borrow()`](/dev/sparklend/core-contracts/pool#borrow) method in `pool.sol` , only if: * It is the first borrow for the `onBehalfOf` address OR * Existing user debt is of the same *siloed asset.* To check if user is in Siloed Borrowing state, you can see if underlying asset borrowed by user is *siloed* using [`getSiloedBorrowing()`](/dev/sparklend/core-contracts/aavedataprovider#getsiloedborrowing) method on AaveProtocolDataProvider.sol. #### Check if Reserved for Siloed Borrowing ```solidity // Resolve the data provider from the PoolAddressesProvider, then read the flag. IAaveProtocolDataProvider dataProvider = IAaveProtocolDataProvider(provider.getPoolDataProvider()); // address of the underlying asset address asset = "0x..."; dataProvider.getSiloedBorrowing(asset); ``` #### FAQ ##### How can user enter siloed borrowing state? User automatically enters siloed borrowing state on their first successful borrow of siloed asset. ##### How does user exit siloed borrowing state? User must repay all their debt to exit the siloed borrowing state. ## Supply Borrow Caps ### Supply/Borrow Caps Sky Governance can appoint `RISK_ADMIN` and `POOL_ADMIN` who have the ability to configure Borrow and Supply Caps of the individual reserves. ### **Borrow Caps** Allow modulation of how much of each asset can be borrowed, which reduces insolvency risk. By default borrow cap of an asset is 0, which signifies no cap. Anyone who has been granted `RISK_ADMIN` or `POOL_ADMIN` role via the ACLManager can call [`setBorrowCap` method in PoolConfigurator](/dev/sparklend/core-contracts/poolconfigurator#reserve-risk-parameters--onlyriskorpooladmins) to update the max total borrow (stable + variable) for the given reserve. :::info In case *Borrow Cap* of the reserve is set lower than the current *totalDebt* the existing borrowers are not affected but no more borrows (stable or variable) can be initiated for that reserve. ::: The on-chain check is `totalStableDebt + totalVariableDebt + amount ≤ borrowCap * 10^decimals`. The cap is denominated in whole tokens (no decimals). ### **Supply Caps** Allow limiting how much of a certain asset is supplied to SparkLend. This helps reducing exposure to a certain asset and mitigate attacks like infinite minting or price oracle manipulation. By default supply cap of an asset is 0, which signifies no cap. Anyone who has been granted `RISK_ADMIN` or `POOL_ADMIN` role via the ACLManager can call [`setSupplyCap` method in PoolConfigurator](/dev/sparklend/core-contracts/poolconfigurator#reserve-risk-parameters--onlyriskorpooladmins) to update the liquidity supply for the given reserve. :::info In case *Supply Cap* of the reserve is set lower than the current liquidity of the reserve, the existing suppliers are not affected but no more liquidity can be supplied to that reserve. ::: The on-chain check is `(scaledTotalSupply + accruedToTreasury) * liquidityIndex + amount ≤ supplyCap * 10^decimals`. Accrued interest counts toward the cap — long-idle reserves can therefore reach the supply cap purely from interest accrual. ## Troubleshooting ### Error Codes SparkLend contracts revert with numeric string codes (e.g. `"35"`) rather than custom errors, in order to minimise contract bytecode. The mapping below is authoritative for the deployed code; the source of truth is [`contracts/protocol/libraries/helpers/Errors.sol`](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/libraries/helpers/Errors.sol). :::info Code `48` is intentionally skipped in `Errors.sol` (the list jumps from `47` to `49`). If you see `"48"` revert, you are reading data from a contract that is not the current SparkLend `Errors` library — typically an old Aave-flavoured fork. ::: #### Reference | Code | Name | Meaning | | ---- | ------------------------------------------------ | ---------------------------------------------------------------------------------- | | 1 | `CALLER_NOT_POOL_ADMIN` | Caller is not a pool admin. | | 2 | `CALLER_NOT_EMERGENCY_ADMIN` | Caller is not an emergency admin. | | 3 | `CALLER_NOT_POOL_OR_EMERGENCY_ADMIN` | Caller is neither a pool nor an emergency admin. | | 4 | `CALLER_NOT_RISK_OR_POOL_ADMIN` | Caller is neither a risk nor a pool admin. | | 5 | `CALLER_NOT_ASSET_LISTING_OR_POOL_ADMIN` | Caller is neither an asset-listing admin nor a pool admin. | | 6 | `CALLER_NOT_BRIDGE` | Caller does not hold `BRIDGE_ROLE`. | | 7 | `ADDRESSES_PROVIDER_NOT_REGISTERED` | Pool addresses provider is not registered with the registry. | | 8 | `INVALID_ADDRESSES_PROVIDER_ID` | Invalid id for the pool addresses provider. | | 9 | `NOT_CONTRACT` | Address is not a contract. | | 10 | `CALLER_NOT_POOL_CONFIGURATOR` | Caller is not the `PoolConfigurator`. | | 11 | `CALLER_NOT_ATOKEN` | Caller is not an AToken. | | 12 | `INVALID_ADDRESSES_PROVIDER` | Provider address is invalid. | | 13 | `INVALID_FLASHLOAN_EXECUTOR_RETURN` | `executeOperation` returned `false`. | | 14 | `RESERVE_ALREADY_ADDED` | Reserve has already been added. | | 15 | `NO_MORE_RESERVES_ALLOWED` | Reserve list is at `MAX_NUMBER_RESERVES = 128`. | | 16 | `EMODE_CATEGORY_RESERVED` | Category `0` is reserved. | | 17 | `INVALID_EMODE_CATEGORY_ASSIGNMENT` | Invalid e-mode category assignment to asset. | | 18 | `RESERVE_LIQUIDITY_NOT_ZERO` | Reserve liquidity must be zero for this action. | | 19 | `FLASHLOAN_PREMIUM_INVALID` | Flash-loan premium is invalid. | | 20 | `INVALID_RESERVE_PARAMS` | Invalid risk parameters for the reserve. | | 21 | `INVALID_EMODE_CATEGORY_PARAMS` | Invalid e-mode category parameters. | | 22 | `BRIDGE_PROTOCOL_FEE_INVALID` | Invalid bridge protocol fee. | | 23 | `CALLER_MUST_BE_POOL` | Caller of this token method must be `Pool`. | | 24 | `INVALID_MINT_AMOUNT` | Invalid amount to mint. | | 25 | `INVALID_BURN_AMOUNT` | Invalid amount to burn. | | 26 | `INVALID_AMOUNT` | Amount must be greater than zero. | | 27 | `RESERVE_INACTIVE` | Reserve must be active. | | 28 | `RESERVE_FROZEN` | Reserve is frozen. | | 29 | `RESERVE_PAUSED` | Reserve is paused. | | 30 | `BORROWING_NOT_ENABLED` | Borrowing is not enabled. | | 31 | `STABLE_BORROWING_NOT_ENABLED` | Stable-rate borrowing is not enabled. | | 32 | `NOT_ENOUGH_AVAILABLE_USER_BALANCE` | User cannot withdraw more than available. | | 33 | `INVALID_INTEREST_RATE_MODE_SELECTED` | Invalid interest-rate mode. | | 34 | `COLLATERAL_BALANCE_IS_ZERO` | Collateral balance is zero. | | 35 | `HEALTH_FACTOR_LOWER_THAN_LIQUIDATION_THRESHOLD` | Operation would drop HF below `HEALTH_FACTOR_LIQUIDATION_THRESHOLD = 1e18`. | | 36 | `COLLATERAL_CANNOT_COVER_NEW_BORROW` | Not enough collateral to cover the new borrow. | | 37 | `COLLATERAL_SAME_AS_BORROWING_CURRENCY` | Collateral and borrow currency overlap (stable-mode constraint). | | 38 | `AMOUNT_BIGGER_THAN_MAX_LOAN_SIZE_STABLE` | Stable-mode borrow exceeds `MAX_STABLE_RATE_BORROW_SIZE_PERCENT`. | | 39 | `NO_DEBT_OF_SELECTED_TYPE` | No debt of the selected interest-rate mode to repay. | | 40 | `NO_EXPLICIT_AMOUNT_TO_REPAY_ON_BEHALF` | `type(uint256).max` may only be passed when repaying for `msg.sender`. | | 41 | `NO_OUTSTANDING_STABLE_DEBT` | User has no outstanding stable-rate debt. | | 42 | `NO_OUTSTANDING_VARIABLE_DEBT` | User has no outstanding variable-rate debt. | | 43 | `UNDERLYING_BALANCE_ZERO` | Underlying balance is zero. | | 44 | `INTEREST_RATE_REBALANCE_CONDITIONS_NOT_MET` | Stable-rate rebalance conditions not satisfied. | | 45 | `HEALTH_FACTOR_NOT_BELOW_THRESHOLD` | Cannot liquidate: HF is at or above `1e18`. | | 46 | `COLLATERAL_CANNOT_BE_LIQUIDATED` | Collateral asset cannot be liquidated. | | 47 | `SPECIFIED_CURRENCY_NOT_BORROWED_BY_USER` | User did not borrow the specified currency. | | 49 | `INCONSISTENT_FLASHLOAN_PARAMS` | `assets.length != amounts.length` in `flashLoan`. | | 50 | `BORROW_CAP_EXCEEDED` | Borrow cap exceeded. | | 51 | `SUPPLY_CAP_EXCEEDED` | Supply cap exceeded. | | 52 | `UNBACKED_MINT_CAP_EXCEEDED` | Unbacked mint cap exceeded. | | 53 | `DEBT_CEILING_EXCEEDED` | Isolation-mode debt ceiling exceeded. | | 54 | `UNDERLYING_CLAIMABLE_RIGHTS_NOT_ZERO` | Cannot drop the reserve: AToken supply or `accruedToTreasury` is non-zero. | | 55 | `STABLE_DEBT_NOT_ZERO` | Stable debt supply must be zero. | | 56 | `VARIABLE_DEBT_SUPPLY_NOT_ZERO` | Variable debt supply must be zero. | | 57 | `LTV_VALIDATION_FAILED` | LTV validation failed. | | 58 | `INCONSISTENT_EMODE_CATEGORY` | E-mode category mismatch. | | 59 | `PRICE_ORACLE_SENTINEL_CHECK_FAILED` | Sentinel rejected the action. | | 60 | `ASSET_NOT_BORROWABLE_IN_ISOLATION` | Asset is not borrowable in isolation mode. | | 61 | `RESERVE_ALREADY_INITIALIZED` | Reserve already initialised. | | 62 | `USER_IN_ISOLATION_MODE_OR_LTV_ZERO` | User is in isolation mode or the asset has zero LTV — cannot enable as collateral. | | 63 | `INVALID_LTV` | Invalid LTV. | | 64 | `INVALID_LIQ_THRESHOLD` | Invalid liquidation threshold. | | 65 | `INVALID_LIQ_BONUS` | Invalid liquidation bonus. | | 66 | `INVALID_DECIMALS` | Invalid decimals. | | 67 | `INVALID_RESERVE_FACTOR` | Invalid reserve factor. | | 68 | `INVALID_BORROW_CAP` | Invalid borrow cap. | | 69 | `INVALID_SUPPLY_CAP` | Invalid supply cap. | | 70 | `INVALID_LIQUIDATION_PROTOCOL_FEE` | Invalid liquidation protocol fee. | | 71 | `INVALID_EMODE_CATEGORY` | Invalid e-mode category. | | 72 | `INVALID_UNBACKED_MINT_CAP` | Invalid unbacked mint cap. | | 73 | `INVALID_DEBT_CEILING` | Invalid debt ceiling. | | 74 | `INVALID_RESERVE_INDEX` | Invalid reserve index. | | 75 | `ACL_ADMIN_CANNOT_BE_ZERO` | ACL admin cannot be zero. | | 76 | `INCONSISTENT_PARAMS_LENGTH` | Array length mismatch. | | 77 | `ZERO_ADDRESS_NOT_VALID` | Zero address not permitted. | | 78 | `INVALID_EXPIRATION` | Permit deadline expired. | | 79 | `INVALID_SIGNATURE` | Permit signature invalid. | | 80 | `OPERATION_NOT_SUPPORTED` | Operation not supported (e.g. transfer on a debt token). | | 81 | `DEBT_CEILING_NOT_ZERO` | Debt ceiling must be zero for this action. | | 82 | `ASSET_NOT_LISTED` | Asset is not listed. | | 83 | `INVALID_OPTIMAL_USAGE_RATIO` | Invalid optimal usage ratio. | | 84 | `INVALID_OPTIMAL_STABLE_TO_TOTAL_DEBT_RATIO` | Invalid optimal stable/total debt ratio. | | 85 | `UNDERLYING_CANNOT_BE_RESCUED` | The underlying asset of an AToken cannot be rescued. | | 86 | `ADDRESSES_PROVIDER_ALREADY_ADDED` | Provider already registered. | | 87 | `POOL_ADDRESSES_DO_NOT_MATCH` | Token implementation's pool reference does not match the initialising pool. | | 88 | `STABLE_BORROWING_ENABLED` | Stable-rate borrowing is currently enabled — disable it before this action. | | 89 | `SILOED_BORROWING_VIOLATION` | User is trying to borrow alongside a siloed asset. | | 90 | `RESERVE_DEBT_NOT_ZERO` | Reserve total debt must be zero for this action. | | 91 | `FLASHLOAN_DISABLED` | Flash-loan is disabled on this reserve (bit 63 of the reserve configuration). | In addition to the numeric codes, `FlashLoanLogic.executeFlashLoan` reverts with the string `FLASHLOAN_INTO_BORROW_DEPRECATED` when called with a non-zero `interestRateModes[i]` — this is the SparkLend-specific disabling of flash-loan-into-borrow. ## AaveProtocolDataProvider * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/misc/AaveProtocolDataProvider.sol) Read-only helper used by frontends and integrators. All methods are derived views over `Pool` and the reserve token contracts. The provider is registered on `PoolAddressesProvider` under the `DATA_PROVIDER` identifier — fetch its address via `PoolAddressesProvider.getPoolDataProvider()`. ### State #### ADDRESSES\_PROVIDER ```solidity IPoolAddressesProvider public immutable ADDRESSES_PROVIDER ``` The provider this data-provider was configured against. ### Methods #### getAllReservesTokens ```solidity function getAllReservesTokens() external view returns (TokenData[] memory) ``` Returns one `TokenData(symbol, tokenAddress)` per active reserve. For two special-cased addresses, the symbol is hard-coded: * `MKR (0x9f8F72aA9304c8B593d555F12eF6589cC3A579A2)` — `symbol == "MKR"` (the live MKR token returns a `bytes32` symbol, which would break `IERC20Detailed.symbol`). * `ETH (0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE)` — `symbol == "ETH"`. For every other reserve, `symbol` is fetched from the underlying via `IERC20Detailed.symbol()`. #### getAllATokens ```solidity function getAllATokens() external view returns (TokenData[] memory) ``` Returns one `TokenData(symbol, tokenAddress)` per active reserve, where the address and symbol are read from the reserve's AToken proxy (e.g. `spUSDS`). #### getReserveConfigurationData ```solidity function getReserveConfigurationData(address asset) external view returns ( uint256 decimals, uint256 ltv, uint256 liquidationThreshold, uint256 liquidationBonus, uint256 reserveFactor, bool usageAsCollateralEnabled, bool borrowingEnabled, bool stableBorrowRateEnabled, bool isActive, bool isFrozen ) ``` Decoded reserve configuration. `usageAsCollateralEnabled` is `liquidationThreshold != 0`. #### getReserveEModeCategory ```solidity function getReserveEModeCategory(address asset) external view returns (uint256) ``` Returns the asset's e-mode category (`0` = default). #### getReserveCaps ```solidity function getReserveCaps(address asset) external view returns (uint256 borrowCap, uint256 supplyCap) ``` Caps are in **whole tokens**, not native units. `0` means no cap. #### getPaused ```solidity function getPaused(address asset) external view returns (bool isPaused) ``` Per-reserve paused flag (bit 60). #### getSiloedBorrowing ```solidity function getSiloedBorrowing(address asset) external view returns (bool) ``` Per-reserve siloed-borrowing flag (bit 62). #### getLiquidationProtocolFee ```solidity function getLiquidationProtocolFee(address asset) external view returns (uint256) ``` Bps share of the liquidation bonus routed to treasury. #### getUnbackedMintCap ```solidity function getUnbackedMintCap(address asset) external view returns (uint256) ``` Bridge unbacked-mint cap (whole tokens). #### getDebtCeiling / getDebtCeilingDecimals ```solidity function getDebtCeiling(address asset) external view returns (uint256) function getDebtCeilingDecimals() external pure returns (uint256) ``` `getDebtCeiling` returns the isolation-mode debt ceiling with `DEBT_CEILING_DECIMALS = 2` (so `200_00` = `$200`). `0` means isolation mode is disabled for the asset. #### getReserveData ```solidity function getReserveData(address asset) external view returns ( uint256 unbacked, uint256 accruedToTreasuryScaled, uint256 totalAToken, uint256 totalStableDebt, uint256 totalVariableDebt, uint256 liquidityRate, uint256 variableBorrowRate, uint256 stableBorrowRate, uint256 averageStableBorrowRate, uint256 liquidityIndex, uint256 variableBorrowIndex, uint40 lastUpdateTimestamp ) ``` Snapshot of the reserve's economics. `totalAToken`, `totalStableDebt`, and `totalVariableDebt` are denominated in the underlying asset's native units. #### getATokenTotalSupply ```solidity function getATokenTotalSupply(address asset) external view returns (uint256) ``` `AToken.totalSupply()` for the reserve. #### getTotalDebt ```solidity function getTotalDebt(address asset) external view returns (uint256) ``` `StableDebtToken.totalSupply() + VariableDebtToken.totalSupply()`. #### getUserReserveData ```solidity function getUserReserveData(address asset, address user) external view returns ( uint256 currentATokenBalance, uint256 currentStableDebt, uint256 currentVariableDebt, uint256 principalStableDebt, uint256 scaledVariableDebt, uint256 stableBorrowRate, uint256 liquidityRate, uint40 stableRateLastUpdated, bool usageAsCollateralEnabled ) ``` #### getReserveTokensAddresses ```solidity function getReserveTokensAddresses(address asset) external view returns ( address aTokenAddress, address stableDebtTokenAddress, address variableDebtTokenAddress ) ``` #### getInterestRateStrategyAddress ```solidity function getInterestRateStrategyAddress(address asset) external view returns (address) ``` #### getFlashLoanEnabled ```solidity function getFlashLoanEnabled(address asset) external view returns (bool) ``` Returns bit 63 of the reserve configuration. ## AaveOracle * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/misc/AaveOracle.sol) Contract used by `Pool` (via `PoolAddressesProvider.getPriceOracle()`) to look up asset prices. `AaveOracle` itself implements a thin per-asset routing layer: each asset is mapped to a Chainlink-compatible `AggregatorInterface` source. The source contract is expected to return prices in the units of `BASE_CURRENCY_UNIT` (typically `1e8` for USD-denominated markets). For SparkLend, the per-asset source addresses point at redundant aggregator contracts (e.g. Aggor) that internally combine Chainlink, Chronicle, and RedStone feeds. The aggregation logic lives in those source contracts, not in `AaveOracle`. Resolution rules in `getAssetPrice(asset)`: 1. If `asset == BASE_CURRENCY`, returns `BASE_CURRENCY_UNIT`. 2. Else if a source is configured, calls `source.latestAnswer()`. If the answer is `> 0`, returns it. Otherwise, falls through to the fallback oracle. 3. Else (no source configured), calls the fallback oracle. #### State Variables | Name | Type | Description | | -------------------- | ------- | ------------------------------------------------------------------------------ | | `BASE_CURRENCY` | address | The base currency used for price quotes (if USD is used, base currency is 0x0) | | `BASE_CURRENCY_UNIT` | uint256 | The unit of the base currency | #### Constructor ```solidity constructor( IPoolAddressesProvider provider, address[] memory assets, address[] memory sources, address fallbackOracle, address baseCurrency, uint256 baseCurrencyUnit ) ``` Initializes the oracle with: * PoolAddressesProvider * Initial list of assets and their price sources * Fallback oracle address * Base currency and its unit ### Methods #### View ##### getAssetPrice `function getAssetPrice(address asset)` Returns the price of the supported `asset` in `BASE_CURRENCY` of SparkLend Market, in units of `BASE_CURRENCY_UNIT` (`1e8` for the USD-denominated SparkLend market). * If the asset is BASE\_CURRENCY, returns BASE\_CURRENCY\_UNIT * Otherwise, tries to get price from price oracle (Aggor). Return Value | Type | Description | | ------- | ----------------------------------------------------------------------------------------------------------------------------- | | uint256 | Price in BASE\_CURRENCY of the Spark market, in units of BASE\_CURRENCY\_UNIT (1e8 for the USD-denominated SparkLend market). | ##### getAssetsPrices `function getAssetsPrices(address[] calldata assets)` Returns the prices of the supported `assets` in `BASE_CURRENCY` of the Spark Market. All prices are in units of `BASE_CURRENCY_UNIT` (`1e8` for the USD-denominated SparkLend market). Call Params | Name | Type | Description | | ------ | ---------- | ------------------------------------------------------------- | | assets | address\[] | The addresses of the assets for which price is being queried. | Return Value | Type | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------ | | uint256\[] | Prices in BASE\_CURRENCY of the Spark market, in units of BASE\_CURRENCY\_UNIT (1e8 for the USD-denominated SparkLend market). | ##### getSourceOfAsset `function getSourceOfAsset(address asset)` Returns the address of the price source for `asset`. ##### getFallbackOracle `function getFallbackOracle()` Returns the address of the fallback oracle. #### Write ##### setAssetSources `function setAssetSources(address[] calldata assets, address[] calldata sources)` Sets the price source for given list of assets. :::danger This method can be called only by `POOL_ADMIN` or `ASSET_LISTING_ADMIN`. Check [ACLManager](/dev/sparklend/core-contracts/aclmanager) for details on system roles. ::: Call Params | Name | Type | Description | | ------- | ---------- | ------------------------------------------------------------------------------------------- | | assets | address\[] | The addresses of the assets for which source is being set. | | sources | address\[] | The address of the source of each asset. Length of assets and sources array should be same. | ##### setFallbackOracle `function setFallbackOracle(address fallbackOracle)` Sets/updates the fallback oracle. :::danger This method can be called only by `POOL_ADMIN`or`ASSET_LISTING_ADMIN`. Check [ACLManager](/dev/sparklend/core-contracts/aclmanager) for details on system roles. ::: Call Params | Name | Type | Description | | -------------- | ------- | ----------------------------------- | | fallbackOracle | address | The address of the fallback oracle. | ## ACLManager * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/ACLManager.sol) ### Overview The *Access Control List Manager* (ACLManager) is the main registry of system roles and permissions. It inherits from OpenZeppelin's `AccessControl` contract and implements the `IACLManager` interface. ACLManager allows a ***Role Admin*** to manage roles. ***Role Admin*** is itself a role that is managed by the `DEFAULT_ADMIN_ROLE`. `DEFAULT_ADMIN_ROLE` is held by the *ACLAdmin,* which is initialized in `PoolAddressesProvider`. The ACL admin must be set in the PoolAddressesProvider before deploying the ACLManager. :::info On Ethereum, the `PoolAddressesProvider` is owned by Sky Governance. In networks other than Ethereum, either the *Crosschain Governance Bridges* or *Community Multisigs* are used to manage the `PoolAddressesProvider`. ::: #### Constructor ```solidity constructor(IPoolAddressesProvider provider) ``` Initializes the ACLManager with the PoolAddressesProvider. The ACL admin must be set in the provider beforehand and cannot be the zero address. #### Role Constants All role constants are keccak256 hashes of their respective role names: * `POOL_ADMIN_ROLE = keccak256('POOL_ADMIN')` * `EMERGENCY_ADMIN_ROLE = keccak256('EMERGENCY_ADMIN')` * `RISK_ADMIN_ROLE = keccak256('RISK_ADMIN')` * `FLASH_BORROWER_ROLE = keccak256('FLASH_BORROWER')` * `BRIDGE_ROLE = keccak256('BRIDGE')` * `ASSET_LISTING_ADMIN_ROLE = keccak256('ASSET_LISTING_ADMIN')` ### Roles Below we outline the powers/responsibilities of the roles and the specific methods that are only accessible to the holders of these roles. | Role | Responsibilities / Powers | Methods Accessible | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `FLASH_BORROWER_ROLE` | Flash loan premium is waived for the holders of this role.⛔️ Does not include flashLoanSimple | `flashLoan` | | `BRIDGE_ROLE` | Can leverage the Portal feature | mintUnbacked backUnbacked | | `ASSET_LISTING_ADMIN_ROLE` | Can update asset oracle sources fallback oracle add new assets to the Spark market | setAssetSources setFallbackOracle initReserves | | `RISK_ADMIN_ROLE` | Can update grace period of Oracle Sentinels reserve params unbacked mint cap liquidation protocol fee existing eMode categories and create new. (not category 0) add/remove asset in silo mode | setGracePeriod setReserveBorrowing setReserveFlashLoaning configureReserveAsCollateral setReserveStableRateBorrowing setReserveFreeze setBorrowableInIsolation setReserveFactor setDebtCeiling setBorrowCap setSupplyCap setLiquidationProtocolFee setEModeCategory setAssetEModeCategory setUnbackedMintCap setReserveInterestRateStrategyAddress setSiloedBorrowing | | `DEFAULT_ADMIN_ROLE` | OpenZeppelin's `0x00` admin role, held by the `ACL_ADMIN` address registered on `PoolAddressesProvider`. Manages the role admins in the ACLManager | setRoleAdmin addPoolAdmin removePoolAdmin addEmergencyAdmin removeEmergencyAdmin addRiskAdmin removeRiskAdmin addFlashBorrower removeFlashBorrower addBridge removeBridge addAssetListingAdmin removeAssetListingAdmin | | `EMERGENCY_ADMIN_ROLE` | Can pause/unpause the pool or individual reserve | setPoolPause setReservePause | | `POOL_ADMIN_ROLE` | Can update token implementations drop reserves pause/unpause reserves activate/deactivate reserves update premiums do all the things available to `RISK_ADMIN_ROLE` and `ASSET_LISTING_ADMIN_ROLE` | all methods available to RISK\_ADMIN\_ROLE all methods available to ASSET\_LISTING\_ADMIN\_ROLE dropReserve updateAToken updateStableDebtToken updateVariableDebtToken setReserveActive updateBridgeProtocolFee updateFlashloanPremiumTotal updateFlashloanPremiumToProtocol | ### View Methods #### isPoolAdmin `function isPoolAdmin(address admin)` Returns `true` if the address has `POOL_ADMIN_ROLE` role. #### isEmergencyAdmin `function isEmergencyAdmin(address admin)` Returns `true` if the address has `EMERGENCY_ADMIN_ROLE` role. #### isRiskAdmin `function isRiskAdmin(address admin)` Returns `true` if the address has `RISK_ADMIN_ROLE` role. #### isFlashBorrower `function isFlashBorrower(address borrower)` Returns `true` if the address has `FLASH_BORROWER_ROLE` role. #### isBridge `function isBridge(address bridge)` Returns `true` if the address has `BRIDGE_ROLE` role. #### isAssetListingAdmin `function isAssetListingAdmin(address admin)` Returns `true` if the address has `ASSET_LISTING_ADMIN_ROLE` role. ### Write Methods #### setRoleAdmin `setRoleAdmin(bytes32 role, bytes32 adminRole)` Setup admin to manage Roles. This method can only be called by an address with `DEFAULT_ADMIN_ROLE`. :::info This method can only be called by address with `DEFAULT_ADMIN_ROLE`. ::: Call Params | Name | Type | Description | | --------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | role | bytes32 | One of the role constants: POOL\_ADMIN\_ROLE, EMERGENCY\_ADMIN\_ROLE, RISK\_ADMIN\_ROLE, FLASH\_BORROWER\_ROLE, BRIDGE\_ROLE, or ASSET\_LISTING\_ADMIN\_ROLE | | adminRole | bytes32 | The role that will be able to grant/revoke the specified role. 0x00 is reserved for DEFAULT\_ADMIN\_ROLE | #### addPoolAdmin `addPoolAdmin(address admin)` Add address to the list of members in `POOL_ADMIN_ROLE` role. Holders of this role can update token implementations, drop, (un)pause and (de)activate reserves, update premiums and do everything the `ASSET_LISTING_ADMIN_ROLE` and `RISK_ADMIN_ROLE` can do. :::info Can be called only by *Role Admin*, specified by *Sky Governance*, responsible for managing `POOL_ADMIN_ROLE` role. ::: Call Params | Name | Type | Description | | ----- | ------- | ----------------------------------------------- | | admin | address | address which will be granted POOL\_ADMIN role. | #### removePoolAdmin `removePoolAdmin(address admin)` Remove given address from the list of members in `POOL_ADMIN_ROLE` role. :::info Can be called only by *Role Admin*, specified by *Sky Governance*, responsible for managing `POOL_ADMIN_ROLE` role. ::: Call Params | Name | Type | Description | | ----- | ------- | --------------------------------------------------------------- | | admin | address | address for which POOL\_ADMIN role permissions must be revoked. | #### addEmergencyAdmin `addEmergencyAdmin(address admin)` Add address to the list of members in `EMERGENCY_ADMIN_ROLE` role. Holders of this role can pause and unpause the pool or an individual reserve. :::info Can be called only by *Role Admin*, specified by *Sky Governance*, responsible for managing`EMERGENCY_ADMIN_ROLE` role. ::: | Name | Type | Description | | ----- | ------- | ---------------------------------------------------- | | admin | address | address which will be granted EMERGENCY\_ADMIN role. | #### removeEmergencyAdmin `function removeEmergencyAdmin(address admin)` Remove given address from the list of members in `EMERGENCY_ADMIN_ROLE` role. :::info Can be called only by *Role Admin*, specified by *Sky Governance*, responsible for managing `EMERGENCY_ADMIN_ROLE` role. ::: | Name | Type | Description | | ----- | ------- | -------------------------------------------------------------------- | | admin | address | address for which EMERGENCY\_ADMIN role permissions must be revoked. | #### addRiskAdmin `function addRiskAdmin(address admin)` Add address to the list of members in `RISK_ADMIN_ROLE` role. Holders of this role can update grace period of Oracle Sentinels, reserve params, unbacked mint cap, liquidation fee and eMode categories. | Name | Type | Description | | ----- | ------- | ----------------------------------------------- | | admin | address | address which will be granted RISK\_ADMIN role. | #### removeRiskAdmin Remove given address from the list of members in `RISK_ADMIN_ROLE` role. | Name | Type | Description | | ----- | ------- | --------------------------------------------------------------- | | admin | address | address for which RISK\_ADMIN role permissions must be revoked. | #### addFlashBorrower `function addFlashBorrower(address borrower)` Add address to the list of members in `FLASH_BORROWER_ROLE` role. Holders of this role do not pay premium for flash loan (Does not apply to `flashLoanSimple`). #### removeFlashBorrower `function removeFlashBorrower(address borrower)` Remove given address from the list of members in `FLASH_BORROWER_ROLE` role. | Name | Type | Description | | -------- | ------- | ------------------------------------------------------------------- | | borrower | address | address for which FLASH\_BORROWER role permissions must be revoked. | #### addBridge `addBridge(address bridge)` Add contract address to the list of ***bridges***. Holders of this role can leverage the Portal feature to seamlessly move supplied assets across SparkLend markets on different networks. :::info Can be called only by *Role Admin*, specified by *Sky Governance*, responsible for managing `BRIDGE_ROLE` role. ::: | Name | Type | Description | | ------ | ------- | ------------------------------------------ | | bridge | address | address which will be granted BRIDGE role. | #### removeBridge `removeBridge(address bridge)` Remove contract address from the list of ***bridges***. :::info Can be called only by *Role Admin*, specified by *Sky Governance*, responsible for managing `BRIDGE_ROLE` role. ::: | Name | Type | Description | | ------ | ------- | ---------------------------------------------------------- | | bridge | address | address for which BRIDGE role permissions must be revoked. | #### addAssetListingAdmin `function addAssetListingAdmin(address admin)` Add address to the list of member in `ASSET_LISTING_ADMIN_ROLE` role. Holder of this role can update oracles & add new asset to the Spark market. | Name | Type | Description | | ----- | ------- | --------------------------------------------------------- | | admin | address | address which will be granted ASSET\_LISTING\_ADMIN role. | #### removeAssetListingAdmin `function removeAssetListingAdmin(address admin)` Remove address from the list of members in `ASSET_LISTING_ADMIN_ROLE` role. | Name | Type | Description | | ----- | ------- | ------------------------------------------------------------------------- | | admin | address | address for which ASSET\_LISTING\_ADMIN role permissions must be revoked. | ## Pool * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/pool/Pool.sol) ### Overview The `Pool` contract is the main entry point for SparkLend. All user-initiated lending operations (supply, withdraw, borrow, repay, liquidate, flash-loan, e-mode selection, collateral toggle) call into `Pool`, which delegates to specialised logic libraries. `Pool` is deployed behind an `InitializableImmutableAdminUpgradeabilityProxy` whose admin is the `PoolAddressesProvider`. Upgrading `Pool` requires changing the implementation pointer on the provider. :::info **Contract names vs. deployed token symbols.** The contract types in this repo are `AToken`, `VariableDebtToken`, and `StableDebtToken` — the function names below reflect that (e.g. `repayWithATokens`, `receiveAToken`). The deployed tokens on Spark markets are minted with Spark-branded **symbols** like `spUSDS` and `spWETH`, configured at reserve initialisation. The "sp" prefix is a symbol, not a separate contract type. ::: ### Logic library breakdown | Library | Responsibilities | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SupplyLogic` | `executeSupply`, `executeWithdraw`, `executeFinalizeTransfer`, `executeUseReserveAsCollateral` | | `BorrowLogic` | `executeBorrow`, `executeRepay`, `executeSwapBorrowRateMode`, `executeRebalanceStableBorrowRate` | | `LiquidationLogic` | `executeLiquidationCall` | | `FlashLoanLogic` | `executeFlashLoan`, `executeFlashLoanSimple` | | `EModeLogic` | `executeSetUserEMode` | | `BridgeLogic` | `executeMintUnbacked`, `executeBackUnbacked` | | `PoolLogic` | `executeInitReserve`, `executeDropReserve`, `executeMintToTreasury`, `executeGetUserAccountData`, `executeRescueTokens`, `executeResetIsolationModeTotalDebt` | | `ValidationLogic` | Pure validation helpers used by all of the above | ### Access control Functions on `Pool` are gated by three modifiers: * `onlyPoolConfigurator` — caller is the `PoolConfigurator` proxy (resolved through `PoolAddressesProvider.getPoolConfigurator()`). * `onlyPoolAdmin` — caller holds `POOL_ADMIN_ROLE` on the `ACLManager`. * `onlyBridge` — caller holds `BRIDGE_ROLE` on the `ACLManager`. End-user functions (supply, withdraw, borrow, repay, liquidate, flash-loan) are permissionless. ### Constructor and initialization ```solidity constructor(IPoolAddressesProvider provider) ``` Caches the `PoolAddressesProvider` in an immutable. Called on the implementation, not the proxy. ```solidity function initialize(IPoolAddressesProvider provider) external initializer ``` Called once on the proxy. Verifies the passed provider matches the immutable and sets `_maxStableRateBorrowSizePercent` to 25%. ### User-facing write methods #### supply ```solidity function supply(address asset, uint256 amount, address onBehalfOf, uint16 referralCode) external ``` Transfers `amount` of `asset` from `msg.sender` to the reserve's AToken contract and mints `AToken` to `onBehalfOf`. If this is the recipient's first supply of this asset and the reserve has non-zero LTV and is not an isolation-mode reserve, the asset is automatically enabled as collateral. :::warning `Pool` must have ERC20 `allowance` from `msg.sender` for at least `amount` of `asset`. ::: | Param | Type | Description | | -------------- | --------- | -------------------------------------------------------------------------- | | `asset` | `address` | Underlying ERC20 being supplied. | | `amount` | `uint256` | Amount in the asset's native units. | | `onBehalfOf` | `address` | Receiver of the minted AToken. | | `referralCode` | `uint16` | Emitted in the `Supply` event for integrator tracking. Pass `0` if unused. | #### supplyWithPermit ```solidity function supplyWithPermit( address asset, uint256 amount, address onBehalfOf, uint16 referralCode, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS ) external ``` Same as `supply`, but consumes an ERC-2612 `permit` signature from `msg.sender` before pulling the underlying. Useful for one-tx supply with permit-supporting assets. #### withdraw ```solidity function withdraw(address asset, uint256 amount, address to) external returns (uint256) ``` Burns the caller's AToken and transfers underlying to `to`. Pass `type(uint256).max` to withdraw the full balance. If the caller is borrowing and the asset is used as collateral, the post-withdraw health factor is validated. | Param | Type | Description | | -------- | --------- | ---------------------------------------------------------------- | | `asset` | `address` | Underlying ERC20 being withdrawn. | | `amount` | `uint256` | Amount in native units, or `type(uint256).max` for full balance. | | `to` | `address` | Receiver of the underlying. | Returns the actual amount withdrawn (relevant when `type(uint256).max` is used). #### borrow ```solidity function borrow(address asset, uint256 amount, uint256 interestRateMode, uint16 referralCode, address onBehalfOf) external ``` Opens a debt position on `onBehalfOf` (which may be `msg.sender` or a third party that has granted credit delegation). Funds are transferred to `msg.sender`. | Param | Type | Description | | ------------------ | --------- | --------------------------------------------------------------------------------------------------------------------- | | `asset` | `address` | Underlying ERC20 being borrowed. | | `amount` | `uint256` | Amount in native units. | | `interestRateMode` | `uint256` | `1` = stable, `2` = variable. | | `referralCode` | `uint16` | Emitted in the `Borrow` event. | | `onBehalfOf` | `address` | Address that incurs the debt; must have approved `msg.sender` via `approveDelegation` if different from `msg.sender`. | :::info Stable-rate borrowing is implemented in the contracts but **disabled at the reserve-configuration level** for every current SparkLend reserve (the `STABLE_BORROWING_ENABLED` flag in the reserve config is `false`). Passing `interestRateMode = 1` will revert with `STABLE_BORROWING_NOT_ENABLED` (`31`) on every live reserve. ::: #### repay ```solidity function repay(address asset, uint256 amount, uint256 interestRateMode, address onBehalfOf) external returns (uint256) ``` Pulls underlying from `msg.sender` and burns debt tokens of `onBehalfOf`. Pass `type(uint256).max` to repay the full debt of the chosen rate mode (only valid when `msg.sender == onBehalfOf`). | Param | Type | Description | | ------------------ | --------- | ---------------------------------------------------------- | | `asset` | `address` | Underlying borrowed asset. | | `amount` | `uint256` | Amount to repay, or `type(uint256).max` to clear the debt. | | `interestRateMode` | `uint256` | `1` = stable debt, `2` = variable debt. | | `onBehalfOf` | `address` | Whose debt is being reduced. | Returns the actual amount repaid. #### repayWithPermit ```solidity function repayWithPermit( address asset, uint256 amount, uint256 interestRateMode, address onBehalfOf, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS ) external returns (uint256) ``` Same as `repay`, with an ERC-2612 `permit` over the underlying being consumed before transferFrom. #### repayWithATokens ```solidity function repayWithATokens(address asset, uint256 amount, uint256 interestRateMode) external returns (uint256) ``` Burns the caller's own AToken balance to repay their own debt — no allowance to `Pool` required, no underlying transfer. Pass `type(uint256).max` to repay up to the caller's full AToken balance without leaving dust. | Param | Type | Description | | ------------------ | --------- | ------------------------------------------------------------------- | | `asset` | `address` | Underlying borrowed asset. | | `amount` | `uint256` | Amount of underlying to credit toward debt, or `type(uint256).max`. | | `interestRateMode` | `uint256` | `1` = stable, `2` = variable. | #### swapBorrowRateMode ```solidity function swapBorrowRateMode(address asset, uint256 interestRateMode) external ``` Swaps the caller's existing debt between stable and variable. The `interestRateMode` argument is the **current** mode being switched **out of**. Effectively unusable on live SparkLend reserves while stable-rate borrowing is disabled. #### rebalanceStableBorrowRate ```solidity function rebalanceStableBorrowRate(address asset, address user) external ``` Re-prices a user's stable debt to the current stable rate, if reserve conditions allow (see `ValidationLogic.validateRebalanceStableBorrowRate`). Effectively unusable while stable-rate borrowing is disabled. #### setUserUseReserveAsCollateral ```solidity function setUserUseReserveAsCollateral(address asset, bool useAsCollateral) external ``` Toggles whether the caller's AToken balance for `asset` contributes to their collateral. Disabling reverts if it would drop the caller below the health-factor liquidation threshold. Enabling is rejected if the asset has `ltv == 0`, or if the user is in isolation mode and the asset has `debtCeiling == 0`. #### liquidationCall ```solidity function liquidationCall( address collateralAsset, address debtAsset, address user, uint256 debtToCover, bool receiveAToken ) external ``` Repays up to `debtToCover` of `user`'s debt in `debtAsset` and seizes a proportional amount of their `collateralAsset` plus the liquidation bonus. | Param | Type | Description | | ----------------- | --------- | -------------------------------------------------------------------------------------------- | | `collateralAsset` | `address` | Underlying collateral to seize. | | `debtAsset` | `address` | Underlying debt to repay. | | `user` | `address` | Borrower being liquidated. | | `debtToCover` | `uint256` | Amount of debt to cover, or `type(uint256).max` for the maximum allowed by the close factor. | | `receiveAToken` | `bool` | `true` to receive the seized collateral as AToken; `false` to receive the underlying. | Constants from `LiquidationLogic`: * `DEFAULT_LIQUIDATION_CLOSE_FACTOR = 0.5e4` (50%) — applies when `0.95e18 < HF < 1e18`. * `MAX_LIQUIDATION_CLOSE_FACTOR = 1e4` (100%) — applies when `HF <= 0.95e18`. * `CLOSE_FACTOR_HF_THRESHOLD = 0.95e18`. #### flashLoan ```solidity function flashLoan( address receiverAddress, address[] calldata assets, uint256[] calldata amounts, uint256[] calldata interestRateModes, address onBehalfOf, bytes calldata params, uint16 referralCode ) external ``` Multi-asset flash loan. Pulls `amounts` of each asset into `receiverAddress`, calls `IFlashLoanReceiver.executeOperation`, then settles each leg. :::warning **SparkLend disables flash-loan-into-borrow.** Every entry of `interestRateModes` must be `0`. A non-zero entry reverts with `FLASHLOAN_INTO_BORROW_DEPRECATED`. To open a debt position, call `borrow()` directly. (`contracts/protocol/libraries/logic/FlashLoanLogic.sol`) ::: The flash-loan fee is waived when `msg.sender` holds `FLASH_BORROWER_ROLE` on the `ACLManager`. The reserve being flash-loaned must have its `flashLoanEnabled` flag set. #### flashLoanSimple ```solidity function flashLoanSimple(address receiverAddress, address asset, uint256 amount, bytes calldata params, uint16 referralCode) external ``` Single-asset flash loan. Cheaper than `flashLoan` for the common case. **Does not** waive the fee for `FLASH_BORROWER_ROLE` holders, and does **not** support opening a debt position. #### setUserEMode ```solidity function setUserEMode(uint8 categoryId) external ``` Sets the caller's e-mode category. Reverts if the caller has open debt in an asset whose `eModeCategory` differs from `categoryId`, or if the change would drop the caller below the health-factor threshold. #### mintToTreasury ```solidity function mintToTreasury(address[] calldata assets) external ``` Mints accrued reserve-factor income to the treasury as AToken for the listed assets. Permissionless. #### rescueTokens ```solidity function rescueTokens(address token, address to, uint256 amount) external ``` Transfers `amount` of any ERC20 `token` accidentally sent to the `Pool` itself out to `to`. **`onlyPoolAdmin`.** #### deposit (deprecated) ```solidity function deposit(address asset, uint256 amount, address onBehalfOf, uint16 referralCode) external ``` Alias for `supply`. Retained for compatibility with older integrations. ### Bridge-only methods These functions are callable only by addresses holding `BRIDGE_ROLE` on `ACLManager`. #### mintUnbacked ```solidity function mintUnbacked(address asset, uint256 amount, address onBehalfOf, uint16 referralCode) external ``` Mints AToken to `onBehalfOf` without underlying backing. Bound by the reserve's `unbackedMintCap`. #### backUnbacked ```solidity function backUnbacked(address asset, uint256 amount, uint256 fee) external returns (uint256) ``` Backs previously-minted unbacked AToken with `amount` of underlying plus a `fee`. :::info The bridge feature is in the contracts but not used by any active SparkLend deployment. No address holds `BRIDGE_ROLE` on production markets. ::: ### PoolConfigurator-only methods The following are callable only by the `PoolConfigurator`: * `initReserve(asset, aTokenAddress, stableDebtAddress, variableDebtAddress, interestRateStrategyAddress)` * `dropReserve(asset)` * `setReserveInterestRateStrategyAddress(asset, rateStrategyAddress)` * `setConfiguration(asset, configuration)` * `updateBridgeProtocolFee(protocolFee)` * `updateFlashloanPremiums(flashLoanPremiumTotal, flashLoanPremiumToProtocol)` * `configureEModeCategory(id, category)` * `resetIsolationModeTotalDebt(asset)` Their high-level entry points are the corresponding methods on `PoolConfigurator`. ### AToken-only methods * `finalizeTransfer(asset, from, to, amount, balanceFromBefore, balanceToBefore)` — invoked by an `AToken` after every transfer to revalidate the sender's health factor and emit collateral-enable/disable events. ### View methods #### getReserveData ```solidity function getReserveData(address asset) external view returns (DataTypes.ReserveData memory) ``` Returns the full `ReserveData` struct: bit-packed configuration, indexes, current rates, last update timestamp, reserve ID, the three token addresses, the interest-rate strategy address, accrued-to-treasury, unbacked, and isolation-mode total debt. See `contracts/protocol/libraries/types/DataTypes.sol`. #### getUserAccountData ```solidity function getUserAccountData(address user) external view returns ( uint256 totalCollateralBase, uint256 totalDebtBase, uint256 availableBorrowsBase, uint256 currentLiquidationThreshold, uint256 ltv, uint256 healthFactor ) ``` All values are denominated in the price oracle's base currency (1e8 for USD-denominated oracles). `healthFactor` is `type(uint256).max` for users with no debt. #### getConfiguration / getUserConfiguration Return the packed `ReserveConfigurationMap` and `UserConfigurationMap` bitmaps. Use the `ReserveConfiguration` and `UserConfiguration` libraries (or the `AaveProtocolDataProvider` helpers) to decode. `ReserveConfigurationMap` bit layout (`contracts/protocol/libraries/types/DataTypes.sol`): | Bits | Field | | ------- | ---------------------------------------------------------------------------- | | 0-15 | LTV | | 16-31 | Liquidation threshold | | 32-47 | Liquidation bonus | | 48-55 | Decimals | | 56 | Active | | 57 | Frozen | | 58 | Borrowing enabled | | 59 | Stable-rate borrowing enabled | | 60 | Paused | | 61 | Borrowable in isolation | | 62 | Siloed borrowing | | 63 | Flash-loan enabled | | 64-79 | Reserve factor | | 80-115 | Borrow cap (whole tokens; 0 = no cap) | | 116-151 | Supply cap (whole tokens; 0 = no cap) | | 152-167 | Liquidation protocol fee | | 168-175 | eMode category | | 176-211 | Unbacked mint cap (whole tokens; 0 = minting disabled) | | 212-251 | Debt ceiling (with `DEBT_CEILING_DECIMALS = 2`; 0 = isolation mode disabled) | | 252-255 | Unused | #### getReserveNormalizedIncome / getReserveNormalizedVariableDebt Return the current cumulative interest index (in ray, `1e27`). A value of `1e27` means no interest accrued; `2e27` means the asset has doubled in claimable value. #### getReservesList / getReservesCount / getReserveAddressById * `getReservesList()` returns the list of underlying-asset addresses, **excluding dropped reserves**. * `getReservesCount()` returns the total number of historically-initialised reserves, **including dropped ones**. * `getReserveAddressById(uint16 id)` returns the underlying for a given reserve id. #### EMode views * `getEModeCategoryData(uint8 id)` — returns the category's `ltv`, `liquidationThreshold`, `liquidationBonus`, `priceSource`, and `label`. * `getUserEMode(address user)` — returns the user's current category (`0` means no e-mode). #### Constants and immutables | Function | Returns | Source | | --------------------------------------- | ------------------------ | ------------------------------------------ | | `ADDRESSES_PROVIDER()` | `IPoolAddressesProvider` | Immutable, set in constructor. | | `MAX_STABLE_RATE_BORROW_SIZE_PERCENT()` | `0.25e4` (25%) | Storage, set in `initialize`. | | `BRIDGE_PROTOCOL_FEE()` | bps | Storage, set by `PoolConfigurator`. | | `FLASHLOAN_PREMIUM_TOTAL()` | bps | Storage, set by `PoolConfigurator`. | | `FLASHLOAN_PREMIUM_TO_PROTOCOL()` | bps | Storage, set by `PoolConfigurator`. | | `MAX_NUMBER_RESERVES()` | `128` | `ReserveConfiguration.MAX_RESERVES_COUNT`. | | `POOL_REVISION()` | `0x1` | Constant. | ### Events `Supply`, `Withdraw`, `Borrow`, `Repay`, `SwapBorrowRateMode`, `RebalanceStableBorrowRate`, `ReserveUsedAsCollateralEnabled`, `ReserveUsedAsCollateralDisabled`, `LiquidationCall`, `FlashLoan`, `MintUnbacked`, `BackUnbacked`, `IsolationModeTotalDebtUpdated`, `UserEModeSet`, `ReserveDataUpdated`, `MintedToTreasury`. See the `IPool` interface for full signatures. ### Error codes See [Troubleshooting errors](/dev/sparklend/features/troubleshooting-errors) for the full numeric-to-name mapping. Error `91 FLASHLOAN_DISABLED`, returned by `validateFlashloanSimple` when a reserve has its `flashLoanEnabled` flag set to `false`, exists in upstream Aave v3.0.2. The SparkLend-specific deviation is the `FLASHLOAN_INTO_BORROW_DEPRECATED` string revert in `FlashLoanLogic`, thrown when a flash loan attempts to open a borrow position (i.e. `interestRateMode` is not `none`). ![SparkLend Pool interaction map: users, BRIDGE\_ROLE holders, and the PoolConfigurator all call into Pool, which delegatecalls the logic libraries, drives the AToken / VariableDebtToken / StableDebtToken contracts, and reads AaveOracle and the PriceOracleSentinel](/assets/diagrams/sparklend-pool-interactions.svg) ## PoolAddressesProvider * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/PoolAddressesProvider.sol) ### Overview The PoolAddressesProvider is a central registry contract that serves as the single source of truth for all protocol contract addresses and configurations. It plays several critical roles in the SparkLend Protocol: 1. **Address Registry** * Maintains a mapping of all protocol contract addresses * Stores addresses for core components like Pool, PoolConfigurator, Price Oracle, and ACL Manager * Provides a standardized way to fetch contract addresses across the protocol 2. **Proxy Factory & Admin** * Acts as a factory for creating proxy contracts * Manages proxy implementations for upgradeable contracts * Handles proxy upgrades through implementation updates * Initializes new proxy contracts with their implementations 3. **Market Configuration** * Stores the market identifier for the protocol * Manages market-specific configurations * Allows for market parameter updates through governance 4. **Access Control** * Owned by Sky Governance on Ethereum mainnet * On other networks, owned by either Crosschain Governance Bridges or Community Multisigs * Controls who can update protocol addresses and configurations The contract is designed to be immutable (except for the owner) and serves as the foundation for the protocol's upgradeability and configuration management. It's the recommended way to fetch any protocol contract address, ensuring that integrations always use the latest deployed versions. This contract inherits from OpenZeppelin's `Ownable` and implements `IPoolAddressesProvider`. It acts as a factory of proxies and admin of those, with the right to change their implementations. :::info Whenever the `Pool` contract is needed, we recommended you fetch the correct address from the `PoolAddressesProvider` smart contract. ::: #### Constructor ```solidity constructor(string memory marketId, address owner) ``` Initializes the PoolAddressesProvider with: * `marketId`: The identifier of the market * `owner`: The address that will own the contract #### Contract Identifiers The contract uses the following constant identifiers to store addresses: * `POOL`: The main Pool contract * `POOL_CONFIGURATOR`: The PoolConfigurator contract * `PRICE_ORACLE`: The Price Oracle contract * `ACL_MANAGER`: The ACL Manager contract * `ACL_ADMIN`: The ACL Admin address * `PRICE_ORACLE_SENTINEL`: The Price Oracle Sentinel contract * `DATA_PROVIDER`: The Pool Data Provider contract #### Events The contract emits the following events: * `AddressSet(bytes32 indexed id, address indexed oldAddress, address indexed newAddress)`: Emitted when an address is set * `AddressSetAsProxy(bytes32 indexed id, address indexed proxyAddress, address indexed oldImplementationAddress, address newImplementationAddress)`: Emitted when a proxy implementation is updated * `PoolUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Pool implementation is updated * `PoolConfiguratorUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the PoolConfigurator implementation is updated * `PriceOracleUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Price Oracle is updated * `ACLManagerUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the ACL Manager is updated * `ACLAdminUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the ACL Admin is updated * `PriceOracleSentinelUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Price Oracle Sentinel is updated * `PoolDataProviderUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Pool Data Provider is updated * `MarketIdSet(string indexed oldMarketId, string indexed newMarketId)`: Emitted when the market ID is updated * `ProxyCreated(bytes32 indexed id, address indexed proxyAddress, address indexed implementationAddress)`: Emitted when a new proxy is created ### View Methods #### getMarketId `function getMarketId() external view override returns (string memory)` Fetch the market id of the associated Spark market. Return Values | Type | Description | | ------ | ------------------------------------- | | string | A string representation of the market | #### getAddress `function getAddress(bytes32 id) public view override returns (address)` Fetch the address of protocol contract stored at given id. Call Params | Name | Type | Description | | ---- | ------- | ---------------------------------------------------------------------------------- | | id | bytes32 | id. Example, the Pool Data Provider is registered under `bytes32('DATA_PROVIDER')` | Return Values | Type | Description | | ------- | ------------------------------------------------- | | address | The address associated with the bytes32 id passed | ```tsx // Get address of incentive controller import { utils } from 'ethers/lib/utils'; const id = utils.keccak256(utils.toUtf8Bytes("INCENTIVES_CONTROLLER")); const address = poolAddressProvider.getAddress(id); ``` #### getPool `function getPool() external view override returns (address)` Fetch the contract of latest pool Return Values | Type | Description | | ------- | ---------------------------------- | | address | The address of the associated Pool | #### getPoolConfigurator `function getPoolConfigurator() external view override returns (address)` Fetches the `PoolConfigurator` address, which is used for market configuration methods such as initializing reserves or updating token implementations. Return Value | Type | Description | | ------- | --------------------------------------------------- | | address | The address of associated market's PoolConfigurator | #### getPriceOracle `function getPriceOracle() external view override returns (address)` Fetch Price Oracle used by the market. Return Value | Type | Description | | ------- | ---------------------------------------------------------- | | address | The address of the price oracle used by associated market. | #### getACLManager `function getACLManager() external view override returns (address)` Fetch ACLManager that manages the system role of the market Return Value | Type | Description | | ------- | ----------------------------------------------------------------------------------------- | | address | The address of the ACLManager contract managing the system role of the associated market. | #### getACLAdmin `function getACLAdmin() external view override returns (address)` Fetch ACLAdmin of the market which holds the `DEFAULT_ADMIN_ROLE` in ACLManager. Return Value | Type | Description | | ------- | ---------------------------------------------------------------------- | | address | The address of the access control list admin of the associated market. | #### getPriceOracleSentinel `function getPriceOracleSentinel() external view override returns (address)` Return Value | Type | Description | | ------- | ------------------------------------------------------------------ | | address | The address of the Price oracle sentinel of the associated market. | #### getPoolDataProvider `function getPoolDataProvider() external view override returns (address)` Fetch address of latest pool data provider. Return Value | Type | Description | | ------- | --------------------------------------------------------------- | | address | The address of the pool data provider of the associated market. | ### Write Methods #### setMarketId `function setMarketId(string memory newMarketId) external override onlyOwner` Updates the identifier of the Spark market Call Params | Name | Type | Description | | ----------- | -------- | ------------------------ | | newMarketId | `string` | The new id of the market | #### setAddress `function setAddress(bytes32 id, address newAddress) external override onlyOwner` Sets the address of protocol contract stored at given id. Eg. `utils.keccak256(utils.toUtf8Bytes("INCENTIVES_CONTROLLER"))` is set to address of `INCENTIVES_CONTROLLER` Call Params | Name | Type | Description | | ---------- | --------- | -------------------------------------------------------- | | id | `bytes32` | keccak256 hash of UTF8Bytes string representing Contract | | newAddress | `address` | The new address to be set corresponding to the `id` | #### setAddressAsProxy `function setAddressAsProxy(bytes32 id, address newImplementationAddress) external override onlyOwner` Sets/updates the implementation address of a specific proxied protocol contract. If there is no proxy registered with the given identifier, it creates a new proxy with `newImplementationAddress` as implementation and calls its `initialize()` function. If a proxy already exists, it updates the implementation and calls `initialize()` via `upgradeToAndCall()`. :::info This function creates a new `InitializableImmutableAdminUpgradeabilityProxy` if one doesn't exist for the given id. ::: Call Params | Name | Type | Description | | ------------------------ | --------- | --------------------------------------------------------------------- | | id | `bytes32` | id of Proxy contract | | newImplementationAddress | `address` | The address of new implementation contract corresponding to the proxy | #### setPoolImpl `function setPoolImpl(address newPoolImpl) external override onlyOwner` Sets/update the implementation of the POOL proxy contract. Call Params | Name | Type | Description | | ----------- | --------- | ----------------------------------------------- | | newPoolImpl | `address` | The address of new Pool implementation contract | #### setPoolConfiguratorImpl `function setPoolConfiguratorImpl(address newPoolConfiguratorImpl) external override onlyOwner` Sets/updates the implementation of the POOL\_CONFIGURATOR proxy contract. Call Params | Name | Type | Description | | ----------------------- | --------- | ----------------------------------------------------------- | | newPoolConfiguratorImpl | `address` | The address of new PoolConfigurator implementation contract | #### setPriceOracle `function setPriceOracle(address newPriceOracle) external override onlyOwner` Sets/updates address of the PriceOracle contract. Call Params | Name | Type | Description | | -------------- | --------- | --------------------------------------- | | newPriceOracle | `address` | The address of new PriceOracle contract | #### setACLAdmin `function setACLAdmin(address newAclAdmin) external override onlyOwner` Sets/updates address of the AclAdmin. Call Params | Name | Type | Description | | ----------- | --------- | ---------------------------- | | newAclAdmin | `address` | The address of new ACL admin | #### setPriceOracleSentinel `function setPriceOracleSentinel(address newPriceOracleSentinel) external override onlyOwner` Sets/updates address of the Price oracle sentinel. Call Params | Name | Type | Description | | ---------------------- | --------- | -------------------------------------- | | newPriceOracleSentinel | `address` | The address of new PriceOracleSentinel | #### setPoolDataProvider `function setPoolDataProvider(address newDataProvider) external override onlyOwner` Sets/updates address of PoolDataProvider. Call Params | Name | Type | Description | | --------------- | --------- | ----------------------------------- | | newDataProvider | `address` | The address of new PoolDataProvider | ## PoolAddressesProviderRegistry * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/PoolAddressesProviderRegistry.sol) A registry of all `PoolAddressesProvider` instances (one per SparkLend market). Each provider is assigned a non-zero `id`; the registry maps both directions (`provider → id` and `id → provider`). The registry is `Ownable`. Only the owner (Sky Governance on mainnet) can register or unregister providers. ### View methods #### getAddressesProvidersList ```solidity function getAddressesProvidersList() external view returns (address[] memory) ``` Returns the array of currently-registered `PoolAddressesProvider` addresses. Order is not stable (unregistration uses swap-and-pop). #### getAddressesProviderIdByAddress ```solidity function getAddressesProviderIdByAddress(address addressesProvider) external view returns (uint256) ``` Returns the `id` registered for a provider, or `0` if not registered. #### getAddressesProviderAddressById ```solidity function getAddressesProviderAddressById(uint256 id) external view returns (address) ``` Returns the provider registered at `id`, or `address(0)` if none. ### Write methods (owner only) #### registerAddressesProvider ```solidity function registerAddressesProvider(address provider, uint256 id) external onlyOwner ``` Registers `provider` under `id`. Reverts on `id == 0`, on `id` already taken, or on `provider` already registered. Emits `AddressesProviderRegistered`. #### unregisterAddressesProvider ```solidity function unregisterAddressesProvider(address provider) external onlyOwner ``` Removes `provider` from the registry. Reverts if it was never registered. Emits `AddressesProviderUnregistered`. ## PoolConfigurator * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/pool/PoolConfigurator.sol) ### Overview `PoolConfigurator` is the privileged admin surface for `Pool`. It is the only contract authorised to call configuration-mutating functions on `Pool` (via the `onlyPoolConfigurator` modifier). End users never call it directly; governance and risk managers do. Like `Pool`, `PoolConfigurator` is upgradeable through the `PoolAddressesProvider`. ### Access control Method-level role checks are enforced by the following modifiers (`PoolConfigurator.sol`): | Modifier | Roles permitted | | ------------------------------ | ----------------------------------------------- | | `onlyPoolAdmin` | `POOL_ADMIN_ROLE` | | `onlyEmergencyAdmin` | `EMERGENCY_ADMIN_ROLE` | | `onlyEmergencyOrPoolAdmin` | `EMERGENCY_ADMIN_ROLE` or `POOL_ADMIN_ROLE` | | `onlyAssetListingOrPoolAdmins` | `ASSET_LISTING_ADMIN_ROLE` or `POOL_ADMIN_ROLE` | | `onlyRiskOrPoolAdmins` | `RISK_ADMIN_ROLE` or `POOL_ADMIN_ROLE` | Role constants are defined on `ACLManager` as keccak256 hashes of their seed strings (e.g. `POOL_ADMIN_ROLE = keccak256('POOL_ADMIN')`). ### Reserve listing and lifecycle #### initReserves — `onlyAssetListingOrPoolAdmins` ```solidity function initReserves(ConfiguratorInputTypes.InitReserveInput[] calldata input) external ``` Creates new reserves. For each input the configurator: 1. Deploys proxies for the AToken, StableDebtToken, and VariableDebtToken backed by the provided implementations. 2. Calls `IInitializableAToken.initialize` and `IInitializableDebtToken.initialize` on each proxy. 3. Calls `Pool.initReserve` with the three new token addresses and the interest-rate strategy. 4. Sets the reserve to `active = true`, `paused = false`, `frozen = false`, with the supplied `underlyingAssetDecimals`. Emits `ReserveInitialized`. #### dropReserve — `onlyPoolAdmin` ```solidity function dropReserve(address asset) external ``` Removes a reserve from the active list. Requires zero AToken supply, zero stable debt, zero variable debt, and zero `accruedToTreasury` on the reserve. #### updateAToken / updateStableDebtToken / updateVariableDebtToken — `onlyPoolAdmin` ```solidity function updateAToken(ConfiguratorInputTypes.UpdateATokenInput calldata input) external function updateStableDebtToken(ConfiguratorInputTypes.UpdateDebtTokenInput calldata input) external function updateVariableDebtToken(ConfiguratorInputTypes.UpdateDebtTokenInput calldata input) external ``` Upgrade the implementation behind each token proxy and re-initialise it with the supplied metadata (name, symbol, incentives controller, params). ### Reserve risk parameters — `onlyRiskOrPoolAdmins` | Function | Effect | | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `setReserveBorrowing(asset, enabled)` | Toggle bit 58 (borrowing enabled). Disabling requires stable-rate borrowing to already be off for the reserve. | | `setReserveStableRateBorrowing(asset, enabled)` | Toggle bit 59. Enabling requires variable borrowing to already be enabled. | | `setReserveFlashLoaning(asset, enabled)` | Toggle bit 63 (flash-loan enabled). | | `configureReserveAsCollateral(asset, ltv, liquidationThreshold, liquidationBonus)` | Set LTV/LT/LB together. Enforces `ltv ≤ liquidationThreshold`, `liquidationBonus > 1e4`, and `liquidationThreshold.percentMul(liquidationBonus) <= 100.00%`. Setting `liquidationThreshold = 0` (disable as collateral) additionally requires `ltv == 0`, `liquidationBonus == 0`, and zero AToken supply. | | `setReserveFactor(asset, newReserveFactor)` | Set the share of borrower interest accruing to treasury. Capped at `1e4` (100%). | | `setReserveFreeze(asset, freeze)` | Bit 57. Frozen reserves block supply and borrow but still allow repay, withdraw, and liquidation. | | `setBorrowCap(asset, newBorrowCap)` | Cap on total borrow in whole tokens (`0` = no cap). | | `setSupplyCap(asset, newSupplyCap)` | Cap on total supply in whole tokens (`0` = no cap). | | `setLiquidationProtocolFee(asset, newFee)` | Share of the liquidation bonus routed to treasury. Capped at `1e4`. | | `setBorrowableInIsolation(asset, borrowable)` | Bit 61. Determines whether the asset can be borrowed by isolation-mode users. | | `setDebtCeiling(asset, newDebtCeiling)` | Isolation-mode debt cap in 2-decimal USD. Setting from `0` to non-zero requires zero AToken supply. Setting to `0` calls `Pool.resetIsolationModeTotalDebt(asset)`. | | `setSiloedBorrowing(asset, newSiloed)` | Bit 62. Setting to `true` requires zero total debt on the reserve. | | `setUnbackedMintCap(asset, newUnbackedMintCap)` | Cap on bridge-minted unbacked AToken supply (whole tokens; `0` disables minting). | | `setReserveInterestRateStrategyAddress(asset, newRateStrategyAddress)` | Swap the asset's interest-rate strategy. | | `setEModeCategory(categoryId, ltv, liquidationThreshold, liquidationBonus, oracle, label)` | Create or update an e-mode category (`categoryId != 0`). Enforces the same math constraints as `configureReserveAsCollateral` and additionally requires any reserves already in the category to keep `ltv` and `liquidationThreshold` no higher than the new category values. | | `setAssetEModeCategory(asset, newCategoryId)` | Bind a reserve to an e-mode category. Requires the category's `liquidationThreshold` to exceed the reserve's individual `liquidationThreshold`. | ### Emergency controls #### setReservePause — `onlyEmergencyOrPoolAdmin` ```solidity function setReservePause(address asset, bool paused) public ``` Toggle bit 60. Pausing blocks supply, withdraw, borrow, repay, liquidation, transfer, and rate-mode swap on that reserve. #### setPoolPause — `onlyEmergencyAdmin` ```solidity function setPoolPause(bool paused) external ``` Convenience that iterates `Pool.getReservesList()` and calls `setReservePause` on each. #### setReserveActive — `onlyPoolAdmin` ```solidity function setReserveActive(address asset, bool active) external ``` Toggle bit 56. Deactivating requires zero AToken supply and zero `accruedToTreasury`. ### Premiums and bridge fee — `onlyPoolAdmin` * `updateFlashloanPremiumTotal(newFlashloanPremiumTotal)` — total fee in bps, capped at `1e4`. * `updateFlashloanPremiumToProtocol(newFlashloanPremiumToProtocol)` — protocol's share of the total premium, in bps. * `updateBridgeProtocolFee(newBridgeProtocolFee)` — bps fee on `backUnbacked`, capped at `1e4`. ### Events `ReserveInitialized`, `ReserveDropped`, `ReserveBorrowing`, `ReserveStableRateBorrowing`, `ReserveFlashLoaning`, `ReserveActive`, `ReserveFrozen`, `ReservePaused`, `BorrowableInIsolationChanged`, `CollateralConfigurationChanged`, `ReserveFactorChanged`, `DebtCeilingChanged`, `SiloedBorrowingChanged`, `BorrowCapChanged`, `SupplyCapChanged`, `LiquidationProtocolFeeChanged`, `UnbackedMintCapChanged`, `EModeCategoryAdded`, `EModeAssetCategoryChanged`, `ReserveInterestRateStrategyChanged`, `BridgeProtocolFeeUpdated`, `FlashloanPremiumTotalUpdated`, `FlashloanPremiumToProtocolUpdated`, `ATokenUpgraded`, `StableDebtTokenUpgraded`, `VariableDebtTokenUpgraded`. ## PriceOracleSentinel * [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/PriceOracleSentinel.sol) This contract validates if the operations are allowed depending on the PriceOracle health. The `PriceOracle` is considered healthy once it's completely up and the grace period has passed. :::info The sentinel is intended for L2 deployments where a sequencer can stall and oracles can desync. On the Ethereum mainnet SparkLend deployment, `PoolAddressesProvider.getPriceOracleSentinel()` is `address(0)`, so `validateBorrow` and `validateLiquidationCall` skip the sentinel checks entirely (`contracts/protocol/libraries/logic/ValidationLogic.sol`). ::: ### View Methods #### isBorrowAllowed `function isBorrowAllowed()` Return Value | Type | Description | | ---- | ------------------------------------------------------------- | | bool | Returns true if PriceOracle is up and grace period has passed | #### isLiquidationAllowed `function isLiquidationAllowed()` Return Value | Type | Description | | ---- | ------------------------------------------------------------- | | bool | Returns true if PriceOracle is up and grace period has passed | #### getSequencerOracle `function getSequencerOracle()` Return Value | Type | Description | | ------- | ------------------------------- | | address | Address of the SequencerOracle. | #### getGracePeriod `function getGracePeriod()` Return Value | Type | Description | | ------- | -------------------------------------------- | | uint256 | The duration of the grace period in seconds. | #### ADDRESSES\_PROVIDER `function ADDRESSES_PROVIDER()` Returns the `IPoolAddressesProvider` this sentinel was constructed against. ### Write Methods #### setSequencerOracle `function setSequencerOracle(address newSequencerOracle)` :::warning Can be called only by PoolAdmin. ::: Call Params | Name | Type | Description | | ------------------ | ------- | --------------------------------------------- | | newSequencerOracle | address | address of the new SequencerOracle to be set. | #### setGracePeriod `function setGracePeriod(uint256 newGracePeriod)` :::warning Can be called only by PoolAdmin or RiskAdmin. ::: Call Params | Name | Type | Description | | -------------- | ------- | ---------------------------------------- | | newGracePeriod | uint256 | duration of new grace period in seconds. | ## Spark ALM Controller **Source code:** [sparkdotfi/spark-alm-controller](https://github.com/sparkdotfi/spark-alm-controller) ### Overview The Spark ALM Controller is the onchain execution layer of the Spark Liquidity Layer. It is a small set of contracts that: * Hold custody of all SLL capital in a single proxy (`ALMProxy`). * Route every action through a controller (`MainnetController` on Ethereum, `ForeignController` on each supported L2). * Enforce per-integration whitelists and exposure caps via a stateful `RateLimits` contract keyed by `keccak256` identifiers. * Provide an emergency revocation path via the `FREEZER` role that does not require a governance vote. The same controller pattern is also used in two narrower contexts: * `ALMProxyFreezable`, a variant of the proxy used where the relayers themselves are granted the proxy's `CONTROLLER` role directly. This is intended for lower-criticality state where governance accepts a wider attack surface in exchange for operational simplicity, and where the `FREEZER` quick-revoke path is still preserved. * `OTCBuffer` and `WEETHModule`, two purpose-built helper contracts described in their own sections below. ### Architecture Every transaction originates from an offchain `RELAYER`, lands on the controller, is rate-limited and parameter-checked, and is then executed by the proxy that actually holds the funds. The controller calls `triggerRateLimitDecrease` / `triggerRateLimitIncrease` on `RateLimits`, and `doCall` / `doCallWithValue` / `doDelegateCall` on the `ALMProxy`, which performs the approved interaction with the external venue (Sky / PSM / AAVE / Morpho / Curve / Uniswap V4 / OTC / …). ![Spark ALM Controller call flow: relayer to controller to proxy to external venue, with rate-limit checks](/assets/diagrams/alm-call-flow.svg) When minting USDS via the Sky allocation system, funds are never held by the controller — they are pulled into the proxy and stay there until a subsequent relayer action moves them. The controller decrements `LIMIT_USDS_MINT`, instructs the proxy to `draw` from the Sky allocator vault (minting USDS to the allocator buffer), and then transfers that USDS from the buffer into the proxy. ![USDS mint sequence: relayer calls mintUSDS, rate limit decreases, proxy draws from the Sky allocator vault and pulls USDS from the buffer](/assets/diagrams/alm-usds-mint.svg) ### Core contracts #### ALMProxy `src/ALMProxy.sol`. Holds custody of all SLL capital. Stateless except for OpenZeppelin `AccessControl`. Only addresses with the `CONTROLLER` role can invoke `doCall`, `doCallWithValue`, or `doDelegateCall`. New controllers can be onboarded by governance without migrating funds. #### MainnetController and ForeignController Stateful entry points for the `RELAYER` role. Each controller: * Checks the relayer's role, decrements (or increments) the relevant rate limit, validates parameters, and asks the proxy to execute the underlying call. * Holds per-integration configuration: `maxSlippages` per pool/exchange, ERC-4626 `maxExchangeRate` thresholds, Uniswap V4 tick limits, CCTP `mintRecipients` per destination domain, LayerZero `layerZeroRecipients` per destination endpoint, OTC buffer registrations, and Ethena `delegatedSigner` state. #### RateLimits `src/RateLimits.sol`. Stores all rate-limit data, keyed by `bytes32`. Each key resolves to a struct: | Field | Description | | ------------- | ---------------------------------------------------------- | | `maxAmount` | Absolute ceiling. The current limit can never exceed this. | | `slope` | Tokens per second of regeneration. | | `lastAmount` | Amount available at `lastUpdated`. | | `lastUpdated` | Block timestamp of the last update. | The current limit is: ``` currentRateLimit = min(slope * (block.timestamp - lastUpdated) + lastAmount, maxAmount) ``` A `maxAmount` of `type(uint256).max` flags an unlimited key (used for actions where the rate limit acts only as a whitelist gate, e.g., approval-only operations). A `maxAmount` of `0` means the key is not configured — any call that would consume it reverts. Only the `CONTROLLER` role on `RateLimits` (held by the active controller contract) may call `triggerRateLimitDecrease` or `triggerRateLimitIncrease`; only `DEFAULT_ADMIN_ROLE` may set new values directly. #### ALMProxyFreezable `src/ALMProxyFreezable.sol`. A 23-line subclass of `ALMProxy` used in narrower contexts. Two architectural differences from the canonical proxy: * In this deployment pattern, the `CONTROLLER` role is intended to be granted directly to relayers rather than to a `MainnetController` / `ForeignController` contract (design intent documented in `docs/ARCHITECTURE.md` — the contract itself does not restrict who receives the role; the standard deploy path grants it to the controller contract). The relayer's calldata is the call. * A `FREEZER` role is introduced. `removeController(address)` revokes the `CONTROLLER` role from a compromised relayer without a governance proposal. This variant trades the parameter-validation layer of a full controller for operational simplicity, and is appropriate where the funds at risk or the action surface are constrained. #### OTCBuffer `src/OTCBuffer.sol`. UUPS-upgradeable buffer contract used to bound exposure to a single OTC counterparty. One `OTCBuffer` is deployed per whitelisted exchange. Its only state-changing method is the admin-callable `approve(asset, allowance)`, which governance uses after deployment to grant the `ALMProxy` an infinite allowance over each whitelisted asset. The OTC swap lifecycle (driven from `MainnetController`): 1. `otcSend(exchange, asset, amount)` — moves `amount` of `asset` from the proxy to the exchange's offchain address, after checking `LIMIT_OTC_SWAP` (keyed by exchange) and confirming any prior swap is `isOtcSwapReady`. 2. The counterparty deposits the returned asset into the corresponding `OTCBuffer`. 3. `otcClaim(exchange, asset)` — pulls the entire `OTCBuffer` balance of `asset` back into the proxy. 4. `isOtcSwapReady(exchange)` returns true once `claimed + rechargeRate · elapsed ≥ sent · maxSlippage`, allowing the next send. The infinite allowance is intentional: `otcClaim` always transfers the full balance, and a finite allowance would let an attacker donate a small amount to push the balance past the allowance and brick claims. #### WEETHModule `src/WEETHModule.sol`. UUPS-upgradeable helper that exists because EtherFi's withdrawal flow mints an NFT rather than returning ETH synchronously, and the proxy cannot safely hold or process NFTs. * `requestWithdrawFromWeETH` on the controller routes the unwrap → `LiquidityPool.requestWithdraw` call so that the resulting `WithdrawRequestNFT` is minted to the `WEETHModule`. * `claimWithdrawal(requestId)` on the module — only callable by its configured `almProxy` — verifies the request is valid and finalized, claims it, wraps received ETH into WETH, and transfers WETH back to the proxy. * The module never holds ETH or WETH outside the single claim transaction, and never holds NFTs except between request and claim. ### Permissions All contracts inherit OpenZeppelin `AccessControl`. The roles are: | Role | Where it lives | What it can do | | -------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | All contracts | Grants and revokes roles. Sets rate-limit data on `RateLimits`. Sets per-integration parameters (`maxSlippages`, `maxExchangeRates`, `mintRecipients`, `layerZeroRecipients`, OTC config, Uniswap V4 tick limits). Authorizes UUPS upgrades on `OTCBuffer` and `WEETHModule`. Held by Sky governance. | | `RELAYER` | Controllers | Calls every action function on `MainnetController` and `ForeignController`. Assumed to be compromisable; logic must keep value inside the system and bound losses with rate limits and slippage. | | `FREEZER` | Controllers + `ALMProxyFreezable` | On controllers, calls `removeRelayer(address)` to revoke the `RELAYER` role from a single address. On `ALMProxyFreezable`, calls `removeController(address)` to detach a compromised relayer from the proxy. There is no global "freeze every action" function. | | `CONTROLLER` | `ALMProxy`, `ALMProxyFreezable`, `RateLimits` | On the proxy, the only role that can invoke `doCall` / `doCallWithValue` / `doDelegateCall`. On `RateLimits`, the only role that can call `triggerRateLimitDecrease` / `triggerRateLimitIncrease`. Held by the active controller contract (or, in the freezable variant, by relayers directly). | ![Role topology: Sky Governance holds DEFAULT\_ADMIN\_ROLE, which grants RELAYER, FREEZER and CONTROLLER; relayer drives the controller, freezer revokes, controller acts on proxy and rate limits](/assets/diagrams/alm-role-topology.svg) ### Controller action surface All functions below run with `nonReentrant` and require the `RELAYER` role. Each action consumes (or restores) the rate-limit key shown. Keys with an "→ address" suffix are combined with an asset, pool, vault, exchange, or destination via `RateLimitHelpers` before lookup; the underlying base key must also exist for the call to succeed. #### MainnetController (`src/MainnetController.sol`) | Family | Functions | Primary rate-limit key | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | USDS allocation | `mintUSDS`, `burnUSDS` | `LIMIT_USDS_MINT` (decreased on mint, restored on burn) | | DAI ↔ USDS | `swapUSDSToDAI`, `swapDAIToUSDS` | none — 1:1 conversion via the Sky `DaiUsds` migrator, not rate-limited | | Mainnet PSM | `swapUSDSToUSDC`, `swapUSDCToUSDS` | `LIMIT_USDS_TO_USDC` (decreased on out, restored on in) | | Generic transfer | `transferAsset` | `LIMIT_ASSET_TRANSFER` → (asset, destination) | | ERC-4626 | `depositERC4626`, `withdrawERC4626`, `redeemERC4626` | `LIMIT_4626_DEPOSIT` / `LIMIT_4626_WITHDRAW`, both → token. Deposits also gated by per-token `maxExchangeRate`. | | AAVE / SparkLend | `depositAave`, `withdrawAave` | `LIMIT_AAVE_DEPOSIT` / `LIMIT_AAVE_WITHDRAW`, both → aToken. Deposit also gated by per-aToken `maxSlippage`. | | Curve stableswap | `swapCurve`, `addLiquidityCurve`, `removeLiquidityCurve` | `LIMIT_CURVE_SWAP` / `LIMIT_CURVE_DEPOSIT` / `LIMIT_CURVE_WITHDRAW`, all → pool. Requires non-zero `maxSlippage[pool]`. | | Uniswap V4 | `swapUniswapV4`, `mintPositionUniswapV4`, `increaseLiquidityUniswapV4`, `decreaseLiquidityUniswapV4` | `LIMIT_UNISWAP_V4_SWAP` / `LIMIT_UNISWAP_V4_DEPOSIT` / `LIMIT_UNISWAP_V4_WITHDRAW`, all → poolId. Tick range and tick spacing must be within `uniswapV4TickLimits[poolId]`. Pools must be hookless. | | Lido wstETH | `depositToWstETH`, `requestWithdrawFromWstETH`, `claimWithdrawalFromWstETH` | `LIMIT_WSTETH_DEPOSIT`, `LIMIT_WSTETH_REQUEST_WITHDRAW` | | EtherFi weETH | `depositToWeETH`, `requestWithdrawFromWeETH`, `claimWithdrawalFromWeETH` | `LIMIT_WEETH_DEPOSIT`, `LIMIT_WEETH_REQUEST_WITHDRAW` → weETHModule. Claim requires the request key to exist. | | Ethena | `setDelegatedSigner`, `removeDelegatedSigner`, `prepareUSDeMint`, `prepareUSDeBurn`, `cooldownAssetsSUSDe`, `cooldownSharesSUSDe`, `unstakeSUSDe` | `LIMIT_USDE_MINT`, `LIMIT_USDE_BURN`, `LIMIT_SUSDE_COOLDOWN` | | Maple | `requestMapleRedemption`, `cancelMapleRedemption` | `LIMIT_MAPLE_REDEEM` → mapleToken | | Superstate | `subscribeSuperstate` | `LIMIT_SUPERSTATE_SUBSCRIBE` | | SPK farms | `depositToFarm`, `withdrawFromFarm` | `LIMIT_FARM_DEPOSIT` / `LIMIT_FARM_WITHDRAW`, both → farm | | Spark Vault | `takeFromSparkVault` | `LIMIT_SPARK_VAULT_TAKE` → sparkVault | | OTC swap | `otcSend`, `otcClaim` | `LIMIT_OTC_SWAP` → exchange. Asset must be in `otcWhitelistedAssets[exchange]`. | | CCTP bridging | `transferUSDCToCCTP` | `LIMIT_USDC_TO_CCTP` and `LIMIT_USDC_TO_DOMAIN` → destinationDomain | | LayerZero OFT bridging | `transferTokenLayerZero` | `LIMIT_LAYERZERO_TRANSFER` → (oftAddress, destinationEndpointId). Source comment notes the integration ships with the rate limit set to zero pending integration testing. | | ETH recovery | `wrapAllProxyETH` | (no rate limit; wraps any proxy ETH into WETH) | #### ForeignController (`src/ForeignController.sol`) | Family | Functions | Primary rate-limit key | | ---------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | PSM3 | `depositPSM`, `withdrawPSM` | `LIMIT_PSM_DEPOSIT` / `LIMIT_PSM_WITHDRAW`, both → asset. Both decrease (no cancellation; PSM3 is immutable and 1:1). | | Generic transfer | `transferAsset` | `LIMIT_ASSET_TRANSFER` → (asset, destination) | | ERC-4626 | `depositERC4626`, `withdrawERC4626`, `redeemERC4626` | `LIMIT_4626_DEPOSIT` / `LIMIT_4626_WITHDRAW`, both → token. Deposit gated by per-token `maxExchangeRate`. | | AAVE | `depositAave`, `withdrawAave` | `LIMIT_AAVE_DEPOSIT` / `LIMIT_AAVE_WITHDRAW`, both → aToken. Deposit gated by per-aToken `maxSlippage`. | | Spark Vault | `takeFromSparkVault` | `LIMIT_SPARK_VAULT_TAKE` → sparkVault | | CCTP bridging | `transferUSDCToCCTP` | `LIMIT_USDC_TO_CCTP` and `LIMIT_USDC_TO_DOMAIN` → destinationDomain. Splits across multiple CCTP burns when `usdcAmount` exceeds the per-message burn limit. | | LayerZero OFT bridging | `transferTokenLayerZero` | `LIMIT_LAYERZERO_TRANSFER` → (oftAddress, destinationEndpointId). Ships with rate limit set to zero pending integration testing. | ### Rate limit keys: full reference The `keccak256`-derived constants currently declared on each controller. Keys flagged "→ ..." are combined with their suffix via `RateLimitHelpers` (`makeAddressKey`, `makeAddressAddressKey`, `makeBytes32Key`, `makeUint32Key`) before storage lookup. #### Common to both controllers ``` LIMIT_4626_DEPOSIT → token LIMIT_4626_WITHDRAW → token LIMIT_AAVE_DEPOSIT → aToken LIMIT_AAVE_WITHDRAW → aToken LIMIT_ASSET_TRANSFER → (asset, destination) LIMIT_LAYERZERO_TRANSFER → (oftAddress, destinationEndpointId) LIMIT_SPARK_VAULT_TAKE → sparkVault LIMIT_USDC_TO_CCTP LIMIT_USDC_TO_DOMAIN → destinationDomain ``` #### MainnetController-only ``` LIMIT_CURVE_DEPOSIT → pool LIMIT_CURVE_SWAP → pool LIMIT_CURVE_WITHDRAW → pool LIMIT_FARM_DEPOSIT → farm LIMIT_FARM_WITHDRAW → farm LIMIT_MAPLE_REDEEM → mapleToken LIMIT_OTC_SWAP → exchange LIMIT_SUPERSTATE_SUBSCRIBE LIMIT_SUSDE_COOLDOWN LIMIT_UNISWAP_V4_DEPOSIT → poolId LIMIT_UNISWAP_V4_SWAP → poolId LIMIT_UNISWAP_V4_WITHDRAW → poolId LIMIT_USDE_BURN LIMIT_USDE_MINT LIMIT_USDS_MINT LIMIT_USDS_TO_USDC LIMIT_WEETH_DEPOSIT LIMIT_WEETH_REQUEST_WITHDRAW → weETHModule LIMIT_WSTETH_DEPOSIT LIMIT_WSTETH_REQUEST_WITHDRAW ``` #### ForeignController-only ``` LIMIT_PSM_DEPOSIT → asset LIMIT_PSM_WITHDRAW → asset ``` ### Trust assumptions | Role / actor | Assumption | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | Fully trusted. Held by Sky governance. | | `RELAYER` | Assumed compromisable. The controller must prevent value from leaving the system and must bound any loss to current rate-limit capacity and configured slippage. | | `FREEZER` | Trusted to revoke a compromised relayer (`removeRelayer` on controllers, `removeController` on the freezable proxy). Cannot perform allocation actions. | | Ethena | Trusted not to honor mint/burn requests with more than 50bps slippage from a delegated signer. Ethena's offchain order-validity checks are part of the trust assumption. A compromised relayer can technically set a delegated signer; Ethena's offchain validation is the second line of defense. | | EtherFi | Trusted to eventually finalize withdrawal requests. EtherFi admins can invalidate (and revalidate) withdrawal requests; an unfinalized request is a liveness issue, not a loss-of-funds issue. | | OTC desks | Trusted to complete a swap up to the per-exchange `LIMIT_OTC_SWAP` ceiling. Maximum loss per exchange is bounded by a single outstanding swap. | A compromised relayer can DOS Ethena unstaking; recovery is documented in `test/mainnet-fork/Attacks.t.sol`. ### Operational requirements These are conditions that must hold for each integration. They are not enforced by governance proposal review alone — most are also enforced in the contract. * **Token requirements.** ERC-20 tokens must be non-rebasing, have at least 6 decimals, and behave as standard ERC-20s. * **Rate-limit keys are the whitelist.** A venue with no governance-set `maxAmount` for its rate-limit key reverts on first interaction. Withdrawals require the matching deposit key to also exist (ERC-4626 and AAVE families). * **ERC-4626 seeding.** Vaults must have initial shares burned to an unrecoverable address before onboarding, to prevent first-deposit rounding attacks. The `maxExchangeRate` mechanism is the second line of defense against donation attacks. * **Curve and Uniswap V4 seeding.** Pools must be seeded with initial liquidity to an unrecoverable address (e.g., `address(1)`) before onboarding. * **Uniswap V4 restrictions.** Only 1:1 stablecoin pools may be onboarded. Pools must be hookless (the rate-limit decrease is computed from pre/post balances and empty `hookData` is passed; a hook could otherwise manipulate balances mid-call). Tick limits and `maxSlippage` must be configured before any action succeeds. * **OTC buffer deployment.** After deploying a new `OTCBuffer`, the admin must call `approve` to grant an infinite allowance (`type(uint256).max`) to the `ALMProxy` for each whitelisted asset. Without this, `otcClaim` can be bricked by a donation attack. * **Slippage required.** Curve, Uniswap V4, AAVE, and OTC operations require a non-zero `maxSlippage` for the target pool / aToken / exchange. ### Verifying the live configuration Live values change as governance onboards venues, raises ceilings, and rotates roles. The repository ships a Wake printer that enumerates which controller function consumes which rate-limit key and verifies the live configuration matches: ``` wake --config printers/wake.toml print rate-limits ``` A zero exit code indicates the spec is satisfied. For live contract addresses (proxy, controllers, rate-limits, OTC buffers, weETH module, per-network deployments) refer to the [Spark Address Registry](/dev/deployments). For role assignees and current per-key `maxAmount` / `slope` values, the `RateLimits.getRateLimitData(key)` and `getCurrentRateLimit(key)` view functions are authoritative. ### Audits Every released controller version has been audited. Cantina audited all versions from v1.0.0 through v1.10.0 (v1.2.0 never shipped as a final release); ChainSecurity audited v1.0.0–v1.7.0 and v1.10.0; Certora audited v1.8.0 and v1.9.0. Reports are linked from the [security and audits page](/dev/security/security-and-audits#spark-liquidity-layer) and live in [`audits/`](https://github.com/sparkdotfi/spark-alm-controller/tree/master/audits). ## Bug Bounty Program Spark has an active bug bounty program managed by Immunefi with bounty rewards of up to $5,000,000. Please submit any bugs or potential issues through the Immunefi platform. Learn more about the bug bounty program below: * [Immunefi SparkLend Bug Bounty Program](https://immunefi.com/bug-bounty/sparklend/information/) ## Security Audits ### SparkLend SparkLend is based on the Aave v3 codebase, including the 3.0.1 and 3.0.2 upgrades, which have been extensively audited. [You can find the audits of Aave v3 here.](https://aave.com/security) Notable code differences include: * The DAI market has a custom interest rate strategy due to its relation with Sky. * A custom oracle had to be made for the Savings DAI market. * The `RewardsController` was not set up through the `PoolAddressesProvider`. #### SparkLend Core Updates Spark-specific core audits covering changes made on top of the base Aave v3 codebase, including protocol-level core updates and related deployment changes. [Audits repository](https://github.com/sparkdotfi/sparklend-v1-core/tree/master/audits) #### SparkLend Advanced SparkLend Advanced covers additional infrastructure around the core market, including oracle and governance automation features used alongside SparkLend. [Audits repository](https://github.com/sparkdotfi/sparklend-advanced/tree/master/audits) #### SparkLend Cap Automator Cap Automator manages supply and borrow cap updates for SparkLend assets according to governance-set parameters, cooldowns, and limits. [Audits repository](https://github.com/sparkdotfi/sparklend-cap-automator/tree/master/audits) ### Spark Liquidity Layer #### Spark ALM Controller Spark ALM Controller is the onchain control layer of the Spark Liquidity Layer. It manages liquidity flows between Ethereum mainnet and L2s and integrates with the DSS Allocator and external protocols. [Audits repository](https://github.com/sparkdotfi/spark-alm-controller/tree/master/audits) ### Cross-chain Infrastructure #### XChain Helpers XChain Helpers is a library of cross-chain messaging helper contracts used between Ethereum mainnet and L2s, including forwarders and receivers for bridge-specific message passing. [Audits repository](https://github.com/sky-ecosystem/xchain-helpers/tree/master/audits) #### XChain SSR Oracle XChain SSR Oracle reports Sky Savings Rate values from Ethereum mainnet to supported chains so integrators can derive the current sUSDS to USDS conversion rate off-mainnet. [Audits repository](https://github.com/sky-ecosystem/xchain-ssr-oracle/tree/master/audits) ### Governance Infrastructure #### Spark Gov Relay Spark Gov Relay contains the infrastructure needed to process the cross-chain execution of governance proposals on bridged protocol instances. [Audits repository](https://github.com/sparkdotfi/spark-gov-relay/tree/master/audits) ### Savings #### Spark PSM Spark PSM is a Peg Stability Module for swapping, depositing, and withdrawing USDC, USDS, and sUSDS. It extends Sky PSM liquidity to supported non-mainnet domains. [Audits repository](https://github.com/sparkdotfi/spark-psm/tree/master/audits) #### Spark Vaults V2 Spark Vaults V2 is an ERC-4626 vault system that lets Spark savings vaults deploy idle liquidity into approved strategies while continuously accruing yield to depositors. [Audits repository](https://github.com/sparkdotfi/spark-vaults-v2/tree/dev/audits) #### Savings Vault Intents Savings Vault Intents is a large-withdrawal request system for Spark Vaults V2. It lets users create redemption intents that are fulfilled later by the Spark ALM Planner once vault liquidity has been prepared. [Audit repository](https://github.com/sparkdotfi/spark-savings-intents/tree/master/audits) #### Savings USDS (sUSDS) sUSDS is an ERC-4626 wrapper around USDS in the Sky Savings Rate module, allowing holders to earn the savings rate while keeping the token transferable and composable. [Audits repository](https://github.com/sky-ecosystem/sdai/tree/susds/audit) #### Savings DAI (sDAI) sDAI is an ERC-4626 wrapper around DAI in the Dai Savings Rate module, allowing depositors to earn the savings rate while retaining standard token utility. [Audits repository](https://github.com/sky-ecosystem/sdai/tree/master/audits) ### Lockstake #### Staked USDS (stUSDS) stUSDS is an ERC-4626 token that provides capital for SKY-backed borrowing through the Lockstake system and isolates that risk from standard savings products. [Audits repository](https://github.com/sky-ecosystem/stusds/tree/master/audit) ## Cross-chain Savings Rate Oracle ### Overview The Cross-chain SSR Oracle reports the Sky Savings Rate (SSR) values across various bridges. This is primarily used to provide integrators the sUSDS/USDS conversion rate (the value of 1 sUSDS in USDS) as sUSDS is an accumulating token that increases in value against USDS over time. This oracle is used by the [Spark PSM](/dev/savings/spark-psm), to enable swapping between USDS and sUSDS at the current conversion rate. Another example use case is decentralized exchanges leveraging the oracle to make liquidity management more capital efficient, by automatically moving sUSDS/USDS order book liquidity according to the conversion rate. The oracle provides three sUSDS values in sync: * `ssr`: The per second Sky Savings Rate (compounding rate) * `chi`: The rate accumulator * `rho`: The last time chi was updated These three values enables integrators to extrapolate an exact sUSDS/USDS conversion rate to any point in the future as long as the `ssr` value is not updated on Mainnet. Because this oracle does not need to be synced unless the `ssr` value changes, it uses canonical bridges for maximum security. The oracle provides convenience functions to fetch the conversion rate at various levels of precision trading off gas efficiency. The specific details are covered in the Functions section below. ### Deployments #### Base | Contract | Address | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | | AuthOracle | [0x65d946e533748A998B1f0E430803e39A6388f7a1](https://basescan.org/address/0x65d946e533748A998B1f0E430803e39A6388f7a1) | | Chainlink Rate Provider | [0x026a5B6114431d8F3eF2fA0E1B2EDdDccA9c540E](https://basescan.org/address/0x026a5B6114431d8F3eF2fA0E1B2EDdDccA9c540E) | | Balancer Rate Provider | [0x49aF4eE75Ae62C2229bb2486a59Aa1a999f050f0](https://basescan.org/address/0x49aF4eE75Ae62C2229bb2486a59Aa1a999f050f0) | | Forwarder (Ethereum) | [0xB2833392527f41262eB0E3C7b47AFbe030ef188E](https://etherscan.io/address/0xB2833392527f41262eB0E3C7b47AFbe030ef188E) | | Receiver (Base) | [0x212871A1C235892F86cAB30E937e18c94AEd8474](https://basescan.org/address/0x212871A1C235892F86cAB30E937e18c94AEd8474) | #### Arbitrum | Contract | Address | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | | AuthOracle | [0xEE2816c1E1eed14d444552654Ed3027abC033A36](https://arbiscan.io/address/0xEE2816c1E1eed14d444552654Ed3027abC033A36) | | Chainlink Rate Provider | [0x84AB0c8C158A1cD0d215BE2746cCa668B79cc287](https://arbiscan.io/address/0x84AB0c8C158A1cD0d215BE2746cCa668B79cc287) | | Balancer Rate Provider | [0xc0737f29b964e6fC8025F16B30f2eA4C2e2d6f22](https://arbiscan.io/address/0xc0737f29b964e6fC8025F16B30f2eA4C2e2d6f22) | | Forwarder (Ethereum) | [0x1A229AdbAC83A948226783F2A3257B52006247D5](https://etherscan.io/address/0x1A229AdbAC83A948226783F2A3257B52006247D5) | | Receiver (Arbitrum) | [0x567214Dc57a2385Abc4a756f523ddF0275305Cbc](https://arbiscan.io/address/0x567214Dc57a2385Abc4a756f523ddF0275305Cbc) | #### Optimism | Contract | Address | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | AuthOracle | [0x6E53585449142A5E6D5fC918AE6BEa341dC81C68](https://optimistic.etherscan.io/address/0x6E53585449142A5E6D5fC918AE6BEa341dC81C68) | | Chainlink Rate Provider | [0x8e3b08e65cC59d293932F5e9aF3186970087a529](https://optimistic.etherscan.io/address/0x8e3b08e65cC59d293932F5e9aF3186970087a529) | | Balancer Rate Provider | [0xe1e4953C93Da52b95eDD0ffd910565D3369aCd6b](https://optimistic.etherscan.io/address/0xe1e4953C93Da52b95eDD0ffd910565D3369aCd6b) | | Forwarder (Ethereum) | [0x6Ac25B8638767a3c27a65597A74792d599038724](https://etherscan.io/address/0x6Ac25B8638767a3c27a65597A74792d599038724) | | Receiver (Optimism) | [0xE2868095814c2714039b3A9eBEE035B9E2c411E5](https://optimistic.etherscan.io/address/0xE2868095814c2714039b3A9eBEE035B9E2c411E5) | #### Unichain | Contract | Address | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | | AuthOracle | [0x1566BFA55D95686a823751298533D42651183988](https://uniscan.xyz/address/0x1566BFA55D95686a823751298533D42651183988) | | Chainlink Rate Provider | [0x7ac96180C4d6b2A328D3a19ac059D0E7Fc3C6d41](https://uniscan.xyz/address/0x7ac96180C4d6b2A328D3a19ac059D0E7Fc3C6d41) | | Balancer Rate Provider | [0x93c81ADc7F98FdBC8C7a15eCBeD312c8F6adbcB3](https://uniscan.xyz/address/0x93c81ADc7F98FdBC8C7a15eCBeD312c8F6adbcB3) | | Forwarder (Ethereum) | [0x45d91340B3B7B96985A72b5c678F7D9e8D664b62](https://etherscan.io/address/0x45d91340B3B7B96985A72b5c678F7D9e8D664b62) | | Receiver (Unichain) | [0x4A71f81C6109230932978bAB7CA746f0be0C4580](https://uniscan.xyz/address/0x4A71f81C6109230932978bAB7CA746f0be0C4580) | Check the Spark Address Registry for the most up to date resource for contract deployments: * [Spark Address Registry](https://github.com/sparkdotfi/spark-address-registry) ### Contracts * Contract Source: [Github](https://github.com/sky-ecosystem/xchain-ssr-oracle/) #### SSROracleBase Contains common functionality shared between the Ethereum mainnet and cross-chain instances of the oracle. Contains convenience functions to fetch the conversion rate at various levels of precision trading off gas efficiency. sUSDS data is compressed into a single word to save SLOAD gas cost. #### SSRAuthOracle Ensures the oracle receives data from an authorized data provider. This is intended to be one or more bridges which publish data to the oracle. Application-level sanity checks are included when new data is proposed to minimize damage in the event of a bridge being compromised. These sanity checks also enforce event ordering in case messages are relayed out of order. `maxSSR` is used as an upper bound for sanity checks to prevent malicious data from being proposed. #### Rate Providers Rate Provider contracts take data from the AuthOracle and formats it for specific purposes and integrations. For example The Chainlink Rate Provider provides an up-to-date SSR conversion price in Chainlink format, enabling existing integrators of Chainlink oracles to easily consume this data. #### Forwarders & Receivers Forwarders and Receivers are bridge-specific messaging contracts. Forwarders permissionlessly relay `sUSDS` data. Receivers decode this message and forward it to the `SSRAuthOracle`. Please note that receivers are generic and part of the [`xchain-helpers` repository](https://github.com/sky-ecosystem/xchain-helpers). #### Functions ##### **Conversion Functions** * **`getConversionRate()`**: Returns the current exact conversion rate for sUSDS/USDS with maximum precision as a 27 decimal number. * **`getConversionRate(uint256 timestamp)`**: Returns the exact conversion rate for sUSDS/USDS for a specific `timestamp` as a 27 decimal number. Can be used to fetch future conversion rates. * **`getConversionRateBinomialApprox()`**: Returns a binomial approximation of the current conversion rate for sUSDS/USDS as a 27 decimal number. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number. * **`getConversionRateBinomialApprox(uint256 timestamp)`**: Returns a binomial approximation of the conversion rate for sUSDS/USDS for a specific `timestamp` in the future as a 27 decimal number. Can be used to approximate future conversion rates. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number. * **`getConversionRateLinearApprox()`**: Returns a linear approximation of the current conversion rate for sUSDS/USDS as a 27 decimal number. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number. * **`getConversionRateLinearApprox(uint256 timestamp)`**: Returns a linear approximation of the conversion rate for sUSDS/USDS for a specific `timestamp` in the future as a 27 decimal number. Can be used to approximate future conversion rates. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number. ### Gotchas / Integration Concerns #### Future Conversions Using the conversion functions for a future rate will only be correct if the Sky Savings Rate (ssr) is not changed in the interim. This rate can be changed by Sky Governance through a governance vote. This fact should be taken into consideration when using the future conversions. You cannot use this function to get past conversion rates. #### Gas and Precision Tradeoffs The oracle contains three functions to provide the conversion rate, where one is a perfectly precise function, and the two others are approximations that in return are cheaper in gas. Depending on your use case, and if gas savings are critical you can elect to use an approximation instead of the exact value. Below is an overview of precision vs gas cost. * `getConversionRate()`: exact value, highest gas cost * `getConversionRateBinomialApprox():` higher precision, medium gas cost * `getConversionRateLinearApprox():` lower precision, lowest gas cost #### Rate Compounding The Sky Savings Rate is a compounding rate that is stored in the rate accumulator `chi`. Using this value, the last time it was updated (`rho`), and the per second Sky Savings Rate (`ssr`), you can calculate the exact conversion rate for the current time using standard rate compounding calculations. If you are new to how Sky's rate mechanism works, you can find more information here: [Sky Savings Rate Mechanism](https://github.com/sky-ecosystem/developerguides/blob/master/mcd/intro-rate-mechanism/intro-rate-mechanism.md#dai-savings-rate). ### Additional resources * [Cross-chain USDS & sUSDS](/dev/savings/cross-chain-tokens) * [Spark PSM](/dev/savings/spark-psm) * [Sky Savings Rate Mechanism](https://github.com/sky-ecosystem/developerguides/blob/master/mcd/intro-rate-mechanism/intro-rate-mechanism.md#dai-savings-rate) ## Cross-chain Tokens :::info If you are looking to integrate Ethereum mainnet sUSDS or sUSDC, you should review [this documentation instead for sUSDS](/dev/savings/susds-token) or [this documentation for sUSDC](/dev/savings/susdc-token). ::: ### Overview The Spark Liquidity Layer enables cross-chain liquidity of USDS, sUSDS and sUSDC. Integrators on these networks can tap into this liquidity by integrating these cross-chain tokens, and the [Spark PSM](/dev/savings/spark-psm), which enables swapping between USDS, sUSDS and USDC (sUSDC is not a PSM asset). The crosschain USDS and sUSDS tokens use the same simple ERC20 token implementation. The only difference between them is that sUSDS will increase in value over time according to the Sky Savings Rate. Converting between them on other networks can be done at no slippage or fees beyond gas using the Spark PSM. The crosschain sUSDS token does not contain any ERC4626 functionality - this is only available on Ethereum mainnet. sUSDC does contain ERC4626 functionality, and can be used to deposit into the [Spark Savings Vault](/dev/savings/susdc-token). ### Contract Details #### USDS * Type/Category: Token * Contract Source: [Github](https://github.com/sky-ecosystem/usds/blob/master/src/Usds.sol) #### sUSDS * Type/Category: Token * Contract Source: [Github](https://github.com/sky-ecosystem/usds/blob/master/src/Usds.sol) #### sUSDC * Type/Category: Token * Contract Source: [Github](https://github.com/sparkdotfi/spark-vaults) (`UsdcVaultL2.sol` for L2 deployments) #### Deployment Addresses | Network | Token | Address | | -------- | ----- | -------------------------------------------------------------------------------------------------------------------------------- | | Base | USDS | [0x820C137fa70C8691f0e44Dc420a5e53c168921Dc](https://basescan.org/address/0x820C137fa70C8691f0e44Dc420a5e53c168921Dc) | | Base | sUSDS | [0x5875eEE11Cf8398102FdAd704C9E96607675467a](https://basescan.org/address/0x5875eEE11Cf8398102FdAd704C9E96607675467a) | | Base | sUSDC | [0x3128a0F7f0ea68E7B7c9B00AFa7E41045828e858](https://basescan.org/address/0x3128a0F7f0ea68E7B7c9B00AFa7E41045828e858) | | Arbitrum | USDS | [0x6491c05A82219b8D1479057361ff1654749b876b](https://arbiscan.io/address/0x6491c05A82219b8D1479057361ff1654749b876b) | | Arbitrum | sUSDS | [0xdDb46999F8891663a8F2828d25298f70416d7610](https://arbiscan.io/address/0xdDb46999F8891663a8F2828d25298f70416d7610) | | Arbitrum | sUSDC | [0x940098b108fB7D0a7E374f6eDED7760787464609](https://arbiscan.io/address/0x940098b108fB7D0a7E374f6eDED7760787464609) | | Optimism | USDS | [0x4F13a96EC5C4Cf34e442b46Bbd98a0791F20edC3](https://optimistic.etherscan.io/address/0x4F13a96EC5C4Cf34e442b46Bbd98a0791F20edC3) | | Optimism | sUSDS | [0xb5B2dc7fd34C249F4be7fB1fCea07950784229e0](https://optimistic.etherscan.io/address/0xb5B2dc7fd34C249F4be7fB1fCea07950784229e0) | | Optimism | sUSDC | [0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55](https://optimistic.etherscan.io/address/0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55) | | Unichain | USDS | [0x7E10036Acc4B56d4dFCa3b77810356CE52313F9C](https://uniscan.xyz/address/0x7E10036Acc4B56d4dFCa3b77810356CE52313F9C) | | Unichain | sUSDS | [0xA06b10Db9F390990364A3984C04FaDf1c13691b5](https://uniscan.xyz/address/0xA06b10Db9F390990364A3984C04FaDf1c13691b5) | | Unichain | sUSDC | [0x14d9143BEcC348920b68D123687045db49a016C6](https://uniscan.xyz/address/0x14d9143BEcC348920b68D123687045db49a016C6) | #### ERC20 token functionality The contract implements the functions specified in the ERC-20 interface. * **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer. * **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer. * **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval. #### ERC4626 token functionality (only crosschain sUSDC) The contract implements the functions specified in the ERC-4626 interface. * **`deposit`**: Deposits a specified amount of tokens into the vault. It returns the amount of shares minted to the caller. * **`mint`**: Mints a specified amount of shares to the caller. It returns the amount of assets deposited by the caller. * **`redeem`**: Redeems a specified amount of shares from the vault. It returns the amount of tokens redeemed to the caller. * **`withdraw`**: Withdraws a specified amount of tokens from the vault. It returns the amount of shares burned from the caller. #### Upgradeability The contract uses the ERC-1822 UUPS pattern for upgradeability and the ERC-1967 proxy storage slots standard. For sUSDS, the `SUsdsDeploy` library sequence should be used for deploying. #### Events emitted * **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens. * **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer. ### Additional resources * [Spark Liquidity Layer](/products/spark-liquidity-layer) * [Spark PSM](/dev/savings/spark-psm) * [sUSDS (Mainnet)](/dev/savings/susds-token) * [sUSDC (Mainnet)](/dev/savings/susdc-token) * [Overview of Sky Savings Rate](/products/spark-savings#sky-stablecoin-vaults) * [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) * [ERC-4626 Tokenized Vault Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/) ## Savings Vault Intents ### Overview Savings Vault Intents is a request-based withdrawal contract for [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2). It is designed for large redemptions where the vault may not hold enough idle liquidity to satisfy an immediate `redeem()` call. Instead of redeeming directly from the vault, a user creates an onchain withdrawal request that specifies the vault, the number of shares to redeem, the recipient of the underlying assets, and an expiry deadline. The Spark ALM Planner monitors these requests offchain, prepares liquidity for the target vault, and then fulfills the request atomically. The contract never takes custody of user shares or redeemed assets. On fulfillment it calls `vault.redeem(shares, recipient, account)` so the underlying assets are sent directly to the designated recipient. ### Supported Networks and Contract Addresses | Network | Contract | Address | | -------- | ------------------- | --------------------------------------------------------------------------------------------------------------------- | | Ethereum | SavingsVaultIntents | [0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf](https://etherscan.io/address/0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf) | ### Contract Details * Contract Name: `SavingsVaultIntents.sol` * Contract Source: [Spark Savings Intents code repository](https://github.com/sparkdotfi/spark-savings-intents) * Ethereum Deployment: [0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf](https://etherscan.io/address/0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf) * Initial `maxDeadlineDuration`: `604800` seconds (7 days) ### Roles and Access Control The contract uses OpenZeppelin `AccessControlEnumerable` and defines two roles: * **`DEFAULT_ADMIN_ROLE`**: Can update the max request deadline window and manage per-vault configuration. * **`RELAYER`**: Can fulfill pending requests after liquidity has been prepared offchain by the Spark ALM Planner. ### Core State * **`RELAYER`**: Role identifier used for fulfillment permissions. * **`maxDeadlineDuration`**: Maximum time window a request deadline can be set into the future. * **`vaultConfig`**: Mapping of vault address to whitelist status and min/max asset thresholds. * **`vaultRequestCount`**: Per-vault request counter used to assign monotonically increasing request IDs. * **`withdrawRequests`**: Mapping of `account => vault => WithdrawRequest` for the currently active request. ### Vault Configuration Each supported vault has a `VaultConfig`: * **`whitelisted`**: Whether requests can be created for the vault. * **`minIntentAssets`**: Minimum underlying asset value allowed per request. * **`maxIntentAssets`**: Maximum underlying asset value allowed per request. The mainnet production deployment was initialized for the following Spark Vaults V2 markets: | Vault | Address | Min Intent Assets | Max Intent Assets | | ------- | --------------------------------------------------------------------------------------------------------------------- | ----------------- | ----------------- | | spUSDC | [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://etherscan.io/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) | 5,000,000 USDC | 500,000,000 USDC | | spETH | [0xfE6eb3b609a7C8352A241f7F3A21CEA4e9209B8f](https://etherscan.io/address/0xfE6eb3b609a7C8352A241f7F3A21CEA4e9209B8f) | 1,250 ETH | 250,000 ETH | | spPYUSD | [0x80128DbB9f07b93DDE62A6daeadb69ED14a7D354](https://etherscan.io/address/0x80128DbB9f07b93DDE62A6daeadb69ED14a7D354) | 5,000,000 PYUSD | 500,000,000 PYUSD | | spUSDT | [0xe2e7a17dFf93280dec073C995595155283e3C372](https://etherscan.io/address/0xe2e7a17dFf93280dec073C995595155283e3C372) | 5,000,000 USDT | 500,000,000 USDT | :::info These thresholds and whitelist settings are governance-controlled and can change over time. Integrators should query `vaultConfig(vault)` and `maxDeadlineDuration()` onchain instead of hardcoding them. ::: ### Request Lifecycle 1. The user approves the Savings Vault Intents contract to spend their Spark Vault shares. 2. The user calls `request(vault, shares, recipient, deadline)`. 3. The contract validates the vault configuration, the deadline, and the caller's balance and allowance. 4. A `RequestCreated` event is emitted for the ALM Planner to pick up offchain. 5. The ALM Planner prepares liquidity for the target Spark Vault. 6. An address with the `RELAYER` role calls `fulfill(account, vault, requestId)`. 7. The contract deletes the stored request and calls `vault.redeem(shares, recipient, account)`. Fulfillment is atomic. The request is either redeemed in full or the transaction reverts. ### Functions #### Admin Functions * **`setMaxDeadlineDuration(uint256 maxDeadlineDuration_)`**: Updates the maximum allowed request deadline window. The value cannot be zero. * **`updateVaultConfig(address vault, bool whitelisted_, uint256 minIntentAssets_, uint256 maxIntentAssets_)`**: Updates whitelist status and the min/max intent bounds for a vault. `minIntentAssets_` must be strictly less than `maxIntentAssets_`. #### User Functions * **`request(address vault, uint256 shares, address recipient, uint256 deadline)`**: Creates or overwrites the caller's pending request for a vault and returns a new `requestId`. * **`cancel(address vault)`**: Cancels the caller's active request for a vault and returns the cancelled `requestId`. #### Relayer Function * **`fulfill(address account, address vault, uint256 requestId)`**: Fulfills a pending request by redeeming the user's shares from the vault and sending assets to the configured recipient. Only callable by the `RELAYER` role. #### View Functions * **`maxDeadlineDuration()`**: Returns the maximum deadline offset in seconds. * **`vaultConfig(address vault)`**: Returns the current whitelist flag and min/max thresholds for a vault. * **`vaultRequestCount(address vault)`**: Returns the total number of requests ever created for a vault. * **`withdrawRequests(address account, address vault)`**: Returns the currently active request for a given user and vault. * **`RELAYER()`**: Returns the role hash for the relayer role. ### Request Validation `request()` enforces the following preconditions: * The vault must be whitelisted. * The recipient must not be the zero address. * `convertToAssets(shares)` must be within the vault's configured min/max bounds. * The deadline must be strictly in the future and no greater than `block.timestamp + maxDeadlineDuration`. * The caller must hold at least `shares` vault shares. * The caller must have approved at least `shares` to the Savings Vault Intents contract. ### Events Emitted * **`RequestCreated(address indexed account, address indexed vault, uint256 indexed requestId, uint256 shares, address recipient, uint256 deadline)`**: Emitted when a request is created or overwritten. * **`RequestCancelled(address indexed account, address indexed vault, uint256 indexed requestId)`**: Emitted when a request is cancelled. * **`RequestFulfilled(address indexed account, address indexed vault, uint256 indexed requestId)`**: Emitted when a request is fulfilled. * **`VaultConfigUpdated(address indexed vault, bool indexed whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)`**: Emitted when admin updates a vault's configuration. * **`MaxDeadlineDurationUpdated(uint256 indexed maxDeadlineDuration)`**: Emitted when admin updates the maximum deadline window. ### Custom Errors * **`VaultNotWhitelisted`**: The vault is not enabled for the intent flow. * **`InvalidRecipientAddress`**: The recipient is the zero address. * **`IntentAssetsBelowMin`**: The requested redemption is below the configured minimum. * **`IntentAssetsAboveMax`**: The requested redemption exceeds the configured maximum. * **`InvalidDeadline`**: The request deadline is invalid or exceeds the allowed window. * **`InsufficientShares`**: The caller does not hold enough vault shares. * **`InsufficientAllowance`**: The contract does not have enough share allowance. * **`RequestNotFound`**: No matching pending request exists for the account and vault. * **`DeadlineExceeded`**: The relayer attempted to fulfill a request after expiry. * **`InvalidAdminAddress`**, **`InvalidRelayerAddress`**, **`InvalidVaultAddress`**, **`InvalidMaxDeadlineDuration`**, **`InvalidIntentAmountBounds`**: Configuration errors. ### Gotchas / Integration Concerns #### One Active Request Per Vault Each user can have only one active request per vault. Creating a new request for the same vault overwrites the existing one and assigns a new `requestId`. #### Overwrites Do Not Emit a Cancel Event Replacing an existing request via `request()` silently removes the old request. Integrators should treat the latest `RequestCreated` event for a given `(account, vault)` pair as authoritative. #### No Partial Fills `fulfill()` redeems the full requested share amount or reverts. The contract does not support partial fulfillment. #### Balance and Allowance Can Change After Request Creation Users can revoke allowance or move shares away after creating a request. In that case fulfillment will revert when the relayer eventually calls `redeem()`. #### Request IDs Protect Against Stale Fulfills `fulfill()` requires the expected `requestId`, preventing a relayer from accidentally fulfilling a request that has since been cancelled or overwritten. ### Additional Resources * [Spark Savings Intents GitHub Repository](https://github.com/sparkdotfi/spark-savings-intents) * [Spark Vaults V2](/dev/savings/spark-vaults-v2) * [Spark Liquidity Layer: Spark ALM Controller](/dev/spark-liquidity-layer/spark-alm-controller) ## sDAI Token ### Overview Savings Dai (sDAI) is an ERC-4626 representation/wrapper of DAI in the Dai Savings Rate module (DSR). sDAI allows users to deposit DAI to receive the yield generated by the Sky Protocol while still being able to transfer, stake, lend and any other use cases. :::info Savings Dai and the Dai Savings Rate are non-custodial and permissionless smart contracts offered by [Sky](https://sky.money), and is not issued by Spark. Spark does not have any control over the Sky Savings Rate or the sDAI token. ::: ### Contract Details * Contract Name: SavingsDai.sol * Contract Source: [sDAI code repository](https://github.com/sky-ecosystem/sdai) * Ethereum Contract Address: [0x83f20f44975d03b1b09e64809b757c47f942beea](https://etherscan.io/address/0x83f20f44975d03b1b09e64809b757c47f942beea) #### Variables * **`name`**: Savings Dai * **`symbol`**: sDAI * **`version`**: 1 * **`decimals`**: 18 * **`totalSupply`**: An unsigned integer representing the total supply of the token. It keeps track of the total number of tokens in circulation. * **`balanceOf`**: A mapping that associates an address with its corresponding token balance. It allows for looking up the balance of a specific address. * **`allow