Add new guides and some new information. #35
Conversation
… management, and emission permissions while improving links and content clarity
…tration and agent information management in guides
…es for voting processes in guides and update the table of contents
…ated references throughout the guides and table of contents
WalkthroughDocumentation restructured: navigation updated in astro.config.mjs; multiple new pages added for Goal Leaders, Builders, and Holders; several legacy v0.6 pages removed or retargeted; numerous link and version-notice updates; global parameters doc revised with new defaults and querying guidance; table-of-contents files synchronized; minor homepage typo fix. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Proposer
participant Portal as DAO Portal
participant Chain as Torus Chain
participant DAO as Governance DAO
participant Treasury as DAO Treasury
Proposer->>Portal: Open "Shape the Network"
Portal->>Proposer: Select "Transfer DAO Treasury"
Proposer->>Chain: Submit proposal (+10,000 TORUS deposit)
Chain-->>Proposer: Tx included
Note over DAO,Chain: Review period then 7-day voting window
actor Voter
Voter->>Portal: Open proposal
Voter->>Chain: Cast vote (changeable during window)
Chain-->>DAO: Tally at deadline
alt Approved (>=50% yes & >10% participation)
Chain->>Treasury: Execute transfer
Treasury-->>Proposer: Funds sent
Chain-->>Proposer: Deposit refunded
else Rejected / Insufficient
Chain-->>Treasury: Deposit retained
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
src/content/docs/explanations/goal-leaders/emission-proposals.mdx (1)
16-16: Typo: “coponents” → “components”User-facing docs: fix the spelling in the first paragraph.
Apply:
-Emission proposals can adapt the token emission rate and distribution across different coponents of the protocol. +Emission proposals can adapt the token emission rate and distribution across different components of the protocol.src/content/docs/explanations/builders/control-space.mdx (1)
39-43: Regex in pattern is incorrect; hyphen creates an unintended range
[a-z0-9-_]defines a range (9-_) in many regex engines. Escape or move the hyphen to the end. Also, anchor the end.-- Pattern: `^[a-z0-9]([a-z0-9-_]{0,61}[a-z0-9])?` +- Pattern: `^[a-z0-9](?:[a-z0-9_-]{0,61}[a-z0-9])?$`If you prefer to keep a capturing group:
-^[a-z0-9]([a-z0-9-_]{0,61}[a-z0-9])? +^[a-z0-9]([a-z0-9_-]{0,61}[a-z0-9])?$src/content/docs/explanations/goal-leaders/recursive-delegation.mdx (1)
20-25: Multiple grammar fixes and pluralsApostrophes and plurals are off; also “types” not “type.”
-At each delegation step, permission's can be +At each delegation step, permissions can be @@ -This applies to the capability, emission and curator permission type. +This applies to the capability, emission, and curator permission types.
🧹 Nitpick comments (57)
src/content/docs/development/network/global-parameters.mdx (3)
24-25: Clarify default formatting and unit; keep style consistent.Other entries use “(default: …)”. Also, consider thousands separators for readability.
-**`block_emission`**: The emission per block (5925.93 TORUS). It specifies the amount of new tokens emitted in each block. +**`block_emission`**: The emission per block (default: 5,925.93 TORUS). Specifies the amount of new tokens emitted in each block.
81-90: Good addition; consider noting governance mutability and optional JSON output.The section is helpful. Two low-friction improvements:
- Add a note that live values can change via governance.
- If the CLI supports it, mention a JSON flag for scripting.
-You can query all of these global parameters using CLI: +You can query all of these global parameters using CLI (values are live and may change via governance): ```bash -torus network params +torus network params +# (Optional) If supported by your CLI version: +# torus network params --json | jq .Please confirm the exact CLI switches available (e.g., --json/--format) before merging. --- `30-31`: **All instances updated—no leftover misspelling found** Great work on renaming `emission_recycling_percentage` (the ripgrep search returned only the corrected key) and adjusting its default to 81%. Optional nit: to remove any ambiguity about whether this is a 0–1 or 0–100 value, consider clarifying the range. For example: ```diff - **`emission_recycling_percentage`**: Percentage of emission recycled (default: 81%). Controls how much emission is recycled back into the system. + **`emission_recycling_percentage`**: Percentage of emission recycled (default: 81%; range: 0–100). Controls how much emission is recycled back into the system.src/content/docs/explanations/goal-leaders/emission-proposals.mdx (1)
47-47: Clarify participation requirement phrasingThe “+ it must be at least 2 days old” phrasing is informal and ambiguous. Recommend tightening it.
-- **Participation Threshold**: Total votes must exceed 10% of all TORUS staked in the network + it must be at least 2 days old +- **Participation Threshold**: Total votes must exceed 10% of all TORUS staked in the network, and the proposal must be at least 2 days old.src/content/docs/explanations/goal-leaders/permissions.mdx (1)
8-10: Minor copy polish for version noticeOptional tightening and consistency with other pages.
-This version is based on the Torus v0.5 and is expected to change with the Torus v1. +This page reflects Torus v0.5 and is expected to change in Torus v1.src/content/docs/explanations/builders/control-space.mdx (3)
6-11: Import used after component usage; move import above the AsideMDX typically expects imports before usage. While bundlers may hoist, keeping imports before components improves reliability and consistency (other pages do this).
-<Aside type="note" title="Version notice"> -This version is based on the Torus v0.5 and is expected to change with the Torus v1. -</Aside> - -import { CardGrid, LinkCard, Aside } from "@astrojs/starlight/components"; +import { CardGrid, LinkCard, Aside } from "@astrojs/starlight/components"; + +<Aside type="note" title="Version notice"> +This version is based on the Torus v0.5 and is expected to change with the Torus v1. +</Aside>
3-3: Hyphenation and article nit: “on‑chain permission system”Consistency nit across docs: prefer “on‑chain/off‑chain.” Also add “the”.
-description: Understand the Torus Control Space and how namespaces enable the integration of offchain capabilities and resources with Torus onchain permission system. +description: Understand the Torus Control Space and how namespaces enable the integration of off‑chain capabilities and resources with the Torus on‑chain permission system.
26-26: Grammar nit: gerund phrasingReads smoother and avoids “allowing to …”.
-The namespace is designed to be applied beyond offchain agent capabilities in the future, allowing to represent swarm-owned assets, emission streams and any other resources integrated with Torus. +The namespace is designed to extend beyond off‑chain agent capabilities, enabling representation of swarm‑owned assets, emission streams, and other resources integrated with Torus.src/content/docs/explanations/goal-leaders/emission-permissions.mdx (2)
6-10: Import order nit: place imports before component usage.While MDX usually handles hoisting, some MDX linters/build steps flag component usage before import. Move the
import { … Aside … }line above the first<Aside>for consistency and to avoid tooling edge cases.Apply this minimal reordering:
-<Aside type="note" title="Version notice"> -This version is based on the Torus v0.5 and is expected to change with the Torus v1. -</Aside> - -import { CardGrid, LinkCard, Aside, Tabs, TabItem } from "@astrojs/starlight/components"; +import { CardGrid, LinkCard, Aside, Tabs, TabItem } from "@astrojs/starlight/components"; + +<Aside type="note" title="Version notice"> +This version is based on the Torus v0.5 and is expected to change with the Torus v1. +</Aside>
12-16: Duplicate introductory paragraph + article grammar.You have two near-identical intro paragraphs (Line 12 and Line 16). Keep one and fix the missing article (“a core tool”) in the remaining copy.
Apply one of the following:
Option A (keep Line 12, remove Line 16):
Emission permissions are the core tool and mechanism for economic incentives on Torus, enabling agents to compose and delegate portions of their incoming emission streams (token flows) to other agents with flexible control. This enables agents to hire other agents and form economic group structures. ## Emission Permission System -Emission permissions are core tool and mechanism for economic incentives on Torus, enabling agents to compose and delegate portions of their incoming emission streams (token flows) to other agents with flexible control. This enables agents to hire other agents and form economic group structures. +<!-- duplicate paragraph removed -->Option B (prefer revised grammar):
-Emission permissions are the core tool and mechanism for economic incentives on Torus, enabling agents to compose and delegate portions of their incoming emission streams (token flows) to other agents with flexible control. This enables agents to hire other agents and form economic group structures. +Emission permissions are a core tool and mechanism for economic incentives on Torus, enabling agents to compose and delegate portions of their incoming emission streams (token flows) to other agents with flexible control. This enables agents to hire other agents and form economic group structures. ## Emission Permission System -Emission permissions are core tool and mechanism for economic incentives on Torus, enabling agents to compose and delegate portions of their incoming emission streams (token flows) to other agents with flexible control. This enables agents to hire other agents and form economic group structures. +<!-- duplicate paragraph removed -->src/content/docs/how-to-guides/builders/create-permission.mdx (2)
267-268: Use site-relative link and add trailing slash for consistency.Root-relative links avoid hardcoding the domain and trailing slashes prevent extra redirects.
-See the [Permission System Documentation](https://docs.torus.network/explanations/goal-leaders/permissions/) for technical details. +See the [Permission System Documentation](/explanations/goal-leaders/permissions/) for technical details.
274-278: Normalize internal hrefs: add trailing slashes.Keep internal links consistent with a trailing slash to avoid 301s and improve SEO hygiene.
- <a href="/explanations/goal-leaders/permissions">Deep dive into architecture</a> + <a href="/explanations/goal-leaders/permissions/">Deep dive into architecture</a> @@ - <a href="/explanations/goal-leaders/emission-permissions">Economic coordination mechanisms</a> + <a href="/explanations/goal-leaders/emission-permissions/">Economic coordination mechanisms</a>src/content/docs/explanations/builders/capability-permissions.mdx (1)
6-8: Consider centralizing version notices to avoid drift.A shared component or frontmatter-driven partial reduces future edit churn across many pages when versions roll.
Example approach:
- Add
version: "0.6"to frontmatter.- Render a
<VersionNotice />component in the layout that reads frontmatter and prints the standardized notice.src/content/docs/explanations/builders/agent-registration.mdx (1)
48-49: Link updates look correct; minor typographic polish.Use a colon after the link for cleaner list semantics and to silence some grammar linters.
-- **[Permission System](https://docs.torus.network/explanations/goal-leaders/permissions/)** - How agents interact and delegate authority -**[Governance & DAO](https://docs.torus.network/explanations/goal-leaders/governance-dao/)** - Understanding DAO decision-making processes +- **[Permission System](https://docs.torus.network/explanations/goal-leaders/permissions/)**: How agents interact and delegate authority +- **[Governance & DAO](https://docs.torus.network/explanations/goal-leaders/governance-dao/)**: Understanding DAO decision-making processesOptional: convert to root-relative links for portability during preview builds.
src/content/docs/how-to-guides/builders/manage-capabilities.mdx (1)
160-166: Prefer site-relative URLs for internal docs links.Using root-relative paths avoids domain coupling and eases staging/preview deployments.
-- **Set up delegation**: [Manage permissions](https://docs.torus.network/how-to-guides/goal-leaders/manage-permissions/) to allow other agents to use your capabilities +- **Set up delegation**: [Manage permissions](/how-to-guides/goal-leaders/manage-permissions/) to allow other agents to use your capabilities @@ -Learn about [recursive delegation](https://docs.torus.network/explanations/goal-leaders/recursive-delegation/) mechanisms and control space architecture. +Learn about [recursive delegation](/explanations/goal-leaders/recursive-delegation/) mechanisms and control space architecture.Also applies to: 174-175
src/content/docs/how-to-guides/goal-leaders/create-capability-permission.mdx (2)
70-77: Clarify “Path Selection Rules” to remove ambiguity about combining held pathsThe current bullets can be interpreted as allowing two held paths; the prohibition that follows may feel contradictory. Tighten the rules so it’s explicit that the “two paths” case is “your own + one held,” never “two held.”
Apply this wording tweak:
- **Path Selection Rules** - You can always delegate one of the following options: - - Your own path - - A Path that you hold with instances available - - Your own path PLUS another path that you have instances for - - You cannot delegate two paths that you hold simultaneously. + **Path Selection Rules** + You may delegate one of: + - Your own path (unlimited instances) + - One path you hold (only if you have available instances) + - Your own path together with one held path (i.e., two paths total) + + Restriction: you cannot delegate two held paths at the same time.
105-108: Minor copy polish: “infinite” → “unlimited”; consistently capitalize SubWalletSmall UX wording consistency improvements.
- # Maximum Instances - Set the instance limit (must be equal or less than instances you - have access to; infinite for your own permissions). + # Maximum Instances + Set the instance limit (must be equal to or less than the instances you + have access to; unlimited when delegating your own paths).- Open SubWallet and <RedText variant="light">sign the transaction</RedText>. + Open <RedText variant="light">SubWallet</RedText> and sign the transaction.Also applies to: 118-119
src/content/docs/explanations/goal-leaders/governance-dao.mdx (4)
8-10: Tighten the version noticeMinor wording tweak for clarity.
-<Aside type="note" title="Version notice"> -This version is based on the Torus v0.5 and is expected to change with the Torus v1. -</Aside> +<Aside type="note" title="Version notice"> +This page reflects Torus v0.5 and may change for Torus v1. +</Aside>
12-15: Consolidate stake-weighting language to avoid repetitionMake the opening paragraph directly state the voting model and avoid restating it below.
-The Torus DAO operates fully on-chain and is TORUS stake-based, managing the protocol through proposals. -The DAO can change network parameters, propose custom changes and decide the emission rate and allocation -between network and treasury dynamically to align with TORUS interests. +The Torus DAO operates fully on-chain with stake‑weighted voting and manages the protocol through proposals. +The DAO can change network parameters, propose custom changes, and dynamically decide the emissions rate and +allocation between the network and the treasury to align with TORUS interests.-Voting power directly correlates to TORUS token holdings: -- **1 TORUS = 1 vote** +Voting power is stake‑weighted: **1 TORUS = 1 vote**.Also applies to: 20-22
25-28: “Sufficient stake” is ambiguous; align with the stated submission feeSince a flat submission fee is listed later, “sufficient stake” could confuse readers into expecting a minimum-balance requirement. Recommend removing it.
-Proposals are the primary mechanism for implementing changes to the Torus protocol. -Any holder with sufficient stake in the network can submit a proposal. +Proposals are the primary mechanism for implementing changes to the Torus protocol. +Any holder can submit a proposal (subject to the submission fee).
39-43: Cross-link “Global Params” to the Global Parameters referenceThis helps readers discover the canonical list of tunables.
-**Global Params Proposals:** +**Global Params Proposals** ([reference](https://docs.torus.network/development/network/global-parameters/)):src/content/docs/explanations/builders/agent-managing.mdx (1)
55-56: Tone/style: prefer “entirely” over “completely”Minor style lift; optional.
-**However:** You can reuse the agent name if you re-register later, but it will be treated as a completely new agent with no connection to the previous one. +**However:** You can reuse the agent name if you re-register later, but it will be treated as an entirely new agent with no connection to the previous one.src/content/docs/how-to-guides/holders/vote-on-proposals.mdx (4)
46-48: Clarify and capitalize “Power User”; fix “this file” → “this guide”Improves readability and product terminology.
- <Card title="Be a Power User" icon="seti:yml"> - You must be a power user to vote on proposals. You can find a guide on how to become a power user in this file. + <Card title="Be a Power User" icon="seti:yml"> + You must be a Power User to vote directly on proposals. You can find instructions on becoming a Power User in this guide. </Card>
85-87: Brand capitalization: SubWalletUse consistent casing across docs.
-Open your subwallet extension and <RedText variant="light">sign the transaction</RedText> to confirm the change. +Open your <RedText variant="light">SubWallet</RedText> extension and sign the transaction to confirm the change.
102-105: Tighten “Power User” wording“Connect your Power User Wallet” can be misread as a different wallet. Clarify that it’s a mode for the same wallet.
-2. **Connect your Power User Wallet** - <RedText variant="light">Ensure you're connected with your TORUS wallet</RedText> that contains the tokens you want to use for voting. - <RedText variant="light">Ensure you're a power user first</RedText> ([follow the steps above](#toggle-voting-power-become-a-power-user-or-return-to-delegated-voting) if needed). +2. **Connect your wallet (in Power User mode)** + <RedText variant="light">Ensure you're connected with the TORUS wallet</RedText> that holds the tokens you’ll use for voting, and that you’ve enabled <RedText variant="light">Power User</RedText> mode ([steps above](#toggle-voting-power-become-a-power-user-or-return-to-delegated-voting)).
118-120: Optional: mention vote changes during the windowThis aligns the guide with the Governance page that notes voters can change their vote during the voting period.
- Your vote has been successfully cast and will be counted towards the proposal's final outcome. - You can view the current voting results and track the proposal's progress. + Your vote has been successfully cast and will be counted toward the proposal's outcome. + You can change your vote any time before the voting window closes, and track progress on the proposal page.src/content/docs/explanations/goal-leaders/dao-treasury.mdx (4)
6-13: Remove unused component imports to reduce bundle size and lint noise.Only Aside is used. Card, CardGrid, Code, Tabs, and TabItem are unused here.
-import { - Aside, - Card, - CardGrid, - Code, - Tabs, - TabItem, -} from "@astrojs/starlight/components"; +import { Aside } from "@astrojs/starlight/components";
18-18: Fix comma splice and wording.Current sentence is run-on and “destined wallet” is awkward.
-Proposals undergo review and voting by the community (all token holders), if approved, Torus Treasury funds are allocated to the destined wallet chosen by the proposer. +Proposals undergo review and voting by the community (all token holders). If approved, Treasury funds are allocated to the wallet specified by the proposer.
22-25: Punctuate list items consistently.End bullet lines with periods for consistency and clarity.
-**Proposal Cost**: Each treasury transfer request requires a 10,000 TORUS deposit from the proposer's wallet. -- **Approved proposals**: The 10,000 TORUS is refunded to the proposer -- **Rejected proposals**: The 10,000 TORUS is transferred to the Treasury, increasing available funds +**Proposal Cost**: Each treasury transfer request requires a 10,000 TORUS deposit from the proposer's wallet. +- **Approved proposals**: The 10,000 TORUS is refunded to the proposer. +- **Rejected proposals**: The 10,000 TORUS is transferred to the Treasury, increasing available funds.
15-17: Tighten the lead paragraph.Optional clarity edit; “TORUS tokens” reads better than bare “TORUS”.
-The DAO Treasury serves as a community-controlled funding mechanism that enables decentralized allocation of TORUS to support ecosystem development +The DAO Treasury is a community-controlled funding mechanism that enables decentralized allocation of TORUS tokens to support ecosystem developmentsrc/content/docs/how-to-guides/builders/manage-your-agent.mdx (4)
20-24: Minor copy edits for flow and consistency.Add a comma after introductory clause and tighten wording.
-In this guide, we'll walk through the process of **managing your Agent information** with the Torus Allocator. -Both the **Registered Agent** and **Root Agent** can manage their information. -<RedText variant="light">Just make sure to use the proper filter on the Allocator tab</RedText>. -In this guide we will be managing the information of a **Registered Agent**. +In this guide, we’ll walk through **managing your Agent information** with the Torus Allocator. +Both the **Registered Agent** and **Root Agent** can manage their information. +<RedText variant="light">Use the appropriate filter on the Allocator tab</RedText>. +In this guide, we will manage the information of a **Registered Agent**.
47-49: Fee type mismatch: this flow edits info, not registration.“Registration fees” is misleading; users only need enough balance to cover transaction/network fees for updates.
-Ensure you have enough **Free Balance** to cover the registration fees. +Ensure you have enough **Free Balance** to cover the transaction fees.Would you confirm the wallet fee behavior on this route? If a specific on-chain call charges a fixed fee, we can list it.
90-99: Standardize “Deregister” vs “De-register”.Use one spelling throughout (“Deregister”). Also mirror the exact UI label if it’s “Deregister Agent”.
-2. **Click Deregister Agent** +2. **Click Deregister Agent** @@ -4. **Review information, Submit and Sign the Transaction** +4. **Review information, submit, and sign the transaction**If the UI uses “Deregister Agent”, update all instances of “De-register” to “Deregister”.
Also applies to: 128-136
121-123: Possible typo in example agent name.“scrapping-swarm” looks like “scraping-swarm”. If “scrapping” is intentional, ignore; otherwise correct the example.
-`scrapping-swarm` +`scraping-swarm`src/content/docs/how-to-guides/goal-leaders/create-emission-permission.mdx (4)
13-15: Remove unused import.ClickableImage is imported but not used.
-import ClickableImage from '/src/components/ClickableImage.astro'; import RedText from '/src/components/RedText.astro';
16-18: Remove duplicated explanation.The “Emission permissions enable economic coordination …” line appears twice.
In this guide, we'll walk through **creating emission permissions** in the Torus portal. -Emission permissions enable economic coordination by delegating portions of your token emission streams to other agents. +Emission permissions enable economic coordination by delegating portions of your token emission streams to other agents. @@ -Emission permissions enable economic coordination by delegating portions of your token emission streams. +Also applies to: 51-52
95-105: Clarify constraints for Streams and Targets.Readers need to know if percentages/weights must sum to 100% and whether they’re validated/normalized.
-# Streams -Click **Add Stream** to add multiple emission streams: -- **Stream ID**: Identifier of the emission stream to delegate -- **Percentage**: Percentage of that stream to delegate (0-100%) +# Streams +Click **Add Stream** to add multiple emission streams: +- **Stream ID**: Identifier of the emission stream to delegate. +- **Percentage**: Percentage of that stream to delegate (0–100%). The sum of percentages across streams must equal 100%. <!-- if true --> @@ -# Target Accounts -Click **Add Target** to add multiple recipients: -- **Account**: Wallet address of the recipient agent -- **Weight**: Percentage weight for this recipient - (distribution among multiple targets) +# Target Accounts +Click **Add Target** to add multiple recipients: +- **Account**: Wallet address of the recipient agent. +- **Weight**: Percentage weight for this recipient (distribution among multiple targets; weights must sum to 100%). <!-- if true -->If the backend normalizes values instead, we can state that instead of a strict 100% sum requirement.
88-94: Link out “Arbiters” for context or define briefly.“Revocable by Arbiters” implies a governance role; add a short definition or link to the governance doc describing arbiters and thresholds.
- - **Revocable by Arbiters**: Can be revoked by arbiters after - a vote threshold set by the delegator + - **Revocable by Arbiters**: Can be revoked by arbiters (governance role) after a vote threshold set by the delegator. See Governance DAO for details.src/content/docs/explanations/holders/governance-participation.mdx (3)
6-13: Remove unused imports.Only Aside is used at the end; drop Card, CardGrid, Code, Tabs, and TabItem.
-import { - Aside, - Card, - CardGrid, - Code, - Tabs, - TabItem, -} from "@astrojs/starlight/components"; +import { Aside } from "@astrojs/starlight/components";
59-69: Standardize threshold wording for clarity.Use consistent operators and tighten language.
-**Standard Requirements:** -- **Support Threshold**: At least 50% of votes must be favorable -- **Participation Threshold**: More than 10% of total token supply must participate -- **Time Limit**: Voting closes after 7 days regardless of participation +**Standard requirements:** +- **Support threshold**: >= 50% of votes must be favorable. +- **Participation threshold**: > 10% of total token supply must participate. +- **Time limit**: Voting closes after 7 days regardless of participation. @@ -**Outcome Scenarios:** -- **Approved**: 50%+ support + 10%+ participation → Automatic execution -- **Rejected**: Less than 50% support + 10%+ participation → Proposal fails -- **Insufficient Participation**: Less than 10% participation → Proposal expires +**Outcome scenarios:** +- **Approved**: support >= 50% and participation > 10% → automatic execution. +- **Rejected**: support < 50% and participation > 10% → proposal fails. +- **Insufficient participation**: participation <= 10% → proposal expires.If exact operators differ in the protocol, adjust to match the on-chain rules.
80-84: Introduce/define “Power User” mode or cross-link.“Power User Setup” and “Switching Modes” assume readers know these terms. Add a one-line definition or link.
-- **Power User Setup**: One-time transaction to enable direct voting control -- **Switching Modes**: Small transaction cost to change between delegated and power user modes +- **Power User setup**: One-time transaction to enable direct voting control (i.e., voting without delegation). See Governance DAO for details. +- **Switching modes**: Small transaction cost to change between delegated and power-user modes.src/content/docs/how-to-guides/goal-leaders/manage-permissions.mdx (3)
13-14: Remove unused import.ClickableImage is imported but not used.
-import ClickableImage from '/src/components/ClickableImage.astro'; import RedText from '/src/components/RedText.astro';
97-99: Confirm edit/revoke capabilities per type.Capability permissions are editable; emission permissions are revoke-only—good. Consider briefly listing which fields are editable to set expectations.
-**For <RedText variant="light">Capability Permissions</RedText>:** -- <RedText variant="light">**Edit**</RedText>: Modify permission terms (duration, revocation conditions, etc.) +**For <RedText variant="light">Capability Permissions</RedText>:** +- <RedText variant="light">**Edit**</RedText>: Modify terms (e.g., duration, revocation conditions, capability path) as allowed by the UI.If capability path is not editable, drop it from the example.
Also applies to: 148-154
58-60: Double-check Manage vs Edit paths and add cross-links.You use two routes: manage-permission (view) and edit-permission (manage). If both are canonical, consider adding a brief note explaining when to use each to avoid confusion.
Also applies to: 102-104
src/content/docs/how-to-guides/table-of-contents.mdx (3)
5-12: Remove unused component imports to avoid dead code and lower bundle size
Steps,Aside,CardGrid,Card,Tabs, andTabItemare imported but not used in this page.Apply:
-import { - Steps, - Aside, - CardGrid, - Card, - Tabs, - TabItem -} from "@astrojs/starlight/components"; +/* No component imports needed on this page */
41-42: Use “Set up” (verb) instead of “Setup” (noun) for consistency and correctnessEverywhere else you use imperative phrasing (e.g., “Register an Agent”). Recommend “Set up Agent Server/Client.”
- - [Setup Agent Server](https://docs.torus.network/how-to-guides/builders/setup-agent-server/) - - [Setup Agent Client](https://docs.torus.network/how-to-guides/builders/setup-agent-client/) + - [Set up Agent Server](https://docs.torus.network/how-to-guides/builders/setup-agent-server/) + - [Set up Agent Client](https://docs.torus.network/how-to-guides/builders/setup-agent-client/)
66-68: Unify social naming (“Twitter” vs “X”) across docsElsewhere in the repo some pages use “X (Twitter)” and x.com links. Pick one convention repo-wide.
Would you like me to sweep the repo and standardize to “X (Twitter)” with x.com links?
src/content/docs/explanations/goal-leaders/recursive-delegation.mdx (5)
12-14: Tighten the version notice phrasingMinor grammar and style clean-up.
-<Aside type="note" title="Version notice"> -This version is based on the Torus v0.6 and is expected to change with the Torus v1. -</Aside> +<Aside type="note" title="Version notice"> +This page reflects Torus v0.6 and may change with Torus v1. +</Aside>
28-31: Fix possessives and improve wording for clarity-* **Specialized Routing:** Agents can specialize solely on routing permissions to the best-fit agent at any given moment, recursively, meaning agent's can also specialize on routing to the best routers. This is critical for the self-organization and efficiency of the network. +* **Specialized Routing:** Agents can specialize in routing permissions to the best-fit agent at any moment—recursively—meaning agents can also specialize in routing to the best routers. This is critical for the network’s self‑organization and efficiency. @@ -* **Composition:** Capability Permissions allow to compose smaller permission scopes into larger scopes from multiple parent (incoming) delegations. +* **Composition:** Capability permissions allow composing smaller permission scopes into larger scopes from multiple parent (incoming) delegations.
34-38: Articles and clarity in “Permission Instance System”-Capability permissions apply a instance system that allows the owner of a capability path to control the number of instances of a permission upon delegation. -It takes one permission instance to utilize it, meaning if multiple permission instances are delegated then the recipient could re-delegate all except one to keep permission access. +Capability permissions apply an instance system that allows the owner of a capability path to control how many instances of a permission can be delegated. +Exercising a permission consumes one instance. If multiple instances are delegated, the recipient can re‑delegate all but one and still retain access.
41-46: Typos and style in RulesIncludes “be be” duplication and minor wording.
-* **Granular Partitioning:** Capability Path can be be partitioned into any set of sub-paths to be re-delegated. +* **Granular Partitioning:** A capability path can be partitioned into any set of sub‑paths for re‑delegation. @@ -* **Delegation Depth:** Measured per permission as the number of delegation steps from the root owner to the current holder. Max: 5 (will increase in future) +* **Delegation Depth:** Measured per permission as the number of delegation steps from the root owner to the current holder. Max: 5 (may increase in the future).Confirm that “Max: 5” remains accurate for v0.6 at publication time.
50-51: Duplicate “Permission System” entries with the same linkBoth bullets point to the same URL with similar descriptions—merge into one or differentiate with anchors.
-- **[Permission System](https://docs.torus.network/explanations/goal-leaders/permissions/)** - Core permission mechanics and delegation basics -- **[Permission System](https://docs.torus.network/explanations/goal-leaders/permissions/)** - Permission system architecture and delegation basics +- **[Permission System](https://docs.torus.network/explanations/goal-leaders/permissions/)** — Core mechanics, architecture, and delegation basicssrc/content/docs/explanations/table-of-contents.mdx (1)
37-37: Rename “Agent Managing” to “Agent Management”Reads more naturally and aligns with noun form used elsewhere (e.g., “Demand Signaling”).
-- [Agent Managing](https://docs.torus.network/explanations/builders/agent-managing/) — Update mechanics and storage architecture +- [Agent Management](https://docs.torus.network/explanations/builders/agent-managing/) — Update mechanics and storage architectureIf you change the visible title, consider renaming the file/route to
agent-managementfor URL consistency.src/content/docs/how-to-guides/goal-leaders/request-dao-treasury-transfer.mdx (4)
13-14: Remove unused importClickableImageNot used in this page; keep imports lean to avoid lint/build noise.
-import ClickableImage from '/src/components/ClickableImage.astro'; import RedText from '/src/components/RedText.astro';
49-57: Clarify Steps 1–3 wording“Click in Shape the Network” is awkward; tighten phrasing and avoid duplication with Step 1.
-1. **Visit the [Proposals Tab in the DAO Governance Portal](https://dao.torus.network/proposals)** - Navigate to the **Shape the Network** section in the Torus DAO Portal. +1. **Open the [DAO Governance Portal – Proposals](https://dao.torus.network/proposals)** + You’ll use the **Shape the Network** entry point to submit your request. @@ -3. **Click in Shape the Network** - It can be found in the top right corner of the page. +3. **Click “Shape the Network”** + It’s in the top‑right corner of the page.
82-90: Strengthen deposit/refund language and wallet neutralityMake it explicit the 10,000 TORUS is a refundable deposit (upon approval) and avoid assuming SubWallet only.
-The proposal cost is **10,000 TORUS** which will be <RedText variant="light">deducted from your connected wallet</RedText>. +The submission requires a **10,000 TORUS refundable deposit** <RedText variant="light">(deducted from your connected wallet at submission)</RedText>. @@ -Open the SubWallet extension and <RedText variant="light">sign the transaction</RedText> to pay the proposal cost. +Open your wallet (e.g., SubWallet) and <RedText variant="light">sign the transaction</RedText> to pay the deposit. @@ -<Aside type="caution"> -The proposal cost will be refunded if your proposal is approved, but will go to the Treasury if rejected. -</Aside> +<Aside type="caution"> +The 10,000 TORUS deposit is refunded if your proposal is approved; if rejected, it is retained by the Treasury. +</Aside>Please confirm “refund upon approval” matches current governance rules at publication.
109-112: Unify social naming with other pagesUse the same “X (Twitter)” vs “Twitter” convention and domains as elsewhere.
-- [Twitter](https://x.com/torus_network) — Updates and ecosystem news +- [X (Twitter)](https://x.com/torus_network) — Updates and ecosystem news
| De-registration results in permanent loss of: | ||
| - **All registered namespaces** — all capability paths will be deleted | ||
| - **Ability to create new delegations** — namespace and emission delegation capabilities are revoked | ||
| - **Delegated permissions** — all permissions granted to/from your agent will be revoked | ||
| - **Agent identity** — the agent is completely removed from the network | ||
|
|
||
| **However:** You can reuse the agent name if you re-register later, but it will be treated as a completely new agent with no connection to the previous one. | ||
| </Aside> |
There was a problem hiding this comment.
Contradiction: de-registration revokes all delegations vs. “emission continuity”
“Permanent Loss” says all permissions granted to/from the agent are revoked, but “Emission Continuity” says emissions continue until a delegator revokes. These statements conflict and will confuse readers.
Pick one model and clarify. If revocation is immediate on de-registration, suggest:
-**Emission Continuity**
-
-You will continue receiving emissions from existing delegations until the delegator manually revokes those permissions.
-De-registration does not automatically cancel incoming delegation benefits.
+**Emission Effects**
+
+De-registration immediately revokes all delegations to/from the agent. Rewards accrued up to the de-registration block remain claimable; no new emissions accrue thereafter.If emissions truly continue, then adjust the “Permanent Loss” section to say delegations are not auto-revoked and explain why.
Also applies to: 60-62
🧰 Tools
🪛 LanguageTool
[grammar] ~49-~49: There might be a mistake here.
Context: ...gistration results in permanent loss of: - All registered namespaces — all capabi...
(QB_NEW_EN)
[style] ~55-~55: Consider using a different adverb to strengthen your wording.
Context: ...gister later, but it will be treated as a completely new agent with no connection to the pre...
(COMPLETELY_ENTIRELY)
🤖 Prompt for AI Agents
In src/content/docs/explanations/builders/agent-managing.mdx around lines 49-56
(and also address related text at 60-62), the document contradicts itself about
whether de-registration immediately revokes all delegations or if emissions
continue until a delegator explicitly revokes them; decide on a single
authoritative model and make the copy consistent: either state that
de-registration performs immediate revocation of all delegations and update the
“Emission Continuity” section to remove or reword any suggestion that emissions
continue, or state that delegations persist until explicitly revoked and change
the “Permanent Loss” bullet to say delegations are not auto-revoked and explain
why (including what remains lost on de-registration). Ensure both sections use
matching terminology and add one brief clarifying sentence about the
timing/mechanism of delegation revocation.
| Successful Proposals Recipient's are expected to: | ||
| - Deliver on proposed milestones and timelines | ||
| - Provide regular progress updates to the community | ||
| - Maintain transparency about fund utilization | ||
|
|
There was a problem hiding this comment.
Grammar: fix possessive and subject agreement.
“Successful Proposals Recipient's” is incorrect. Use a clear subject.
-Successful Proposals Recipient's are expected to:
+Recipients of successful proposals are expected to:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Successful Proposals Recipient's are expected to: | |
| - Deliver on proposed milestones and timelines | |
| - Provide regular progress updates to the community | |
| - Maintain transparency about fund utilization | |
| Recipients of successful proposals are expected to: | |
| - Deliver on proposed milestones and timelines | |
| - Provide regular progress updates to the community | |
| - Maintain transparency about fund utilization |
🧰 Tools
🪛 LanguageTool
[grammar] ~50-~50: There might be a mistake here.
Context: ...l Proposals Recipient's are expected to: - Deliver on proposed milestones and timel...
(QB_NEW_EN)
🤖 Prompt for AI Agents
In src/content/docs/explanations/goal-leaders/dao-treasury.mdx around lines 50
to 54, the heading/text "Successful Proposals Recipient's are expected to:" uses
incorrect possessive and subject agreement; change it to a clear plural subject
such as "Recipients of successful proposals are expected to:" and update the
following list items if needed to match grammar and punctuation (capitalize
consistently and ensure list entries complete the sentence).
| Right now, | ||
|
|
There was a problem hiding this comment.
Remove stray fragment (“Right now,”).
Appears to be an unfinished thought.
-Right now,
+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Right now, |
🤖 Prompt for AI Agents
In src/content/docs/explanations/holders/governance-participation.mdx around
lines 22 to 23 there is a stray fragment "Right now," which is an unfinished
thought; remove that fragment (or replace it with a complete sentence that fits
the surrounding context) so the paragraph reads smoothly and no orphaned phrase
remains.
| Learn about [recursive delegation](https://docs.torus.network/explanations/goal-leaders/recursive-delegation/) delegation mechanisms and control space architecture. | ||
| </Aside> |
There was a problem hiding this comment.
Fix duplicated word in sentence.
“recursive delegation delegation mechanisms” → remove the duplicated “delegation”.
-Learn about [recursive delegation](https://docs.torus.network/explanations/goal-leaders/recursive-delegation/) delegation mechanisms and control space architecture.
+Learn about [recursive delegation](https://docs.torus.network/explanations/goal-leaders/recursive-delegation/) mechanisms and control space architecture.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Learn about [recursive delegation](https://docs.torus.network/explanations/goal-leaders/recursive-delegation/) delegation mechanisms and control space architecture. | |
| </Aside> | |
| Learn about [recursive delegation](https://docs.torus.network/explanations/goal-leaders/recursive-delegation/) mechanisms and control space architecture. | |
| </Aside> |
🤖 Prompt for AI Agents
In src/content/docs/how-to-guides/builders/manage-capabilities.mdx around lines
174 to 175, the sentence contains a duplicated word "delegation delegation";
remove the extra "delegation" so it reads "recursive delegation mechanisms"
(i.e., keep a single "delegation") and ensure spacing and punctuation remain
correct.
| 3. **Sign the Transaction in the SubWallet and Wait for the Confirmation** | ||
| You will be prompted by <RedText variant="light">SubWallet to sign the on-chain transaction</RedText>. | ||
| Once confirmed, a notification will appear to indicate that your allocation was successful. | ||
|
|
There was a problem hiding this comment.
Incorrect success message (“allocation”).
This step is about updating agent info. Replace “allocation” with “update”.
-Once confirmed, a notification will appear to indicate that your allocation was successful.
+Once confirmed, a notification will indicate that your update was successful.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 3. **Sign the Transaction in the SubWallet and Wait for the Confirmation** | |
| You will be prompted by <RedText variant="light">SubWallet to sign the on-chain transaction</RedText>. | |
| Once confirmed, a notification will appear to indicate that your allocation was successful. | |
| 3. **Sign the Transaction in the SubWallet and Wait for the Confirmation** | |
| You will be prompted by <RedText variant="light">SubWallet to sign the on-chain transaction</RedText>. | |
| Once confirmed, a notification will indicate that your update was successful. |
🧰 Tools
🪛 LanguageTool
[grammar] ~80-~80: There might be a mistake here.
Context: ...sign the on-chain transaction. Once confirmed, a notification will ap...
(QB_NEW_EN)
🤖 Prompt for AI Agents
In src/content/docs/how-to-guides/builders/manage-your-agent.mdx around lines 79
to 82, the success message mistakenly says "allocation" even though this step
updates agent info; change the final sentence so the notification indicates that
your agent update was successful (replace "allocation" with "update") and ensure
surrounding wording still reads naturally (e.g., "your agent update was
successful" or "the update was successful").
| @@ -0,0 +1,179 @@ | |||
| --- | |||
| title: Manage Permissions | |||
| description: Step-by-step guide to creating and managing permissions in the Torus portal. | |||
There was a problem hiding this comment.
Align description with page scope (managing, not creating).
The page focuses on viewing/managing existing permissions, not creating them.
-description: Step-by-step guide to creating and managing permissions in the Torus portal.
+description: Step-by-step guide to viewing and managing permissions in the Torus portal.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| description: Step-by-step guide to creating and managing permissions in the Torus portal. | |
| description: Step-by-step guide to viewing and managing permissions in the Torus portal. |
🤖 Prompt for AI Agents
In src/content/docs/how-to-guides/goal-leaders/manage-permissions.mdx around
line 3, the frontmatter description currently says "Step-by-step guide to
creating and managing permissions in the Torus portal" but the page scope is
only viewing/managing existing permissions; update the description to reflect
managing (not creating) — for example, change it to "Step-by-step guide to
viewing and managing permissions in the Torus portal" or a similar phrase that
removes "creating" so the frontmatter accurately matches page content.
| 5. **Complete the Transfer Request Form** | ||
| Fill out the required information: | ||
|
|
||
| ```md | ||
| # Destination | ||
| [Enter the wallet address where funds should be sent] | ||
|
|
||
| # Value | ||
| [Specify the amount in TORUS you're requesting] | ||
|
|
||
| # Application Title | ||
| [Provide a clear, descriptive title for your project] | ||
|
|
||
| # Application Body | ||
| [Write a detailed explanation including: | ||
| - Project overview and objectives | ||
| - How it benefits the Torus ecosystem | ||
| - Timeline and milestones | ||
| - Budget breakdown and justification | ||
| - Your background and qualifications] | ||
| ``` | ||
| 5. **Submit and Sign the Transaction** |
There was a problem hiding this comment.
List numbering breaks: two “5.” entries under
This can render oddly depending on the Steps component. Increment the second “5.” to “6.” and the current “6.” to “7.”
-5. **Complete the Transfer Request Form**
+5. **Complete the Transfer Request Form**
@@
-5. **Submit and Sign the Transaction**
+6. **Submit and Sign the Transaction**
@@
-6. **All Done**
+7. **All Done** 📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 5. **Complete the Transfer Request Form** | |
| Fill out the required information: | |
| ```md | |
| # Destination | |
| [Enter the wallet address where funds should be sent] | |
| # Value | |
| [Specify the amount in TORUS you're requesting] | |
| # Application Title | |
| [Provide a clear, descriptive title for your project] | |
| # Application Body | |
| [Write a detailed explanation including: | |
| - Project overview and objectives | |
| - How it benefits the Torus ecosystem | |
| - Timeline and milestones | |
| - Budget breakdown and justification | |
| - Your background and qualifications] | |
| ``` | |
| 5. **Submit and Sign the Transaction** | |
| 5. **Complete the Transfer Request Form** | |
| Fill out the required information: |
🧰 Tools
🪛 LanguageTool
[grammar] ~82-~82: There might be a mistake here.
Context: ...``` 5. Submit and Sign the Transaction The proposal cost is 10,000 TORUS wh...
(QB_NEW_EN)
🤖 Prompt for AI Agents
In src/content/docs/how-to-guides/goal-leaders/request-dao-treasury-transfer.mdx
around lines 61 to 82, the ordered step numbering repeats "5." causing rendering
issues; update the second "5." to "6." and then increment the current "6." to
"7." so the steps read 5., 6., 7. in sequence within the Steps component.
Summary by CodeRabbit
New Features
Documentation
Refactor