Today, I went through the Starport whitepaper, the lending kernel built and designed by Astaria.

I really liked reading through it. Mainly because it addresses one key problem with DeFi that I'm sure has been bugging a lot of us: Backwards Compatibility. This has been a glaring pain point across many DeFi protocols to date.

Backwards compatibility refers to whether smart contracts continue functioning as intended after being upgraded or changed. For example, if a popular lending protocol releases LoanContract V2, will existing V1 borrowers

• stop receiving repayments, or

• be unable to provide collateral, or

• just be limited to an outdated environment?

I’ll touch upon all this issue later in the article, but let’s first examine Starport in detail.

---

Starport is designed as a framework for enforcing loan agreements.

The Starport whitepaper introduces a lending framework for building customized lending protocols on Ethereum.

At its core, Starport consists of two key components:

• The Starport contract acts as the main entry point for originating new loans and refinancing existing loans. Its key responsibility is to enforce the agreements and rules around originating or refinancing a loan. It also maintains a record of the current state of any loan by representing critical loan details in a Loan struct, hashing this struct into a unique loanID, and storing the hash on-chain. This “loanID” then acts as a handle for referencing the loan in future transactions.

• The Custodian contract is the entry point for loan repayment or settlement/liquidation. Its duty is to hold and custody the borrower's collateral assets, as well as enforce the conditions around repaying or settling the loan as defined by the relevant Pricing and Settlement modules (see below). The Custodian can be customized by borrowers and lenders, but Starport will provide a default gas-efficient implementation.

The whitepaper notes that the team will release a default Custodian contract optimized for gas efficiency. This is an important design decision for two key reasons.

1. Firstly, having a ready-made Custodian implementation can significantly reduce barriers to getting started building lending protocols on Starport. Developer teams can simply integrate with the default Custodian initially rather than having to build their own custom collateral management and liquidation logic from scratch. The accelerated time-to-value is super attractive!

2. Starport's core team can ensure this default contract itself is optimized at the Solidity code level for minimum gas consumption through prudent data storage patterns and external call minimization. With gas prices being the nemesis of so many DeFi users, squeezing efficiencies on key transactions like settlements and repayments is impactful. Over time, I suspect this performant default will become the competitive benchmark as more advanced teams publish custom Custodian variants. The end result is leaner gas costs for end users.

In addition to these core pieces, Starport utilizes a modular architecture consisting of three key modules:

• The Pricing module defines the specific conditions around repaying a loan or refinancing an existing loan. For example, it may specify an interest rate and repayment schedule. It provides these repayment and refinance rules to the Custodian and Starport contracts, respectively.

• The Status module simply specifies whether a given loan is currently active or inactive. An inactive status means the loan may be settled/liquidated. An active status means it may be repaid. This status can flip over time if settlement does not occur.

• Finally, the Settlement module defines the specific conditions around settling/liquidating an inactive loan, such as which assets may be liquidated and how. It also specifies an authorized fulfiller who is allowed to perform settlement.

The primary purpose of Modules within Starport's architecture is (hopefully) to enable customization and extensibility of the core lending protocol. Different teams can develop their own Modules that best suit the lending use case they are targeting - whether that's undercollateralized loans, specialized pricing models, support for exotic NFT collateral etc.

By making Modules replaceable, many variations of lending products can be built while reusing the solid foundation Starport provides around loan data, agreement enforcement, settlement infrastructure.

Modules only need to implement the specific interface functions documented that the Starport Core contracts rely on to provide parameters. Teams can implement Modules in the language of their choice and register them with Starport Core. This keeps custom logic abstracted out and loosely coupled from the base layer.

It would be interesting to see modules purpose-built for use cases like RWAs, NFT valuations, yield-generating collateral, etc. This would showcase the versatility of the framework. Let me elaborate on how that could work and what it would enable:

1. Real World Assets as Collateral: New Pricing and Settlement modules could be built to specifically support real world assets (RWA) like invoices, royalties, property as loan collateral. Key enhancements:

   1. Custom pricing models tuned for volatility and liquidity profiles of different RWA classes. Factoring in historical benchmark performance data.

   2. Oracle integrations to reliably source real-time valuations for the assets. Whether leveraging professional appraisal services or tokenization platforms providing feed.

   3. Business logic around compliance, KYC, jurisdiction nuances when accepting and liquidating RWAs.

   This unlocks an entirely new category of undercollateralized and cross-border lending acceptable only against real-world assets.

2. NFT Valuations: Similarly, purpose-built modules could enable using NFTs as collateral. NFTs present unique challenges due to their non-fungible nature and the complexity of valuation. Custom modules can account for this:

   1. Historical NFT sales data-based valuations - e.g. rarity traits, collection multiples. Accounting for overall market cycles.

   2. Allowlists approved by underwriters indicating NFT collections deemed acceptable based on expert review.

   This provides a decentralized infrastructure for NFT backed lending catering to native requirements of Web3 borrowers.

3. Yield Generating Assets: Accepting yield generating collateral like Yearn vault shares, AAVE aTokens, and managing periodic yield realizations also requires custom logic:

   1. Settlement modules that delay or avoid liquidation if yield revenue is sufficiently covering interest costs.

   2. Auto-compounding realized yield back into collateral as a repay strategy.

   3. Governance powered yield routing to opted strategies.

   This enables entirely new lending products with interest payments covered by collateral yields.

I’m speculating with the examples above. Anyhow, we can expect something.

There are three distinct roles for actors within Starport

• Borrower provides collateral assets in exchange for debt.

• Lender provides debt to the borrower, with the expectation they will repay the loan later.

• Fulfiller actually executes transactions like loan origination or settlement on behalf of borrowers and lenders.

(A single entity may take on multiple roles)

The lending works as follows

1. Originate

The Originate action is what creates a new loan in Starport. It enforces the agreement and transfers to originate a new loan between a borrower and lender.

Specifically, when a loan is originated, a few key things happen:

1. Collateral is transferred from the borrower to the Custodian contract. This collateral lives in the Custodian for the lifespan of the loan.

2. Debt is transferred from the lending party to the borrower. This represents the actual funds that the borrower requested to borrow.

3. Any other additional conditions are enforced - things like additional transfer fees, repayment terms, etc. These extra conditions are specified by the various Modules.

4. The Starport contract updates its storage to create a new Loan struct representing this loan, with details like the borrower address, loan amount, collateral details, etc.

5. This Loan struct is hashed into a unique loanID that serves as an identifier for this loan in future transactions.

6. The loan transitions into an OPEN state, indicating origination is complete.

Originate handles the enforcement and transfers to open a new loan between a borrower and lender, with details stored in Starport via a Loan struct and loaned.

2. Repayment

The Repayment action allows the borrower to repay the loan they originated and reclaim their collateral from the Custodian.

1. The borrower makes repayment transactions to the Custodian contract based on repayment terms defined in the Pricing module. This repays outstanding debt owed to the lender.

2. Upon repaying the debt per the Pricing module's conditions, the Custodian transfers back the borrower's collateral that it had been holding in custody.

3. Starport transitions the loan state to CLOSED indicating the repayment is settled.

Repayment allows terminating an active loan by paying back debt and getting back posted collateral.

3. Settlement

Settlement refers to liquidating collateral of an inactive loan to repay the lender. This can only happen when loan Status has flipped to inactive per the Status module.

1. The Settlement module defines conditions like which collateral can be liquidated, haircuts to apply, and who the authorized fulfiller is to conduct settlement.

2. The authorized fulfiller triggers settlement on the Custodian contract based on these conditional parameters.

3. The Custodian liquidates the borrower collateral per module conditions and uses it to repay original debt + penalties owed to the lender.

4. Any remaining collateral after repaying lender can be returned to borrower.

5. Like repayment, the loan state transitions to CLOSED afterwards.

Settlement provides a liquidation mechanism for deals gone bad where borrower cannot or did not repay normally.

4. Refinance

Refinancing allows replacing the existing lender on a loan with a new lender. This closes out old loan and creates new one while accumulating interest owed:

1. The fulfiller initiates refinancing based on conditions like interest rate and repayment schedule from Pricing module.

2. Starport computes total debt outstanding on current loan and enforces transfer: new lender pays this to old lender.

3. Old loan transitions to CLOSED state while new Loan struct and loanID are created for the refinanced loan between borrower and new lender. Pricing parameters updated.

4. New loan begins with state OPEN - it can now be repaid or liquidated by new lender separately.

Refinance gives the means to replace the financing party while carrying over the borrower's obligations to a fresh loan record.

In the Starport framework, ensuring the authentication of a fulfiller, who is responsible for executing transactions on behalf of the borrower or lender, is a critical component.

There are three distinct methods provided for this purpose, each with its own mechanics and requirements.

1. msg.sender Authentication

The msg.sender method relies on the basic principle of Ethereum smart contracts. In this context, msg.sender refers to the address that is directly initiating the transaction.

In the Starport framework, a transaction can be authenticated if the msg.sender (the address executing the transaction) is either the borrower's or the lender's address.

Suppose Arhat is a borrower who needs to perform a transaction related to his loan. Arhat will execute the transaction from his Ethereum account (or EOA). The smart contract will check if msg.sender (the address from which the transaction is initiated) matches Arhat's address. If it does, the transaction is deemed authenticated, as it is directly executed by the borrower.

2. Approval Authentication

This method involves a process of approval, where either the borrower or lender grants permission to another entity (a different Ethereum address) to execute transactions on their behalf.

In practical terms, this could be implemented through a smart contract function where the borrower or lender calls an approve function. This function records the address of the approved entity and possibly other parameters such as the amount or type of transaction they're allowed to make.

It's important to note that the approval must be exclusive – it has to come from either the borrower or the lender, not both. This ensures clarity in transactional authority and prevents conflicting authorizations.

Let's say JJ, a lender, wants to allow a third party, named Kai, to handle certain transactions. JJ would use the approval method to grant Kai permission. When Kai initiates a transaction, the smart contract checks if Kai's address is approved by JJ for this type of transaction. If the check passes, Kai's transaction proceeds.

3. CaveatEnforcer.SignedCaveats

This method is based on the EIP-712 standard, which enables structured data to be signed and verified in Ethereum. It allows for clearer and more secure interactions than simple hexadecimal strings.

In this method, either the borrower or lender signs a structured data packet (a "struct") that specifies the conditions under which a transaction can be executed. This could include details like transaction amounts, types, or expiry dates.

Once the struct is signed, it's passed to a contract called CaveatEnforcer. This contract validates the signature against the known addresses of the borrower or lender to ensure it's legitimate.

The CaveatEnforcer contract can also enforce additional conditions based on the contents of the signed struct. For example, it might allow a transaction only if it's within a specified amount range or before a certain expiry date.

Consider a borrower, Omar, who wants to authorize transactions under specific conditions. He signs a struct with terms like a maximum repayment amount and a validity period. When a transaction is initiated under these terms, the CaveatEnforcer checks Omar's signature and the transaction conditions. If both match Omar's specifications, the transaction is authenticated.

These three methods in the Starport framework offer a range of options for authenticating transactions, from the straightforward use of msg.sender to more complex conditional approvals using EIP-712 signed data. This flexibility allows for secure and tailored transaction execution, fitting different needs and scenarios within the lending protocol.

Representment is a key mechanism used within Starport…

…to optimize storage and gas costs associated with maintaining data availability for loan state.

1. Critical loan details like collateral amount, borrower address, loan terms etc. are stored in a single Starport.Loan struct when a loan is originated.

   1. When a loan is originated in Starport, all critical details such as collateral amount, borrower address, loan terms, etc., are consolidated into a single Starport.Loan struct. This struct becomes the central repository of all relevant data for the loan.

2. The Starport.Loan struct is then hashed using the keccak256 algorithm. This hashing process simplifies the diverse and potentially large amount of data in the struct into a single bytes32 value, known as the loanID. This loanID is stored on the blockchain, while the actual Starport.Loan struct itself is not stored on-chain. This approach significantly reduces the amount of data stored on the blockchain.

3. When the loan struct is hashed and the loanID is stored, a Representment event is emitted. This event contains the data from the Starport.Loan struct and is emitted for the purpose of indexing. Front-end systems or other off-chain services can index this event, effectively keeping track of the loan's details without needing to store all the data on-chain.

Now what happens in any subsequent transaction like repayment or liquidation

1. the external system interfacing with Starport must "represent" the original Starport.Loan struct. This representation is based on the data they have indexed from the earlier Representment event.

2. the Starport contract then re-hashes this represented Starport.Loan struct to ensure it matches the original stored loanID. This step is crucial for verifying that the data being used in the transaction is consistent with the original data of the loan.

3. If the hashes match, the Starport contract recognizes that the represented data is accurate and continues with the transaction using this data.

This way, all critical loan details are NOT stored redundantly each transaction. Only the hash committing to the state is stored. Representing original data from events massively saves storage and gas.

By storing only the hash (loanID) and not the entire data set, and by relying on external systems to represent the original data from indexed events, Starport achieves a significant reduction in storage and gas costs. This method allows critical loan details to be verified without redundant storage of data for each transaction.

It’s important to note that Starport is designed as a lending kernel/framework…

…for composing and enforcing the agreements and rules around originating, repaying, settling, and refinancing loans on Ethereum. It provides the core data availability and agreement enforcement layer that any lending protocol can build on top of by plugging into Starport's modular architecture.

Starport stores all critical information about a loan on-chain in a Loan data struct. This includes:

• Borrower address

• Collateral asset type & amounts

• Loan principal amount

• Interest rates

• Other terms

This Loan struct represents the entire state of the loan. Starport handles storing this struct on-chain, updating it when the state changes, and deleting it when loan closes out. By reliably maintaining this data on-chain, Starport solves a hard computer science problem around availability and access to loan state information that any lending protocol needs.

Based on each loan's data, Starport also enforces the actual asset transfers and rules required when key actions happen like loan creation, repayment, default settlement etc.

For example, during origination, it handles:

• Transferring collateral assets from borrower to Custodian

• Transferring principal loan amount from lender to borrower

During repayment, it handles:

• Computing repayment amounts owed per pricing terms

• Transferring repayment amount from borrower to lender

• Returning collateral to the borrower

By encoding and enforcing these asset transfer agreements for various stages of the lending lifecycle, Starport provides critical financial logic wiring that lending protocols can hook into.

Finally, Starport exposes the various modules like Pricing, Settlement, etc. Specifically designed to allow custom logic for interest rates, liquidation conditions, etc., to be defined and plugged in.

This modular approach enables lending protocols to leverage all the heavy lifting Starport does around data and agreement enforcement while customizing certain aspects like interest rate modeling for their particular needs.

So Starport itself does not aim to be a full-fledged lending application. Rather, it handles:

• Enforcing the transfers and conditions required during key loan transactions (origination, repayment, etc.)

• Storing/managing the critical loan state data like collateral amounts, borrower addresses, loan terms, etc.

• Exposing hooks and modules for pricing models, settlement logic, and interest rates to be plugged into Starport.

This modular approach allows developers to leverage Starport's infrastructure to then build their own custom lending protocol on top simply by defining pricing parameters, liquidation conditions, etc.

Is Starport the answer to Backwards Compatibility Issue?

As I mentioned earlier, I believe Starport does tackle the Backwards Compatibility issue within smart contracts.

When any DeFi protocol releases an updated version of a contract, there's a potential risk that existing functionalities might break.

For instance, if a lending protocol launches a new version of a LoanContractV3, there could be concerns about whether existing borrowers will continue to receive repayments or if they can still provide collateral as intended.

In Starport, the core components that handle critical functions like loan origination and repayment are immutable. This means they are not subject to change, ensuring that existing loans continue to operate as intended, regardless of updates in other parts of the system. The more dynamic aspects of the lending protocol, such as pricing models, risk parameters, and collateral criteria, are implemented in separate, interchangeable modules. This modularization allows for these components to be updated or swapped without affecting the core contract logic.

With this design, new loans can take advantage of the updated logic in these modules, while existing loans maintain their functionality using the old module hooks. This selective upgradability ensures that ongoing loans are not disrupted by changes in the system. This approach allows for continuous innovation in areas like risk models and loan products, without rendering existing loans obsolete. Backward compatibility is effectively maintained, ensuring that both new and old loans can coexist and function correctly within the same system.

For developers, this clear separation between the immutable loan processing logic and the upgradable parametric logic allows for more straightforward testing and verification. They can ensure that the interaction between old and new loans under different modules remains stable and predictable.

Thoughts

I believe Starport introduces an elegantly designed, flexible architecture for powering decentralized lending protocols. A few aspects that stand out to me:

The modular approach, allowing custom implementations of components like Pricing, Settlement terms, and Custody, seems quite extensible. I expect this will promote various modules catering to different collateral assets, risk models, or target niches.

Furthermore, the ability to evolve modules independently without needing to upgrade the core protocol helps future-proof things.

As I mentioned earlier, Backwards compatibility has been a major pain point across DeFi, so Starport mitigates this through its modular approach.

The data storage and representment optimizations are technically exemplary. By avoiding redundant on-chain writes, I believe Starport can realize ultra-lean gas costs for transactions like loan origination and repayment. This level of efficiency significantly expands the design space for innovative lending dApps.

I also find the flexibility around Custodian contracts quite unique. Empowering borrowers and lenders to bring customized custody implementations tuned to their security preferences or institutional requirements is creative. This likely broadens Starport's appeal across both retail and sophisticated institutional use cases.

I've got to say, on paper, this looks too good.

Wrapping up intricate lending processes – like making sure agreements are followed, handling compliance, and sorting out settlements – into neat, adjustable modules is really a prime example of what smart contracts are all about.

It's tackling this tricky part of lending infrastructure with a neat on-chain solution, and honestly, that's pretty impressive. I'm genuinely excited to see the kind of creative lending protocols and structured products that developers are going to build using this framework.

---

Thank you for reading through, and subscribe below for regular post updates.

I’d also appreciate it if you shared this with your friends, who would enjoy reading this.

You can contact me here: Twitter and LinkedIn.

Please also find the research I contribute to at L2 Iterative Ventures Substack for more detailed institutional insights.

---

Previous Research:

1. Decoding & Democratizing Web3

2. P2E: A Shift in Gaming Business Models

3. Stablecoins: Is there hope?

4. If you don't control your data why do you trust it

5. Primer on L2 Scaling Solutions

6. Understanding User Dynamics in DeFi

7. Intro to Lending and Borrowing Mechanics in DeFi

8. Part 2: DeFi Deep Dive on COMP, AAVE, and MKR

9. Best Way to Create Value with Data in Web3

10. Building a Decentralized Climate Finance DAO

11. Org vs. DAOs: Governance & Growth in Modern Society

12. ERC-4337: The Future of Ethereum Token Standards

13. Identity Without Borders: Decoding My Online Identity

14. Web3s 3-Wave Model of Evolution of Complex Systems

15. Understanding Tokenomics: Case Study of dYdX

16. DeFi Hacks Unveiled: What We've Learned from Q2

17. Voting Mechanisms & Incentives for Governance in DAOs

18. Uniswap’s Fee Switch Dilemma

19. MakerDAO's Endgame: 5 Phases and 14 MIPs

20. Liquid Staking Tokens: Can They Bounce Back?

21. Binance Smart Chain: Luban Hard Fork

22. crvUSD: A Stable Alternative?

23. friend.tech: Tokenizing Incentives for "friends"

24. MEV Endgame: Exploring Mempool Privacy Schemes

25. Privacy Pools: Towards Practical Privacy & Compliance with Smart Contracts

26. Rollup Roulette: Deep Dive into Shared Liquidity

27. Modeling Player-Centric P2E (Tokenless) Tokenomics

28. Unpacking FRAX v3: Hybrid Assets, Modular Design

29. zkProofs & Recursive SNARKs