Beta is live. Write a note on anything Web3, screenshot its mindmap and submit it at
doqtri.xyz/promo for a share of the $100 USD prize pool.
Contents
Try it in 30 seconds
- Open doqtri.xyz and sign up with email. No browser extension needed:
a passkey (Face ID, fingerprint or device PIN) creates your Stellar wallet. Prefer Freighter?
Use Connect wallet instead.
- Click the template icon in the vault and pick one of 14 starters, such as a roadmap, grant
proposal or sprint plan. Its headings become your mindmap instantly.
- Hit Save & anchor. The note's hash is written to Stellar testnet, and its public audit page
at
/d/[docId] shows the receipt to anyone, logged in or not.
Problem
Teams plan in living documents (Google Docs, Notion, markdown vaults), then ship the work in
n8n, Make, Retool, Langflow and scattered repos. That creates a trust gap:
- Plans and reality diverge. The doc says “done”; the workflow was never built.
- Progress is unverifiable. “Shipped” badges live in private app state anyone can edit.
- No shared receipt. Stakeholders can’t independently check which version of the plan was
active, or which mindmap nodes actually went live.
- Audit trails rot. Screenshots and status meetings don’t survive handoffs, vendor churn, or
“we’ll update the doc later.”
In short: you can’t prove planned vs shipped.
Solution
Doqtri is Obsidian for executable plans, with Stellar as the proof layer.
| Layer | What it does |
|---|
| Vault + editor | Write the plan in markdown, or import a PDF/DOCX; headings compile into a mindmap |
| Executable mindmap | Each node tracks Planned → Building → Built → Verified |
| Ship panel | Link a node to the GitHub issue or PR (or n8n / Make / Retool / Langflow build) that shipped it |
| DoqtriRegistry (Soroban) | Anchors SHA-256 document hashes and node status on Stellar, with owner auth |
| Public audit | Anyone opens /d/[docId] and reads the history from the ledger, not from our database |
Every semantic change bumps an on-chain version; every shipped node leaves a receipt.
Features
Write and plan
- Obsidian-style vault: markdown notes,
[[wikilinks]], a global graph and a per-note mindmap
- Template gallery: 14 starter notes (roadmaps, sprints, grant proposals, contract launches,
research, postmortems…) with a live preview of each mindmap
- Imports that never lose your file: PDF/DOCX → markdown with live per-step progress,
retries, and an “import without AI” fallback
- Rename and delete notes; anchored notes are protected from deletion
Mindmap Studio
- Themes (Monochrome, Neon Grid, Aurora, Blueprint, Paper…), fonts and layouts
- 3D view, PNG export, and focus mode that highlights and locks one branch
Ship and prove
- Save & anchor: one button registers or updates the note's hash on Stellar
- Link mindmap nodes to GitHub issues and pull requests; the PR's state suggests the node's status
- Version history with transaction receipts, and a public audit page per document
Accounts and wallets
- Email sign-up with passkey wallets: a Stellar smart wallet unlocked by Face ID, fingerprint
or PIN, with backup passkeys; anchoring fees are relayed through a fee forwarder
- Wallet sign-in with Freighter and other Stellar wallets: a signed one-time challenge, not just an address
- XLM balance in the status bar and a pre-flight fee check before any wallet prompt
- Phone layout with a bottom tab bar, in the Monochrome Glass design
How verification works
You don't have to trust Doqtri's database to check a claim:
- Doqtri hashes the note's content (SHA-256) and the owner signs a
register_document or
update_document call on the DoqtriRegistry contract. Each update increments the version.
- Node status changes (
Planned → Building → Built → Verified) are written with
set_node_status, including the tool and artifact reference.
- Anyone can open the public audit page at
/d/[docId]. It rebuilds the version history from
the ledger and checks that the current content hash matches the anchored one.
- Every entry links to its transaction on Stellar Expert, so the check doesn't depend on Doqtri.
What it proves: which version existed, when, and who signed it. It doesn't judge whether the
work itself is good.
Architecture
Browser Server (Next.js on Vercel) Stellar (Soroban)
┌──────────────────────────┐ API ┌──────────────────────────────┐ ┌────────────────────┐
│ Vault · editor · mindmap │────────► │ /api/* — notes, ingest (AI), │ │ DoqtriRegistry │
│ Mindmap Studio · ship │ │ GitHub links, audit reads │ │ documents, nodes │
│ │ └──────────────┬───────────────┘ │ versions, events │
│ Wallet signs the tx: │ │ └─────────▲──────────┘
│ · Freighter / wallets │──── signed transaction ─┼──────────────────────────────────┤
│ · passkey smart wallet ─┼──► relayer + FeeForwarder (fee-forwarder/) ───────────────┘
└──────────────────────────┘ │
▼
Supabase: auth, documents (RLS), storage
Public audit page /d/[docId] ◄──── reads history straight from the ledger
Deployed contracts
The live app at doqtri.xyz runs on Stellar testnet. The same contract is also deployed on
mainnet, where it was used for a 20-wallet production test; switching the app to mainnet is two
environment variables (see Network selection).
Stellar Testnet (the live app)
Explorer links
Template marketplace (testnet)
TemplateMarket (market/) sells community templates and splits each payment
between the creator, the parent template's creator and the treasury. Plan and
status: 004-template-marketplace.md.
In the app: Publish as template in a note's Stellar proof panel, and one
Templates page (/vault/templates) with three tabs: Starter (Doqtri's
samples), Community (buy, use, tip, report a copy) and Yours (your
published templates and what they earned). Admins review copy reports at
/admin/reports. Deploying to another network: market/deploy.sh (see the
plan's phase 4 runbook).
Stellar Mainnet
Explorer links
What mainnet actually costs
| Operation | Fee charged |
|---|
| WASM upload (one-time) | 8.0525 XLM |
| Deploy contract (one-time) | 0.0183 XLM |
register_document | 0.055094 XLM |
set_node_status | 0.048082 XLM |
update_document | 0.000801 XLM |
| Full document lifecycle, per user | ~0.104 XLM |
The upload is expensive because the code entry's rent dominates it — about 17×
the testnet price, while a register_document write costs only ~1.5× testnet.
That rent expires: keep the code entry alive with
stellar contract extend --wasm-hash <hash> --network mainnet --ledgers-to-extend <n>.
Contract interface
| Function | Auth | Description |
|---|
register_document(owner, doc_id, content_hash) | owner | Anchor a new document at version 1 |
update_document(doc_id, new_hash) | owner | Anchor a new hash; returns incremented version |
set_node_status(doc_id, node_id, status, tool, artifact_ref) | owner | Record node lifecycle |
get_document(doc_id) | none | Read anchored document state |
get_node(doc_id, node_id) | none | Read a node’s build record |
Workspaces (on this branch, not yet deployed). Several wallets write the same documents, each
signing for itself. The owner manages admins; admins and the owner manage editors. The revoker is one
contract-wide server key, set by the contract admin, that may only remove members (editors and admins),
so a member removed in the app loses chain access at once. A document put in a workspace becomes the
workspace owner's: its author then writes it as a member, and loses it when removed.
Who owns a workspace document. For a document with a DocWorkspace entry, owner-level authority
always comes from the workspace's current owner, read at call time; the stored Document.owner does
not count. That covers the original owner-only calls too (update_document, set_node_status,
anchor, unassign_document, moving it with assign_document). So a transfer moves every document in
the workspace at once without rewriting any record (D-18, D-28): get_document reports the current
owner straight away, and the stored record catches up the next time the document is written.
unassign_document stores the current owner, since a document in no workspace is owned by its stored
owner again. A former owner keeps no role; the new owner may add_admin them back.
| Function | Auth | Description |
|---|
create_workspace(workspace_id, owner) | owner | Create a workspace; ids are first come, first served, so check get_workspace after |
add_admin(workspace_id, owner, admin) | workspace owner | Make a member (or anyone) an admin |
remove_admin(workspace_id, caller, admin) | workspace owner or revoker | Remove an admin from the workspace; false if there was none |
add_editor(workspace_id, admin, editor) | admin or owner | Add an editor; at most MAX_MEMBERS (100) members |
remove_editor(workspace_id, caller, editor) | admin, owner or revoker | Remove an editor (never an admin); false if there was none |
transfer_workspace(workspace_id, owner, new_owner) | owner and new owner | Hand the workspace and its documents on; a member who becomes owner leaves the member list |
admin_reassign_owner(workspace_id, new_owner) | contract admin | Recovery when the owner can no longer sign (D-29, D-31); the new owner does not co-sign |
set_revoker(revoker) | contract admin | Set or replace the revoke-only server key |
assign_document(doc_id, workspace_id) | document owner, a member | Let the workspace's members write the document; hands it to the workspace owner |
unassign_document(doc_id) | document owner | Take the document out of its workspace; false if it was in none |
update_document_as / set_node_status_as / anchor_as(signer, …) | signer: doc owner or a member | The three write calls for any writer |
get_workspace, get_members, get_role, get_revoker, get_doc_workspace, is_editor | none | Reads; get_members is the whole on-chain member list |
Events. (doqtri, register | update | node) events always carry the doc_id as their value; the
*_as calls add the signer as a third topic. Workspace events use their own first topic, doqtri_ws:
ws_create, admin_add, admin_rm, edit_add, edit_rm carry (workspace_id, subject, caller);
ws_xfer (transfer) and ws_recov (contract-admin reassignment) carry (workspace_id, new_owner, previous_owner), and a no-op to the current owner emits nothing;
assign carries (doc_id, workspace_id, new_owner), unassign (doc_id, workspace_id), and
revoker the new revoker's address.
Node statuses: Planned · Building · Built · Verified
Storage keys: DataKey::Doc(doc_id) · DataKey::Node(doc_id, node_id) · DataKey::Workspace(workspace_id)
(owner and members) · DataKey::DocWorkspace(doc_id) · instance: DataKey::Admin, DataKey::Revoker
TTL: threshold 30 days → extend to 90 days on every write (1 day = 17280 ledgers)
Quick start — app (doqtri/frontend)
Prerequisites: Node 20+ and a Supabase project. An OpenAI key is only needed for AI imports.
cd doqtri/frontend
cp .env.example .env.local # fill in the Supabase block at minimum
npm install
npm run dev
Open http://localhost:3000, sign up, and you land in the vault.
npm test # unit tests (Vitest)
npm run lint
npm run build && npm run start
npm run test:e2e # Playwright; needs real Supabase keys
| Variable | Needed for |
|---|
NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY | Required. Auth, notes, storage |
OPENAI_API_KEY (OPENAI_MODEL, AI_DAILY_LIMIT) | AI import and regenerate |
NEXT_PUBLIC_NETWORK_PASSPHRASE, NEXT_PUBLIC_CONTRACT_ID (+ RPC / Horizon URLs) | Choosing the network; defaults to the testnet contract |
DOQTRI_RELAYER_SECRET, CHANNELS_API_KEY | Passkey wallets: the relayer that submits email users' writes |
GITHUB_TOKEN | GitHub links on mindmap nodes (higher API rate limit) |
NEXT_PUBLIC_TURNSTILE_SITE_KEY | Captcha on sign-up |
DOQTRI_ADMINS, CHAIN_* limits | Admin pages and on-chain rate limits |
Network selection
The frontend defaults to testnet. Two env vars flip it to mainnet — every
other network value (RPC, Horizon, explorer URLs) derives from the passphrase in
doqtri/frontend/lib/stellar/config.ts:
NEXT_PUBLIC_NETWORK_PASSPHRASE="Public Global Stellar Network ; September 2015"
NEXT_PUBLIC_CONTRACT_ID=CCP5KFIWLUNPV2G7ATBKFMIZF54JYRC343P5JCTARC4PRTGM23IU6ET4
The passphrase must match that string exactly, spaces around the ; included;
anything else is treated as testnet. Setting the mainnet passphrase without a
contract ID throws at startup rather than silently falling back to the testnet
contract.
NEXT_PUBLIC_* values are inlined at build time, so changing them in the Vercel
dashboard has no effect until a new build runs — redeploy after editing them.
Deploy (Vercel): set the Root Directory to doqtri/frontend and add the variables above.
Database migrations live in doqtri/backend/migrations/.
Quick start — contract
Prerequisites:
- Rust stable +
rustup target add wasm32v1-none
- Stellar CLI
# from repo root
cargo test -p doqtri-registry
cd contract
stellar contract build
WASM (workspace layout):
target/wasm32v1-none/release/doqtri_registry.wasm
Deploy (testnet)
# one-time identity
stellar keys generate alice --network testnet --fund
stellar contract deploy \
--wasm ../target/wasm32v1-none/release/doqtri_registry.wasm \
--source alice \
--network testnet \
--alias doqtri
Deploy (mainnet)
Same command against --network mainnet, with a funded real account — budget
~8.1 XLM for the WASM upload (see the mainnet fee table). Simulate first; a
simulation is free and needs no key:
stellar contract deploy \
--wasm ../target/wasm32v1-none/release/doqtri_registry.wasm \
--source-account <YOUR_KEY> \
--network mainnet
Invoke (live contract)
CONTRACT=CCCIDUCFQMTMAGESMPTB3MFW4TURS62ORSZNICFOE6MNQZO3MI7F6QRJ
stellar contract invoke \
--id $CONTRACT --source alice --network testnet -- \
register_document \
--owner alice \
--doc_id "doqtri-launch-plan" \
--content_hash 0101010101010101010101010101010101010101010101010101010101010101
stellar contract invoke \
--id $CONTRACT --source alice --network testnet -- \
set_node_status \
--doc_id "doqtri-launch-plan" \
--node_id "node-weekly-report" \
--status '"Built"' \
--tool "n8n" \
--artifact_ref "wf_8Xk2p"
stellar contract invoke \
--id $CONTRACT --source alice --network testnet -- \
get_document --doc_id "doqtri-launch-plan"
Tech stack
Repository layout
doqtri/ # git repo root
├── doqtri/
│ ├── frontend/ # the app (Next.js vault, mindmaps, wallet, audit pages)
│ ├── backend/ # Supabase migrations + AI prompts
│ ├── progress/ # feature plans (mindmap, passkey wallets, user-paid fees)
│ └── image/ # brand assets
├── contract/ # Soroban DoqtriRegistry
├── market/ # Soroban TemplateMarket (template sales + royalties)
├── fee-forwarder/ # Soroban FeeForwarder for passkey-wallet fees
├── docs/ # user testing, wallet integration, screenshots
├── .github/workflows/ci.yml
└── README.md
See also doqtri/README.md and doqtri/SPEC.md.
CI
GitHub Actions (.github/workflows/ci.yml) runs four jobs:
- Contract tests:
cargo test -p doqtri-registry -p doqtri-market
- Build WASM:
stellar contract build for both contracts, uploaded as artifacts
- App build + unit tests: lint, Vitest and
next build
- E2E (Playwright): signs in and drives the vault against Supabase; runs on pushes to
main
User testing
| Round | Network | Testers | Transactions | Rating |
|---|
| Product test | Testnet | 50 | 150 | 4.00 / 5 (survey) |
| Production test | Mainnet | 20 | 60 | — |
Every wallet, transaction and survey response is in docs/user-testing.md,
and the original Freighter integration walkthrough is in
docs/stellar-wallet-integration.md.
Raw responses: onboarding survey ·
mainnet feedback.
Roadmap
Shipped since the first user tests
Every gap the 50 testnet testers reported is now closed:
Next
License
MIT
