WHEATPAPER

THE dFARMER AS A COMPUTATIONAL PORTFOLIO

The useful distinction is between identity and behavior. The ERC-721 establishes a persistent identity and ownership relation. The associated ERC-6551 Token-Bound Account supplies the account through which the Farmer's portfolio state may be represented and acted upon. The NFT therefore identifies the system; it does not, by itself, constitute the system's entire computational behavior.

The mint is consequently a state-initialization event. DERP participates in the generation mechanism, entropy resolves the Farmer's generated state, and that state determines a four-element asset universe. Once established, the four underlying assets are fixed; strategy may govern their treatment, but it does not redefine the domain in which the Farmer operates.

Mint ETH establishes the initial capital state. If the initial capital is M and the allocation weights are w₁,...,wₙ, then ∑ᵢ wᵢ = 1, Cᵢ = M wᵢ. After initialization, the owner may alter permitted strategy parameters. Tractor observes the resulting portfolio state, evaluates the configured rules, and submits an action only when that action satisfies the protocol's authorization boundary.

The architecture is therefore a separation of identity, account, portfolio domain, intention, policy, and execution. This separation matters because an instruction to act and an authority to act are not the same thing. In symbolic form: F = (I, A, U, S, P, X) where I is identity, A the account, U the permitted asset universe, S the strategy, P the protocol policy, and X the executed action.

A SYSTEM OF STATE, CONTROL, AND FEEDBACK

The architecture can be read as a chain of transformations. Identity establishes continuity; the TBA establishes the account; generation establishes the asset domain; strategy establishes intended behavior; policy establishes permissible behavior; and Tractor translates the permitted decision into an observable transaction. The resulting system is naturally described as a feedback system: state → observation → decision → policy check → action → new state.

ERC-721 AS THE IDENTITY COORDINATE

Each dFarmer is represented by an ERC-721 token. Its principal function in this architecture is persistence of identity: the pair I = (C, N) where C is the collection contract and N is the token identifier, supplies a stable reference to the Farmer across transfers and state changes.

The identity acts as the coordinate to which generated traits, personality, asset-domain information, account association, strategy configuration, and portfolio state are related. Ownership therefore changes the controlling principal without requiring the identity of the Farmer to be recreated.

THE TOKEN-BOUND ACCOUNT AS PORTFOLIO STATE

ERC-6551 provides the account relationship through which an NFT may be associated with a Token-Bound Account. In dFARMERS, the TBA is intended to function as the Farmer's portfolio account. This creates a useful separation: identity answers “which Farmer?”; the TBA answers “where is its portfolio state?”.

ERC-6551 itself does not define dFARMERS trading rules, authorization policy, withdrawal limits, or autonomous execution. Those properties belong to the deployed TBA implementation, protocol contracts, and authorization layer. The standard establishes the account model; the implementation establishes the behavior.

The TBA therefore occupies an important control boundary. Tractor may propose or submit an action, but submission is not equivalent to authority. The intended relationship is: Tractor authority ⊆ Farmer permissions ⊆ protocol policy. The account and protocol determine whether the proposed transition is admissible.

GENERATION, ENTROPY, AND INITIAL CONDITIONS

DERP is engaged in the Farmer-generation mechanism as an input to the generation process. Let R denote the relevant entropy state and G the generation function. Then: G(R) = (T, P, U) where T denotes generated traits, P the generated personality, and U the resulting asset universe.

The important invariant is that the generated asset domain is not a strategy variable. Once U₀ has been established at generation, Uₜ = U₀ for subsequent t, subject to the actual deployed protocol rules. The owner may alter permitted behavior inside U, but does not redefine U through the strategy interface.

THE ASSET UNIVERSE AS A STATE-SPACE BOUNDARY

Let the Farmer's generated asset universe be U = {a₁, a₂, a₃, a₄}. The four elements are the domain over which portfolio allocation and strategy may operate. The distinction between the universe and the allocation is fundamental: U describes what may be represented; the weights w describe how capital is distributed within U.

Thus the system separates selection from control. Generation establishes the domain U; strategy determines a permitted state within that domain. This prevents an owner strategy from silently redefining the Farmer's underlying identity or generated asset class.

ELIGIBILITY AS AN ENVIRONMENTAL CONSTRAINT

The asset universe is also conditional upon external eligibility. Let E(a,r) ∈ {0,1} denote whether asset a is available to a participant in region r. The effective universe is therefore U(r) = {a ∈ U : E(a,r)=1}. The system must not treat an unavailable asset as though it were executable merely because it exists in the general universe.

Where the applicable stock-token assets are eligible, the generated four-asset model may be used. Where they are unavailable or not permitted, the specified fallback is Ufallback = {$STONKBROKER, $DERP, ETH} with equal weights w₁ = w₂ = w₃ = 1/3 ≈ 33.333%. This satisfies the required normalization ∑wᵢ = 1.

Regional eligibility is consequently part of the initial state function. The portfolio cannot be described independently of the environment in which its permitted assets may be accessed. This is not merely a legal qualification; it is a system constraint on the reachable state space.

Changes in regional eligibility may therefore change the set of reachable portfolio states. Any expansion of supported regions or assets remains dependent upon the applicable deployment, infrastructure, and rules governing those assets.

STRATEGY AS A CONTROL FUNCTION

Strategy is a control function over an already-defined state space. If xₜ denotes portfolio state, yₜ the observed environment, and θ the owner-configured parameters, the intended control may be written uₜ = S(xₜ, yₜ; θ). The strategy does not create the asset universe; it determines permitted behavior within it.

The Farmer may begin with an assigned strategy and subsequently accept owner configuration within the permitted parameter space. The important distinction is between changing θ and changing the protocol itself: the former is configuration; the latter is outside ordinary strategy control.

The strategies are intended to be grounded in published portfolio methodologies and expressed as explicit rules. The present system should therefore be understood as constrained automation, not as a claim that an unrestricted artificial intelligence independently invents investment policy.

CAPITAL ALLOCATION AS STATE INITIALIZATION

Minting establishes an initial capital state. Let M be the capital available for allocation and wᵢ the weight assigned to asset aᵢ. Then Cᵢ = M wᵢ, ∑ᵢ wᵢ = 1. The resulting initial portfolio is P₀ = {(aᵢ, Cᵢ)}.

After initialization, additional capital changes the portfolio state according to the deployed funding and execution rules. In general, xₜ₊₁ = f(xₜ, mₜ, uₜ, εₜ), where mₜ is capital introduced at time t, uₜ is the permitted control action, and εₜ represents external execution conditions.

CAPITAL AS A DYNAMIC STATE VARIABLE

The mint therefore performs two coupled operations: it establishes identity and initializes capital. Generation determines the asset domain; allocation maps available mint capital onto that domain.

TRACTOR AS THE EXECUTION ELEMENT OF A FEEDBACK LOOP

Tractor is the delegated execution mechanism of the system. Its purpose is not to possess unrestricted authority, but to translate an admissible strategy decision into an attempted state transition.

At time t, Tractor observes portfolio state xₜ and relevant information yₜ. It evaluates the configured strategy and produces an intended action uₜ. The action is then subjected to protocol policy before execution. Thus observation precedes action, and action remains subordinate to authority.

Let P denote the set of protocol-permitted actions. Then the executable action is Xₜ = uₜ, if uₜ ∈ P ∅, otherwise. The significance is structural: a strategy can produce an intention that the protocol refuses to realize. Autonomy is thus bounded by the set of reachable states defined by policy.

The owner remains the controlling principal for the Farmer, while Tractor operates through delegated permissions that may be revoked according to the deployed implementation. The architecture is therefore one of constrained delegation rather than unrestricted autonomous custody.

WITHDRAWAL AS A CONSTRAINED STATE TRANSITION

Withdrawal is another state transition governed by policy. If Bᵢ denotes the balance of position i, the stated per-position constraint is Wᵢ ≤ 0.5 Bᵢ. If tₗ denotes the last withdrawal time, the stated cooldown requires t - tₗ ≥ 365 days.

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.

POLICY AS A CONTROL BOUNDARY

Once an NFT can be associated with capital and delegated execution, the relevant security problem becomes one of controlling reachable state transitions. The system therefore separates strategy configuration from the authority required to execute a transition.

The security objective is not to make Tractor incapable of error. It is to ensure that an erroneous or unauthorized instruction does not imply authority. Policy must remain an independent boundary around the execution mechanism.

INTENTION WITHOUT AUTHORITY ESCALATION

Owner configuration changes the parameter vector θ governing strategy. Such configuration is therefore a change in intended behavior, not a transfer of protocol authority. The protocol boundary remains external to θ.

OBSERVATION BEFORE GREATER AUTONOMY

The present Tractor implementation is deliberately rule-driven. This is not a deficiency in terminology; it is an explicit systems decision. The first requirement of an autonomous control system is that its behavior be observable and its permissible actions describable.

The system therefore begins with a measurable loop: observation → rule evaluation → permitted action → observation. Telemetry supplies the record from which the behavior of that loop can be evaluated. If T is the telemetry set, then measured behavior B may be regarded as a function of T, and strategy quality can be evaluated against observed outcomes rather than asserted in advance.

THE ASSET LAYER AND THE APPLICATION BOUNDARY

The application layer is designed around tokenized real-world assets available through the supported chain environment. dFARMERS does not thereby become the issuer of every underlying instrument; it organizes identity, account association, portfolio logic, policy, and delegated execution around supported assets.

The architectural boundary can therefore be stated as ASSET INFRASTRUCTURE → APPLICATION STATE → CONTROL LOGIC → EXECUTION. The underlying asset layer supplies the instruments; dFARMERS supplies the Farmer abstraction and the control system surrounding them.

The precise scope of the application should remain distinct from the underlying asset infrastructure. The protocol description here is concerned with the Farmer identity, portfolio account, strategy, policy, telemetry, and execution architecture; the rights, availability, and mechanics of any underlying instrument remain properties of their respective infrastructure.

WHY ADDITIONAL ABSTRACTION IS NOT YET REQUIRED

ERC-4337 represents an additional abstraction mechanism. The engineering question is therefore not whether the mechanism is sophisticated, but whether the present system requires the capability it provides. For the current architecture, the required account relationship is already supplied through ERC-6551 and the deployed TBA model.

Introducing another abstraction layer before its capabilities are necessary would enlarge the system without enlarging its required state space. The present composition is therefore intentionally economical: ERC-721 + ERC-6551 TBA + authorization + Tractor.

This is an engineering choice rather than a rejection of account abstraction in principle. If future requirements introduce a capability that materially improves the system, the abstraction boundary can be reconsidered. Until then, unnecessary machinery is avoided.

PORTFOLIO DYNAMICS UNDER UNCERTAINTY

The system is structured as a portfolio process rather than as a single discrete event. That structural distinction does not remove market risk. If portfolio value is Vₜ = ∑ᵢ qᵢ,ₜ pᵢ,ₜ, then changes in prices, quantities, execution conditions, and strategy behavior can all alter Vₜ. No architecture of rules guarantees a favorable result.

A Farmer instead represents a continuing state whose evolution is governed by portfolio rules. Its relevant questions are therefore questions of state, exposure, allocation, execution, and risk rather than the outcome of a single uncertain event.

These rules define a bounded state space. The objective is not to eliminate uncertainty, which cannot be done, but to constrain the set of transitions through which the system may respond to uncertainty.

STANDARD, IMPLEMENTATION, AND BEHAVIOR

ERC-721 and ERC-6551 define infrastructure primitives. Neither standard, by itself, defines the dFARMERS generation function, asset-domain rules, allocation mechanism, strategy engine, withdrawal policy, Tractor authorization, telemetry system, or autonomous behavior.

Those characteristics belong to the deployed implementation. Consequently, claims about security, enforcement, or autonomous behavior must be evaluated against the actual contracts, account implementation, authorization logic, execution infrastructure, and operational controls rather than inferred from the standards alone.

The existence of a TBA therefore does not imply a particular policy. The account relationship and the behavioral policy are separate propositions and must be verified independently.