WHEATPAPER
dFARMERS defines a dFarmer as a programmable on-chain portfolio primitive. At mint, DERP is engaged in the Farmer-generation process and entropy determines the Farmer's generated traits, personality, and four-asset portfolio universe. The dFarmer is an ERC-721 token associated with an ERC-6551 Token-Bound Account (TBA). Mint ETH is automatically allocated across the four assets assigned to that Farmer, establishing its initial portfolio. Thereafter, owner-configurable strategy parameters govern portfolio behavior, while the TBA implementation and protocol authorization layer constrain what may actually be executed. Tractor operates as the delegated autonomous portfolio operator within those boundaries.
THE dFARMER AS A PORTFOLIO PRIMITIVE
dFARMERS treats the dFarmer as a persistent portfolio identity rather than a static digital collectible. The ERC-721 token establishes identity and ownership; its ERC-6551 Token-Bound Account provides the associated on-chain portfolio account.
The mint is a portfolio-generation event. DERP participates in the entropy process, the resulting traits and personality determine four supported assets, and those four assets become fixed to the Farmer's portfolio universe. The owner cannot replace those four underlying assets.
Mint ETH is automatically allocated across the four designated assets. After initialization, the owner may configure the Farmer's strategy and operating parameters through the Farm interface. Tractor then evaluates the portfolio and executes permitted actions subject to the protocol's authorization boundaries.
The system therefore separates identity, account infrastructure, asset assignment, strategy, and execution authority while keeping final control with the dFarmer owner and protocol-enforced rules.
A MULTI-LAYER PORTFOLIO MODEL
dFARMERS separates six functions that are commonly conflated: who the Farmer is, where its assets reside, how its assets are selected, how capital is managed, what actions are permitted, and which software is authorized to execute those actions.
ERC-721 AS THE IDENTITY PRIMITIVE
Each dFarmer is represented by a unique ERC-721 token. ERC-721 supplies the canonical non-fungible identity by which the Farmer can be owned, transferred, identified, and associated with its corresponding Token-Bound Account.
The identity is the persistent reference to which the Farmer's generated traits, personality, four-asset universe, TBA, strategy configuration, and portfolio state are attached.
ERC-6551 TOKEN-BOUND ACCOUNT
ERC-6551 provides the account framework by which an NFT may be associated with a Token-Bound Account. In dFARMERS, the TBA serves as the dFarmer's on-chain portfolio account: the account in which supported positions are held and through which permitted portfolio operations are executed.
ERC-6551 itself does not define dFARMERS trading rules, authorization policy, withdrawal limits, or autonomous execution. Those properties are supplied by the deployed TBA implementation, protocol contracts, and authorization layer.
In this architecture, the TBA functions as both the Farmer's account and the primary enforcement boundary for delegated execution. Tractor can submit an action, but the account and protocol logic determine whether that action is permitted.
DERP ENGAGEMENT AND ENTROPY-DRIVEN GENERATION
DERP is engaged in the Farmer-generation mechanism as an entropy input. At mint, the generation process resolves the Farmer's traits and personality. That generated state determines the Farmer's four designated supported assets.
The asset universe is therefore established during generation. It is not selected later by the owner and cannot be replaced through the strategy interface.
THE FARMER RECEIVES FOUR FIXED ASSETS
Each Farmer receives exactly four supported underlying assets as a consequence of the mint-time generation process. These assets constitute that Farmer's permitted portfolio universe.
The first supported asset assigned to the Farmer.
The second supported asset assigned to the Farmer.
The third supported asset assigned to the Farmer.
The fourth supported asset assigned to the Farmer.
The owner may change how the four assets are managed, but may not replace the underlying four-asset universe.
This separation is fundamental. Asset assignment occurs once during Farmer generation; portfolio management remains configurable after mint.
STOCK TOKEN AVAILABILITY IS REGION-DEPENDENT
The four-asset Farmer model is subject to the legal and geographic availability of supported tokenized stock assets. The stock positions described in the Farmer-generation model are not universally available to every minter. Eligibility depends on whether the minter is located in a jurisdiction in which the applicable Robinhood tokenized stock assets are permitted and available.
Where the minter is located in an eligible region, the Farmer may receive its four designated supported stock assets according to the established generation process. Where the minter is located in a region in which Robinhood stock tokens are not permitted or available, the Farmer does not receive those stock positions. Instead, the Farmer receives a three-asset allocation consisting of $STONKBROKER, $DERP, and Ethereum, allocated at 33% each.
The Farmer receives its four designated supported assets when the applicable tokenized stock assets are legally and technically available to the minter.
The Farmer receives $STONKBROKER, $DERP, and Ethereum at 33% each when Robinhood stock tokens are unavailable or not permitted in the minter's region.
Regional eligibility is therefore an input to the Farmer's initial asset configuration. The protocol does not assume that tokenized stock access is globally uniform, and it does not represent unavailable stock positions as though they were accessible to an ineligible minter.
dFARMERS will actively monitor newly qualified regions, regulatory developments, and amendments to applicable laws and rules that may change the availability of supported tokenized stock assets. As additional jurisdictions become qualified, the protocol may evaluate those regions for inclusion in the supported deployment and asset-eligibility framework.
STRATEGY DETERMINES HOW THE FARMER OPERATES
Asset assignment and portfolio management are separate functions. The four underlying assets are fixed by the Farmer-generation process; strategy determines how capital and positions may be managed within that universe.
Farmers are initially assigned a strategy, but the owner can subsequently modify the Farmer's strategy and operating parameters through the Farm interface, subject to protocol-defined boundaries.
Defines the selected level of portfolio risk.
Controls the permitted level of trading activity.
Determines how target allocations may be restored.
Defines the selected threshold for realizing gains.
Defines how eligible capital is distributed within the Farmer's universe.
Determines the range within which owner configuration may operate.
The strategies are intended to be derived from published academic research supporting the underlying portfolio methodologies. They are implemented as defined autonomous flows rather than as claims of unrestricted artificial intelligence.
MINT CAPITAL FOLLOWS THE GENERATED FARMER
The initial economic state of a Farmer is established at mint. ETH received from the mint is automatically allocated across the four assets determined for that Farmer.
Subsequent capital may be introduced through the Farmer account environment and managed according to the active strategy. The exact routing and execution path remains dependent on the deployed protocol contracts and supported execution environment.
FROM MINT TO FARMER CAPITAL
The mint establishes the Farmer's initial portfolio. The generation process determines the four assets, and mint ETH is automatically deployed across those assets.
TRACTOR AS THE DELEGATED AUTONOMOUS OPERATOR
Tractor is the autonomous application layer responsible for operating a dFarmer within its configured strategy and protocol permissions.
Tractor monitors portfolio state and the Farmer's configured strategy, determines when a permitted action should occur, and submits the corresponding transaction. Tractor is not granted unrestricted control over the Farmer.
When Tractor submits an action, the TBA authorization layer evaluates the request against the Farmer's permitted assets, approved contracts, allocation rules, transaction limits, trading restrictions, liquidation constraints, and other protocol-defined policies. An action that falls outside those boundaries must not execute.
The owner retains ultimate control over the Farmer and can revoke Tractor's authorization. The system is therefore designed as constrained delegation rather than unrestricted autonomous custody.
PROTOCOL-CONSTRAINED CAPITAL WITHDRAWAL
The Farmer's TBA is designed around continued portfolio participation. Withdrawals are therefore subject to protocol constraints intended to prevent unrestricted extraction of portfolio positions.
A Farmer may execute a withdrawal no more than once during a twelve-month period.
A maximum of 50% of each individual TBA position may be withdrawn during the permitted withdrawal window.
At least half of each position remains inside the Farmer's TBA following a maximum withdrawal.
Withdrawal limits and cooldowns are protocol controls rather than strategy settings.
The 50% restriction applies independently to each position. It does not permit the owner to withdraw 50% of total account value from one asset while removing the remaining portfolio exposure.
ENFORCING FARMER BOUNDARIES
A portfolio-bearing TBA has a larger security surface than a conventional NFT. dFARMERS therefore separates owner-configured strategy from protocol-controlled authorization and account rules.
Execution is restricted to the Farmer's four assigned supported assets.
TBA execution may be restricted to approved contracts and operations.
Protocol rules constrain permitted capital allocation and transaction behavior.
Trading frequency and execution activity may be bounded by protocol rules.
Liquidation behavior remains subject to defined account and strategy boundaries.
Tractor acts only as a delegated operator within explicit permissions and may be revoked by the owner.
Invalid or unauthorized operations should fail before producing an unintended portfolio state. The protocol boundary is therefore independent from Tractor's software decision process.
USER CONTROL WITHOUT PROTOCOL OVERRIDE
The Farm interface exposes a defined set of strategy parameters that the dFarmer owner may modify. Changes to on-chain strategy configuration require the applicable network transaction and gas.
MEASUREMENT BEFORE GREATER AUTONOMY
The current Tractor implementation is intentionally rule-driven. It should not be characterized as an unrestricted artificial intelligence capable of independently inventing investment decisions.
The initial objective is reliable instruction-following and deterministic execution. The system then collects real-world performance and behavioral data that can be used to evaluate strategy quality, portfolio response, execution reliability, and the value of progressively more sophisticated autonomy.
Relevant system activity is captured for analysis and verification.
SQLite is used as the current development data-storage layer.
Strategy logic is derived from published academic research.
Real-world Farmer behavior becomes an input to future system design.
Autonomous flows can be evaluated against observable outcomes.
More sophisticated autonomy is introduced only as evidence supports it.
ROBINHOOD CHAIN AND TOKENIZED REAL-WORLD ASSETS
dFARMERS is designed to interact with actual tokenized real-world assets on Robinhood Chain rather than simulated representations. The Farmer's TBA is intended to hold and control the corresponding on-chain positions.
The underlying RWA infrastructure provides the tokenized assets. dFARMERS operates at the application layer, providing the Farmer identity, TBA association, strategy system, authorization boundaries, telemetry, and autonomous portfolio-management logic.
dFARMERS is not intended to issue the underlying securities, take custody of users' assets as a broker, or represent the underlying financial infrastructure itself. The product is designed as an application and portfolio-management layer around supported tokenized assets.
WHY ERC-4337 IS NOT REQUIRED AT THIS STAGE
ERC-4337 was evaluated as a potential account-abstraction layer because of the additional capabilities it can provide for smart-account infrastructure. For the current proof of concept, however, those capabilities are not required.
ERC-6551 already provides the account relationship required by the Farmer architecture, while the deployed TBA implementation and protocol authorization layer establish the execution boundaries required for Tractor.
The system therefore avoids introducing an additional abstraction layer before its operational requirements justify it. A more sophisticated account-abstraction model may become appropriate in a later development stage, potentially S2, as the system evolves.
A PORTFOLIO SYSTEM, NOT A WAGERING MECHANISM
dFARMERS is designed to function as an automated portfolio system rather than a discrete betting mechanism. Financial risk remains inherent: underlying assets can lose value, strategies can underperform, and no portfolio outcome is guaranteed.
The structural distinction is that a Farmer represents an ongoing portfolio of supported assets governed by allocation, execution, and risk-management rules. It is not designed around a discrete wager on an uncertain event.
Defined asset universes, allocation parameters, transaction restrictions, trading-frequency limits, liquidation controls, and withdrawal constraints establish the operating boundaries within which Tractor can act.
The persistent NFT identity representing the Farmer.
The Farmer's on-chain account and delegated-execution boundary.
The fixed asset universe established during Farmer generation.
The autonomous software operating within owner and protocol permissions.
STANDARD VS. PROTOCOL IMPLEMENTATION
ERC-721 defines a non-fungible token standard. ERC-6551 defines an architecture for Token-Bound Accounts. Neither standard, by itself, defines the dFARMERS strategy engine, Farmer-generation process, four-asset assignment, automatic mint-capital allocation, withdrawal restrictions, Tractor authorization, telemetry system, or autonomous portfolio behavior.
Those characteristics belong to the dFARMERS implementation: its contracts, TBA implementation, generation mechanism, authorization logic, execution infrastructure, and supporting systems. Their security and enforceability therefore depend upon the actual deployed implementation.
Likewise, the existence of an ERC-6551 TBA does not independently guarantee any particular trading, withdrawal, or authorization behavior. Those properties must be enforced by the deployed account and protocol architecture.
THE dFARMER AS A CONSTRAINED AUTONOMOUS PORTFOLIO
dFARMERS defines the dFarmer as a programmable portfolio primitive composed of identity, account infrastructure, DERP-engaged generation, four fixed assets, capital, configurable strategy, protocol policy, and delegated autonomous execution.
The ERC-721 establishes who the Farmer is. The ERC-6551 Token-Bound Account provides its portfolio account. DERP is engaged in the generation process; entropy resolves the Farmer's traits and personality; and that generated state determines the four underlying assets that form the Farmer's fixed portfolio universe.
Mint ETH is automatically allocated across those four assets. Thereafter, the owner may modify the Farmer's strategy and operating parameters, but cannot replace the underlying asset universe. Tractor evaluates the portfolio and submits permitted actions, while the TBA implementation and protocol authorization layer enforce the boundaries under which those actions may occur.
The current system deliberately represents constrained autonomy rather than unrestricted artificial intelligence. Its strategies are defined, its execution is observable, and its system events are collected for empirical evaluation. Real-world data can then inform future increases in autonomous capability.
The resulting architecture is intended to establish a foundation for progressively more capable on-chain portfolio agents: deterministic execution first, telemetry and validation second, and increasingly sophisticated autonomy only as evidence supports it.