Skip to main content

Smart Contracts

Pulsar is a DeFi protocol that uses smart contracts to facilitate swap tokens and interactions on the blockchain. Pulsar protocol has three main smart contracts: Factory, Pair, and TWAMM contract.

The Factory contract allows for the creation of liquidity pools, while the Pair contract manages the underlying assets (two ERC20 tokens) and their corresponding liquidity tokens. The TWAMM contract, also known as the Time-Weighted Average Market Maker is responsible for handling instant swap, term swap and facilitating liquidity provision and removing.

Together, these contracts enable the Pulsar Protocol to provide decentralized, automated finance for a range of assets on the Ethereum blockchain.





Factory is deployed at 0x408f66057163d829a30d4d466092c6b0eebb692f on the Ethereum Mainnet, at 0xB5B03706C24c79D3F7a368b30562a1711d74F688 on the Mantle, and at 0x336a2f76d2be24e7cb6f468665a4277d4d617d00 on the Arbitrum One.

The factory holds the generic bytecode responsible for powering pairs. Its primary job is to create one and only one smart contract per unique token pair. It also contains logic to turn on the protocol charge.





TWAMM is deployed at 0xcd43aba971bef65555d877657f83093ddfb885b8 on the Ethereum Mainnet, at 0x8E76C60461eBd76fE54960F50f436ccF24F0D9a6 on the Mantle, and at 0x04538b69f9a637500ecf2b705e05ab38bab27b7e on the Arbitrum One.

The TWAMM, which uses the Library fully supports all the basic requirements of a user-friendly front-end offering Instant Swap, Term Swap and Liquidity Management functionality.

Address List#

Ethereum Mainnet0x408f66057163d829a30d4d466092c6b0eebb692f0xcd43aba971bef65555d877657f83093ddfb885b8
Arbitrum One0x336a2f76d2be24e7cb6f468665a4277d4d617d000x04538b69f9a637500ecf2b705e05ab38bab27b7e




The Pair, which uses the BinarySearchTree, LongTermOrders, OrderPool have two primary purposes: serving as time weighted average market makers of two ERC20 tokens and keeping track of pool token balances. They also expose data which can be used to execute Long Term Orders.



The Library provides a variety of convenience functions for fetching data.



The main abstraction for implementing long-term orders is the OrderPool. The order pool represents a set of long-term orders, which sell a given token to the embedded AMM at a constant rate. The token pool also handles the logic for the distribution of sales proceeds to the owners of the long-term orders.

The distribution of proceeds is done through a modified version of algorithm from Scalable Reward Distribution on the Ethereum Blockchain. Since order expiries are decoupled from proceeds distribution in the TWAMM model, the modified algorithm needs to keep track of additional parameters to compute proceeds correctly.



In addition to the OrderPool, the LongTermOrders struck keep the state of the virtual order execution. Most importantly, it keep track of the last block where virtual orders were executed. Before every interaction with the embedded AMM, the state of virtual order execution is brought forward to the present block. We can do this efficiently because only certain blocks are eligible for virtual order expiry. Thus, we can advance the state by a full block interval in a single computation. Crucially, advancing the state of long-term order execution is linear only in the number of block intervals since the last interaction with TWAMM, not linear in the number of orders.



BinarySearchTree (BST) is a data structure that is used to store and organize data in a hierarchical manner. In Pulsar's particular BST, the nodes are long-term order expiration block heights. The tree allows for nodes to be inserted and deleted, and when execute virtual orders, it will retrieve a list of expirations from the lastVirtualOrderBlock up until the current time, as well as a list of expirations for the next week.

Fixed Point Math#

This implementation uses the PRBMath Library for fixed point arithmetic, in order to implement the closed form solution to settling long-term trades. Efforts were made to make the computation numerically stable, but there's remaining work to be done here in order to ensure that the computation is correct for the full set of expected inputs.