Starport primary-source snapshot

Fetched: 2026-05-08 UTC

1) Official docs overview

Source: https://docs.astaria.xyz/concepts/starport

Selected excerpts from the official docs:

Starport is a simple kernel framework used for composing lending protocols on the Ethereum Virtual Machine (EVM).

Starport itself is not a lending protocol, but instead handles the data availability and agreement enforcement that is required for any lending protocol.

In Starport, there are three distinct actors: borrowers, lenders, and fulfillers.

Additional signals from the source:

  • The docs are explicit that Starport should be cataloged as infrastructure rather than as a standalone market.
  • The main mechanism is the split between a reusable core and app-specific lending logic layered above it.

2) Docs-derived architecture summary

Source: https://docs.astaria.xyz/concepts/starport.md?ask=What%20are%20Starport%27s%20core%20contracts,%20module%20interfaces,%20supported%20assets,%20unsupported%20asset%20types,%20and%20main%20actors%3F

Selected excerpts from the docs query endpoint:

Core contracts: Starport and Custodian

Module interfaces / modules: Pricing, Status, and Settlement

Supported assets: collateralized loans and options for: ERC-20, ERC-721, ERC-1155

Unsupported asset types: rebasing tokens; fee-on-transfer tokens

Additional signals from the source:

  • The docs’ own retrieval endpoint cleanly confirms the kernel boundary: two core contracts plus three pluggable module surfaces.
  • The unsupported-token caveat matters because it narrows the “any asset” framing often used at the app layer.

3) Whitepaper abstract and core/kernel framing

Source: ../whitepapers/starport-whitepaper.tex

Selected excerpts from the first-party TeX source:

Starport is a simple kernel framework used for composing lending protocols on the Ethereum Virtual Machine (EVM).

Starport itself is not a lending protocol but instead handles the data availability and agreement enforcement that is required for any lending protocol.

Any existing or future lending protocol can be constructed by implementing the three primary Starport modules \emph{Pricing}, \emph{Status}, and \emph{Settlement}.

Starport has the capability to support collateralized loans and options for any ERC-20, ERC-721, or ERC-1155 as either collateral or debt. Rebasing and fee-on-transfer tokens are not supported.

Additional signals from the source:

  • The whitepaper strengthens the interpretation that Starport’s real novelty is kernelization, not a novel borrower-facing market format by itself.
  • The phrase “any existing or future lending protocol” suggests Astaria is presenting Starport as a generalized lending substrate, not just a private internal component.

4) Loan lifecycle, settlement rights, and refinance path

Source: ../whitepapers/starport-whitepaper.tex

Selected excerpts from the first-party TeX source:

Originate is the action of enforcing conditions in order to create a new loan.

Settlement is the process of resolving a loan that has transitioned to an inactive status.

Settlement conditions are provided by the Settlement module. The Settlement module returns the authorized fulfiller and conditions of settlement. Specifying the authorized fulfiller is optional. If an authorized fulfiller is not specified any fulfiller can provide the conditions of settlement. Otherwise, settlement is restricted to the authorized fulfiller.

Refinance is the action of replacing an existing lender with an incoming lender with no change to the underlying borrower.

Additional signals from the source:

  • Starport makes settlement-executor rights an explicit design surface rather than hard-coding one liquidation path.
  • Refinance is a first-class lifecycle action at the kernel level, which helps explain why Astaria can treat refinance/recall logic as core rather than peripheral.

5) Authentication, side transfers, and representment

Source: ../whitepapers/starport-whitepaper.tex

Selected excerpts from the first-party TeX source:

There are three methods to ensure the fulfiller is authenticated by the borrower or the lender to transact on their behalf.

msg.sender must be equal to either the borrower or lender

An EIP-712 signed struct that enforces conditional approval from either the borrower or lender

additionalTransfers is a concept within originate that allows the fulfiller to reimburse themselves or other entities … for cost incurred to perform the transaction or an additional reward for executing the transaction.

Representment is a data availability strategy that reduces storage requirements and as an effect reduces transaction gas consumption.

Additional signals from the source:

  • The real control surface is not just interest-rate logic; it also includes who can act for whom, what side payments are permitted, and how loan state is re-presented off-chain/on-chain.
  • “Representment” is analytically useful because it shows Starport optimizing for compact core state plus event-indexed external reconstruction.

6) Repository README: deployments and audit posture

Source: https://raw.githubusercontent.com/AstariaXYZ/starport/master/README.md

Selected excerpts from the first-party README:

Starport is a kernel for building lending protocols.

Note: The canonical contracts for Starport, do not include modules. The modules included in this repository should be considered unsafe unless explicitly named in the audit report.

Astaria engaged Certora to audit and formally verify the security of Starport.

Additional signals from the source:

  • The README makes a subtle but important trust distinction: the core deployment is treated as canonical, while modules remain a separate trust surface.
  • That supports a mechanism reading where security and governance migrate upward into module selection and app-layer composition.

7) GitHub organization context

Source: https://github.com/AstariaXYZ

Selected excerpts/signals from the public organization page:

  • The org mission is “instant liquidity for any on-chain asset.”
  • The public repos include starport, starport-whitepaper, astaria-core, and v1-core.
  • The repo description says starport is “a kernel for building lending protocols,” while v1-core is “a modular lending protcol built on Starport for flexible and intent driven loans.”

Why it mattered:

  • The org page provides the cleanest first-party evidence that Starport and Astaria v1 should be treated as separate analytical layers: kernel versus application.

Working conclusion

Starport is best cataloged as modular lending-kernel infrastructure / loan-state enforcement framework / refinance-capable credit substrate. The most reusable insight is that it moves practical authority away from one protocol-wide pool design and into a narrower core plus multiple pluggable control surfaces: pricing, status, settlement, fulfiller authentication, authorized settlement execution, and the app-layer protocol that chooses how to compose those pieces.