Community market proposals

Open proposals, reviewed lending activation

Projects can prepare a proposal without membership or a listing payment. The first proposal format targets Morpho markets. A wallet signature identifies the submitting account; it does not prove that account controls the token project.

The proposal contains the collateral and loan contracts, collateral type, oracle, interest rate model, liquidation threshold, requested exposure limits, liquidity plan, liquidation plan and evidence URL. Popularity is not a substitute for reliable pricing or executable liquidation depth. An LP token needs a review of the underlying assets, withdrawal mechanics and valuation. This format accepts fungible ERC-20 collateral; a nonfungible Uniswap position requires a separately reviewed wrapper or vault and cannot be deposited directly.

At serevin.app/projects, connect your wallet and sign a message to submit a proposal. Serevin stores the signed proposal and review records in Cloudflare D1 and returns an immutable proposal identifier. This does not send a blockchain transaction or authorize a token transfer. Downloading a draft saves it locally without submitting it.

Show where the lending funds come from

Describe collateral trading depth and lending capital separately. A trading pool can provide an exit route for collateral; it does not automatically supply the loan asset to a lending market. Token supply, launch liquidity and a proposed supply cap are not proof that loan funds are available.

Identify the project treasury or voluntary lenders, the loan asset and amount, any conditions, and the evidence supporting each commitment. Label capital as already funded, committed with conditions, or planned. A statement in a proposal is not an escrow deposit or an enforceable funding guarantee; reviewers still need to verify it.

Submitting or approving a proposal does not reserve Serevin funds, allocate staking rewards or activate borrowing. Lending availability depends on actual loan assets, reviewed market settings and the separate activation process. Do not send tokens to an implementation address or a proposal identifier.

What both administrators approve

The identifier hashes a canonical proposal together with the submitting wallet and chain identity. Each administrator signs an approval for that identifier after reviewing the complete contents. Previously unsubmitted content receives a different identifier with no inherited approvals. Submitting content the same wallet has already sent returns its existing record and current reviews. The same administrator cannot satisfy both approvals.

Review signatures, timestamps and changes of decision are recorded in Cloudflare D1. Either administrator can revoke their own review of a current proposal. A superseded proposal retains its reviews as history and accepts no further review changes. A change to the configured reviewer set or policy version invalidates earlier-policy reviews for release status. This is offchain review evidence, not an onchain governance transaction or an independent audit.

Owners can retrieve their own proposals; configured administrators can retrieve the latest review queue. Signed access shows up to the 50 most recent available records, not a complete history. Each reviewer is shown as not yet reviewed, approved or review revoked, with a timestamp where recorded. A revoked review does not by itself mean rejection or specify requested changes.

Open Private feedback on a stored proposal, then sign to load its conversation. The proposing wallet and current Serevin reviewers can ask evidence questions and add replies. Each plain-text note is retained with its wallet signature, exact proposal and reviewer-policy snapshot. The application checks the signature before displaying it. Recorded times are supplied by the server, not signed timestamps.

Feedback does not approve, revoke, reject or activate a market. Notes cannot be edited or deleted through the interface. Identical text from the same wallet returns its original record, even after later policy changes. A signed read shows the 25 most recent notes, with an indication when older notes are retained. Switching the wallet, network, connector or selected conversation clears the feedback draft. If a submission response is uncertain, reload the conversation before trying again.

Use as a new draft copies a proposal belonging to the connected wallet into the form. It does not replace, withdraw or supersede the original. An unchanged copy cannot be submitted from this mode. The copy clears when the wallet account, network or connector changes and is not saved between page visits. Download a draft to retain your own copy. Returning to previously submitted content preserves that record’s existing reviews.

Requests use expiring one-use wallet signatures. There is no public directory of unreviewed submissions, and submitted evidence links are not fetched automatically. The proposal binds the evidence URL, not the content hosted at that URL; reviewers must check for changes in the underlying evidence.

Replace a proposal without losing its history

On a proposal from your connected wallet, choose Prepare an amendment. Edit the replacement and review the previous and new values before choosing Sign and replace proposal. The wallet message binds the exact source identifier, the content digest of every replacement field, the chain, origin, current reviewer policy, one-use request and expiry. Only the submitting wallet can replace its proposal.

Serevin saves the new proposal and its owner-signed replacement link together. The source is marked replaced and remains readable with its earlier reviews and feedback. The new proposal starts without approvals and has its own feedback conversation. Both administrators must review the new contents. An amendment does not activate lending, transfer funds or change any contract configuration.

An amendment must use contents that your wallet has not previously submitted. It cannot reuse an old record, form a loop or create multiple replacements from the same source. Amendments share the limit of five new proposals per wallet per day. Use as a new draft remains an independent submission and does not retire the original. An ordinary repeat submission retains the existing record, including its history and reviews.

The queue shows at most 50 recent records. Use Open an exact proposal with its identifier to retrieve an older one, or follow its verified previous and replacement links. Each private lookup requires a fresh signature and remains available only to the proposing wallet and current reviewers. The app verifies the owner signature on each relationship before displaying it. Relationship times are server-recorded receipt times.

If the amendment response is lost, open the source by its exact identifier with a fresh signature. A verified replacement link establishes which amendment was recorded. A child with similar contents alone does not establish replacement. Requests are not automatically retried. A changed wallet, network or connector clears private results and the copied amendment draft.

Inspect contracts before reviewing a market

Open a stored proposal and choose Sign to inspect contracts. Its owner and current reviewers can authorize a bounded read-only inspection. The signature identifies the exact proposal, origin, chain, reviewer policy and expiring one-use request. It does not sign future report contents, approve token spending, change a review or activate lending. No gas is required.

Serevin collects contract code hashes, optional ERC-20 names, symbols and decimals, standard implementation and beacon slot pointers, and one exact minimal-clone pattern. Pointer targets are read one level deep. Zero slots do not prove immutability or the absence of other delegation and token controls. Unsupported or failed reads are labelled unavailable; missing runtime code is a different observation.

The collector verifies the configured Morpho runtime and derives the candidate market ID from the five proposed parameters. It records whether that market was created and its stored supply, borrowing, shares, last accrual and fee when readable. These are raw integers at a recorded block, not current accrued balances or executable withdrawal quotes. The loan token reports Morpho’s shared cash balance; this is not cash committed to the proposal. A convincing token name or balance does not establish transferable value.

New reports also compare recognized oracle addresses with a versioned snapshot of the existing reviewed reference profiles. The exact oracle runtime, all six configured feed or vault getters including expected zero pointers, dependency runtimes and any pinned implementation or aggregator targets are checked at the same block. Matching, changed and unavailable configurations are separate outcomes. Unknown oracle addresses require manual review, even when their code or interface looks familiar. Observed unexpected pointers are not followed as trusted dependencies.

The report separately records whether the proposed asset pair and complete Morpho market ID match the reference. A known oracle used with a different token, interest rate model or loan-to-value setting does not approve that market. Reference comparisons do not add assets to the live lending registry, change proposal approvals or authorize transactions.

After every configured oracle pin matches, supported feed wrappers are queried for latestRoundData with a strict ABI check. A positive publication timestamp no later than the report block is recorded separately from the block time. There is no invented maximum feed age or claim that an answer is economically correct. Unavailable or invalid publication reads remain unavailable. Vault-only and direct-runtime profiles with no configured feed timestamp are marked not applicable; the block time is never substituted for a publication date.

Every report records Robinhood Chain identity, one block number, hash and timestamp, collection times, source proposal and collector version. The closing read checks the same block and chain. Reports can become stale or refer to a block later reorganized. The application checks the report shape, content digest and authorizing wallet signature. A digest provides content integrity, not independent attestation of RPC truth.

Sign to load reports retrieves the five most recent observations for the exact proposal and indicates when older reports are retained. A report on a superseded proposal stays attached to that original proposal; it does not transfer to its replacement. Reports and authorizing signatures are retained. Downloads include private proposal details and wallet addresses. A wallet, chain or connector change clears displayed private results.

Choose Sign to load review packet to read the exact proposal, its current-policy review decisions, original action signatures and up to five recent retained evidence reports together. This uses one expiring private-access signature. It does not run a new contract inspection, approve evidence or authorize a lending release. The packet records the service read time; each included report retains its own block, collection time and limitations. Conflicting block identities remain visible rather than being treated as one verified observation.

Download private packet saves this view as JSON on your device without another signature or automatic sharing. It includes every report listed in the packet, regardless of which individual report is selected below. Feedback and externally hosted documents are not included, and their absence does not mean outstanding questions are resolved. Review decisions can change after the packet is read. Request identifiers bind the response to your signed read; they are not independent attestations of the packet contents.

One inspection runs at a time with an 18-second network deadline, at most 64 collector reads and 80 total transport attempts including the configured primary and public backup. Responses, code, gas and ABI return sizes are bounded. The service admits four inspection attempts per rolling minute and six per requesting wallet per rolling day. Failed collections count. The 25-second storage lease expires after a crash. If a response is lost, load reports with a fresh signature before inspecting again; collection is not automatically repeated.

Earlier version 1 reports keep their original fields, caveats, digests and signatures. They display that oracle checks were not collected rather than implying a failed read. New version 2 reports identify the historical reference catalogue and its digest so later configuration changes do not reinterpret old comparisons. Both versions can appear in the same private history.

A release comparison is separate from the private review packet. The existing external lending release is bound to its exact contract configuration and displayed market list. A future candidate cannot inherit that historical approval by setting a verified flag. Candidate preparation remains private and disabled while financial decisions, evidence and a distinct release approval are incomplete.

A separate private admission record binds the exact candidate, original dossier, financial decision references and proposed release. Current admins must sign new admission decisions; their earlier proposal reviews do not count as these approvals. A changed policy, replacement proposal, changed review event or newer admission revocation prevents an old approval from being reused. Both admission reviews can be recorded without publishing a market. The publication and activation step remains unavailable, and the existing markets stay on their current release.

Publishing website code does not by itself activate a new lending market. An interrupted release must be reconciled against its exact saved version before another deployment is attempted. Current approvals, market evidence and transaction permissions must still be checked separately before new lending becomes available.

Admission records are checked against the original published market configuration, preserved separately from active settings. A later configuration change does not rewrite that historical evidence. Current administrator policy and financial approvals still govern new actions; a readable old record cannot restore a revoked approval.

Admins can open Admission review from Project markets. Choose a prepared request JSON to inspect it locally, or enter the exact request ID and sign to open a stored record. Importing does not upload it. Review the token addresses, original evidence block, validity, financial decisions and open requirements before checking the confirmation and signing. Each submission, read, approval and revocation requires its own short-lived message. The browser verifies original submission and decision signatures, then derives the displayed status. A lost response requires a fresh signed read; the application does not resend an action automatically. A changed wallet clears imported and loaded private contents from this view. Downloads remain on your device.

Direct Morpho calls do not enforce the supply and borrow caps written in a proposal, including a proposed zero cap. A separate decision must establish enforceable limits or explicitly resolve that difference before admission. The maintained interface currently supports its reviewed USDG loan markets; a different loan asset, unsupported delegation or a new market missing from the interface requires additional implementation and review. An observation for one proposal does not cover every market affected by a shared dependency change.

Oracle semantics, feed-specific publication-age requirements, asset-pair suitability, executable liquidation depth, token restrictions, LP or vault underlying assets, actual funding and enforceable exposure limits still need review. The configured pin graph does not cover every possible delegation or mutable token control. Submitted evidence URLs are not fetched. Observing a market does not list its assets, admit collateral or change transaction permissions.

Review does not activate a lending market

Two reviews mark the proposal reviewed for release. They do not deploy contracts, enroll collateral, change a transaction manifest, seed liquidity, set financial parameters or enable borrowing. The release operator must verify those steps separately and record the approved configuration.

Morpho market creation uses five immutable parameters. It is permissionless at the underlying protocol, subject to enabled interest rate models and liquidation thresholds. Serevin’s listing policy controls the Serevin interface; it cannot prevent anyone using Morpho elsewhere.

Requested supply and borrow caps in the proposal are review conditions. Morpho Blue has no native per-market exposure-cap setting. A cap needs an enforceable vault or adapter design before it can be represented as a guarantee. Serevin’s own isolated-market contracts have separately controlled exposure caps.

A stock-token pair may be tradable without being suitable or transferable as lending collateral. Trading hours, issuer permissions, freezes, corporate actions and price sources must be reviewed for the exact asset. Launchpad liquidity does not supply the separate cash lenders need.

The live SVRN spot market

The owner launched SVRN on Long with an SVRN/AI pair on 8 September 2026 Eastern Time. The canonical contract, creation transaction and pool are recorded in the SVRN chapter. An additional SVRN/ETH market would use the same token and requires separate liquidity.

The quote asset is Artificial Inu, a separate volatile token. Pairing with it gives no redemption right against its stock-token holdings. The launch receipt and fee registry identify Serevin’s treasury as a beneficiary. Automatic fee collection, conversion and allocation are not enabled by that registration.

SVRN/AI is featured as a spot market, separately from the five reviewed Morpho lending markets. Adding this market to the interface does not authorize SVRN or AI as collateral. A lending proposal still needs both administrator reviews, a verified oracle, approved risk settings and separate lender funding.