Summary
This proposal asks the K9 Finance DAO to evaluate K9 Farm, a working prototype for creating and managing automated on-chain trading and liquidity strategies.
The proposal requests DAO approval to:
- Recognize K9 Farm as a potential K9 Finance product.
- Have the current K9 developers or other qualified developers perform a technical and architectural review.
- Obtain independent security-audit quotations.
- Define the work, budget, ownership, operating model, and KNINE utility required for a limited pilot.
- Return to the DAO with a final implementation proposal and capped budget before public deployment.
I am not requesting payment for the prototype work already completed. However, I cannot personally fund a professional audit or additional work performed by K9 developers and external security specialists.
No treasury expenditure should occur under this proposal until the DAO has received and approved a clear scope, quotations, milestones, and maximum spending limit.
Background
Before everything went wrong, we had several discussions about how holders could take profits without placing one large sell order into the market.
I had already been experimenting with automated trading, and those discussions encouraged me to continue developing the idea. Drew also contacted me at the time and expressed interest in potentially using something like this. I mention that only as background, not as an endorsement from Drew.
Running an automated system privately on your own computer is one thing. Making it user-friendly and sufficiently secure for other people is much more difficult.
That is what I have been working toward with K9 Farm.
The current system is a working, unaudited mainnet canary used with limited funds. It has live execution on a small number of Ethereum and BSC markets, but it should not be treated as an audited or unrestricted public product.
I believe it is now developed enough to bring before the community for discussion.
What Is K9 Farm?
K9 Farm is a control panel for creating automated crypto strategies without requiring users to interact directly with smart contracts or continuously monitor charts.
A user connects a wallet, chooses a supported blockchain and market, deposits a limited amount into a personal on-chain vault, and defines the rules that the automation may follow.
In simple terms, the user tells the application:
“Here is the amount I am willing to use. These are my rules and limits. Monitor the market and execute only when those conditions are met.”
The dashboard displays:
- Wallet and vault balances.
- Funds available for withdrawal.
- Funds reserved by active or paused strategies.
- Current market and liquidity-pool prices.
- Active, paused, completed, and failed strategies.
- Automated transactions and execution results.
- The balance available for automation gas.
- KNINE credits used by the automation system.
The current prototype contains integrations for Ethereum, Base, BSC, and Arbitrum. Only a small number of markets have been enabled while testing.
Additional chains or markets should not be activated automatically. Each one should pass technical and risk criteria before being made available.
Current Strategy Types
1. Price Slicer
Price Slicer divides a larger purchase or sale into multiple smaller transactions.
For example, a user could instruct K9 Farm to:
Use 100 USDT to purchase a token through ten smaller transactions. Only buy while the price is below a defined maximum, and wait at least three minutes between transactions.
The same mechanism can gradually sell tokens above a defined minimum price.
This cannot eliminate price impact or guarantee a better execution price. It may, however, reduce the risk of committing the entire amount through one badly timed transaction.
Possible uses include:
- Gradual profit-taking.
- Gradual accumulation.
- Treasury execution with defined limits.
- Reducing dependence on trying to identify an exact market top or bottom.
2. Candle Swing
Candle Swing reacts to defined short-term price movements.
An example strategy could be:
Buy when a completed pool-price candle closes at least 2.5% below that candle’s opening price. Depending on the selected exit mode, sell after a later completed candle closes at least 2.1% above its own opening price.
The user may configure:
- Candle duration.
- Percentage movement required to trigger a purchase.
- Percentage movement required to trigger a sale.
- Amount per transaction.
- Maximum transactions per day.
- Cooldown between transactions.
- Maximum number of purchases that may remain open.
This strategy is intended to automate repeated market movements without requiring the user to monitor a chart continuously.
The dApp also supports three exit approaches:
- Fixed buy and sell amounts.
- Sell the acquired buy batch.
- Sell enough of the acquired tokens to recover the original paired-asset amount, subject to the available batch.
It does not guarantee profitable trades. A token can continue falling after a purchase, fail to recover to the sell target, or experience liquidity and execution problems.
3. Range Order
Range Order places funds into a selected concentrated-liquidity price range on compatible markets.
While the market price remains within the position’s range, the position may earn trading fees. As the market moves across the range, the balance between the two assets changes.
I view range-based strategies in three broad ways:
Fee-harvesting range
The user selects a relatively wide range and attempts to collect trading fees while the market remains inside it.
Sell-through range
The user expects to sell a token as its price rises. Instead of selling the entire amount at one exact target, the position progressively converts the token into its paired asset as the market moves through the selected range.
Buy-through range
The user wants to accumulate a token during a price decline. The position progressively converts the paired asset into the target token as the market moves through the selected range.
I previously referred to the last two as “short” and “long” ranges. However, sell-through range and buy-through range are more accurate descriptions because these are concentrated-liquidity positions, not leveraged derivative positions.
Range Orders may be configured with:
- Target price.
- Width of the liquidity range.
- Amount to deploy.
- Starting asset.
- Exit conditions.
- Optional restart behavior.
V4 is explicitly disabled. Current Range support is Uniswap V3/PancakeSwap V3 only.
Range strategies carry significant risks, including impermanent loss, adverse token conversion, price movement outside the range, smart-contract risk, pool manipulation, and fee income that may not compensate for losses.
Proceeds from completed slices remain allocated to the strategy until the user selects Claim proceeds. They then become withdrawable without requiring the active strategy to be paused.
Why This Could Benefit K9 Finance DAO
A Functional Use for KNINE
K9 Farm is designed so that KNINE is not merely associated with the application, it is required to access and operate the automation features.
KNINE access requirement
Users must hold a minimum amount of KNINE before they can use K9 Farm.
The current prototype requires a wallet to hold at least:
4,000,000 KNINE
This is a provisional requirement and may be changed by the DAO. The purpose is to create a clear connection between holding KNINE and accessing the K9 Farm ecosystem.
KNINE as automation credits
In addition to holding the minimum amount, users purchase credits with KNINE to pay for the automation service.
This works similarly to the credit systems used by many AI and software platforms:
- The user holds enough KNINE to qualify for access.
- The user converts or deposits KNINE into K9 Farm automation credits.
- Monitoring and HOLD decisions are free. One credit is reserved when a billable execution is queued and finalized only after verified success. Terminal failures release it.
- KNINE currently enters the
K9Creditscontract. A configured treasury-role address can withdraw it.. for example to the K9 Treasurry.
The prototype currently uses a provisional rate of:
1,000 KNINE per billable automation tick or successful transaction
The exact definition of a billable action must be finalized before launch
The final credit price should be determined by the DAO after considering:
- Automation-server and keeper expenses.
- RPC and infrastructure costs.
- Development and maintenance costs.
- Transaction frequency.
- The market value of KNINE.
- The need to keep K9 Farm affordable for normal users.
- The amount of revenue returned to the DAO treasury.
Because the KNINE used to purchase credits goes to the treasury, increased K9 Farm usage could create continuous demand for KNINE while also providing the DAO with resources for development, security, infrastructure, or other governance-approved purposes.
This proposal does not currently include a burn mechanism. The DAO could consider one later, but the initial model is for automation-credit payments to be received by the treasury.
KNINE whale benefits
Wallets holding at least:
400,000,000 KNINE
would qualify for a proposed KNINE Whale tier.
The precise benefits should be approved by the DAO, but possible Whale-tier benefits could include:
- Early access to newly approved markets.
- Early access to beta strategies and interface features.
- Participation in controlled product testing.
- Higher strategy or automation limits where technically safe.
- Reduced credit costs or other loyalty benefits.
- Priority access during limited pilot phases.
- A role in suggesting and reviewing potential markets.
- Access to a dedicated strategy and market-research community.
Holding 400 million KNINE should not allow a user to bypass contract-level security controls, market-risk limits, or other protections. Whale benefits should provide access and participation advantages, not unrestricted permissions.
Dedicated K9 Whale strategy community
K9 Farm could also help reactivate the existing K9 Telegram whale community.
The whale chat could become a dedicated place for qualifying holders to discuss:
- Automated strategy configurations.
- Potential markets for K9 Farm.
- Liquidity conditions.
- Pool volume and fee opportunities.
- Token unlocks and other market risks.
- Results from testing new strategies.
- Suggestions for adding or removing supported markets.
- Problems discovered during pilot testing.
- Future K9 Farm features.
These discussions should not take place extensively in the main K9 Finance Telegram channel. Keeping them in a dedicated, token-gated group would reduce spam, prevent the main channel from becoming filled with token promotions, and allow more focused technical and strategy discussions.
However, the group should not become a place for coordinated pumps, undisclosed paid promotion, market manipulation, or organized trading against other participants. Its purpose should be research, education, strategy discussion, product feedback, and risk assessment.
Projects should not be added to K9 Farm merely because they are promoted repeatedly in the whale chat. Every proposed market must still pass the DAO’s published liquidity, security, volume, contract, and risk criteria.
Proposed KNINE utility model
Under the current concept, KNINE would have three connected functions within K9 Farm:
- Access utility: Hold at least 4 million KNINE to use the application.
- Usage utility: Spend KNINE credits when automation services are used.
- Whale utility: Hold at least 400 million KNINE to qualify for additional access, testing, research, and community benefits.
The amounts currently used in the prototype are starting points, not permanent parameters. The DAO should retain authority to adjust them based on KNINE’s market value, operating costs, user adoption, security considerations, and community feedback.
Any changes should be announced in advance and should never interfere with a user’s ability to end a strategy or withdraw available funds.
More community activity
A functioning product could create new reasons for:
- Community education.
- Market discussions.
- Strategy discussions.
- Governance participation.
- Monthly or quarterly market reviews.
- Product feedback and development.
Like many community members, I miss the activity and excitement that K9 previously had. I believe shipping something useful is one possible way to begin rebuilding that energy.
User Control and Vault Design
The intended model is that each user operates through a personal on-chain vault.
The automation should receive only the permissions required to execute strategies that the user has explicitly created. It should not receive unrestricted control over the user’s wallet.
Users remain responsible for wallet approvals when:
- Depositing assets.
- Creating or modifying strategies.
- Ending strategies.
- Withdrawing assets.
The current interface allows a user to:
- Pause a strategy.
- Reactivate a paused strategy.
- Permanently end a strategy.
- Release reserved funds.
- Withdraw available funds.
- Maintain a separate balance for automation gas.
These security properties must be independently confirmed through code review and audit. They should not be treated as verified merely because the interface describes them this way.
Market-Selection Process
I propose that supported markets be reviewed monthly during the pilot and every two or three months once the system is stable.
Community members could suggest additions or removals throughout the review period. The Roundtable of Dogs, a technical working group, or another DAO-authorized group could evaluate the suggestions using published criteria.
Possible criteria include:
- Sustainable on-chain trading volume.
- Adequate and non-concentrated liquidity.
- Reliable pool-price data.
- Reasonable expected price impact.
- Token-contract and admin-key risks.
- Transfer taxes, blacklist functions, pausing, or unusual token behavior.
- Holder concentration.
- Token age and trading history.
- Upcoming token unlocks or emissions.
- Whether professional market making is active.
- Chain reliability and transaction costs.
- Exposure to bridges or external protocols.
- Suitability for each K9 Farm strategy.
- Evidence of manipulated or artificial volume.
A recently launched token may sometimes produce attractive fee opportunities after its market has stabilized but before major unlocks begin. However, launch age or high volume alone should never qualify a market.
The DAO should also retain the ability to suspend a market immediately when a serious security, liquidity, or token-contract risk is discovered.
Proposed Implementation Plan
Phase 1; Technical review and documentation
The prototype owner and selected developers would document:
- Smart-contract architecture.
- Vault permissions.
- Keeper or automation infrastructure.
- Admin roles and keys.
- Upgradeability.
- Emergency controls.
- Price sources.
- Strategy accounting.
- Gas accounting.
- KNINE credit accounting.
- Supported chains and pools.
- Current tests and known limitations.
- Source-code ownership and licensing.
Deliverable: A public technical assessment identifying the work required before an audit and pilot.
Phase 2; Security design and audit preparation
Required work may include:
- Threat modeling.
- Additional automated testing.
- Fork and adversarial testing.
- Permission and withdrawal testing.
- Price-manipulation protection.
- Slippage and deadline enforcement.
- Rate limits and position caps.
- Emergency pause procedures.
- Keeper-key security.
- Monitoring and incident-response procedures.
- User-interface improvements.
- Clear user risk warnings.
Deliverable: Audit-ready contracts and documented operating procedures.
Phase 3; Independent audit
The DAO should obtain quotations from at least two qualified security providers where practical.
The selected audit scope, provider, cost, and payment milestones should be published before funds are committed.
Critical or high-severity findings must be resolved and reviewed before a pilot begins.
Deliverable: Public audit report and remediation report.
Phase 4; Limited pilot
The first pilot should use:
- A small number of approved markets.
- Conservative per-user and system-wide limits.
- No DAO treasury trading unless separately approved.
- Clear warnings that the product is experimental.
- Active monitoring.
- A defined process for suspending strategies or markets.
- A limited initial group of users.
Deliverable: Pilot report covering reliability, incidents, transaction costs, strategy activity, and user feedback.
Phase 5; Public-launch decision
After the pilot, the DAO would receive:
- Final operating budget.
- Maintenance requirements.
- Infrastructure costs.
- Proposed KNINE credit economics.
- Revenue and treasury treatment.
- Security and incident history.
- User feedback.
- Recommended launch limits.
- Legal or regulatory considerations where applicable.
A separate DAO decision would then determine whether K9 Farm should become an official public K9 Finance product.
Funding Request
This proposal does not request an undefined development budget or authorize an immediate unrestricted deployment.
Instead, it requests authorization to obtain:
- A technical assessment from the K9 development team or other qualified developers.
- A detailed remediation and completion estimate.
- Independent audit quotations.
- Estimated infrastructure and maintenance expenses.
Once those figures are available, they should be published for community review.
Any treasury expenditure should require:
- A clearly stated maximum amount.
- Named deliverables.
- Milestone-based payments.
- Identification of the responsible parties.
- Disclosure of conflicts of interest.
- A final DAO or authorized governance approval.
I am not requesting compensation for the prototype work already completed. Any future development responsibilities, intellectual-property rights, licensing terms, maintenance obligations, and liability expectations must still be documented fairly for both the DAO and contributors.
Funding should only be considered after existing DAO obligations related to migration, user claims, and treasury commitments have been accounted for.
Governance and Oversight
Before launch, the DAO should define who has authority to:
- Add or remove markets.
- Change risk limits.
- Change credit pricing.
- Pause automation.
- Upgrade contracts.
- Operate keeper infrastructure.
- Respond to an incident.
- Communicate security problems.
- Authorize spending.
- Publish operational reports.
Important changes should be transparent and subject to appropriate multisig or governance controls.
A regular public report should include:
- Active users and strategies.
- Strategy transaction success and failure rates.
- Gas expenditure.
- KNINE credit usage.
- Supported and suspended markets.
- Security incidents.
- Contract upgrades.
- Infrastructure expenses.
- Revenue received by the DAO, if any.
User profitability should not be presented as the primary success metric because market outcomes depend on each user’s choices and market conditions.
Principal Risks
K9 Farm cannot remove the normal risks of crypto or DeFi.
These include:
- Losses caused by market movements.
- Impermanent loss.
- Tokens failing to recover after a purchase.
- Selling too early during a price increase.
- Smart-contract vulnerabilities.
- Keeper or infrastructure failure.
- Incorrect or manipulated pool prices.
- Excessive slippage.
- Front-running and MEV.
- Failed or delayed transactions.
- Gas-price increases.
- Malicious or unusual token contracts.
- Chain, bridge, or protocol failures.
- Incorrect user settings.
- Regulatory or legal uncertainty.
No strategy should be marketed as safe, guaranteed, passive income, or consistently profitable.
Users should begin with small amounts and understand the rules and risks of each strategy before increasing their exposure.
What This Proposal Does Not Approve
Approval of this proposal would not:
- Declare the prototype audited.
- Make K9 Farm an official production product immediately.
- Guarantee profits or fee income.
- Authorize the system to trade DAO treasury assets.
- Approve unlimited treasury spending.
- Approve every currently integrated chain or token.
- Give an automation operator unlimited access to user wallets.
- Eliminate the need for a subsequent launch decision.
Requested Decision
I ask the community to choose between the following options:
Option A; Approve phased evaluation
Approve K9 Farm for technical assessment, audit scoping, budget preparation, and development of a limited-pilot proposal.
No public production launch or uncapped treasury expenditure is authorized.
Option B; Request revisions
Return the proposal for changes or additional information before approving an assessment.
Option C; Do not proceed
The DAO should not dedicate development or treasury resources to K9 Farm.
Closing
K9 Farm began with a simple idea: people should be able to define how they want to trade or provide liquidity without being forced to watch charts all day or commit everything through one transaction.
The prototype is working, but I do not want to pretend that working software is automatically secure or ready for the public. That requires professional review, testing, auditing, clear governance, and honest communication about risk.
I am bringing it to the community because I believe it could become:
- A real K9 Finance product.
- A meaningful utility for KNINE.
- A useful tool for people who want rule-based DeFi automation.
- One contribution toward making K9 Finance active and productive again.
I welcome technical criticism, questions, feature suggestions, and discussion about whether the DAO should take the next step.
