Loading...
Supporting developers, startups, and full-fledged companies building on Stellar and Soroban
© 2026 Stellar Development Foundation
Subscribe to the Newsletter
By LendWise
DeFi lending markets are fragmented across protocols, chains and assets. This fragmentation leaves lending rate data scattered and inconsistent, while position monitoring remains siloed across protocol-specific interfaces. As a result, users must piece together rates and portfolio positions across multiple sources. LendWise solves this by standardizing lending data, centralizing position monitoring, and providing optimization and execution tools across protocols and chains.
LendWise combines three layers: a market intelligence and portfolio layer that standardizes lending rates across 900+ markets on 25+ chains and monitors positions across protocols; an optimization engine that identifies lending and borrowing strategies based on market conditions, risk preferences and investment horizon; and a cross-chain execution layer that enables users to allocate capital and manage lending positions across chains from a single interface.
The Stellar integration brings Stellar into that same standardized framework as a first-class chain family, rather than as a single-protocol integration. LendWise standardizes lending data through one adapter contract that every protocol implements; the Stellar work delivers the pieces that let any Stellar lending protocol plug into it: historical rate and liquidity reconstruction from Stellar's public ledger data (Hubble), since Stellar lending protocols expose spot rates but not the comprehensive historical data investors need to make informed decisions; Stellar wallet authentication (SEP-10); a standardized position and risk model so Stellar positions can be monitored alongside Aave, Morpho and Compound positions; and Circle CCTP, allowing users to transfer native USDC from other supported chains to Stellar from within LendWise and deploy it into Stellar lending venues as they are integrated.
$66.7K
LendWise is currently live across major EVM lending markets, including Ethereum, Base and Arbitrum, with integrations covering Morpho Blue, Aave and Compound, and has attracted a growing base of recurring users since launch.
We have already started the Stellar integration, and its foundation is in production. Stellar is registered as a chain family in LendWise alongside EVM. Stellar wallet connection is live through Stellar Wallets Kit, covering Freighter, xBull, Lobstr and Albedo. A Soroban RPC data source has been running in production since August 2026, with a paced client calibrated against the public endpoint's measured rate ceiling, and with failure modes — oracle contract traps, undecodable results, RPC refusals — discovered and handled in production rather than in a spec. A BigQuery client against Stellar's Hubble public dataset is live and used for contract discovery from historical contract events. The deliverables below generalize that foundation so that any Stellar lending protocol can build on it.
Alongside product development, we implemented a structured marketing and adoption strategy focused on growing LendWise's user base and measuring engagement. We integrated PostHog to track detailed product analytics, established an active presence on LinkedIn, X and Farcaster, and started publishing technical and educational content on Medium and https://lendwise.fi/. LendWise is also fully open source: its data model, protocol adapters and validation tools are public, allowing developers and protocol teams to audit the methodology and contribute new protocol adapters directly to the platform. PostHog was integrated recently and has already recorded approximately 50 unique users, more than 500 page views and several wallet connections over the last month.
The Stellar integration also includes Circle CCTP, creating a direct path for LendWise users to transfer native USDC from supported chains to Stellar and deploy it into Stellar lending venues through LendWise. In this context, we have built a working POC demonstrating cross-chain execution from an EVM chain to Stellar using CCTP.
Tranche 1 — MVP — $12,430 (11 days)
What this delivers:
A historical-state reconstruction module querying Stellar Hubble — the public BigQuery mirror of the Stellar ledger — for a given Soroban contract's ledger entries and events, bucketed at hourly intervals, and producing the same standardized hourly market data format the spot pipeline writes (supply and borrow APY, total supplied liquidity, total borrowed liquidity, utilization);
A decode hook so each Stellar lending adapter supplies only its contract-specific state decoding and gets a getApyHistory implementation for free — the same interface the Aave, Compound and Morpho adapters already implement;
Registration of the Stellar adapter family into the existing generic backfill script, requiring no changes to the script itself.
Technical approach: Stellar lending protocols have no subgraph or history API of their own — unlike Aave's official subgraph or Compound's REST API — so there is no shortcut of just calling an existing endpoint. Historical reconstruction has to replay contract state from Hubble's crypto-stellar dataset (history_contract_events and ledger-entry history) and transform it into the standardized hourly market data format. LendWise already runs a BigQuery client against Hubble in production for contract discovery; this deliverable generalizes it from "which contracts exist" to "what state did this contract hold at hour H". The backfill harness it feeds into is protocol-blind by design, so all of the new work here is the reconstruction module and its decode hook — nothing protocol-specific.
Success criteria: The module ships in the public repository with its tests passing in CI and is registered in the generic backfill script; for a given Soroban contract address, it reconstructs an hourly state series over the recorded time horizon from Hubble, with the output published alongside the code.
What this delivers:
A SEP-10 challenge-issuing endpoint on the backend;
Client-side challenge-signing flow added to the existing StellarWalletContext;
Session persistence wired into the existing unified wallet store's chainFamily discriminator, matching how EVM wallet sessions already persist;
Support across all four already-integrated wallets: Freighter, xBull, Lobstr, Albedo.
Technical approach: SEP-0010 works by having the server build a challenge transaction — sequence number 0, a ManageData operation encoding a nonce, a short validity window, signed by the server's own key — addressed to the client's claimed public key. The client signs it without ever broadcasting it, and the server verifies the returned signature against that key. This is preferred over a bare "sign this string" scheme because it reuses Stellar's native transaction and signature verification plus its built-in time-bounds/sequence anti-replay protection, rather than inventing a separate mechanism. It must be built and verified against the correct network passphrase (Public Global Stellar Network vs Test SDF Network), since a mismatch there fails verification silently rather than with a clear error.
Success criteria: On lendwise.fi, a reviewer clicks "Connect Stellar Wallet," picks any supported wallet, signs the authentication prompt, and their address stays connected after refreshing the page, with the session verified server-side against the signed challenge.
Tranche 2 — Testnet — $12,430 (11 days)
What this delivers:
A health-factor calculation module, generalized to run against any set of reserves a user holds positions in, on any protocol: per-reserve collateral and liability weights are supplied by the protocol's adapter through the adapter contract, and prices come from the oracle price map the spot pipeline already fetches;
Unit tests against multiple known reserve/oracle scenarios, including an unpriced-asset case;
A UI component in the portfolio view displaying the computed health factor, with a distinct "unknown" state rather than a numeric guess when an underlying price is missing.
Technical approach: Health factor is Σ(collateral_i × price_i × collateral_weight_i) / Σ(liability_i × price_i ÷ liability_weight_i) across every reserve involved. The weights are risk parameters each adapter reads from its own protocol — separate from the interest-rate model — which keeps the module independent of any one protocol's parameterization: EVM adapters and Stellar adapters feed the same formula, and a Stellar lending adapter that exposes its weights gets a health factor comparable with EVM positions with no further work. The module reuses the oracle price map already fetched per pool in the spot pipeline, so no second round of oracle calls is needed. An unpriced reserve must fail the calculation closed rather than valuing that collateral at zero, which would understate risk rather than flag it as unknown. The same formula, fed with Aave's per-reserve liquidation thresholds, reproduces Aave's own reported health factor within tolerance — that is how the math is validated, independently of any Stellar venue.
Success criteria: The module ships with its unit-test suite passing in CI, covering multiple reserve/oracle scenarios including an unpriced asset. On a staging environment, a fixture Stellar adapter registered through the adapter contract exposes known positions and per-reserve risk weights for a Stellar testnet address; the portfolio page shows, for that address, the health factor the module computes from them, and the "unknown" state when one reserve's price is removed from the oracle map.
What this delivers:
A merge layer combining the existing EVM position-fetch calls with the Stellar-side fetch, routed by the wallet store's chainFamily discriminator: Stellar addresses go to Stellar adapters — any lending adapter registered through the adapter contract — and never to EVM ones, and the Stellar side always includes the wallet's native holdings (XLM and trustline balances such as USDC), so bridged USDC is visible in the portfolio the moment it lands;
Partial-failure UI states — a visible indicator when one chain family's data is temporarily unavailable, instead of the whole dashboard failing;
No new work required for daily historical aggregation of Stellar rates — confirmed by reading the aggregation query directly, it already covers any protocol writing to the hourly table.
Technical approach: The merge runs each chain family's fetch through Promise.allSettled; a rejected Stellar-side promise renders the EVM side with a partial-data indicator rather than blanking the dashboard — this is allSettled's native behavior, not additional logic built on top of it. Routing by chainFamily is what keeps a Stellar G… address from ever being handed to an EVM adapter expecting a 0x… one.
Success criteria: For a user with a connected EVM wallet holding an Aave position and a connected Stellar wallet holding USDC, the portfolio page shows both in the same view — a reviewer can check this with their own wallets on lendwise.fi. The degradation path is demonstrated by the team on a staging environment with the Stellar endpoint made unreachable: the same page still renders the EVM side with the partial-data indicator, with a recording or screenshots provided with the submission.
Tranche 3 — Mainnet — $41,810 (37 days)
What this delivers:
Integration with Circle's CCTP V2 contracts on the EVM source-chain side (initiating the burn);
Integration with the Stellar-side token-messenger-minter, message-transmitter, and cctp-forwarder Soroban contracts;
Correct 7-vs-6 decimal rescaling built directly into the core transfer logic, not added afterward;
A working reference flow validated against Stellar testnet with a real, checkable transaction hash.
Technical approach: CCTP V2 on Stellar is three open-source Soroban contracts (circlefin/stellar-cctp). The cctp-forwarder exists specifically because Stellar's account model can't receive an arbitrary contract's mint the way an EVM address receives an ERC-20 mint(to, amount) call. Domain IDs are CCTP-specific integers, not chain IDs (Stellar testnet is domain 27) — using the wrong identifier routes the message to the wrong destination context. USDC is 7 decimals on Stellar versus 6 on every EVM CCTP chain, so amounts must be rescaled, not passed through raw. Circle's own documentation is explicit that routing mintRecipient to the end-user's address directly, instead of to the CctpForwarder contract (with destinationCaller also set to it), results in funds that are permanently unrecoverable — this constraint shapes the implementation from the first line of code, not as an afterthought.
Success criteria: A reviewer is given a real testnet and mainnet transaction hashs showing USDC minted on Stellar in the correct amount, clickable on a Stellar block explorer (e.g. Stellar Expert).
What this delivers:
A pre-flight check reading the recipient Stellar account's trustline ledger entry before a bridge transfer is initiated;
A ChangeTrust-signing prompt in the UI when the trustline is missing;
Sequencing logic that runs this check before the EVM-side burn is submitted, not after.
Technical approach: Stellar requires an explicit trustline — a ChangeTrust operation, locking 0.5 XLM of the account's base reserve — before an account can hold any non-native asset, including SEP-41-wrapped USDC. There is no EVM equivalent; any address can hold any ERC-20 with no setup step. A mint to an account without a trustline fails at the ledger level, and that failure only surfaces after the source-chain burn has already been attested — so the check has to run before the burn is even started, not just before the mint.
Success criteria: Using any fresh Stellar wallet with no USDC trustline, the app prompts to create one before the transfer, and the transfer completes right after — a reviewer can test this themselves with a new wallet.
What this delivers:
An Iris API polling client for Circle's attestation service, reusing the existing paced-request pattern already proven on the Soroban RPC integration;
Selection and implementation of the Fast Transfer finality tier as the default path;
A guided end-to-end bridge flow in the LendWise UI — source chain and amount selection, the trustline pre-flight from 3.1b, burn, attestation wait with live status, mint — ending with native USDC confirmed in the user's Stellar wallet and reflected in the unified portfolio from 2.2b, as one guided user action, and available in a testnet mode (EVM testnet + Stellar testnet) on a staging environment so a reviewer can run it without mainnet funds;
The flow built as a protocol-independent step, so any Stellar lending venue integrated through the adapter contract can be reached from it without reworking the bridge;
Transaction-hash logging at every step (burn, attestation, mint) for auditability;
A validated run on mainnet, in addition to the testnet path.
Technical approach: CCTP V2 offers two finality tiers — Fast Transfer (finality threshold ≤1000) and Standard (≥2000) — trading wait time for finality strength; Fast Transfer is used by default since Stellar's own ~5-second finality means the attestation wait dominates total transfer time regardless of tier. The days budgeted here beyond a bare bridge UI account for real-world cross-chain testnet flakiness — two networks plus an external attestation service in one critical path — and for the mainnet validation run.
Success criteria: A reviewer can complete one full run themselves on testnet — send USDC from an EVM testnet wallet and see it arrive as native USDC in their Stellar testnet wallet, and in their LendWise portfolio, within a few minutes, with a transaction hash for every step. A completed mainnet transaction hash is also provided as supporting evidence.
What this delivers:
The existing comparison/optimizer engine made chain-family aware, so any Stellar venue writing to the shared rate tables is ranked alongside Aave, Morpho and Compound for the same asset — verified in CI against a fixture Stellar adapter, since this grant does not assume a live Stellar lending venue;
A "Bridge USDC to Stellar" entry point on the comparison tables — on the Stellar chain filter and on the USDC asset rows — deep-linking into the guided CCTP flow built in 3.1 with asset, amount and destination pre-filled; a ranked Stellar entry, once one exists, carries the same deep link.
Technical approach: Reuses the existing optimizer ranking logic — rates from any registered Stellar adapter flow into the same apy_daily/apy_hourly tables every other protocol uses, so this is primarily a UI and deep-linking task, not a new ranking engine.
Success criteria: On lendwise.fi, a reviewer filtering the comparison tables on Stellar, or opening a USDC row, reaches the guided bridge flow with the destination pre-filled through the deep link. The chain-family-aware ranking is covered by tests passing in CI against a fixture Stellar adapter, so any Stellar venue registered through the adapter contract is ranked next to Aave/Morpho/Compound with no further engineering.
What this delivers:
The Stellar adapter family included in the existing nightly reconcile pipeline's gap-detection logic;
The Stellar adapter family included in the same automatic healing/backfill-on-gap mechanism already running for EVM adapters, using the Hubble reconstruction module from 1.1b as the refetch path;
The Stellar adapter family visible in the existing pipeline_reports monitoring log.
Technical approach: The reconcile job already runs generically across every registered adapter; this deliverable is registering the Stellar adapter family into that existing gap-detection/healing cycle rather than building new monitoring infrastructure. Without a getApyHistory implementation, reconcile has no refetch path for a protocol and fills every hole from a neighbouring hour; 1.1b is what makes real healing possible for Stellar adapters.
Success criteria: A status report or monitoring screenshot provided with the submission shows the Stellar adapter family included in the same health checks as the other protocols, with gap detection and the Hubble refetch path exercised against a fixture Stellar adapter on staging, since this grant does not assume a live Stellar lending venue.
What this delivers:
Published developer-facing documentation: how to integrate a Stellar lending protocol into LendWise through the adapter contract (spot data source, Hubble history decode hook, positions and risk weights), and the CCTP integration architecture;
A full manual QA pass across the live mainnet CCTP path, covering both a first-time user (no existing trustline) and a returning user (existing trustline) journey.
Technical approach: Primarily a documentation and verification deliverable rather than new engineering — closing out the tranche by confirming the full path built across 3.1a–3.1c behaves correctly for both account states in production, and by publishing the contract that lets a Stellar lending protocol integrate through it without waiting on LendWise's engineering time.
Success criteria: Integration documentation is published and reachable at a public URL.
not required for this round.
Successful Delivery of Lendwise's SCF #45 Build Award
As Lead Developer of Lendwise, Cédric successfully led the technical implementation and delivery of all milestones under our SCF #45 Build Award. Every deliverable was completed and validated by the SCF team, demonstrating his ability to deliver complex blockchain integrations through Mainnet deployment. His work included integrating Blend v2.1 into Lendwise's multichain lending framework, reconstructing historical lending data from Stellar ledger activity, extending portfolio monitoring across EVM and Stellar networks, and integrating Circle CCTP for native USDC transfers.
These developments enabled Lendwise to bring Blend lending markets into the same standardized analytics and portfolio infrastructure as Aave, Morpho lending markets and Compound.
Professional Experience
Cédric is a Senior Full Stack Engineer with over 12 years of software development experience, including CTO responsibilities on large-scale technology platforms. He previously spent several years at Consensys, the Ethereum technology company behind MetaMask and Infura, developing expertise in smart-contract engineering, Solidity, DeFi infrastructure and blockchain applications. His background combines full-stack development, backend engineering, smart-contract integration and application architecture.
Contribution to the RWA Expansion
Cédric leads Lendwise's next development phase, including the reusable RWA integration framework, financial-data services, embedded-wallet integrations and onboarding infrastructure.
LinkedIn: https://www.linkedin.com/in/cedricmagne/
Project references:
GitHub: https://github.com/lendwise-fi/lendwise
SCF #45 Award: https://communityfund.stellar.org/submissions/recmK8tdxCKvSU3GS
Blockchain Data Engineering Experience
Léonard specializes in blockchain data engineering, DeFi analytics and historical financial-data processing. He previously worked as a DeFi Data Scientist at PyratzLabs and a Web3 Data Analyst at Bloometa, developing blockchain ETL pipelines, quantitative risk-scoring methodologies and on-chain analytics dashboards using Python. His experience includes extracting and transforming blockchain data, designing structured datasets, developing analytical pipelines and maintaining historical financial information across decentralized protocols.
Contribution to Lendwise
As Head of Data, Léonard contributes to the infrastructure supporting Lendwise's lending-market analytics, historical interest-rate reconstruction, protocol comparisons and data-quality processes.
For the RWA expansion, his expertise will support issuer-specific data adapters, historical NAV and yield observations, data normalization, source validation and freshness monitoring.
LinkedIn: https://www.linkedin.com/in/leonard-gouillard/
Digital-Asset Markets and DeFi Product Experience
Florian is a Senior Trader at Bitcoin Suisse AG, a Swiss digital-asset financial-services company serving private and institutional clients.
He brings more than five years of experience in decentralized finance research, smart-contract interaction, lending-market analysis and trading execution. His background combines practical market knowledge with an understanding of lending rates, liquidity conditions, financial products and risk considerations.
Contribution to Lendwise
As Product Lead, Florian contributes to the definition of Lendwise's financial-product requirements, lending comparisons, optimization features and investment workflows.
For the RWA expansion, his expertise supports the comparison of tokenized bonds and yield-bearing funds with DeFi lending markets, particularly in relation to investment horizons, liquidity, currency exposure and product eligibility.
LinkedIn: https://www.linkedin.com/in/flho718/
Quantitative Finance and Academic Research
Bastien is a quantitative researcher specializing in applied mathematics, decentralized finance, interest-rate modeling and financial risk management. His professional experience includes working as a Quantitative Risk Analyst at Natixis, a Quantitative Analyst at Société Générale Corporate and Investment Banking, and a Quantitative Researcher at Securd Labs.
His academic research at Université Paris-Saclay and CentraleSupélec focuses on the mathematical modeling and optimization of decentralized lending protocols. He has co-authored research investigating optimal interest-rate mechanisms, liquidity risk, leveraged lending positions and capital allocation across DeFi markets.
Selected Academic Publications
1. Optimal Risk-Aware Interest Rates for Decentralized Lending Protocols — Digital Finance, Springer, 2026
This research develops mathematical models for optimizing interest rates in decentralized lending protocols while accounting for liquidity risk, borrowing demand and interest-rate stability. The methodology combines stochastic modeling, optimal control, Monte Carlo techniques and deep learning.
Publication: https://doi.org/10.1007/s42521-026-00200-8
Open-access preprint: https://arxiv.org/abs/2502.19862
2. Leveraged Positions on Decentralized Lending Platforms — 2026
The paper develops a mathematical framework for optimizing leveraged staking and borrowing strategies across DeFi lending markets.
It models linear, kinked and adaptive interest-rate mechanisms, including Morpho's AdaptiveCurveIRM, while accounting for borrowing costs, leverage constraints and transaction fees.
The research includes backtesting on Ethereum and Base lending markets and demonstrates the importance of position sizing and rebalancing for strategy performance.
Publication: https://arxiv.org/abs/2601.14005
Direct PDF: https://arxiv.org/pdf/2601.14005
3. Optimal Execution on Uniswap v2/v3 Under Transient Price Impact — 2026
This research examines optimal execution strategies on decentralized exchanges, considering price impact, liquidity structure and dynamic execution decisions.
Publication: https://arxiv.org/abs/2601.03799
Contribution to Lendwise
At Lendwise, Bastien leads research into lending optimization and risk-management methodologies. His quantitative expertise supports the development of models for comparing lending protocols, evaluating borrowing costs, assessing liquidity risk and identifying risk-adjusted strategies.
For the RWA expansion, he contributes to the methodology for comparing accumulating and distributing yield-bearing products, including NAV changes, income distributions, currency exposure and liquidity constraints.
His research provides a quantitative foundation for extending Lendwise's optimization framework beyond conventional DeFi lending markets.
LinkedIn: https://www.linkedin.com/in/bastien-baude/
Research publications: https://lendwise.fi/docs/research/
DeFi Entrepreneurship and Liquidity Infrastructure
Mounir is the Founder of ParaSwap, a decentralized liquidity aggregation protocol. He brings extensive experience in decentralized finance, blockchain infrastructure, liquidity aggregation and the development of financial applications connecting multiple protocols and liquidity sources.
Through ParaSwap, he has gained experience in decentralized trading, transaction routing, smart-contract integrations, execution optimization and scaling DeFi infrastructure.
His entrepreneurial background also includes product strategy, ecosystem development and partnerships within decentralized finance.
Advisory Contribution to Lendwise
Mounir provides strategic expertise in DeFi infrastructure, liquidity aggregation, multichain integrations and product development. His experience is relevant to Lendwise's approach to aggregating fragmented financial information, integrating new protocols and extending access to decentralized financial opportunities.
For the RWA expansion, his advisory experience supports our approach to reusable integration infrastructure, liquidity-related product design and the long-term development of cross-chain financial services.
LinkedIn: https://www.linkedin.com/in/mounibec/
leonard
By LendWise
Lending & RWA Yield Intelligence
By LendWise
Cross-Chain Lending Intelligence