Stefan Nikolic

@stefann

Joined on Dec 9, 2024

  • Github: github.com/stefann-01 Email: st.nikolic01@gmail.com LinkedIn: linkedin.com/in/stefann01 X: x.com/stefann__01 Project summary GnoLend is the first lending protocol built using Gnolang, implementing financial primitives for decentralized lending and borrowing. The protocol features lending markets with configurable parameters, variable interest rate models, collateralized borrowing with health monitoring, and liquidation mechanisms for undercollateralized positions. It employs a shares-based accounting system to track user positions, calculates interest based on utilization metrics, and maintains system solvency through real-time risk assessment. For price determination, GnoLend integrates with Gnoswap's liquidity pools, using them as price oracles in the absence of dedicated oracle infrastructure. This approach enables the protocol to obtain reliable price data directly from on-chain sources without requiring external oracle networks, demonstrating how essential financial primitives can be implemented within the current gno.land ecosystem.
     Like  Bookmark
  • Lending Platform on Gno.land ⚠️ This version is deprecated and no longer maintained. Please refer to the latest version. 1. Protocol Overview GnoLend is a non-custodial lending protocol on Gno.land that facilitates lending and overcollateralized borrowing of crypto assets. The protocol operates through isolated lending pools, where each pool contains a single GRC20 token. When users deposit assets into a pool, they receive interest-bearing gTokens, which represent their share of the lending pool. These gTokens accrue interest via a static rate mechanism and are transferable as GRC20 tokens. Users can borrow assets from any pool by providing collateral that exceeds their borrowed position value, with borrowing limits determined by asset-specific Loan-to-Value (LTV) ratios. Lending Pool State Variables Each lending pool maintains the following key data:
     Like  Bookmark
  • @matijamarjanovic matijamarjanovic69@gmail.com https://www.linkedin.com/in/matijamarjanovic/ Project summary As you may already know, @stefann-01 has initiated work on GnoLend, and I have joined him toward the end of the SCP to contribute to its development. We’ve developed a strong interest in DeFi and are excited about the opportunity to integrate decentralized finance concepts with our ongoing work on the gno.land ecosystem. GnoLend is the first lending protocol built using Gnolang, implementing financial primitives for decentralized lending and borrowing. The protocol features lending markets with configurable parameters, variable interest rate models, collateralized borrowing with health monitoring, and liquidation mechanisms for undercollateralized positions. It employs a shares-based accounting system to track user positions, calculates interest based on utilization metrics, and maintains system solvency through real-time risk assessment.
     Like  Bookmark
  • Account abstraction (AA) is a transformative concept in Ethereum, aimed at simplifying and enhancing user experience while enabling unprecedented flexibility for developers. By revisiting the architectural constraints of Ethereum's account model, AA proposes a more dynamic and programmable approach to accounts. It’s a solution born from years of grappling with the limitations of externally owned accounts (EOAs) and contract accounts (CAs), pushing the boundaries of what’s possible on Ethereum. 1. The Origins of Account Abstraction Ethereum's account model divides accounts into two categories: EOAs: Controlled by private keys, EOAs are used by individuals to send transactions and pay gas fees. They are simple but rigid, with their behavior hardcoded into the protocol. CAs: Governed by smart contract code, CAs execute logic defined within them but cannot initiate transactions independently or pay gas fees. This rigid separation served Ethereum's early goals but soon revealed significant limitations. For example, the reliance on private keys led to issues with wallet recovery and security. The inability to program custom account behavior meant developers had to rely on clunky workarounds to implement features like multi-signature wallets or gas payment in tokens other than Ether.
     Like  Bookmark