A Pump.fun token. A property treasury. A public record of where the money goes.
Working model · v0.1
$HOUSE has not launched. There is no connected token, funded treasury, acquired property, or active payout system. These docs define the proposed launch model; settings below are design decisions awaiting final adoption.
One token. Two money flows.
HouseMech proposes using the creator revenue from a Solana token launched on Pump.fun to build a portfolio of fractional real estate. Available net rent from those holdings would then fund USDC distributions to eligible $HOUSE holders.
Trading activity funds acquisitions. Property income funds rental distributions. Keeping those flows separate makes it possible to see whether rewards came from rent, instead of new trading activity.
The token is the entry point. Creator revenue is the proposed funding source.
Proposed launch configuration
Item
Model / status
Name / symbol
HouseMech / HOUSE
Network / trading pair
Solana / SOL
Launch mode
Regular creator-fee token; no holder-reward mode or Mayhem mode
Token mint
Not created
Official coin page
Available after the verified mint is published
Supply, decimals & authorities
Verify from the deployed mint and publish at launch
Team holdings / initial purchases
Disclose all related wallets and purchases before public promotion
Use the mode that funds the treasury
HouseMech’s model requires creator fees to reach the project’s disclosed recipient. Pump’s current creation documentation distinguishes regular tokens from holder-reward tokens, where the creator fee is routed to holders instead of the creator wallet. That setting is permanent. New cashback launches are currently disabled.
Rental distributions are a separate system.
HouseMech’s proposed rent payments are funded from property income and administered by HouseMech. They are not Pump.fun’s native holder rewards.
A launch begins on Pump’s bonding curve. If the applicable graduation conditions are met, trading can move to a PumpSwap pool. Graduation is not a property purchase, a funding guarantee, or a payout event. HouseMech would reconcile receipts in either phase.
Rates depend on the platform’s current schedule and trading configuration. HouseMech does not set Pump’s platform fees and does not assume every trade on every venue produces creator revenue.
At launch, the address register should link the exact mint, its Pump.fun page, the explorer record, and the creator-fee recipient. A matching name, image, or ticker is not proof that a coin belongs to HouseMech. No official $HOUSE mint exists in this draft.
03 / THE MONEY
Creator fees & allocation
Only revenue actually received can be allocated.
What the percentages apply to
The 50 / 40 / 10 split applies to creator revenue actually settled to HouseMech’s disclosed collection wallet, after any platform-level deductions or recipient sharing. It does not apply to trading volume, a trader’s full transaction fee, or rent.
Balances still claimable from a platform are reported separately from collected cash. Each receipt needs an amount, asset, timestamp, transaction, and associated token or pool. Pump controls its fee schedule; the split below is HouseMech’s own proposed budget.
50%Buyback & burnAcquire $HOUSE and retire the acquired tokens.
40%Property treasuryAccumulate funds for fractional interests and acquisition costs.
10%Operations & reservesPay treasury administration, accounting, infrastructure, and network costs.
Example: 10 SOL received
Budget
Allocated amount
Buyback & burn
5 SOL
Property acquisitions
4 SOL
Operations & reserves
1 SOL
This is an allocation example, not an estimate of expected revenue. When funds are converted, report the actual proceeds, execution price, and fees. A dollar valuation at receipt is an accounting record, not a guarantee of later purchasing power.
Reconcile before spending
Match collected fees to confirmed transactions and recipient settings.
Assign each receipt to the three budget ledgers without rounding away funds.
Approve each spend from its own budget and attach supporting records.
Carry unspent amounts forward. Publish any proposed budget change before applying it to future receipts.
Routine network and administration costs come from the operations budget. Property purchase and settlement costs come from the property budget. Never count the same expense against two budgets.
A transparent use of one budget, without a promised token price.
The proposed execution policy
Fifty percent of collected creator revenue is earmarked for $HOUSE repurchases. Operators would batch purchases when available liquidity and transaction costs allow, subject to treasury approval and a recorded maximum slippage. Unspent funds stay in the buyback budget.
A purchase and a burn are separate actions. Tokens acquired for this purpose remain excluded from rental distributions until an actual burn is confirmed. A transfer to another wallet alone is not reported as a burn.
What gets published
Budget available and amount spent, including conversion costs.
Purchase transaction, execution venue, $HOUSE received, and average price.
Burn transaction, amount retired, and resulting verified supply.
Unused budget and the reason for any delayed execution.
When execution pauses
Execution pauses if quotes are unreliable, liquidity is insufficient, signing controls fail, or a security or legal issue arises. The report must distinguish funds allocated, tokens purchased, and tokens burned.
A burn is not a price floor.
Repurchases can occur while market prices fall. No minimum price, appreciation, liquidity, or redemption value is part of this model.
05 / THE MONEY
The property treasury
From a public watchlist to documented fractional ownership.
Who owns the interest?
Lofty describes each property as held by a separate LLC, with investors acquiring interests in that entity. Under this proposal, an eligible HouseMech operating entity would acquire the interests. $HOUSE holders would not individually appear as owners of those Lofty interests simply by holding the token.
The project’s entity, its account eligibility, custody arrangements, and the legal basis for onward distributions must be resolved before purchases or launch claims. Lofty’s marketplace availability does not itself authorize this structure.
Property: inspection, condition, location, tenant status, and operating history.
Finances: rent actually collected, recurring costs, debt terms, taxes, reserves, and potential capital calls.
Ownership: entity documents, voting rights, transfer restrictions, marketplace limits, and conflicts of interest.
Execution: available shares, total purchase cost, custody route, and evidence of settlement.
Operators would publish an acquisition note before committing treasury funds. Portfolio concentration limits and any reserve target must be approved and disclosed before the first acquisition; this version does not invent limits for an unfunded portfolio.
Three distinct statuses
Status
Meaning
Watchlist
A listing being considered. No ownership claimed.
Pending acquisition
An approved order or settlement is in progress. Not yet a verified holding.
Verified holding
Settled ownership is documented, with quantity and cost recorded.
All six properties currently shown on the website are watchlist references. Their retro artwork and real photos identify listings; neither is evidence of a purchase.
Sales and capital calls
Sale proceeds, returned capital, and realized gains remain in the property treasury under this draft. They are not silently counted as rental income. A new policy would be required to distribute them. If an additional capital contribution is requested, operators must disclose the obligation, available reserves, and intended response.
06 / THE MONEY
Rent & distributable cash
Count received cash once. Keep property capital separate.
The rental income waterfall
PROPERTY LEVELRent, less property costsManagement, repairs, debt service, taxes, and property reserves
HOUSEMECH LEVELCash received by the treasuryReconcile the property statement to the actual receipt
DISTRIBUTION LEVELAvailable payout poolAfter disclosed settlement costs, obligations, and reserve top-ups
The starting point is the net rental cash actually received by HouseMech. If a property has already deducted a cost, HouseMech does not subtract it again. Accrued or projected rent, valuation gains, token trading fees, sale proceeds, and deposits do not enter the rental pool.
How the pool is calculated
Available pool = unallocated rental cash carried forward + net rent received − unpaid attributable obligations − approved reserve top-ups − settlement costs
Previously assigned holder balances remain liabilities and are not added back into the next pool. An expense already funded by the operations budget cannot also reduce holder income. Required taxes or withholding and any reserves must be documented; amounts depend on the final operating structure.
From a platform credit to usable cash
A rent credit in a property account is not yet a funded Solana payout. Record the credit, withdrawal request, settlement or conversion, and final treasury receipt separately. Internal transfers and conversions are not new income. Only the settled receipt counts toward available cash.
Lofty’s current overview describes daily account credits and standard bank withdrawals that may take up to four business days. HouseMech must verify its actual withdrawal route and any separate conversion to Solana USDC. A daily batch therefore may distribute previously settled rental cash or have no new allocation.
These figures demonstrate the calculation only. They are not current receipts, a forecast, or an adopted reserve percentage.
A zero-income period
If no net rental cash is available, there is no new rental distribution. Capital is not relabeled as rent to maintain a payout streak. Losses, vacancies, large repairs, settlement delays, or reserve needs can reduce the pool to zero.
Lofty’s own account-crediting cycle does not set HouseMech’s payout calendar. The proposed HouseMech cycle runs daily and depends on received, reconciled funds. See the distribution policy →
07 / FOR HOLDERS
Holding time & eligibility
Your proposed weight combines token balance with holding age.
The four tenure tiers
Effective holding age
Weight
Tier
Under 7 complete days
0×
On the doorstep
7 to under 30 days
1×
Moved in
30 to under 90 days
2×
Settled in
90 days or more
4×
Deeply rooted
A day means 86,400 seconds of confirmed on-chain holding history. Age starts when tokens are received. The draft tracks balances by Solana wallet owner, aggregating that owner’s token accounts for the verified $HOUSE mint.
Buying, selling, and moving tokens
First receipt: the holding clock starts at zero.
Additional receipt: blend the old age with the new tokens, whose age starts at zero.
Any outgoing amount to another owner: reset the remaining balance’s age to zero. This includes a sale, gift, or move to another wallet you control.
Transfers between accounts with the same wallet owner: preserve age after the indexer verifies there was no beneficial balance change.
Full exit: a later receipt starts a new clock.
Age after an addition = old balance × old age ÷ (old balance + added balance)
Example: adding 1,000 tokens to 1,000 tokens aged 40 days gives 2,000 tokens aged 20 days. The weight moves from 2× to 1×. Incoming dust can also lower average age; the draft has no exemption for small transfers.
Which balances count?
The draft includes identifiable self-custody wallet balances with complete history, subject to the final lawful participation rules. Team, treasury, buyback, distribution, platform reserve, bonding-curve, liquidity-pool, and burn balances are excluded. All known related wallets and exclusions must be disclosed.
Tokens held through an exchange, pool, or wrapper are not attributed to its customers. Transferring them to self-custody starts a new clock. Changing wallets or using additional wallets does not carry tenure across owners.
Daily snapshot rules
Use the last finalized Solana slot strictly before the daily 00:00 UTC cutoff. Reconstruct age from ordered confirmed history through that slot. Missing history, unknown ownership, or inconsistent balances must be resolved before a distribution is finalized; current balances alone cannot establish tenure.
The indexer, exclusion list, snapshot records, and review process are requirements for implementation. They are not running in this website.
08 / FOR HOLDERS
Daily USDC distributions
An auditable allocation of actual rental income.
The proposed daily cycle
00:00 UTC · close and snapshot
Close the previous UTC day and record balances at the last finalized slot strictly before the boundary. Include only rental cash settled before the cutoff; later receipts enter the next batch.
01:00 UTC target · reconcile and publish
Reconcile cash, costs, reserves, eligibility, and existing unpaid balances. Publish the proposed daily allocation file, snapshot slot, calculation version, and supporting records.
02:00 UTC target · approve and submit
After operator review, approve the manifest and submit USDC transfers. A corrected manifest requires fresh approval. Missing records or unresolved calculations delay the batch.
After confirmation · mark paid
Link each confirmed payment to its transaction. Pending and failed transfers remain outstanding until reconciled. Carry small unpaid balances into the next cycle.
Holder allocation = available USDC pool × holder weight ÷ total eligible weight
Illustrative holder
Balance / tier
Weight
Share of 1,000 USDC
A
10,000 / 1×
10,000
100 USDC
B
20,000 / 2×
40,000
400 USDC
C
12,500 / 4×
50,000
500 USDC
The example assumes these are the only eligible holders. A 4× weight means more of the same pool per token; it does not mean a 4× investment return. If total eligible weight is zero, the unallocated pool carries forward.
Settlement and small balances
The draft uses direct USDC transfers to eligible wallet owners, not a claim portal. Daily payment requires available settled cash, eligible ownership, the minimum payable amount, and approval. These times are processing targets, not guaranteed payment times. The payout asset is native USDC on Solana; its exact mint must be verified and published in the address register before funding. Holder participation restrictions or verification requirements must be settled before launch.
Calculate in integer USDC base units and round each allocation down to six decimals. Unassigned rounding dust stays in the unallocated pool. Amounts below 1 USDC accumulate in a separate holder payable ledger until the threshold is reached. Apply the 1 USDC threshold to the wallet’s accumulated payable amount. A later token sale does not erase an already finalized allocation, and tomorrow’s holder weights do not redistribute that prior balance.
Failed transfers remain owed and are retried only after checking that an earlier attempt did not succeed. Each period, wallet, and payment has a unique record to prevent duplicate payouts. Under the proposed direct-transfer model, receiving a payment requires no seed phrase, token approval, or payment to unlock it.
The distribution record
Each completed daily batch should publish its income report, snapshot slot, calculation version, exclusion list, allocation-file hash, USDC funded, payments confirmed, failures, and unpaid balances. Private identity documents never belong in the public allocation file.
09 / OPERATIONS
Treasury & custody
Separate budgets, limited signing access, and records for each movement.
The proposed account layout
Account
Purpose
Proposed control
Creator-fee recipient
Receive or collect project revenue
Publish recipient settings and supported authority controls
Main treasury
Hold buyback, property, and operations budgets
2-of-3 approval with separately controlled signers
Limited funding per period; documented treasury approval
A Solana multisignature cannot by itself enforce how a bank account or Lofty account is used. Operators must document controls at each step, including any conversion or settlement service. The proposed design is not fully autonomous or trustless.
Approval and reconciliation
Keep signing keys out of the website, source code, and analytics tools.
Verify recipients, asset mints, amounts, and source budgets before approval.
Record initiator and approvers, transaction results, and supporting invoices.
Use a limited payout wallet and retain an independent record of completed transfers.
If something goes wrong
Pause affected spending or distributions for a compromised signer, inconsistent holder data, settlement outage, or suspected account issue. Publish the affected function and last reliable report, investigate, rotate access where needed, and reconcile before resuming. Do not mark a paused feed as current or a submitted transaction as paid.
Who can change the model?
This draft is operator-managed; it does not create token-holder governance. The proposed policy requires public notice at least seven days before a material prospective change to allocation, tenure, or payout rules, except an immediate security pause. A finalized holder payable is not retroactively recalculated under a new version.
Operator identities, signer addresses, entity details, and the final enforceable policy remain launch prerequisites.
10 / OPERATIONS
Addresses & live data
The verification register for the token, accounts, and reports.
CONNECTION STATUSNot connected
No token has been launched. This register contains no simulated addresses, market prices, or payout transactions.
The address register
Record
Current state
Solana $HOUSE mint
Not created
Pump.fun coin page / curve
Not available
PumpSwap pool
Not available; depends on graduation
Creator-fee recipient
Not designated
Treasury / signer set
Not configured
Property operating entity / account
Not established in this model
Distribution wallet / USDC mint
To be verified before funding
Holdings evidence / payout records
No acquisitions or distributions
What a real connection needs
Solana data: verify the mint, supply, authorities, creator-fee recipient, collected receipts, wallet balances, and confirmed transactions.
Historical indexer: reconstruct wallet ownership, balances, and tenure from the mint’s creation through each snapshot.
Property records: reconcile entity statements, purchases, rental receipts, expenses, and custody evidence through authorized records.
Payout service: version calculations, approve funding, track each transfer, and retain an unpaid balance ledger.
A Pump.fun link alone does not connect property records or create rental payments. No supported Lofty integration is presumed by this draft; use authorized exports or a confirmed integration and disclose its update frequency.
How the dashboard should report
Display each data source and last successful update. Show unavailable or stale data as such. Distinguish purchase cost from estimated property value, rental cash from creator receipts, and pending transfers from confirmed distributions. Never substitute illustrative figures for live balances.
11 / READ BEFORE LAUNCH
Holder rights & risks
What the model proposes—and what ownership would require.
A token is not a property deed
$HOUSE is a proposed Solana token associated with a rental-distribution model. The draft does not itself grant an enforceable right to a house, a Lofty account, property votes, treasury redemption, or a guaranteed payment. Any income rights must be established in final legal documents, with eligible participation and the responsible entity identified.
The intended structure requires review of securities, tax, custody, and distribution obligations in the relevant jurisdictions, together with the applicable platform and property agreements. Describing a token as a meme coin does not settle those questions.
The material risks
Token market: prices can fall to zero; liquidity and creator revenue can disappear.
Real estate: vacancy, repairs, debt, taxes, insurance, and capital calls can eliminate net income.
Liquidity mismatch: a tradable token does not make fractional property interests instantly saleable.
Counterparties and custody: the project relies on its operators, platforms, managers, banks, and settlement providers.
Technology: wallet compromise, faulty history, duplicate payments, or software errors can cause loss.
USDC and settlement: depegging, issuer controls, chain issues, and conversion costs can affect distributions.
Legal and tax: participation, reporting, withholding, or the proposed structure may need to change before launch.
Independent project
HouseMech is not represented as affiliated with or endorsed by Pump.fun or Lofty. Links document the intended platforms and real property references. Neither platform is responsible for this proposed rental payout system.
Final documents must explain entity reporting, any participant verification, withholding, and the treatment of distributions. Do not assume a platform’s own investor tax reporting covers a separate HouseMech payment. Never publish personal verification documents alongside public wallet records.
12 / READ BEFORE LAUNCH
From draft to launch
A token launch and an operating rental treasury are different milestones.
Where things stand
✓
Website and public modelRetro website, six reference listings, and documentation v0.1.
01
Adopt the operating structureIdentify the entity and operators; confirm platform eligibility, holder rights, tax handling, and the final policies.
02
Build and test the systemsFee accounting, historical tenure, snapshots, treasury approvals, payout reconciliation, and independent review.
03
Launch and verify the coinConfirm creator-revenue mode, publish the mint and recipient, disclose related holdings, and verify live feeds.
04
Acquire the first interestsFund the property budget, complete due diligence, settle purchases, and publish ownership evidence.
05
Receive rent and distributeReconcile actual net cash, publish the first snapshot, complete review, and record confirmed payouts.
What must be tested
The implementation needs test cases for additions and partial sales, all tenure boundaries, excluded wallets, missing history, a zero-income day, no eligible holders, rounding, small carried balances, failed and duplicate transfers, and changes in fee settings. Re-run a snapshot from the same inputs and verify identical results.
Use simulation and test environments before a limited real-funds trial. Independent review should cover both the payout code and the accounting process. No test, audit, integration, or signer configuration is claimed as complete here.
Launch publication checklist
Final versioned model, entity information, holder terms, and public support channel.
Verified mint, creator mode, related holdings, authorities, and official links.
Treasury and payout controls, reserve policy, and acquisition rules.
Data freshness policy, reporting examples, and incident process.
Evidence for each acquired interest before changing its status to a holding.
No date is promised. The first rental payout follows actual acquisitions and received income, not the token’s creation date.
13 / REFERENCE
Frequently asked questions
Straight answers to the questions holders are likely to ask.
Is $HOUSE live?
No. The name, launch route, and economics are a draft. There is no official mint or active Pump.fun connection yet.
Where will I be able to find the coin?
Once launched and verified, the address register will link the exact Pump.fun coin page and mint. You can connect Phantom or Solflare to display your public Solana address. Connecting does not request a signature or transaction. Token purchases and rental payouts are not available on this website yet.
Do I own part of the homes?
Holding $HOUSE would not automatically give you a direct property or Lofty entity interest. The intended rental distribution arrangement needs final legal documents. See holder rights.
What is the APY?
No fixed APY or minimum payment is proposed. Rent, costs, reserves, available funds, and the total eligible holder weight determine a day’s allocation. Some periods may distribute nothing.
Does daily processing guarantee a payment every day?
No. HouseMech must receive settled rental cash, reconcile it, and approve the batch. The draft runs every day, but income delays, costs, eligibility, and the 1 USDC payment threshold can mean no transfer on a particular day. Approved unpaid amounts stay attributed to their holder.
What if I sell or move tokens?
An outgoing transfer to a different owner resets tenure for the remaining balance. Previously finalized allocations remain recorded as owed. Moving between your own wallets also starts a new holding clock.
What if trading fees stop?
New acquisitions and buybacks may pause. Existing interests may still earn rent, but neither their income nor continued operations are guaranteed. Rental funds and acquisition capital remain separately accounted for.
Do I need to stake or claim?
The draft requires neither staking nor a claim signature. It proposes direct payments to eligible self-custody wallet owners. The final eligibility process must be published before launch.
Can I redeem $HOUSE for treasury assets?
No redemption mechanism is included in this model. Token market price and the estimated value of the property treasury are separate measures.
Where do I report a payout issue?
A verified support channel must be published before distributions start. None has been designated in this draft. Never send private keys or recovery phrases to anyone claiming to provide support.
14 / REFERENCE
Sources & version history
Platform facts have sources. HouseMech policies are proposals.
References checked September 22, 2026. Platform terms, launch modes, and fee schedules can change. Recheck them before launch; this document is not a snapshot of a deployed token’s settings.
Version 0.1 · September 22, 2026
First complete HouseMech operating draft. Documents the proposed Pump.fun launch, 50 / 40 / 10 creator-revenue allocation, fractional acquisition process, weighted tenure, daily USDC distributions, custody controls, and launch requirements.
All numerical examples are illustrative. No live connection, token launch, property acquisition, payout implementation, or legal adoption is recorded by this version.
Future changes
New versions should state what changed, the reason, the effective date, and which future receipts or distribution periods are affected. Keep prior versions accessible so each payment can be checked against the rules used to calculate it.
HouseMech