SilkNode

A private settlement research architecture

Public architecture paper September 2026

Public summary

SilkNode is research into a private, modular settlement network whose rules remain inspectable and whose authority remains narrow.

The central idea is simple. Privacy is not enough if different participants can interpret the same history differently. Determinism is not enough if the ledger exposes every relationship. Modularity is not enough if an upgrade can quietly widen authority. SilkNode studies how private transfers, proof of work, deterministic ordering, local wallet custody, bounded software agents, and isolated asset gateways might coexist without collapsing into one trusted service.

The current system is a private, synthetic, no-value research prototype. A signed research snapshot contains implemented components for deterministic rule profiles, work verification, ordered execution, proof-bearing shielded-transfer feasibility, local wallet state, persistence, and bounded node experiments. Focused model, regression, component, and unit suites have passed against that lineage. A private multi-process devnet and work-weighted branching experiments also exist, but remain prototypes rather than evidence of a secure public network.

SilkNode is not launched. It has no mainnet, valuable asset, live bridge, reserves, production mining rewards, final token economics, public performance figure, production anonymity claim, or completed security audit. Its graph design is an experiment in deterministic convergence, not a claim of finality or solved consensus. Its privacy work addresses bounded ledger properties; network metadata privacy remains a separate and difficult problem.

The project’s direction is consequential precisely because it is constrained. A wallet should control its own keys. A node should verify without gaining spending authority. A relay should move data without becoming a custodian. An AI model should propose actions without becoming the enforcement layer. An external-asset gateway should not be able to rewrite native settlement or create the native resource asset. Every authority should be named, bounded, and replaceable where possible.

This paper explains that architecture, the evidence that currently exists, and the research gates that remain. It intentionally omits reconstruction-enabling protocol detail. High-level ideas can still be copied; no public paper can prevent that. The disclosure boundary protects unfinished mechanisms and attack surfaces, not abstract concepts.

1. Status language

Every technical claim in this paper uses one of four labels.

IMPLEMENTED AND VERIFIED

A bounded property exists in the current signed private research lineage and has direct local verification through focused tests or invariant checks. This label does not mean production safe, audited, independently reproduced, or deployed.

PRIVATE PROTOTYPE

An integrated experiment exists in private code or a private test environment. It may exercise real cryptographic or networking behavior, but has not crossed the evidence threshold for a public network.

PLANNED

The capability is part of the intended research or product path, but is not a current capability.

OPEN RESEARCH

The design question remains unsettled. There may be candidate mechanisms or partial experiments, but no answer should be treated as selected or proven.

These labels are deliberately conservative. A feature can contain implemented and verified subcomponents while the overall system remains a private prototype.

2. Problem statement

Digital value systems usually optimize one layer at a time.

Some make transaction history easy to verify but expose a durable social graph. Some hide ledger details while leaving network observation, recovery, or custody as separate trust problems. Some increase concurrency but make ordering and recovery harder to explain. Some add programmable agents while allowing models, application servers, or custodians to become de facto policy authorities. Some connect external assets by introducing a bridge whose failure can contaminate the native system.

SilkNode asks a narrower question:

Can a private settlement system derive one deterministic state from independently verified work while keeping keys local, upgrade authority explicit, and optional product layers outside the trusted core?

That question has several implications.

First, privacy must be defined in layers. Hiding a transfer amount is not the same as hiding who connected to whom. A private ledger is not automatically a private network. A private wallet is not automatically recoverable. Claims must say which boundary they cover.

Second, concurrency must still result in one reproducible interpretation. If eligible work can arrive in parallel, ordering cannot be a matter of local preference. The system needs a deterministic rule that honest implementations can evaluate independently.

Third, extensibility must not become ambient authority. New proof systems, assets, wallets, agents, and gateway adapters should enter through explicit profiles and capability ceilings. Unknown behavior should fail closed.

Fourth, usability is part of the security model. If ordinary users must understand internal graph rules, relay construction, or proof machinery to remain safe, the architecture has failed at the product boundary.

3. Design principles

3.1 Narrow authority

Each module should receive only the authority required for its task. The ordering layer should not spend funds. The network layer should not mutate private balances. The wallet should not decide global history. An AI model should not change protocol rules. A gateway should not issue the native resource asset.

The current architecture implements a narrow execution-authority boundary. It is not presented as a formally proven minimal trusted computing base.

Status: IMPLEMENTED AND VERIFIED for bounded component separation. OPEN RESEARCH for a complete production trust proof.

3.2 Determinism before convenience

Identical validated inputs under the same active rule profile should produce identical trusted state. Rejection should leave that state unchanged. Restart should not create a second interpretation of history.

Status: IMPLEMENTED AND VERIFIED in bounded synthetic and shielded component tests. PRIVATE PROTOTYPE at the integrated node level.

3.3 Privacy by data minimization

The safest sensitive datum is one the network never receives. Wallet secrets and private recognition state should remain local. Public verification material should reveal no more than the active rules require. Ledger privacy and transport privacy are assessed separately.

Status: IMPLEMENTED AND VERIFIED for bounded local-wallet and shielded-transfer properties. OPEN RESEARCH for production anonymity and resistance to broad network observation.

3.4 Fail-closed evolution

An unknown profile, module, proof rule, or activation state should not be interpreted optimistically. Evolution should be explicit, versioned, reviewable, and bounded by declared capabilities.

Status: IMPLEMENTED AND VERIFIED for current profile and capability boundaries. PLANNED for a production upgrade process.

3.5 Replaceable edges

Wallet interfaces, miners, relays, indexers, agent software, and gateway adapters should be replaceable without redefining native settlement. Replaceability reduces capture and makes failure domains easier to reason about.

Status: IMPLEMENTED AND VERIFIED for selected module seams. PLANNED for independent clients and product implementations.

3.6 Evidence before adjectives

Performance, accessibility, privacy, decentralization, and security are measurement claims. They are not branding. A candidate advances only when its evidence survives realistic conditions and independent scrutiny.

Status: IMPLEMENTED AND VERIFIED as a research policy. OPEN RESEARCH for the measurements themselves.

4. System boundary

SilkNode separates the system into a small settlement path and optional product layers.

The settlement path receives public transaction material, verifies eligibility, derives an ordered history, evaluates state transitions, and commits a checkpoint. The wallet observes declared public data, recognizes relevant activity locally, and retains private authority. Networking moves candidate information between nodes but does not gain settlement or spending power.

Optional layers include user interfaces, mining coordination, agent clients, archival services, and external-asset gateways. They can improve access, automation, or interoperability, but they must not silently expand the authority of the native settlement path.

The intended responsibility flow is:

1. A wallet constructs public verification material while retaining private authority.
2. A node checks that submitted material belongs to the active profile.
3. The work layer validates the evidence attached to eligible bodies.
4. The ordering layer derives one deterministic interpretation from eligible work.
5. The execution layer evaluates that interpretation against an immutable prior state.
6. A single checkpoint boundary commits the next trusted state.
7. Wallets and read-only services reconcile from declared public results.

This is a responsibility map, not a protocol recipe. The exact formats, proof relation, ordering procedure, activation rules, and network exchanges are intentionally outside this public paper.

5. Module responsibilities

5.1 Identity and profile layer

The identity and profile layer names the rule context under which data is interpreted. It binds a network instance to declared semantics and rejects unknown or incompatible behavior. Capability ceilings prevent a component from claiming powers outside its profile.

Its purpose is not to create a general plugin marketplace inside consensus. Its purpose is to make the accepted rule surface finite and inspectable.

Status: IMPLEMENTED AND VERIFIED for bounded profile validation and fail-closed capability checks.

5.2 Work layer

The work layer verifies objective evidence associated with candidate history. It answers whether the evidence satisfies the active experimental profile. It does not choose monetary policy, grant finality, or prove that mining is decentralized.

The current direction studies memory-intensive proof of work because commodity accessibility and resistance to concentrated optimization are desirable. Those properties require sustained measurement across devices, implementations, and operating conditions. Candidate integration is not proof of accessibility.

Status: IMPLEMENTED AND VERIFIED for replaceable work-verification primitives. PRIVATE PROTOTYPE for current candidate integration. OPEN RESEARCH for accessibility, fairness, difficulty policy, and decentralization.

5.3 Ordering layer

The ordering layer receives eligible bodies and derives one deterministic order. It cannot mutate private state. Its output is an input to execution, not an alternative execution engine.

A linear baseline remains important because it is easier to reason about and provides a comparison point. The graph direction explores whether independently produced work can be admitted concurrently while preserving deterministic convergence and bounded recovery.

Status: IMPLEMENTED AND VERIFIED for bounded deterministic cumulative-work ordering. PRIVATE PROTOTYPE for work-weighted branching and convergence experiments. OPEN RESEARCH for production consensus, finality, adversarial stability, and a demonstrated advantage over a simpler linear design.

5.4 Execution kernel

The execution kernel reads an immutable trusted base, validates an ordered transition, and produces typed effects. It does not write directly to durable state. This separation makes rejected inputs easier to reason about and narrows the place where state can change.

The transparent control kernel exercises synthetic accounting, authority, migration, and mandate behavior. These are test semantics, not valuable operation or final economics.

Status: IMPLEMENTED AND VERIFIED for bounded deterministic transition behavior.

5.5 Checkpoint materializer

The checkpoint materializer is the sole authority permitted to commit the next trusted state. It accepts only effects that have passed the active validation path. Readers, relays, wallets, and ordering components cannot bypass it.

The intended recovery property is atomicity: after interruption, the system should reopen either the prior complete state or the next complete state, never an ambiguous mixture.

Status: IMPLEMENTED AND VERIFIED for bounded persistence and recovery cases. PRIVATE PROTOTYPE for integrated long-running operation.

5.6 Shielded transfer component

The shielded component studies proof-bearing transfers that can be publicly validated without exposing the private values and ownership relationships required to authorize them. Public validity and private recognition are separate responsibilities.

The current work demonstrates feasibility under a bounded experimental profile. It does not establish a production proof system, complete anonymity, resistance to every cryptographic attack, or privacy against network observation.

Status: IMPLEMENTED AND VERIFIED for bounded shielded-transfer feasibility. PRIVATE PROTOTYPE for node integration. OPEN RESEARCH for production proof assurance and end-to-end privacy.

5.7 Wallet

The wallet owns user secrets, recognizes relevant activity, maintains encrypted local state, and constructs public transaction material. The node-facing boundary should not require spending keys or a private account database.

The wallet must also survive honest history changes. When a previously observed branch is no longer selected, local state should remove orphaned effects and continue from the selected history. Recovery should depend on user-held material plus declared public data, not on a privileged application database.

Status: IMPLEMENTED AND VERIFIED for bounded local key separation, persistence, replay, restart, and reorganization handling. PLANNED for a production wallet, mobile proving, human recovery flows, and independent implementations.

5.8 Node

The node hosts admission, persistence, synchronization, bounded recovery, work verification, ordering, and checkpoint coordination. It should expose narrow status receipts rather than invite operators to manipulate internal state.

The present node is a private local experiment. Its networking and relay work explore authenticated exchange, bounded catch-up, branch reconciliation, restart, and traffic-shaping ideas. These experiments do not establish public-network resilience or anonymity.

Status: PRIVATE PROTOTYPE.

5.9 Relay and discovery

Relay and discovery components move information and help peers find eligible sources. They receive no spending authority and should not become global truth providers. A node must independently validate what it receives.

Relays may still observe, delay, censor, correlate, or withhold traffic. Multiple paths can reduce dependence on one intermediary, but cannot by themselves defeat a broad observer.

Status: PRIVATE PROTOTYPE for bounded transport experiments. OPEN RESEARCH for robust metadata privacy, discovery under adversarial conditions, censorship resistance, and denial-of-service behavior.

5.10 Agent client

Agent software is a future client layer. A model may propose an action, but the protocol should enforce a user-defined mandate that limits value, scope, duration, and destination authority. The model remains replaceable and off-consensus.

This separates intelligence from enforcement. A useful agent can be wrong without gaining the power to redefine its own permissions.

Status: IMPLEMENTED AND VERIFIED only for a bounded synthetic mandate state machine. PLANNED for an agent wallet product. OPEN RESEARCH for revocation, concurrent actions, recovery, privacy, and usable policy design.

5.11 External-asset gateways

An external-asset gateway is a later interoperability layer, not part of native settlement. Each asset and gateway version should be isolated. A gateway must not issue the native resource asset, modify native history, or inherit authority over unrelated gateways.

Three properties must remain distinct:

• Native wallet independence: the user can control native funds without a service account.
• Claim transfer: a private representation can change ownership inside the system.
• Independent exit: a valid holder can recover the underlying asset without discretionary operator approval.

Only the first is part of the present native direction. Gateway issuance, reserve assurance, release, and independent exit remain future research. There are no live gateways, bridges, reserves, deposits, or withdrawals.

Status: PLANNED and OPEN RESEARCH.

6. The narrow trusted core

SilkNode’s trusted path is intentionally smaller than the full product.

The trusted path must decide only:

• which rule profile is active;
• whether submitted material is eligible;
• how eligible work is ordered;
• whether the ordered transitions are valid;
• which effects follow from valid transitions; and
• which complete checkpoint becomes authoritative.

Everything else should be outside direct state-transition authority.

Wallet presentation, search, indexing, relay choice, miner dashboards, agent reasoning, gateway user interfaces, and analytics can all be useful without being allowed to rewrite settlement. This distinction matters because product complexity grows faster than consensus confidence. The architecture should let the product improve without placing every product dependency inside the permanent trust base.

The trusted core still depends on cryptographic assumptions, correct implementations, active profile selection, local platform integrity, and data availability. Calling it narrow is not the same as calling it safe. Independent review and hostile testing remain necessary.

Status: IMPLEMENTED AND VERIFIED for selected authority separations. OPEN RESEARCH for a complete production security argument.

7. Proof of work and deterministic graph ordering

7.1 Why proof of work remains in scope

SilkNode studies proof of work because it provides an objective cost that nodes can verify without granting permanent voting identities. That does not make every work function fair, accessible, or decentralized.

The research objective is a work function that remains practical on broadly available hardware, is costly to specialize around, and can be verified efficiently. The project will not claim those properties from a short benchmark or a chosen algorithm name. They require sustained measurements, cross-device comparison, implementation diversity, thermal and energy analysis, and observation at realistic scale.

7.2 Why a graph is being studied

Independent miners may discover eligible work at similar times. A graph can preserve more concurrent work than a strictly linear tip rule. In principle, that may reduce discarded effort and improve responsiveness.

The cost is complexity. A graph increases the state that implementations must validate, store, recover, and order. It can also create new incentives and adversarial strategies. SilkNode therefore treats graph ordering as a candidate that must beat a linear baseline on measured outcomes, not as a predetermined feature.

7.3 The public-safe ordering claim

The current prototype admits work-bearing branches, independently verifies them, retains alternatives, and applies a deterministic selection and ordering policy in bounded local experiments. Nodes presented with the same eligible view are expected to derive the same selected history.

This paper does not disclose the selection rule, tie handling, graph bounds, timing policy, difficulty policy, checkpoint cadence, or branch mechanics. It makes no finality claim.

Status: PRIVATE PROTOTYPE.

7.4 Advancement gate

The graph candidate should advance only if it materially improves the linear baseline without worsening:

• agreement under partial views;
• restart and recovery behavior;
• storage and verification burden;
• privacy leakage;
• denial-of-service exposure;
• mining accessibility; or
• incentive stability.

This gate is falsifiable and may reject the graph direction.

Status: OPEN RESEARCH.

8. Privacy model

Privacy is divided into four boundaries.

8.1 Ledger privacy

The shielded design aims to avoid publishing the values and ownership relationships required to validate a transfer. Public observers should be able to validate allowed state changes without learning the wallet’s private recognition state.

Status: IMPLEMENTED AND VERIFIED for bounded feasibility cases. OPEN RESEARCH for a production profile.

8.2 Wallet privacy

Private keys, viewing authority, and recognized wallet state should remain local. A node should receive public transaction material, not the wallet’s full private history.

Status: IMPLEMENTED AND VERIFIED for the bounded local wallet.

8.3 Network privacy

Even a perfectly shielded ledger can leak through connection timing, message size, route reuse, peer observation, endpoint compromise, or a global observer. Relay and cover experiments can change the cost of observation, but are not an anonymity proof.

Status: PRIVATE PROTOTYPE for selected transport experiments. OPEN RESEARCH for meaningful production guarantees.

8.4 Product privacy

Interfaces, crash reports, update systems, gateways, and support channels can recreate the identity graph that the ledger avoids. Product telemetry should therefore be minimal, explicit, and separable from core operation.

Status: PLANNED.

No equivalence to a production privacy network is claimed. The current evidence is bounded and local.

9. Trust assumptions and failure domains

SilkNode does not remove trust. It attempts to expose and contain it.

9.1 Native settlement

Participants assume that the active rules and cryptographic primitives behave as intended, implementations enforce them correctly, and enough valid data remains available to reconstruct state. Independent implementations and review are needed to reduce common-mode failure.

9.2 Local device

A compromised device can steal keys, alter what the user sees, or authorize unwanted actions. Ledger privacy cannot repair endpoint compromise. Hardware-backed storage, clear signing intent, recovery design, and update integrity belong to the product threat model.

9.3 Peers and relays

Peers and relays are untrusted sources of candidate data. They may lie, omit, delay, correlate, or disappear. Authentication can identify a configured counterparty; it does not make that counterparty honest or available.

9.4 Archives

Recovery may depend on public history being available. An archive can withhold data even if it cannot forge valid state. Availability diversity and recovery measurements are therefore separate requirements.

9.5 Miners

Miners provide work, not semantic authority. Concentration can still affect censorship, reorganization pressure, and liveness. Accessibility must be observed rather than assumed.

9.6 Software agents

Models and agent runtimes are untrusted decision aids. The protocol boundary must enforce the user’s mandate even when the model is mistaken, manipulated, unavailable, or replaced.

9.7 Gateways

Every external-asset gateway introduces asset-specific custody, reserve, censorship, and exit assumptions. Those risks must remain isolated from native settlement and from other gateway domains.

9.8 Signed source and tests

A signed research revision supports provenance on the verifying machine. It does not prove publication, ownership of an external identity, correctness, absence of vulnerabilities, or independent audit. Passing tests demonstrate only the cases they exercise.

10. Current evidence

The current private research lineage provides the following bounded evidence.

Fresh verification for this paper checked a signed private snapshot and passed focused model, regression, component, and node unit suites. Separate proof-heavy local cases covering graph reconstruction and convergence, interruption-safe state commitment, and wallet restart and branch reconciliation also passed. These receipts support only the bounded outcomes explicitly reported above. The public paper does not elevate uncommitted work, stale prose, test names, or historical plans into current capability claims.

11. User experience direction

Security boundaries only matter if people can use them without becoming protocol operators.

11.1 Wallet experience

A production wallet should make four states obvious:

• what the user controls locally;
• what has been submitted but not selected;
• what is selected in the current history; and
• what can be recovered from user-held material.

A private transfer flow should show intent, authority, and completion without revealing internal proof or graph mechanics. A recovery flow should explain what can be restored, what public data is required, and what cannot be recovered. Branch changes should reconcile quietly while leaving an inspectable receipt.

Status: PLANNED.

11.2 Node experience

A node should have safe defaults, a narrow lifecycle, and clear local receipts for profile, synchronization, storage, and selected history. Routine operation should not require editing internal state or choosing a preferred branch manually.

Status: PRIVATE PROTOTYPE for a headless local lifecycle. PLANNED for production packaging and cross-platform operation.

11.3 Mining experience

A miner should be able to inspect the active work profile, verify received jobs, measure local behavior, and submit work without granting custody or broad node authority. Consumer-device accessibility must be tested across sustained loads and diverse systems.

Status: PRIVATE PROTOTYPE for candidate work integration. PLANNED for usable tooling. OPEN RESEARCH for accessibility and pool design.

11.4 Agent experience

An agent wallet should begin with a user-created mandate, not an unrestricted account. The interface should show remaining authority, pending actions, revocation state, and a receipt that can be checked without trusting the model’s explanation.

Status: PLANNED.

11.5 Gateway experience

A gateway interface must state which asset, which gateway version, which custody assumptions, which reserve evidence, and which exit path apply. Native and gateway balances must never be presented as the same trust object.

Status: PLANNED and OPEN RESEARCH.

12. Economic design

SilkNode’s economic design is constrained before it is specified.

The architecture contemplates one native resource asset, SILK, for native settlement and resource accounting. No external gateway may create it. Fees must not silently expand supply. Any issuance must be explicit in the active rules, bounded by reviewable policy, and separable from external-asset accounting.

The following questions remain open:

• whether and how new native units should be issued;
• how work should be rewarded without creating avoidable concentration;
• which resources fees should price;
• how fee behavior should remain usable during congestion;
• how long-term security should be funded;
• how upgrades affect economic expectations; and
• how distribution can avoid hidden privilege.

There is no final emission curve, reward allocation, fee formula, premine assumption, sale plan, or valuable mining system in this paper. Synthetic balances and control-kernel accounting are test instruments only.

Economic advancement requires simulation, adversarial analysis, accessibility measurement, clear supply invariants, public review, and a separate decision to permit valuable operation.

Status: OPEN RESEARCH.

13. AI agents and bounded spending authority

Machine payments create a new authority problem. The question is not whether a model can construct a transaction. The question is who can widen the model’s permission after the user has left.

SilkNode’s design direction is that a user creates a bounded mandate. The protocol evaluates the mandate, not the model’s confidence. Agent software can search, negotiate, recommend, and assemble a proposed action, but it cannot grant itself more value, more time, a wider destination set, or a new asset domain.

The agent remains outside consensus. Different models and providers can compete without becoming protocol dependencies. A user can replace the model while retaining the same local wallet and settlement rules.

Research gates include:

• no accepted action sequence may exceed the original user authority;
• concurrent proposals must not multiply a shared budget;
• revocation must have an explicit and testable boundary;
• recovery must not resurrect expired authority;
• receipts must be independently checkable; and
• private intent should not become public policy metadata by default.

Status: IMPLEMENTED AND VERIFIED for bounded synthetic mandate behavior. PLANNED for a real agent client. OPEN RESEARCH for production semantics and UX.

14. Private asset gateways

External assets are treated as later gateway research. A gateway is not a synonym for the native network and not evidence that an external asset has become trustless.

The isolation requirements are:

1. A gateway cannot issue native SILK.
2. A gateway cannot alter native ordering or settlement.
3. Failure of one asset domain cannot authorize claims in another.
4. Accepted claims cannot exceed the evidence accepted for that gateway.
5. Users must be told whether exit is operator-dependent or independently enforceable.
6. Gateway upgrades must not silently reinterpret existing claims.

The strongest desired property is independent exit: a valid holder can recover the underlying asset without discretionary operator approval. That remains an objective, not a current capability. Some external systems may make it impossible without changing the trust model. The research must be willing to reject a gateway design that cannot state its authority honestly.

Status: PLANNED and OPEN RESEARCH.

15. Testnet path

SilkNode will not turn a private prototype into a valuable public network by changing a label.

Stage A: bounded component evidence

Deterministic profiles, execution, work verification, shielded feasibility, wallet behavior, persistence, and recovery are tested in isolation.

Status: IMPLEMENTED AND VERIFIED for the exercised scope.

Stage B: private no-value local network

Multiple local processes exercise synchronization, branch selection, restart, and recovery without valuable assets.

Status: PRIVATE PROTOTYPE.

Stage C: private no-value multi-host network

Independent hosts and operators test real latency, churn, partial views, resource use, packaging, and operational recovery. Results must separate protocol behavior from deployment mistakes.

Status: PLANNED.

Stage D: controlled no-value testnet

Invited external participants run reproducible builds, compare implementations, report incompatibilities, and test hostile network conditions under a coordinated disclosure process.

Status: PLANNED.

Stage E: public adversarial no-value testnet

The network is opened for broader attack, observation, mining-accessibility measurement, wallet recovery trials, and long-duration operation. Public dashboards report evidence without turning temporary metrics into guarantees.

Status: PLANNED.

Stage F: valuable-operation decision

Only after independent review, testnet evidence, economic selection, release reproducibility, operational readiness, and explicit authorization should valuable operation be considered. This stage has no promised date and may be rejected.

Status: OPEN RESEARCH.

16. Falsifiable research claims

The project should be judged by claims that can fail.

Determinism

• Identical validated inputs under one active profile produce identical checkpoints.
• Rejected, malformed, replayed, or unauthenticated inputs do not alter trusted state.
• Unknown semantics do not activate by inference.

Recovery

• An interruption leaves either the prior complete state or the next complete state.
• Reopening does not silently reinterpret the active profile.
• Wallets remove orphaned effects and continue from the selected history.
• User-held recovery material plus declared public data is sufficient for the promised recovery scope.

Ordering and work

• Nodes with the same eligible view select the same history.
• Nodes that regain the same eligible view converge after synchronization and restart.
• The graph candidate advances only if it materially outperforms the linear baseline without unacceptable safety, privacy, storage, recovery, or fairness costs.
• Mining-accessibility claims survive sustained consumer-device and scale-comparison measurements.

Privacy

• Public ledger material does not reveal the private fields the active shielded profile promises to hide.
• The node-facing wallet boundary does not require spending authority.
• Network-privacy claims are measured separately from ledger-privacy claims.

Agents

• No accepted agent action sequence exceeds or widens the user’s original mandate.
• Revoked or expired authority cannot be restored by a model, service, or replay.

Gateways

• External claims never exceed the evidence accepted for their isolated gateway.
• Gateway failure cannot alter native settlement or native issuance.
• Independent exit is claimed only when a valid holder can recover the underlying asset without discretionary operator approval.

Any failure should narrow the claim, change the design, or stop the relevant path.

17. Roadmap

The roadmap is evidence-gated rather than date-gated.

Current

• Maintain signed, bounded private research checkpoints.
• Keep the valuable-operation boundary closed.
• Consolidate deterministic execution, shielded wallet behavior, work verification, branching experiments, persistence, and recovery.
• Keep status language synchronized with current code and fresh test receipts.

Next

• Complete private no-value multi-host validation.
• Produce reproducible node, wallet, and miner packages.
• Measure resource behavior and mining accessibility across diverse hardware.
• Exercise wallet restoration and branch reconciliation under realistic history growth.
• Add independent implementations or independent conformance clients.
• Conduct focused external review of the narrow trusted path.

Later

• Run a controlled no-value testnet.
• Expand to a public adversarial no-value testnet only when operational and disclosure gates pass.
• Prototype agent clients against bounded mandates.
• Prototype isolated gateway models only after their custody, reserve, and exit assumptions are explicit.
• Select economics only after measurement and adversarial review.

Not scheduled

• Mainnet.
• Valuable issuance.
• Production mining rewards.
• Live external-asset gateways.
• A token sale.

18. What SilkNode is not claiming

This paper does not claim:

• a launched or production-ready network;
• a completed audit or proof of security;
• a solved blockchain trilemma;
• finality or production consensus from the graph experiment;
• a throughput figure;
• privacy equivalent to an established production network;
• resistance to a global observer;
• proven mining decentralization or commodity accessibility;
• final token economics;
• live deposits, withdrawals, bridges, reserves, or custody;
• valuable issuance, rewards, or fees;
• a production agent wallet;
• unilateral external-asset redemption;
• a launch date; or
• exclusive ownership of the high-level ideas described here.

19. Disclosure boundary

This public paper describes purpose, responsibility, trust, evidence, nonclaims, user flows, and research gates. It intentionally withholds exact proof construction, ordering mechanics, canonical formats, identity derivations, work and difficulty parameters, network exchanges, peer topology, persistence sequencing, agent enforcement internals, gateway release mechanics, negative test vectors, unpublished findings, and operational procedures.

That boundary has two goals. It avoids publishing an unfinished interoperability recipe, and it avoids turning a research paper into an attack map. It does not make the high-level architecture secret. Readers can independently arrive at similar ideas, and prior public work across privacy systems, proof of work, deterministic state machines, capability security, and modular protocols remains relevant.

20. Conclusion

SilkNode is an attempt to make private settlement powerful without making its authority vague.

The current evidence supports a bounded statement: a signed private research lineage contains modular components for deterministic profiles, work verification, ordered execution, shielded-transfer feasibility, local wallet state, persistence, and private node experiments, with focused suites passing for the exercised scope. It does not support a claim of a secure public network.

The path forward is therefore disciplined. Keep keys local. Keep models outside enforcement. Keep gateways isolated. Keep ordering deterministic. Keep state-commit authority narrow. Measure proof of work rather than marketing it. Treat network privacy as its own problem. Advance from private no-value evidence to public testing only when each boundary can survive independent scrutiny.

If SilkNode succeeds, the result will not be a ledger that asks users to trust more complexity. It will be a system whose complexity is divided so that each part has less power to betray them.