# Spending Integration
Stablecoin-Based Debit Extension
The Spending Integration Layer enables users to utilize borrowed stable assets for real-world transactions through regulated card issuers. This module extends Horizon’s borrowing functionality into everyday payments without altering the protocol’s core mechanics.
Horizon remains an on-chain collateral and risk engine. Card issuance, fiat conversion, compliance, and settlement are handled exclusively by licensed third-party providers.
***
System Overview
Users deposit supported collateral (e.g., ETH) into Horizon and borrow a stable asset such as USDx under overcollateralized conditions. The borrowed stable may then be transferred to a partnered crypto card provider. The provider converts the stable asset to fiat at point of sale and settles transactions through traditional card networks (e.g., Visa or Mastercard).
Horizon does not issue cards, process payments, or perform fiat settlement. It provides collateralized borrowing infrastructure. The card provider supplies regulated financial services.
***
Architectural Separation
The Spending Layer exists entirely outside the core protocol contracts.
The Core Protocol Layer governs:
* Collateral deposits
* Borrow limits
* Loan-to-value enforcement
* Liquidation thresholds
* Stable issuance
* Repayment and collateral release
The Spending Layer governs:
* Stablecoin transfer to card provider
* Fiat conversion at point of sale
* Card network settlement
* Identity verification and compliance
There are no protocol-level dependencies on the card provider. If the provider is removed, borrowing functionality remains unchanged.
***
User Flow
A user deposits ETH into Horizon and borrows USDx within defined LTV limits. The interface displays available borrow capacity and outstanding debt.
If the user elects to spend, they transfer borrowed USDx to their wallet address associated with a supported card provider. The card provider maintains custody of the stable asset for settlement purposes and converts it to fiat at the time of transaction authorization.
Repayment occurs directly through Horizon. The user returns USDx to the protocol to reduce debt and unlock collateral. Card activity does not alter loan accounting beyond the initial transfer of stable assets.
***
Risk and Liquidation Model
All liquidation logic remains on-chain and governed by collateral value and LTV thresholds. Spending activity does not modify liquidation rules. If collateral value declines and the position breaches defined health factors, liquidation proceeds according to protocol rules regardless of card usage.
The card provider does not possess liquidation authority over user collateral. It only controls assets voluntarily transferred to its custody.
***
Compliance Boundary
Horizon does not perform KYC, AML, credit underwriting, or consumer financial compliance for card issuance. These obligations are fully borne by the third-party provider.
The interface must disclose that card services are provided by regulated entities and that Horizon does not custody fiat or operate payment rails.
***
Implementation Model
The Spending Layer may be implemented as:
* A “Send to Card” interface within the dashboard
* A direct transfer to a user-controlled card wallet address
* Optional API-based integration with approved providers
No protocol upgrades are required to enable or disable this functionality. The integration exists at the interface level and may be removed without affecting contract logic.
***
Economic Considerations
Horizon may optionally negotiate commercial agreements with card providers, including interchange revenue sharing or referral incentives. Such arrangements do not affect borrowing mechanics or protocol accounting.
Borrowed stable assets used for spending remain liabilities of the borrower until repaid. The spending function does not constitute unsecured credit issuance. All borrowing remains fully collateralized.
***
Design Objective
The Spending Integration Layer extends Horizon’s utility without expanding its regulatory footprint. The protocol remains a non-custodial, overcollateralized borrowing system. Card functionality operates as a separate, regulated service layer.
This structure preserves architectural clarity while enabling real-world capital mobility.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://trader-li.gitbook.io/horizon-protocol/build-on-horizon/spending-integration.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.