Integration with NFTfi
You're building a landing platform or NFT marketplace, and users request the ability to take out a loan against an NFT with a fixed term and fixed rate. Without liquidation oracles or AMM — only peer-to-peer. NFTfi is one of the oldest protocols, audited and with extensive documentation. However, integration requires correct handling of EIP-712 offers, state monitoring, and race conditions. We implement full integration: from offer signing to loan monitoring via subgraph.
The core of the protocol consists of two key contracts: NftfiHub (registry and router) and DirectLoanFixedOffer (fixed-rate loans). Since v2.1, DirectLoanFixedOfferRedeploy with ERC-1155 support has been added. The typical flow: the borrower locks an NFT, receives ETH or USDC, and if not repaid, the NFT transfers to the lender. No liquidation oracles — only clean fixed-term loan.
| Contract | Version | Purpose |
|---|---|---|
| NftfiHub | v2.0+ | Registry and router for all loan types |
| DirectLoanFixedOffer | v2.0 | Fixed-rate loans with ERC-721 |
| DirectLoanFixedOfferRedeploy | v2.1 | ERC-1155 support and updated logic |
How the NFTfi protocol works
- Borrower calls approve for the NFT to the NFTfi address, then accepts an offer via acceptOffer.
- Lender creates a signed off-chain offer (EIP-712) stored in NFTfi's database or your backend.
- Upon acceptOffer, the contract transfers the NFT to itself, sends tokens to the borrower, and mints a promissory note NFT (ERC-721) to the lender.
- At expiry: payBackLoan from the borrower or liquidateOverdueLoan from the lender.
What is the offer structure (EIP-712)?
Integration via offer signing is where most errors occur. The offer contains:
struct Offer { uint256 loanPrincipalAmount; uint256 maximumRepaymentAmount; uint256 nftCollateralId; address nftCollateralContract; uint32 loanDuration; // in seconds uint16 loanAdminFeeInBasisPoints; address loanERC20Denomination; address referrer; } The signature is created via signTypedData in ethers.js or viem, using the NFTfi contract's domain separator. The domain separator includes the chainId — an offer for Ethereum mainnet is invalid on Goerli, even if the contract address matches. See EIP-712 for details.
Common mistake: mishandling intermediate loan states
A loan can be in states: Active, Repaid, Liquidated, or in an edge case — when the block with payBackLoan is mined after loanDuration expires but before liquidateOverdueLoan is called. The contract accepts both calls in a short window (usually 2–5 blocks, 30–60 seconds on Ethereum, 4–10 seconds on Polygon). If the frontend does not update the status atomically, a user may see an active loan that has already been liquidated.
Recommended approach: listen to LoanStarted, LoanRepaid, LoanLiquidated events via ethers.js provider.on or a The Graph subgraph. The subgraph is preferable for UI — it allows complex queries (all active loans for a collection, loan history for an address). On-chain events give near-zero latency but require manual filtering. The subgraph delays up to 30 seconds but queries are 10x simpler for analytics.
| Monitoring method | Latency | Query complexity | Reliability |
|---|---|---|---|
| On-chain events (ethers) | Real-time | Low — manual filtering needed | High (no infrastructure dependency) |
| The Graph subgraph | ~30 seconds | High — GraphQL with aggregations | Medium (depends on node) |
Why choose NFTfi for P2P lending?
NFTfi is one of the oldest protocols in this niche with audited smart contracts and extensive documentation. Off-chain offers reduce gas costs for the lender (no transaction needed to create). Supported currencies include ETH, USDC, DAI, and other approved ERC-20 tokens. Using the @nftfi/js SDK accelerates development — the SDK is 2x faster to implement than raw ABI integration. The average acceptOffer transaction on Ethereum costs about $50 in gas; on Polygon, under $1. Our integration packages start at $3,000. We guarantee quality integration with audited contracts and extensive experience. Our team has completed over 15 projects with NFTfi. Order NFTfi integration for your project — get a consultation tailored to your case.
What is included in the integration
- SDK/library: Official @nftfi/js for fast integration or direct ABI work for full gas estimation control.
- Subgraph queries: GraphQL for active offers, loan history, collection data. Integrated via @apollo/client or urql.
- Loan currencies: ETH, USDC, DAI, and other approved ERC-20s. Requires approve logic for each currency from the lender before offer creation.
- Referral system: Support for referrer address in offers — a way to monetize the integration.
Our NFTfi integration includes peer-to-peer lending with fixed-term loans, utilizing EIP-712 offers and smart contracts.
Checklist of common integration errors
- Incorrect chainId in domain separator — offer invalid in another network.
- Missing approve for NFT before acceptOffer — transaction reverts.
- Ignoring LoanLiquidated event after payBackLoan — state desync.
- Misinterpreting loanDuration in seconds — confusion with minutes.
- Missing deadline check — outdated offers can be accepted.
Deliverables
- Full documentation of integration (API, events, subgraph queries).
- Access to subgraph endpoints and dashboard.
- Training for your team on offer signing and monitoring.
- 1 month of post-launch support and bug fixes.
Process
- Study ABI and test on testnet (1 day). Deploy a test NFT, manually create a loan via contract, verify all events.
- Backend integration (1–2 days). Store and relay offers, webhooks for loan events.
- Frontend components (1–2 days). Offer creation form, active loans display, repayment flow.
Timeline estimates
Basic integration — creating and accepting offers, loan monitoring — 3–5 days. Full lending UI with collection analytics and automated offer creation — 1–1.5 weeks. Contact us to discuss details — we will tailor an optimal plan.