Jackfa
DOCS / ARCHITECTURE

A system you
can check.

Jackfa keeps the plan, the permission to trade, the order attempt, and the evidence apart. Every boundary has one defined job.

STATUS / IN DEVELOPMENT · ROADMAP
DEVICEPlan + owner signature
SERVICESWatch + execute
RECORDLock + verify
01 / SERVICE EXPLORER

Separate jobs.
Clear boundaries.

SERVICE / DRAFTER

Text → checked rules

Turns plain words into a structured draft, a readable version, validation results, and a list of anything ambiguous. Nothing ambiguous becomes a live rule.

INTERFACEplan.draft
02 / THE DATA & TRUST MODEL

Keep the record.
Guard the rule.

What the owner holds.

Every lock is signed by its owner. Rules are put in a canonical form and salted before they are hashed, so a hash alone gives nothing away. Jackfa never holds your main wallet key.

Hidden, but still checked.

The watcher has to read a locked rule to know when it fires. That access stays narrow: plain rules and salts must never land in ordinary storage or logs, and nothing outside the watcher needs them.

What is stored.

Users, linked accounts, permissions, plans, fires, orders, follows, record events, and routes make up the data model.

State is not one thing.

Plan state, position state, reveal state, and evidence state are tracked apart. A fire, a fill, a reveal, and a published root are related events, not the same success.

API layerJob queueRelational storeTime-series storeIsolated watcherOwner signingHourly rootsAlert relay
03 / CONTRACTS

Small contracts.
One job each.

01

Lock registry

Owner-signed locks with separate entry and exit hashes, nonces, and expiry deadlines.

lock · cancel
02

Reveal log

Entry reveals at fire and exit reveals at close, each matched to its original hash.

revealEntry · revealExit
03

Record roots

Hourly roots and event counts; any single record event can be proven against one.

publishRoot
04

Fee ledger

Reserved for the fair-follow sharing fee. Inactive until fair follow ships; the fee is announced before it starts.

inactive

Locks, reveals, roots, and fees are kept apart on purpose. Read what you are signing, and check any permission, before you approve it.

04 / OPERATING PRINCIPLES

Draw the boundary.
Check every decision.

G01

Drafter quality

An ambiguous rule needs a decision from its author. Readable rules make that decision visible.

G02

Order policy

Every order must belong to a locked, live plan and stay inside the owner’s own limits.

G03

Permission scope

Linked accounts grant trade-only access. Withdrawals are never part of the permission.

G04

Fair follow ordering

Follower batches go before the author, with acknowledgements and timestamps keeping the order visible.

G05

Plaintext handling

Rules and salts stay out of ordinary application storage and logs.

See how it fits together.

Follow each service back to the part of the plan lifecycle it serves.

Explore the guide library