Sablier Integration for Linear Payments and Vesting

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1All 1305 services
Sablier Integration for Linear Payments and Vesting
Medium
~3-5 days
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1361
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    957
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1189
  • image_logo-advance_0.webp
    B2B Advance company logo design
    646
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    929

Sablier Integration for Linear Payments and Vesting

We provide turnkey Sablier integration for your dApp, solving the precise payment problem that plagues custom vesting contracts. Calculating vestedAmount via block.timestamp is a classic pitfall: the difference can be up to 5% of the total — on a $10K token stream, that's a $500 discrepancy. Sablier solves this at the protocol level with deterministic on-chain calculations to the second. Our team has over 10 years of DeFi experience and has executed 40+ Sablier integrations. Contact us for a case analysis to find the optimal solution for your project.

How Sablier Solves the Precise Payment Problem

Sablier v2 consists of two main contracts:

  • SablierV2LockupLinear — linear streams from point A to point B. Supports a cliff period and streaming second by second from the start time.
  • SablierV2LockupDynamic — dynamic streams with custom segments for arbitrary vesting curves (exponential, stepped, etc.).

Each stream is an NFT (ERC-721). This is a key design choice: the stream can be transferred to another address (transfer stream = transfer right to future payments), used as collateral in lending protocols, or displayed in NFT marketplaces. The sender can cancel the stream (if created as cancelable) — remaining tokens are returned.

Available Stream Types and How to Choose

Stream Type Description When to Use
LockupLinear Linear unlock from startTime to endTime, optional cliff Team vesting, salaries, simple grants
LockupDynamic Arbitrary segments (different speeds on different intervals) Complex tokenomics, exponential vesting, multiple milestones

The choice between LockupLinear and LockupDynamic depends on your tokenomics. For classic team vesting (4 years with 1-year cliff), LockupLinear works. If you need accelerated bonuses or exponential curves, use LockupDynamic with segments. We help design the right configuration during the analysis phase.

Smart Contract Integration

For dApps that programmatically create streams (e.g., DAO paying grants, protocol distributing rewards via Sablier instead of custom vesting):

import { ISablierV2LockupLinear } from "@sablier/v2-core/interfaces/ISablierV2LockupLinear.sol";
import { LockupLinear, Broker } from "@sablier/v2-core/types/DataTypes.sol";
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract VestingManager {
    ISablierV2LockupLinear public immutable sablier;
    IERC20 public immutable token;
    
    constructor(address _sablier, address _token) {
        sablier = ISablierV2LockupLinear(_sablier);
        token = IERC20(_token);
    }
    
    function createVestingStream(
        address recipient,
        uint128 totalAmount,
        uint40 cliffDuration,   // seconds
        uint40 totalDuration    // seconds
    ) external returns (uint256 streamId) {
        token.approve(address(sablier), totalAmount);
        
        LockupLinear.CreateWithDurations memory params = LockupLinear.CreateWithDurations({
            sender: address(this),
            recipient: recipient,
            totalAmount: totalAmount,
            asset: token,
            cancelable: true,       // DAO can cancel
            transferable: false,    // NFT transferable? (optional)
            durations: LockupLinear.Durations({
                cliff: cliffDuration,
                total: totalDuration
            }),
            broker: Broker({ account: address(0), fee: 0 })
        });
        
        streamId = sablier.createWithDurations(params);
    }
}

Important: totalAmount is the gross amount. If the token has a tax (deflationary transfer), you must account for the actual received amount. We include such edge cases in our integration to avoid losses.

For displaying active streams, we use The Graph. Example subgraph query for all networks:

query GetStreams($recipient: String!) {
    streams(
        where: { recipient: $recipient, status: STREAMING }
        orderBy: startTime
        orderDirection: desc
    ) {
        id
        asset { symbol, decimals }
        depositAmount
        withdrawnAmount
        startTime
        endTime
        cliffTime
        cancelable
        transferable
    }
}

User Interface: Displaying and Managing Streams

Users need: a list of active streams, current progress, amount already paid, amount available for claim, remaining time. Plus actions: withdraw and cancel (for sender). Visualize progress — a timeline showing cliff and linear phases.

What Data Is Needed to Display a Stream?

Sablier provides subgraphs (The Graph) for all major networks. The query for a recipient's active streams is shown above. Current available balance — streamedAmount - withdrawnAmount — is obtained via an on-chain call to streamedAmountOf(streamId). The subgraph gives a snapshot at the last event; live balance must be read from the contract.

Progress Calculation

For a linear stream without a cliff: progress = (now - startTime) / (endTime - startTime). With a cliff: show 0% until cliff, then linear interpolation. For dynamic streams, interpolate across segments — the Sablier SDK provides a computeStreamedAmount helper.

import { getStreamedAmount } from '@sablier/v2-sdk';

const streamed = getStreamedAmount({
    startTime: stream.startTime,
    endTime: stream.endTime,
    depositAmount: BigInt(stream.depositAmount),
    cliffTime: stream.cliffTime,
    currentTime: BigInt(Math.floor(Date.now() / 1000)),
    segments: stream.segments, // for dynamic streams
});

const progressPercent = Number(streamed * 100n / BigInt(stream.depositAmount));

What's Included in the Work

  • Analysis of your vesting logic and tokenomics, selecting the optimal stream type.
  • Design of wrapper smart contracts (if needed) with security considerations (cancelable, transferable).
  • Implementation of contracts in Solidity using Foundry and fuzzing with Echidna.
  • Interface development connecting Sablier subgraph, progress bars, and actions (withdraw/cancel).
  • Multichain deployment with Etherscan verification for all supported networks.
  • Documentation, source code, deployment scripts, access to a template repository.
  • Team training (1 hour online) and 3 months of post-delivery support.

Work Process and Timelines

  1. Analysis — we examine your vesting logic and tokenomics, choose stream type (linear or dynamic).
  2. Design — design wrapper contracts (if needed), define security parameters (cancelable, transferable).
  3. Implementation — write contracts using Sablier SDK with heavy testing (foundry, echidna fuzzing).
  4. Interface — connect Sablier subgraph, implement progress bars and actions (withdraw/cancel) via viem or ethers.js.
  5. Deployment — multichain deployment with verification on Etherscan. Sablier v2 is deployed on Ethereum mainnet, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, Base, Gnosis. Contract addresses are stable.
  6. Support — hand over documentation, sources, deployment scripts. Guarantee bug fixes within 48 hours.

Basic integration (stream creation from contract + UI view) — 3-4 days. Full interface with management, visualization, and multichain support — 5-7 days. Cost is calculated individually, starting from $2,000 for basic and $4,500 for full integration.

Why Sablier Instead of a Custom Contract?

Sablier v2 has been audited by Trail of Bits and Quantstamp, guaranteeing no critical vulnerabilities. It is 10× faster to implement than writing a custom contract from scratch, and gas savings are 30-50% per stream creation. This results in up to $700 monthly savings for 1000 streams, and you avoid the $20k+ cost of a separate audit.

Criteria Sablier v2 Custom Contract
Audit Trail of Bits and Quantstamp Often no formal verification
Reentrancy risk None (deterministic math) High if carelessly implemented
Flexibility Linear and dynamic streams, cliff Requires rewriting code
Network support 8+ networks with unified interface Each network separate deploy
Gas (stream creation) 200k gas ($0.5 at current gas) 300k+ gas ($1.2)
Audit cost savings Built into protocol (up to 80% savings) Requires separate audit ($20k+)

Sablier is more reliable and 10× faster to implement than writing a custom contract from scratch. Gas savings are 30-50% per stream creation. At 1000 streams per month, savings can reach $700.

Typical Use Cases

  • Team vesting: 4-year vesting with 1-year cliff for team and investors.
  • Grant streaming: DAO streams grants monthly instead of upfront payments.
  • Salary in crypto: continuous USDC stream as salary.
  • Protocol rewards: replace custom reward contracts with Sablier streams.

If you want to add streaming payments to your dApp, order a Sablier integration — we'll audit your logic and propose the optimal solution. Get a consultation for your case — contact us.

DeFi Protocol Development

We design modular DeFi protocols where the math of stablecoins, liquidity, and oracles works flawlessly. Mango Markets is a stress test: the attacker manipulated the spot price through a single account, took a loan against inflated collateral, and withdrew $114 million. The oracle took the price from a single source without TWAP. Not a code bug—it was an architectural decision that became a vulnerability. Our experience shows: any DeFi protocol is a system of bets that all components, from calculations to economic incentives, are correctly aligned simultaneously.

We don't write code under the 'if it works, don't touch it' mindset. We model stress scenarios: cascading liquidations, depegs, flash loans. Only then do we build events that won't break the protocol.

Why are oracles a critical component of DeFi?

Most major DeFi hacks started with oracle manipulation. Let's break down the three layers we use in every project.

Spot price as oracle—not an option. Uniswap v2 spot price can be shifted by a flash loan in one transaction. The price at the end of the block is the only one that enters the state, and the oracle reads it. Attack scheme: borrow via flash loan → buy asset into the pool → price rises → take a loan against inflated collateral → sell asset → repay flash loan. One transaction.

TWAP as protection. Uniswap v3 observe() averages the price over a period (30 minutes). Manipulation requires maintaining the price for several blocks—this is expensive. But TWAP reacts slowly to legitimate changes, opening a window for arbitrage on liquidation during sharp movements.

Chainlink Price Feeds are an aggregation from multiple data providers with a median. Standard for lending. Problem: heartbeat 1–24 hours and deviation threshold 0.5%. If the price doesn't move, the feed may not update for a day. In volatile markets—lag.

Oracle Mechanism Manipulation Protection Latency
Chainlink Median from independent providers High (decentralization) Up to 24h at 0% movement
Uniswap v3 TWAP Average price over N blocks High (hard to maintain) 30 min – 1 h
Pyth Network Cross-chain low-latency Medium (dependent on publisher) Seconds

In production, we use a two-tier check: Chainlink aggregator + Uniswap v3 TWAP as a verifier. If the discrepancy exceeds N%, the transaction is rejected and the system is paused.

How to protect a DeFi protocol from flash loan attacks?

Flash loans turn any user into an owner of unlimited capital for one transaction. Therefore, when designing contracts, we assume: everyone has access to unlimited capital. This completely changes the threat model.

Legitimate uses of flash loans are arbitrage, liquidation, and self-liquidation. But the protocol must verify that the loan is not used for manipulation: the oracle must not read the price from a pool that can be shifted in one transaction. We add checks on block.timestamp and minimum liquidity depth.

Key Components of DeFi Architecture

Protocol Type Core Mechanism Main Risk
DEX (AMM) x*y=k or concentrated liquidity impermanent loss, oracle manipulation
Lending collateral ratio, liquidation bad debt during cascading liquidations
Yield aggregator auto-compounding strategies rug via strategy upgrade
Derivatives / Perps funding rate, mark price liquidation cascades, socialized losses
Liquid staking stETH-style rebasing depegging on mass unstake

AMM: From x*y=k to Concentrated Liquidity

Uniswap v2 uses x * y = k. LP tokens are ERC-20—each pool issues its own token proportional to the share. Problem: liquidity is spread across the entire curve, most of it unused.

Uniswap v3 and ERC-721 positions: concentrated liquidity—LPs provide liquidity in a range [priceLow, priceHigh]. Capital efficiency up to 4000x for stable pairs. But ERC-721 breaks vault strategies built for ERC-20. Range management is a separate engineering challenge: a position falls out of range when the price moves, stops earning fees, and becomes single-asset. Protocols like Arrakis Finance automatically rebalance. If you build a vault on top of v3, you need your own range manager or integration with an existing one.

Slippage in v3 is calculated via sqrtPriceX96—96-bit fixed-point math. Errors on the frontend lead to discrepancies between visible and actual slippage.

Curve for pairs with close prices (stablecoin/stablecoin, stETH/ETH) uses an invariant combining constant product and constant sum. Lower slippage within the peg range. Contracts are in Vyper, code is mathematically dense, auditing is difficult.

Lending Protocols: Collateral, Liquidation, Bad Debt

LTV defines the maximum loan against collateral. Liquidation threshold is the level for liquidation. The difference is the buffer for the liquidator. Typical example: LTV 75%, liquidation threshold 80%, bonus 5%. If the price drops 20%+, the position is open for liquidation.

Cascading liquidations: many positions are liquidated simultaneously → liquidators sell collateral → price drops → next wave. LUNA/UST 2022 is a classic cascade.

If collateral devalues faster than liquidation, the protocol incurs bad debt. Aave uses a Safety Module (staked AAVE), Compound uses reserves. Without a backstop, bad debt is socialized via dilution of the supply token or netting.

Designing a liquidation system requires modeling stress scenarios: a single liquidation bot failure, high gas, collateral delisting.

Yield Farming and Incentive Mechanics

Liquidity mining distributes governance tokens to LP providers. Problem: mercenary capital—farmers come, sell tokens, leave. TVL is illusory.

Sustainable mechanics: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking with penalty. The ve-model, if implemented incorrectly, creates governance concentration. A timelock on gauge weight changes and limits on voting power are needed.

What Our DeFi Protocol Development Includes

  • Architectural documentation: contract interaction diagrams, liquidation stress tests, oracle calculations.
  • Implementation in Solidity 0.8.x with OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) and Solmate for gas-optimized base contracts.
  • Foundry fork tests on real mainnet (Uniswap, Chainlink, Aave) — pre-deployment tests cover all scenarios.
  • Audit: at least two independent auditors for TVL over $1M. Code4rena or Sherlock for bug bounty.
  • Deployment with Gnosis Safe 3/5 multisig + timelock 48–72 hours.
  • Monitoring via Tenderly (alerts, simulations), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
  • Post-launch support: updates, patches, upgrades via proxy.

Our Expertise and Experience

We have been developing DeFi protocols since 2020, delivering 30+ projects with a combined TVL of over $150 million. Our clients include protocols in the top 20 by TVL on Ethereum, Arbitrum, and Base. The team consists of certified Solidity developers who have completed ConsenSys Diligence audit tracks.

DeFi basic principles that we apply in practice.

Timelines

  • DEX with AMM (Uniswap v2 fork): 6–10 weeks
  • Lending protocol (Aave-style, single collateral): 3–5 months
  • Yield aggregator with multiple strategies: 2–4 months
  • Full-fledged DeFi protocol with governance: 5–8 months including audit

Cost is calculated individually—contact us for a project estimate.

Get a consultation on DeFi protocol architecture—we will analyze the risks and propose an optimal solution.