Fixed terms.
Visible settlement.

Bilateral credit, not a pooled market.

Each loan combines a collateral asset, a credit asset, principal, fixed and/or accruing interest, a lender, a borrower, and a default timestamp. The borrower’s collateral is held by the loan contract. The lender receives a transferable ERC-721 LOAN token representing the claim.

Simple and elastic proposals

A simple proposal describes a one-time exchange with exact amounts. An elastic proposal allows acceptance of a credit amount within the proposed limit, with collateral scaled according to the signed ratio. This deployment includes both proposal contracts; Dutch Auction, List, and Chainlink proposal products are not deployed.

Interest calculation

The contract combines fixed interest with minute-based accruing interest. Its Solidity implementation computes whole elapsed minutes and uses integer arithmetic:

The demo’s full-term preview uses a human-readable days/365 approximation. A production write path must call the current contract for exact integer amounts instead of relying on browser floating-point estimates.

Offer capacity and revocation

Utilized credit is tracked to prevent an offer from funding beyond its limit. Repayment does not restore utilized capacity. An unused offer can be revoked through the proposal/nonce mechanism; a created loan continues under its own terms.

What each participant does.

Borrower

1. Choose collateral and credit assets. Verify both token contracts, decimals, and actual wallet balances.
2. Review collateral amount, principal, interest, duration, acceptor restrictions, and default timestamp.
3. For a real integration, approve the exact collateral amount, accept the proposal, and confirm creation in the wallet.
4. Before expiry, fund principal plus the exact current repayment amount, approve that credit asset, and repay.
5. Confirm collateral receipt and the final LOAN/vault state from the transaction receipt and fresh reads.

Lender

1. Choose acceptable collateral and credit, set limit/minimum, collateral ratio, APR, duration, expiration, and any borrower restriction.
2. Publish an on-chain proposal or sign an EIP-712 proposal through a reviewed integration. Supply exact credit approval when required.
3. After a borrower accepts, hold or transfer the LOAN NFT. Track its deadline independently.
4. Receive repayment through direct settlement or claim repaid credit. After default, claim collateral.

Current demo equivalents

The Borrow, Lend, and My credit views reproduce these decisions using illustrative offers and local browser state. Repay, revoke, transfer, and claim buttons update only the demo ledger. JSON downloads are planning artifacts, not signed offers or proof of blockchain state. Reset removes local demo changes; it cannot affect a wallet or contract.

One rail. Independent asset risks.

IMF can serve as a common collateral or credit asset. K9 currencies can be borrowed or lent against IMF, other K9 currencies, or external tokens. Each K9 system also has a separate equity ShareToken. The lending rail does not merge their reserves, guarantee exchange rates, or create automatic FX conversion.

Token deployment does not imply an active offer, deep liquidity, a stable market value, or a successful loan. Verify current state on DogeOS before every integration.

A shared service for the DogeOS ecosystem.

A project can put its own interface and credit policy in front of the same lending core. It does not need a new pool admin or a separate deployed loan contract. The desk can define supported tokens, term templates, branding, counterparty policy, and operational monitoring.

Integration layers

• Asset registry: contract address, decimals, symbol, category, transfer behavior, and verification status.
• Term templates: collateral ratio, fixed/accruing interest, duration, credit limit, minimum, and expiry.
• Participant policy: open acceptance, a restricted acceptor, or treasury-funded initial offers.
• Discovery: an indexer for proposals, loans, NFT ownership, repayment, revocation, and claims.
• Operations: deadline notices, claim workflows, receipt journals, incident controls, and support.

The Project Studio currently saves an off-chain demo template. It does not register a token on-chain, publish an offer, or create a project treasury. No DUKKY or SIXRR deployment is inferred.

Value addition versus pooled lending

Projects can support long-tail collateral without exposing a shared pool to every asset. Losses remain attached to bilateral lender claims rather than a common utilization pool. The tradeoff is fragmented liquidity, more counterparty discovery work, and no instant pooled exit.

Independent PWN v1.3 on DogeOS.

10 contracts · chain 6281971 · protocol fee 0 · source commit 4f6c851f7681

Loan source is unmodified PWN v1.3, Solidity 0.8.16, optimizer enabled with 200 runs, London EVM. All ten contracts were reported is_verified=true through Blockscout’s smart-contract API. This is an independent deployment; no official PWN affiliation or inherited production assurance is claimed.

Administration

Deployer, config admin, Hub owner, and fee collector are the fresh testnet EOA 0x19F8782f560Bf1A70Ca0Cd49D6cFDF6830a1205E. Protocol fee is zero. A production system should replace single-key administration with a reviewed multisig and timelock process, explicit key custody, and monitored upgrade procedures.

The Config proxy’s own TransparentUpgradeableProxy source was explicitly verified in addition to its EIP-1967 implementation resolution. Sourcify verification was attempted but its public endpoints returned 404 at verification time; do not describe Sourcify as complete.

Network

• Chain: DogeOS Chikyū testnet, ID 6281971
• RPC: https://rpc.testnet.dogeos.com
• Explorer: blockscout.testnet.dogeos.com
• Native gas token: 18-decimal tDOGE

Two exits, executed end to end.

Both LOAN NFTs are burned. Reading status 0 after these complete lifecycles reflects deleted storage, not an active loan. The manifest records 34 unique deployment, funding, approval, proposal, creation, repayment, and claim links. These are historical testnet proofs—not current offers or user balances.

Before broadcast, the copied protocol’s relevant suite passed 427 tests. This supports implementation testing; it is not an independent security audit or production certification.

Login is optional. Authority is not implied.

The application uses the official @dogeos/dogeos-sdk 4.0.4 React integration, packaged as a separate local JavaScript/CSS bundle. It is lazy-loaded only after the user selects Connect or log in. The initial page does not load React or open a wallet dialog.

Supported connection choices

• External EVM wallets through basicLogins: ['externalWallets']
• DogeOS-managed Google and X social login with its embedded EVM wallet
• DogeOS Chikyū EVM only, defaultConnectChain: ChainTypeEnum.EVM

Email login and WalletConnect-specific project configuration are not enabled. The public application client ID is an identifier, not a secret. It must be restricted to the approved HTTPS origin. Connection is not an authenticated IMF backend session, token approval, loan signature, or transaction authorization.

Current wallet boundary

The wallet island displays connection state. It does not register a lending transaction engine, request message signatures, call authentication-token APIs, or access non-EVM providers. Demo controls remain usable without a wallet. No private key or seed phrase belongs in this static frontend.

The deadline removes neither market nor software risk.

• Collateral value risk. A price decline does not trigger simple-loan liquidation. At default, collateral may be worth less than debt. Lenders must choose ratios, assets, and duration conservatively.
• Liquidity risk. A LOAN NFT is transferable but transferability does not create a buyer or an exit price. Project tokens and ShareTokens may be thinly traded.
• Deadline risk. Repayment at or after the default timestamp reverts. Wallet delays, gas, RPC outages, and incorrect repayment amounts can prevent timely settlement.
• Claim and counterparty risk. After default, only the current LOAN NFT holder can claim collateral. NFT transfer and ownership tracking are operationally critical.
• Token behavior risk. Fee-on-transfer, rebasing, pausing, upgradeable, or nonstandard tokens can break amount assumptions. Verify exact received amounts and compatibility.
• Approval and signature risk. Unlimited approvals and opaque signatures increase exposure. Production journeys should use exact approvals and human-readable term review.
• Smart-contract and integration risk. Source availability, explorer verification, and historical tests do not eliminate vulnerabilities or frontend encoding errors.
• Admin and upgrade risk. The current single EOA is a testnet convenience. Key compromise or unsafe upgrades can alter system behavior.
• RPC/indexer risk. Unavailable or stale data is not zero. Production interfaces must distinguish failure from empty state and reconcile against receipts and fresh chain reads.
• Testnet asset risk. Test tokens and prices may have no monetary value. No yield, repayment performance, liquidity, or production availability is promised.

A deliberate path from demo to live credit.

1. Freeze the asset and proposal policy. Define accepted tokens, decimals, term limits, fee policy, and supported proposal types.
2. Add read models. Verify contract bytecode and Hub tags, discover proposals/loans, and keep unavailable state distinct from zero.
3. Implement transaction preparation. Encode exact integer amounts, approvals, EIP-712 data where needed, current simulation, and gas estimation.
4. Require explicit review. Display terms and every approval separately. Invalidate unsent preparations after account, chain, or terms changes.
5. Reconcile receipts. Decode created loan IDs and events, refresh wallet/vault/NFT state, journal hashes, and never auto-resubmit.
6. Test with separate wallets. Exercise creation, partial elastic acceptance, repayment, third-party repayment, NFT transfer, revocation, default, and failed paths.
7. Add operations. Persistent indexer, deadline notifications, incident response, support, monitoring, and backups.
8. Harden administration. Independent security review, multisig/timelock, documented upgrade runbooks, and production key custody.

Recommended launch sequence

Keep the current demo public for education. Enable a narrow IMF/K9USD testnet write path only after the transaction engine passes separate-wallet QA. Add elastic proposals and external project desks after the indexer and operations workflows are reliable. Do not infer that a Barkswap pool is required for PWN settlement; no lending pool was needed for the two proofs.

Core calls and verification checklist.

Release checklist

• Chain ID 6281971 and all addresses match the reviewed manifest.
• Every token address, decimals result, and contract bytecode is freshly checked.
• All 10 core contracts and relevant Hub tags are correct.
• Current protocol fee and admin are read, not assumed.
• Static call and gas estimate succeed immediately before review.
• Every transaction has an explicit wallet confirmation and reconciled receipt.
• Demo records, RPC reads, historical evidence, and live state are labeled separately.
• No key material, secret environment file, or privileged automation enters the frontend.

Download the full deployment and transaction manifest. Application: lending.imf.li/#mechanics.

Short answers.