Open
Conversation
📝 WalkthroughWalkthroughThis PR rebrandings all documentation from TradeTrust CLI to TrustVC CLI and replaces static command-line examples with interactive prompt-driven workflows. It also updates library imports from Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~35 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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. Comment Tip You can customize the tone of the review comments and chat replies.Configure the |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (13)
docs/introduction/key-components-of-tradetrust/w3c-vc/verifying-documents/verifying-documents-cli.mdx-86-86 (1)
86-86:⚠️ Potential issue | 🟡 MinorCorrect typo: “revokable” → “revocable”.
Use the standard spelling to keep terminology professional and consistent.
✏️ Suggested doc fix
-- For transferable records or revokable documents, the CLI may automatically detect and use the appropriate blockchain network +- For transferable records or revocable documents, the CLI may automatically detect and use the appropriate blockchain network🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/introduction/key-components-of-tradetrust/w3c-vc/verifying-documents/verifying-documents-cli.mdx` at line 86, Replace the misspelled word "revokable" with the correct spelling "revocable" in the sentence that reads "For transferable records or revokable documents, the CLI may automatically detect and use the appropriate blockchain network" (in the verifying-documents-cli.mdx content under W3C VC docs); update only the word so the sentence becomes "For transferable records or revocable documents, the CLI may automatically detect and use the appropriate blockchain network" to maintain consistent terminology.docs/introduction/key-components-of-tradetrust/w3c-vc/verifying-documents/verifying-documents-cli.mdx-77-77 (1)
77-77:⚠️ Potential issue | 🟡 MinorFix awkward phrasing in expired-document warning example.
“The document credential has expired.” reads awkwardly and conflicts with the new generic “document” terminology.
✏️ Suggested doc fix
-⚠ warning The document credential has expired. +⚠ warning The document has expired.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/introduction/key-components-of-tradetrust/w3c-vc/verifying-documents/verifying-documents-cli.mdx` at line 77, Replace the awkward example warning text "The document credential has expired." with the concise, generic phrasing "The document has expired." so the example line reads: "⚠ warning The document has expired." to align with the new generic "document" terminology.docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx-26-28 (1)
26-28:⚠️ Potential issue | 🟡 MinorReplace placeholder text with proper link to credential-status documentation.
Line 27 contains placeholder text "(link to issuing W3C VC)" that should be converted to a proper Markdown link pointing to the credential status guide:
:::note Legacy Method -This method uses the legacy OpenAttestation approach. It is recommended to use the legacy CLI tool (tradetrust-cli) to run this command. For new implementations, we recommend adopting the newer document issuance method. Please refer to this guide: Issuing W3C VCs (link to issuing W3C VC). +This method uses the legacy OpenAttestation approach. It is recommended to use the legacy CLI tool (tradetrust-cli) to run this command. For new implementations, we recommend adopting the newer document issuance method. Please refer to this guide: [Issuing W3C VCs](/docs/how-tos/credential-status). :::🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx` around lines 26 - 28, Replace the placeholder "(link to issuing W3C VC)" inside the ":::note Legacy Method" block with a proper Markdown link to the credential status guide; specifically, update the text "Issuing W3C VCs (link to issuing W3C VC)" to use standard Markdown syntax [Issuing W3C VCs](<credential-status-guide-URL>) so the link points to the credential-status documentation, ensuring the placeholder string is removed and the new URL is inserted.docs/introduction/key-components-of-tradetrust/transferability/transactions.md-172-173 (1)
172-173:⚠️ Potential issue | 🟡 MinorClarify signer eligibility per action to prevent failed transactions.
Line 172 and Line 217 mention which wallet to use, but the wording is still ambiguous. Please state explicitly that the signing wallet must match the actor authorized for that action (e.g., current holder vs current owner), with a short cross-reference to the action table in each section.
Suggested wording update
-Do take note that the wallet supplied should be that of Charlie instead of Alice since Charlie currently holds and owns the token. +Use the wallet of the actor authorized for this action. In this state, Charlie is both current holder and owner, so Charlie must sign this transaction. -Do take note that the wallet supplied should be that of Bob instead of Charlie since Bob currently holds the token and Charlie owns the token. +Use the wallet of the actor authorized for this action. In this state, Bob is the current holder, so Bob must sign this transaction.Also applies to: 217-218
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/introduction/key-components-of-tradetrust/transferability/transactions.md` around lines 172 - 173, Replace the ambiguous phrase "wallet supplied should be that of Charlie instead of Alice" with an explicit statement that the signing wallet must match the actor authorized to perform the action (e.g., "the signing wallet must be the current holder's wallet (Charlie) for holder-only actions, and the current owner's wallet for owner-only actions"); in both the sentence at the Charlie/Alice mention and the separate occurrence around lines referencing 217-218, add a short cross-reference to the "Action table" (e.g., "see Action table for authorized actor per action") so readers can verify which actor (holder vs owner) must sign each transaction.docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx-48-48 (1)
48-48:⚠️ Potential issue | 🟡 MinorCorrect the link on Line 48—it points to a non-existent section in TrustVC CLI docs.
The
tradetrust wrap raw-documents --output-dir wrapped-documentscommand on Line 28 is correct and matches the current TradeTrust documentation. However, the link on Line 48 references "TrustVC CLI wrapping," but the TrustVC CLI does not expose wrapping as a CLI subcommand—only as library functions. The GitHub link points to a section that doesn't exist, which can confuse readers about whether they should switch tools.Replace the link with one to the OpenAttestation CLI wrapping documentation, or clarify in the text that the TrustVC reference is for users migrating to the SDK approach, not the CLI.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx` at line 48, The link text "Visit our github page to learn more about [TrustVC CLI wrapping](https://github.com/trustvc/trustvc-cli/#wrapping-documents)!" points to a non-existent TrustVC CLI subcommand; replace that link so it either (a) links to the OpenAttestation CLI wrapping docs or (b) changes the sentence to clarify that the TrustVC reference is for SDK/library usage only (not a CLI subcommand). Update the anchor URL and/or wording in the line containing "Visit our github page..." so it accurately references the OpenAttestation CLI wrapping documentation or explicitly states the TrustVC link is SDK-only.docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx-50-50 (1)
50-50:⚠️ Potential issue | 🟡 MinorCapitalize “GitHub” in user-facing docs.
Line 50 should use the official capitalization for consistency and professionalism.
Suggested fix
-> Visit our github page to learn more about [TrustVC CLI wrapping](https://github.com/trustvc/trustvc-cli/#wrapping-documents)! +> Visit our GitHub page to learn more about [TrustVC CLI wrapping](https://github.com/trustvc/trustvc-cli/#wrapping-documents)!🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx` at line 50, Update the user-facing markdown link text to use the official capitalization "GitHub" instead of "github" in the sentence containing the link to TrustVC CLI wrapping (the link text "TrustVC CLI wrapping" and URL "https://github.com/trustvc/trustvc-cli/#wrapping-documents"); change the visible text portion "github" to "GitHub" so the link reads "Visit our GitHub page to learn more about TrustVC CLI wrapping!".docs/how-tos/transactions.md-185-186 (1)
185-186:⚠️ Potential issue | 🟡 MinorTighten wording for clarity.
Line 185 reads awkwardly; simplify the sentence.
Suggested fix
-Now we will see performing the same transactions via the command line. +Now we will perform the same transactions via the command line.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/transactions.md` around lines 185 - 186, The sentence "Now we will see performing the same transactions via the command line." is awkward; replace it with a clearer, tighter phrasing such as "Now we'll perform the same transactions from the command line." — locate the sentence in the docs (the line containing "Now we will see performing the same transactions via the command line.") and update it accordingly.docs/how-tos/transactions.md-171-171 (1)
171-171:⚠️ Potential issue | 🟡 MinorUse “macOS” instead of “MacOS”.
Line 171 should use the official spelling.
Suggested fix
-For Linux or MacOS users, if you have npm installed on your machine, you may install the CLI using the following command: +For Linux or macOS users, if you have npm installed on your machine, you may install the CLI using the following command:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/transactions.md` at line 171, Replace the nonstandard capitalization "MacOS" in the sentence "For Linux or MacOS users, if you have npm installed on your machine, you may install the CLI using the following command:" with the official spelling "macOS" so the line reads "For Linux or macOS users, if you have npm installed on your machine, you may install the CLI using the following command:".docs/how-tos/open-attestation/prerequisites.md-36-36 (1)
36-36:⚠️ Potential issue | 🟡 MinorUse official OS capitalization: “macOS”.
Line 36 should use
macOSfor correctness.Suggested fix
-For Linux or MacOS users, if you have `npm` installed on your machine, you may install the CLI using the following command: +For Linux or macOS users, if you have `npm` installed on your machine, you may install the CLI using the following command:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/prerequisites.md` at line 36, Update the OS name capitalization in the sentence that currently reads "For Linux or MacOS users, if you have `npm` installed on your machine, you may install the CLI using the following command:" by replacing "MacOS" with the official "macOS" (i.e., change the string "MacOS" to "macOS") so the sentence reads "For Linux or macOS users..." to use the correct vendor capitalization.docs/how-tos/deployment.md-27-27 (1)
27-27:⚠️ Potential issue | 🟡 MinorUse “macOS” for platform naming consistency.
Line 27 should use
macOS.Suggested fix
-For Linux or MacOS users, if you have npm installed on your machine, you may install the CLI using the following command: +For Linux or macOS users, if you have npm installed on your machine, you may install the CLI using the following command:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/deployment.md` at line 27, Update the platform name in the sentence "For Linux or MacOS users, if you have npm installed on your machine, you may install the CLI using the following command:" to use the correct casing "macOS" (replace "MacOS" with "macOS") so the line reads "For Linux or macOS users..." to ensure consistent platform naming in docs.docs/how-tos/open-attestation/verifiable-documents/dns-did/revoking-document.mdx-81-81 (1)
81-81:⚠️ Potential issue | 🟡 MinorFix grammar in the wrapped-document reference sentence.
Line 81 has a minor wording issue (“one of the file”).
Suggested fix
-- The **hash** is the value of `targetHash` field of one of the [previously wrapped documents](/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli) (open one of the file, head to the bottom and check for the `targetHash` in the `signature` object.) +- The **hash** is the value of the `targetHash` field in one of the [previously wrapped documents](/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli) (open one of the files, scroll to the bottom, and check `targetHash` in the `signature` object).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/revoking-document.mdx` at line 81, The sentence describing the hash has a grammar mistake ("one of the file"); update the sentence that starts "The **hash** is the value of `targetHash` field..." to read something like: "The **hash** is the value of the `targetHash` field of one of the previously wrapped documents (open one of the files, scroll to the bottom and check for the `targetHash` in the `signature` object)." Make sure `targetHash` and `signature` remain code-formatted and only correct "file" → "files" and improve the small wording/flow as shown.docs/how-tos/open-attestation/prerequisites.md-16-20 (1)
16-20:⚠️ Potential issue | 🟡 MinorFix heading level progression for markdown lint compliance.
The section starts at
###directly; add an##parent heading first to satisfy MD001 and maintain document hierarchy.Suggested fix
-### What TrustVC CLI does +## TrustVC CLI + +### What TrustVC CLI does🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/prerequisites.md` around lines 16 - 20, Add a parent H2 heading above the existing "What TrustVC CLI does" H3 to fix markdown heading hierarchy (MD001); insert a new `##` heading (for example "TrustVC CLI" or "Using TrustVC CLI") immediately before the "What TrustVC CLI does" section, so the "What TrustVC CLI does" (currently `### What TrustVC CLI does`) and the following `### Installation of TrustVC CLI` are nested under that H2.docs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-cli.mdx-45-45 (1)
45-45:⚠️ Potential issue | 🟡 MinorReplace "Token" with "Document" or "Document Batch" in line 45.
Line 45 uses incorrect terminology for the
trustvc document-store issuecommand. Change "Token with hash..." to "Document/Document Batch with hash..." to match the official CLI output.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-cli.mdx` at line 45, Update the success message text produced by the trustvc CLI command so it uses the correct terminology: replace the phrase "Token with hash" with "Document with hash" or "Document Batch with hash" in the output string for the trustvc document-store issue command; locate the output formatting code that generates the exact message "Token with hash 0x80cc53..." (or the template producing "Token with hash <hash> has been issued on <chain>") and change the literal/text template to "Document with hash <hash> has been issued on <chain>" (or "Document Batch..." where appropriate) to match the official CLI output.
🧹 Nitpick comments (5)
docs/how-tos/issuer/did-web.md (2)
383-386: Add one path-based CLI example input to prevent root-DID confusion.For this section, showing only the command is a bit thin for a path-based walkthrough. A short prompt/answer example (e.g.,
https://example.com/department-a/did.json) would make this actionable and reduce accidental root DID generation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/issuer/did-web.md` around lines 383 - 386, Update the DID-Web CLI example that currently shows only the command "trustvc w3c did-web" by adding a short path-based input/answer example to demonstrate a non-root DID (e.g., provide a sample URL like https://example.com/department-a/did.json as the prompt and show the resulting command or expected output). Locate the block containing the "trustvc w3c did-web" example and insert one concise example line immediately after it to illustrate a path-based DID so readers won’t accidentally generate a root DID.
149-150: Clarify input terminology for DID host value and output artifact naming.These prompts currently mix terms in a way that can mislead users: “domain” is shown with a full URL value, and “DID token file” appears to refer to DID document outputs. Consider making both prompts explicit and consistent.
✏️ Suggested wording update
-? Enter the domain where your did:web public key will be hosted (e.g., https://example.com/.well-known/did.json): https://example.com/.well-known/did.json -? Enter a directory to save the generated DID token file (optional): . +? Enter the DID document URL where your did:web will be hosted (e.g., https://example.com/.well-known/did.json): https://example.com/.well-known/did.json +? Enter a directory to save the generated DID files (optional): .Also applies to: 292-293
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/issuer/did-web.md` around lines 149 - 150, The prompts mix terminology and can mislead users: update the prompt string "Enter the domain where your did:web public key will be hosted (e.g., https://example.com/.well-known/did.json)" to explicitly ask for the full DID host URL (e.g., "Enter the DID host URL where your did:web will be published (e.g., https://example.com)") and change the prompt "Enter a directory to save the generated DID token file (optional)" to clearly refer to the DID document output (e.g., "Enter an output directory to save the generated DID document file (e.g., ./did.json) (optional)"); ensure both prompts use consistent terms like "DID host URL" and "DID document file" so users understand required input and the produced artifact.docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdx (1)
60-60: Add inline code formatting for function and package names.The function name
signW3Cand package name@trustvc/trustvcshould be formatted with backticks for consistency with standard markdown documentation practices.📝 Suggested fix
-The CLI digitally signs a Verifiable Credential using the signW3C function from the `@trustvc/trustvc` package, ensuring that the credential is tamper-evident and can be trusted by external verifiers. +The CLI digitally signs a Verifiable Credential using the `signW3C` function from the `@trustvc/trustvc` package, ensuring that the credential is tamper-evident and can be trusted by external verifiers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdx` at line 60, Update the sentence to use inline code formatting for the function and package names: wrap signW3C and `@trustvc/trustvc` in backticks so it reads like `signW3C` and `@trustvc/trustvc`; keep the rest of the sentence unchanged to preserve meaning and context.docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.md (1)
59-76: Consider adding non-interactive equivalents alongside interactive prompts.These transcripts are great for first-time users, but adding one concise non-interactive command example per section would improve copy/paste usability for CI or scripted workflows.
Also applies to: 106-121, 154-170, 200-215, 248-264, 292-308, 332-347, 371-387
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.md` around lines 59 - 76, Add a single non-interactive CLI example alongside the interactive transcript for each section (e.g., the "trustvc title-escrow transfer-owner-holder" transcript shown) that shows the equivalent flags/arguments to supply the wrapped document path, new owner address, new holder address, wallet type, wallet file path, wallet password, and optional remark so users can copy/paste for CI/scripts; repeat this for the other listed sections (106-121, 154-170, 200-215, 248-264, 292-308, 332-347, 371-387), placing the non-interactive example immediately after the interactive block and using the same command names (like transfer-owner-holder) to make locating the examples straightforward.docs/how-tos/deployment.md (1)
86-89: Consider removing duplicate “deploy Function Explanation” subsection.This repeats earlier content and can be consolidated to reduce doc redundancy.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-tos/deployment.md` around lines 86 - 89, Remove the duplicated "deploy Function Explanation" subsection that describes the deploy function and Token Registry clone behavior; locate the second occurrence (heading text "deploy Function Explanation" and the paragraph referencing the deploy function and Token Registry) and either delete it or merge any unique content into the first occurrence, ensuring headings, anchors, and internal links remain correct and there are no repeated descriptions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@docs/how-tos/open-attestation/transferable-records/issuing-document/issuing-document-cli.mdx`:
- Around line 26-43: The docs wrongly claim the trustvc token-registry mint
command auto-extracts token registry address, tokenId, and network from the
wrapped document; update the workflow text for the trustvc token-registry mint
section to instruct users to pass --network, --address, and --tokenId explicitly
(either as command flags or via interactive prompts that ask for them) and
remove the statement that the CLI automatically extracts those values from the
Document path prompt; reference the command name trustvc token-registry mint and
the flags --network, --address, and --tokenId so users know exactly which inputs
are required.
In
`@docs/how-tos/open-attestation/transferable-records/token-registry/token-registry-cli.mdx`:
- Around line 34-36: Replace the hard-coded private key literal in the shell
example for the OA_PRIVATE_KEY environment variable with an obvious placeholder
(e.g. export OA_PRIVATE_KEY="REPLACE_WITH_PRIVATE_KEY" or export
OA_PRIVATE_KEY="<YOUR_PRIVATE_KEY_HERE>") so the token-registry CLI example no
longer contains realistic key-like values; update the code block containing
OA_PRIVATE_KEY to use that placeholder and ensure any surrounding documentation
text mentions that users must supply their own private key.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/deploying-document-store/document-store-code.mdx`:
- Around line 31-44: The snippets currently use ethers v6 syntax (e.g., new
ethers.JsonRpcProvider(...)) but are stated to support both v5 and v6; update
the docs by either labeling these examples explicitly as "ethers v6" or add an
ethers v5 variant that replaces v6-only symbols: in the v5 variant change new
ethers.JsonRpcProvider(...) to new ethers.providers.JsonRpcProvider(...), keep
usage of deployDocumentStore and CHAIN_ID the same, ensure Wallet/signer usage
(Wallet, signer.getAddress()) remains compatible with v5, and mirror this change
in the other snippets referenced (the blocks around the other occurrences).
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-code.mdx`:
- Around line 31-54: The example incorrectly treats documentStoreIssue as
returning a transaction response; update the code using documentStoreIssue(...)
to await a transaction hash string (e.g., const txHash = await
documentStoreIssue(...)) and log that hash directly instead of calling tx.wait()
or accessing receipt.hash. Also fix provider instantiation to be compatible with
both ethers v5 and v6 by using the correct constructor for the version in use
(ethers.providers.JsonRpcProvider for v5 or ethers.JsonRpcProvider for v6) or by
detecting the ethers API and selecting the appropriate provider constructor
before creating the signer (references: documentStoreIssue, tx/txHash, Wallet,
signer, ethers.JsonRpcProvider, ethers.providers.JsonRpcProvider).
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-cli.mdx`:
- Around line 24-37: The docs mention both targetHash and merkleRoot but don't
explain how to choose batch revocation; update the CLI flow for the "trustvc
document-store revoke" command to show how to override the extracted targetHash
and select merkleRoot (either by documenting the interactive prompt choice
"Revoke type: [single|batch]" and instructing the user to paste the merkleRoot
when "batch" is chosen, or by documenting the CLI flag that accepts a merkle
root such as --merkle-root/--hash-type). Reference the existing "Document path"
prompt (which auto-extracts targetHash) and explicitly state the new step or
flag that lets users select "merkleRoot" to revoke an entire batch.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-code.mdx`:
- Around line 31-54: The example incorrectly treats documentStoreRevoke as
returning a TransactionResponse; update the call to capture the returned
transaction hash (e.g., const txHash = await documentStoreRevoke(...)) and
remove the tx.wait() call, then log the txHash directly; additionally clarify
the provider syntax by showing the ethers v6 provider (ethers.JsonRpcProvider)
used in the snippet and, if v5 compatibility is desired, show the v5 equivalent
(ethers.providers.JsonRpcProvider) as an alternative so readers know which
constructor to use.
In
`@docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.md`:
- Around line 251-264: Update the CLI success output for the title-escrow
transfer commands to use "owner" (not "holder") or add an explicit clarifying
note; specifically modify the success message emitted by the
nominate-transfer-owner command and the endorse-transfer-owner command (the
strings that currently read "Transferable record's holder has been successfully
nominated to new owner..." and similar) so they reference "owner" consistently
with the documented operation, or append a short parenthetical clarifier that
"holder" in this output refers to ownership, then run the CLI to verify both
commands' success messages match the docs.
In
`@docs/introduction/key-components-of-tradetrust/transferability/transactions.md`:
- Around line 59-76: This file documents CLI commands using the deprecated
"trustvc" binary; replace every occurrence of the CLI token "trustvc" (e.g., the
command string "trustvc title-escrow transfer-owner-holder" and other "trustvc
..." examples) with "tradetrust" so the examples become "tradetrust title-escrow
...". Update all 17 instances in the document, ensuring interactive examples,
help/usage snippets and any inline command references consistently use
"tradetrust" instead of "trustvc".
In
`@docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdx`:
- Line 35: Replace the incorrect package and CLI command names: change the
install package from `@trustvc/trustvc-cli` to `@trustvc/w3c-cli`, replace
occurrences of the command trustvc w3c w3c-sign with the correct CLI invocation
w3c-cli sign (also update the other referenced command to use w3c-cli sign), and
wrap the identifiers signW3C and `@trustvc/trustvc` in inline code formatting for
consistency.
---
Minor comments:
In `@docs/how-tos/deployment.md`:
- Line 27: Update the platform name in the sentence "For Linux or MacOS users,
if you have npm installed on your machine, you may install the CLI using the
following command:" to use the correct casing "macOS" (replace "MacOS" with
"macOS") so the line reads "For Linux or macOS users..." to ensure consistent
platform naming in docs.
In `@docs/how-tos/open-attestation/prerequisites.md`:
- Line 36: Update the OS name capitalization in the sentence that currently
reads "For Linux or MacOS users, if you have `npm` installed on your machine,
you may install the CLI using the following command:" by replacing "MacOS" with
the official "macOS" (i.e., change the string "MacOS" to "macOS") so the
sentence reads "For Linux or macOS users..." to use the correct vendor
capitalization.
- Around line 16-20: Add a parent H2 heading above the existing "What TrustVC
CLI does" H3 to fix markdown heading hierarchy (MD001); insert a new `##`
heading (for example "TrustVC CLI" or "Using TrustVC CLI") immediately before
the "What TrustVC CLI does" section, so the "What TrustVC CLI does" (currently
`### What TrustVC CLI does`) and the following `### Installation of TrustVC CLI`
are nested under that H2.
In
`@docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx`:
- Line 48: The link text "Visit our github page to learn more about [TrustVC CLI
wrapping](https://github.com/trustvc/trustvc-cli/#wrapping-documents)!" points
to a non-existent TrustVC CLI subcommand; replace that link so it either (a)
links to the OpenAttestation CLI wrapping docs or (b) changes the sentence to
clarify that the TrustVC reference is for SDK/library usage only (not a CLI
subcommand). Update the anchor URL and/or wording in the line containing "Visit
our github page..." so it accurately references the OpenAttestation CLI wrapping
documentation or explicitly states the TrustVC link is SDK-only.
In `@docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx`:
- Around line 26-28: Replace the placeholder "(link to issuing W3C VC)" inside
the ":::note Legacy Method" block with a proper Markdown link to the credential
status guide; specifically, update the text "Issuing W3C VCs (link to issuing
W3C VC)" to use standard Markdown syntax [Issuing W3C
VCs](<credential-status-guide-URL>) so the link points to the credential-status
documentation, ensuring the placeholder string is removed and the new URL is
inserted.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-did/revoking-document.mdx`:
- Line 81: The sentence describing the hash has a grammar mistake ("one of the
file"); update the sentence that starts "The **hash** is the value of
`targetHash` field..." to read something like: "The **hash** is the value of the
`targetHash` field of one of the previously wrapped documents (open one of the
files, scroll to the bottom and check for the `targetHash` in the `signature`
object)." Make sure `targetHash` and `signature` remain code-formatted and only
correct "file" → "files" and improve the small wording/flow as shown.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx`:
- Line 50: Update the user-facing markdown link text to use the official
capitalization "GitHub" instead of "github" in the sentence containing the link
to TrustVC CLI wrapping (the link text "TrustVC CLI wrapping" and URL
"https://github.com/trustvc/trustvc-cli/#wrapping-documents"); change the
visible text portion "github" to "GitHub" so the link reads "Visit our GitHub
page to learn more about TrustVC CLI wrapping!".
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-cli.mdx`:
- Line 45: Update the success message text produced by the trustvc CLI command
so it uses the correct terminology: replace the phrase "Token with hash" with
"Document with hash" or "Document Batch with hash" in the output string for the
trustvc document-store issue command; locate the output formatting code that
generates the exact message "Token with hash 0x80cc53..." (or the template
producing "Token with hash <hash> has been issued on <chain>") and change the
literal/text template to "Document with hash <hash> has been issued on <chain>"
(or "Document Batch..." where appropriate) to match the official CLI output.
In `@docs/how-tos/transactions.md`:
- Around line 185-186: The sentence "Now we will see performing the same
transactions via the command line." is awkward; replace it with a clearer,
tighter phrasing such as "Now we'll perform the same transactions from the
command line." — locate the sentence in the docs (the line containing "Now we
will see performing the same transactions via the command line.") and update it
accordingly.
- Line 171: Replace the nonstandard capitalization "MacOS" in the sentence "For
Linux or MacOS users, if you have npm installed on your machine, you may install
the CLI using the following command:" with the official spelling "macOS" so the
line reads "For Linux or macOS users, if you have npm installed on your machine,
you may install the CLI using the following command:".
In
`@docs/introduction/key-components-of-tradetrust/transferability/transactions.md`:
- Around line 172-173: Replace the ambiguous phrase "wallet supplied should be
that of Charlie instead of Alice" with an explicit statement that the signing
wallet must match the actor authorized to perform the action (e.g., "the signing
wallet must be the current holder's wallet (Charlie) for holder-only actions,
and the current owner's wallet for owner-only actions"); in both the sentence at
the Charlie/Alice mention and the separate occurrence around lines referencing
217-218, add a short cross-reference to the "Action table" (e.g., "see Action
table for authorized actor per action") so readers can verify which actor
(holder vs owner) must sign each transaction.
In
`@docs/introduction/key-components-of-tradetrust/w3c-vc/verifying-documents/verifying-documents-cli.mdx`:
- Line 86: Replace the misspelled word "revokable" with the correct spelling
"revocable" in the sentence that reads "For transferable records or revokable
documents, the CLI may automatically detect and use the appropriate blockchain
network" (in the verifying-documents-cli.mdx content under W3C VC docs); update
only the word so the sentence becomes "For transferable records or revocable
documents, the CLI may automatically detect and use the appropriate blockchain
network" to maintain consistent terminology.
- Line 77: Replace the awkward example warning text "The document credential has
expired." with the concise, generic phrasing "The document has expired." so the
example line reads: "⚠ warning The document has expired." to align with the
new generic "document" terminology.
---
Nitpick comments:
In `@docs/how-tos/deployment.md`:
- Around line 86-89: Remove the duplicated "deploy Function Explanation"
subsection that describes the deploy function and Token Registry clone behavior;
locate the second occurrence (heading text "deploy Function Explanation" and the
paragraph referencing the deploy function and Token Registry) and either delete
it or merge any unique content into the first occurrence, ensuring headings,
anchors, and internal links remain correct and there are no repeated
descriptions.
In `@docs/how-tos/issuer/did-web.md`:
- Around line 383-386: Update the DID-Web CLI example that currently shows only
the command "trustvc w3c did-web" by adding a short path-based input/answer
example to demonstrate a non-root DID (e.g., provide a sample URL like
https://example.com/department-a/did.json as the prompt and show the resulting
command or expected output). Locate the block containing the "trustvc w3c
did-web" example and insert one concise example line immediately after it to
illustrate a path-based DID so readers won’t accidentally generate a root DID.
- Around line 149-150: The prompts mix terminology and can mislead users: update
the prompt string "Enter the domain where your did:web public key will be hosted
(e.g., https://example.com/.well-known/did.json)" to explicitly ask for the full
DID host URL (e.g., "Enter the DID host URL where your did:web will be published
(e.g., https://example.com)") and change the prompt "Enter a directory to save
the generated DID token file (optional)" to clearly refer to the DID document
output (e.g., "Enter an output directory to save the generated DID document file
(e.g., ./did.json) (optional)"); ensure both prompts use consistent terms like
"DID host URL" and "DID document file" so users understand required input and
the produced artifact.
In
`@docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.md`:
- Around line 59-76: Add a single non-interactive CLI example alongside the
interactive transcript for each section (e.g., the "trustvc title-escrow
transfer-owner-holder" transcript shown) that shows the equivalent
flags/arguments to supply the wrapped document path, new owner address, new
holder address, wallet type, wallet file path, wallet password, and optional
remark so users can copy/paste for CI/scripts; repeat this for the other listed
sections (106-121, 154-170, 200-215, 248-264, 292-308, 332-347, 371-387),
placing the non-interactive example immediately after the interactive block and
using the same command names (like transfer-owner-holder) to make locating the
examples straightforward.
In
`@docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdx`:
- Line 60: Update the sentence to use inline code formatting for the function
and package names: wrap signW3C and `@trustvc/trustvc` in backticks so it reads
like `signW3C` and `@trustvc/trustvc`; keep the rest of the sentence unchanged
to preserve meaning and context.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 125c1e82-7f6c-4377-8269-ad507aeced47
📒 Files selected for processing (22)
docs/how-tos/deployment.mddocs/how-tos/issuer/did-web.mddocs/how-tos/open-attestation/prerequisites.mddocs/how-tos/open-attestation/transferable-records/issuing-document/issuing-document-cli.mdxdocs/how-tos/open-attestation/transferable-records/token-registry/token-registry-cli.mdxdocs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/create.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/revoking-document.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/deploying-document-store/document-store-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/deploying-document-store/document-store-code.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-code.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-cli.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-code.mdxdocs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli.mdxdocs/how-tos/transactions.mddocs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.mddocs/introduction/key-components-of-tradetrust/transferability/transactions.mddocs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdxdocs/introduction/key-components-of-tradetrust/w3c-vc/verifying-documents/verifying-documents-cli.mdx
Comment on lines
+26
to
43
| The TrustVC CLI uses an interactive prompt system that automatically extracts the token registry address, token ID (merkle root), and network from your wrapped document. | ||
|
|
||
| To mint the transferable record, simply run the following command: | ||
|
|
||
| ```sh | ||
| tradetrust token-registry mint --address 0x8431012Bc040942B59e3C5bf428221eab0b2f723 --tokenId 0x0d9839a8034cb783d98bd57bcbaafb4dc3614c4193d2edf8a655c1ec6635b7ea --beneficiary 0x6FFeD6E6591b808130a9b248fEA32101b5220eca --holder 0x6FFeD6E6591b808130a9b248fEA32101b5220eca --remark "This is a test remark" --encryptionKey "testEncryptionKey" --network sepolia -f key.txt | ||
| trustvc token-registry mint | ||
| ``` | ||
|
|
||
| Note to replace the following values: | ||
| The CLI will interactively prompt you for: | ||
|
|
||
| - --address: `0x8431012Bc040942B59e3C5bf428221eab0b2f723` with your token registry contract address | ||
| - --tokenId: `0x0d9839a8034cb783d98bd57bcbaafb4dc3614c4193d2edf8a655c1ec6635b7ea` with your merkle root (with a `0x` prefix) | ||
| - --beneficiary: `0x6FFeD6E6591b808130a9b248fEA32101b5220eca` with your owner wallet addresses | ||
| - --holder: `0x6FFeD6E6591b808130a9b248fEA32101b5220eca` with your holder wallet addresses | ||
| - --remark: `This is a test remark` with your mint remark | ||
| - --encryptionKey: `testEncryptionKey` with your encryption key | ||
| 1. **Document path**: Path to your wrapped document file (e.g., `./wrapped-documents/document-1.json`) | ||
| - The CLI automatically extracts the token registry address, token ID, and network from the document | ||
| - Verifies the document signature before proceeding | ||
| 2. **Beneficiary address**: The initial owner/recipient of the document (e.g., `0x6FFeD6E6591b808130a9b248fEA32101b5220eca`) | ||
| 3. **Holder address**: The initial holder of the document (can be the same as beneficiary) | ||
| 4. **Wallet selection**: Choose between encrypted wallet, private key file, or environment variable | ||
| 5. **Remark** (optional, V5 only): Additional remarks to be encrypted and stored with the token | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In official TrustVC CLI documentation, does trustvc token-registry mint always auto-extract token registry address, token ID, and network from wrapped documents? If not, what fallback options/flags are supported?
💡 Result:
No. In the official CLI docs, token-registry mint is documented as a command where you explicitly provide the network, token registry address, and token ID (document hash) as flags—it is not described as auto-extracting those values from a wrapped document. [1]
Fallback / supported inputs (per docs):
- Network:
--network <NETWORK>[1] - Token Registry address:
--address <TOKEN_REGISTRY_ADDRESS>[1] - Token ID (document hash):
--tokenId <TOKEN_ID>[1]
Wallet fallback options supported by the CLI (for blockchain transactions, including mint):
--encrypted-wallet-path <path>(encrypted wallet JSON; recommended)OA_PRIVATE_KEYenvironment variable--key-file <path>(file containing private key)--key <privateKey>(inline private key) [2]
Notes:
mintis documented as equivalent toissue. [1]
Sources
- TradeTrust CLI README (Token Registry → “Mint document to token registry”) https://github.com/TradeTrust/tradetrust-cli/blob/master/README.md
- TradeTrust CLI README (“Providing the wallet”) https://github.com/TradeTrust/tradetrust-cli/blob/master/README.md
Correct the workflow: The CLI does not auto-extract token registry address, token ID, and network from wrapped documents.
The documented workflow (lines 26–43) incorrectly describes how trustvc token-registry mint operates. Per the official TradeTrust CLI documentation, these values must be explicitly provided as command flags:
--network <NETWORK>--address <TOKEN_REGISTRY_ADDRESS>--tokenId <TOKEN_ID>
The command does not automatically extract these from the wrapped document. Update the documentation to show users how to provide these required flags, either through command-line arguments or interactive prompts that request them explicitly (rather than claiming auto-extraction).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/how-tos/open-attestation/transferable-records/issuing-document/issuing-document-cli.mdx`
around lines 26 - 43, The docs wrongly claim the trustvc token-registry mint
command auto-extracts token registry address, tokenId, and network from the
wrapped document; update the workflow text for the trustvc token-registry mint
section to instruct users to pass --network, --address, and --tokenId explicitly
(either as command flags or via interactive prompts that ask for them) and
remove the statement that the CLI automatically extracts those values from the
Document path prompt; reference the command name trustvc token-registry mint and
the flags --network, --address, and --tokenId so users know exactly which inputs
are required.
Comment on lines
+34
to
+36
| ```sh | ||
| export OA_PRIVATE_KEY=d8f30c982fc23245a2cc4ec8271edcb4637f539d490ce750cdb5085241ffb41c | ||
| ``` |
There was a problem hiding this comment.
Do not publish key-like literal values in examples.
Line 35 contains a realistic private key string. Even as sample content, this triggers secret scanning and encourages unsafe copy/paste practices. Use an obvious placeholder instead.
Suggested fix
-export OA_PRIVATE_KEY=d8f30c982fc23245a2cc4ec8271edcb4637f539d490ce750cdb5085241ffb41c
+export OA_PRIVATE_KEY=<YOUR_PRIVATE_KEY_HEX>🧰 Tools
🪛 Gitleaks (8.30.0)
[high] 35-35: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/how-tos/open-attestation/transferable-records/token-registry/token-registry-cli.mdx`
around lines 34 - 36, Replace the hard-coded private key literal in the shell
example for the OA_PRIVATE_KEY environment variable with an obvious placeholder
(e.g. export OA_PRIVATE_KEY="REPLACE_WITH_PRIVATE_KEY" or export
OA_PRIVATE_KEY="<YOUR_PRIVATE_KEY_HERE>") so the token-registry CLI example no
longer contains realistic key-like values; update the code block containing
OA_PRIVATE_KEY to use that placeholder and ensure any surrounding documentation
text mentions that users must supply their own private key.
Comment on lines
+31
to
+44
| The TrustVC library supports both ethers v5 and v6, and provides two types of document stores: | ||
|
|
||
| 1. **Standard Document Store** (default): For immutable documents that cannot be transferred | ||
| 2. **Transferable Document Store**: For documents that can change ownership | ||
|
|
||
| ```ts | ||
| import { DocumentStoreFactory } from "@tradetrust-tt/document-store"; | ||
| import { TransactionReceipt } from "@ethersproject/abstract-provider"; | ||
| import { deployDocumentStore, CHAIN_ID } from "@trustvc/trustvc"; | ||
| import { Wallet, ethers } from "ethers"; | ||
|
|
||
| const unconnectedWallet = new Wallet("privateKey"); | ||
| const provider = new ethers.providers.JsonRpcProvider("http://127.0.0.1:8545"); // Local network | ||
| const wallet = unconnectedWallet.connect(provider); | ||
| const walletAddress = await wallet.getAddress(); | ||
| // Setup wallet and provider | ||
| const wallet = new Wallet("privateKey"); | ||
| const provider = new ethers.JsonRpcProvider("https://sepolia.infura.io/v3/YOUR_INFURA_KEY"); | ||
| const signer = wallet.connect(provider); | ||
| const walletAddress = await signer.getAddress(); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
ethers.js v5 vs v6 JsonRpcProvider constructor API differences
💡 Result:
-
Namespace / import change
- v5:
new ethers.providers.JsonRpcProvider(...)(class lives underethers.providers) [1] - v6:
new ethers.JsonRpcProvider(...)(providers moved fromethers.providers.*toethers.*) [3]
- v5:
-
Constructor signature
- v5:
new ethers.providers.JsonRpcProvider(urlOrConnectionInfo?, networkish?)[1]urlOrConnectionInfocan be a URL string or aConnectionInfoobject;networkishoptional. [1]
- v6:
new JsonRpcProvider(url?: string | FetchRequest, network?: Networkish, options?: JsonRpcApiProviderOptions)[2]- 3rd
optionsparameter is new (batching/polling/static network behavior, etc.). [2]
- 3rd
- v5:
-
“Static” provider behavior
- v5:
StaticJsonRpcProvideris a separate class (for networks that cannot change). [1] - v6:
StaticJsonRpcProvideris folded intoJsonRpcProvidervia thestaticNetworkoption. Example from the migration guide:new JsonRpcProvider(url, network, { staticNetwork: network })ornew JsonRpcProvider(url, undefined, { staticNetwork: true })[3]
- v5:
Quick mapping example
// v5
const p5 = new ethers.providers.JsonRpcProvider(url, network);
// v6
const p6 = new ethers.JsonRpcProvider(url, network); // normal
const p6static = new ethers.JsonRpcProvider(url, network, { staticNetwork: network }); // v5 StaticJsonRpcProvider equivalent🏁 Script executed:
# Check if the file exists and examine the code snippets at the mentioned lines
fd "document-store-code.mdx" --type fRepository: TradeTrust/documentation
Length of output: 305
🏁 Script executed:
# Read the mdx file to examine the code snippets at the mentioned lines
cat -n "docs/how-tos/open-attestation/verifiable-documents/dns-txt/deploying-document-store/document-store-code.mdx" | sed -n '25,100p'Repository: TradeTrust/documentation
Length of output: 3231
Mark these examples as ethers v6, or add a v5 variant.
Line 31 claims the library supports both ethers v5 and v6, but all three code snippets use new ethers.JsonRpcProvider(...), which is v6 syntax. In ethers v5, this should be new ethers.providers.JsonRpcProvider(...). V5 users copying these examples verbatim will encounter errors.
Suggested doc tweak
-The TrustVC library supports both ethers v5 and v6, and provides two types of document stores:
+The TrustVC library supports both ethers v5 and v6.
+
+The examples below use ethers v6 syntax (`ethers.JsonRpcProvider`). If you are using ethers v5, replace it with `ethers.providers.JsonRpcProvider(...)`.
+
+It also provides two types of document stores:Also applies to: 67-73, 95-97
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/deploying-document-store/document-store-code.mdx`
around lines 31 - 44, The snippets currently use ethers v6 syntax (e.g., new
ethers.JsonRpcProvider(...)) but are stated to support both v5 and v6; update
the docs by either labeling these examples explicitly as "ethers v6" or add an
ethers v5 variant that replaces v6-only symbols: in the v5 variant change new
ethers.JsonRpcProvider(...) to new ethers.providers.JsonRpcProvider(...), keep
usage of deployDocumentStore and CHAIN_ID the same, ensure Wallet/signer usage
(Wallet, signer.getAddress()) remains compatible with v5, and mirror this change
in the other snippets referenced (the blocks around the other occurrences).
Comment on lines
+31
to
+54
| The TrustVC library provides a `documentStoreIssue` function that supports both ethers v5 and v6, and automatically detects the document store type (standard, transferable, or legacy TT document store). | ||
|
|
||
| ```ts | ||
| import { DocumentStoreFactory } from "@tradetrust-tt/document-store"; | ||
| import { documentStoreIssue } from "@trustvc/trustvc"; | ||
| import { Wallet, ethers } from "ethers"; | ||
|
|
||
| const unconnectedWallet = new Wallet("privateKey"); | ||
| const provider = new ethers.providers.JsonRpcProvider("http://127.0.0.1:8545"); // Local network | ||
| const wallet = unconnectedWallet.connect(provider); | ||
| const documentStore = DocumentStoreFactory.connect("0x63A223E025256790E88778a01f480eBA77731D04", wallet); | ||
| console.log(`Document Store Name: ${await documentStore.name()}`); // Document Store Name: DemoDocumentStore | ||
| // Setup wallet and provider | ||
| const wallet = new Wallet("privateKey"); | ||
| const provider = new ethers.JsonRpcProvider("https://sepolia.infura.io/v3/YOUR_INFURA_KEY"); | ||
| const signer = wallet.connect(provider); | ||
|
|
||
| // Issue a document hash to the document store | ||
| const tx = await documentStoreIssue( | ||
| "0x63A223E025256790E88778a01f480eBA77731D04", // Document store address | ||
| "0x8dcf358a9436bca6654f565e3c5843d91c0052d3a2eff37bbd380038e8a1fa39", // Document hash (merkle root) | ||
| signer, | ||
| { | ||
| maxFeePerGas: "50000000000", // Optional: EIP-1559 gas settings | ||
| maxPriorityFeePerGas: "2000000000", | ||
| }, | ||
| ); | ||
|
|
||
| const receipt = await tx.wait(); | ||
| console.log(`Document issued in transaction: ${receipt.hash}`); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n docs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-code.mdxRepository: TradeTrust/documentation
Length of output: 6887
🌐 Web query:
TrustVC documentStoreIssue return type API documentation
💡 Result:
In TrustVC, documentStoreIssue(...) returns:
Promise<string>— the transaction hash of the issuance transaction. [1]
Sources:
[1] (github.com)
Citations:
🌐 Web query:
ethers.js v5 vs v6 JsonRpcProvider syntax differences
💡 Result:
Namespace / class name
- v5:
new ethers.providers.JsonRpcProvider(...)(docs.ethers.org) - v6:
new ethers.JsonRpcProvider(...)(providers are exported at the top-levelethersnamespace) (docs.ethers.org)
Constructor signature
- v5:
new JsonRpcProvider(urlOrConnectionInfo?, networkish?)(docs.ethers.org) - v6:
new JsonRpcProvider(urlOrFetchRequest?, networkish?, options?)whereoptionsis aJsonRpcApiProviderOptionsobject (batching, polling,staticNetwork, etc.) (docs.ethers.org)
“Static” provider change
- v5:
StaticJsonRpcProviderexisted as a separate class. - v6:
StaticJsonRpcProviderbehavior is integrated intoJsonRpcProvider(use the v6options.staticNetworkcapability instead of a separate class). (docs.ethers.org)
Side-by-side examples
v5
import { ethers } from "ethers";
const provider = new ethers.providers.JsonRpcProvider(
"https://rpc.example",
{ name: "mainnet", chainId: 1 }
);v6
import { ethers } from "ethers";
const provider = new ethers.JsonRpcProvider(
"https://rpc.example",
{ name: "mainnet", chainId: 1 },
{ staticNetwork: true } // optional
);Citations:
- 1: https://docs.ethers.org/v5/api/providers/jsonrpc-provider?utm_source=openai
- 2: https://docs.ethers.org/v6/api/providers/jsonrpc/?utm_source=openai
- 3: https://docs.ethers.org/v5/api/providers/jsonrpc-provider?utm_source=openai
- 4: https://docs.ethers.org/v6/api/providers/jsonrpc/?utm_source=openai
- 5: https://docs.ethers.org/v6/migrating/?utm_source=openai
- 6: https://docs.ethers.org/v5/api/providers/jsonrpc-provider?utm_source=openai
- 7: https://docs.ethers.org/v6/api/providers/jsonrpc/?utm_source=openai
Fix incorrect API usage in documentStoreIssue example.
The documentStoreIssue function returns a transaction hash string, not a transaction response object. Calling tx.wait() and accessing receipt.hash will fail at runtime. Additionally, ethers.JsonRpcProvider is v6-only syntax; the v5 equivalent is ethers.providers.JsonRpcProvider, so this code does not support both ethers v5 and v6 as documented.
Suggested fix
-const tx = await documentStoreIssue(
+const txHash = await documentStoreIssue(
"0x63A223E025256790E88778a01f480eBA77731D04", // Document store address
"0x8dcf358a9436bca6654f565e3c5843d91c0052d3a2eff37bbd380038e8a1fa39", // Document hash (merkle root)
signer,
{
maxFeePerGas: "50000000000", // Optional: EIP-1559 gas settings
maxPriorityFeePerGas: "2000000000",
},
);
-const receipt = await tx.wait();
-console.log(`Document issued in transaction: ${receipt.hash}`);
+console.log(`Document issued in transaction: ${txHash}`);Also applies to: 65-67 (provider syntax)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/issuing-document/issuing-document-code.mdx`
around lines 31 - 54, The example incorrectly treats documentStoreIssue as
returning a transaction response; update the code using documentStoreIssue(...)
to await a transaction hash string (e.g., const txHash = await
documentStoreIssue(...)) and log that hash directly instead of calling tx.wait()
or accessing receipt.hash. Also fix provider instantiation to be compatible with
both ethers v5 and v6 by using the correct constructor for the version in use
(ethers.providers.JsonRpcProvider for v5 or ethers.JsonRpcProvider for v6) or by
detecting the ethers API and selecting the appropriate provider constructor
before creating the signer (references: documentStoreIssue, tx/txHash, Wallet,
signer, ethers.JsonRpcProvider, ethers.providers.JsonRpcProvider).
Comment on lines
+24
to
+37
| The TrustVC CLI uses an interactive prompt system that automatically extracts the document store address, target hash, and network from your wrapped document. | ||
|
|
||
| ```bash | ||
| tradetrust document-store revoke --address 0xBBb55Bd1D709955241CAaCb327A765e2b6D69c8b --hash 0x1e0c5e93c04032ed6571b31c785b963f0a27776041f35bdcc98cd8dfe073adc0 --network sepolia --encrypted-wallet-path wallet.json | ||
| trustvc document-store revoke | ||
| ``` | ||
|
|
||
| In the example above: | ||
| The CLI will interactively prompt you for: | ||
|
|
||
| 1. **Document path**: Path to the wrapped document file (JSON) | ||
| - The CLI automatically extracts the document store address, target hash, and network from the document | ||
| - Verifies the document signature before proceeding | ||
| 2. **Wallet selection**: Choose between encrypted wallet, private key file, or environment variable | ||
|
|
||
| - `--address` is the document store address, for instance the one created with the [Deploying Document Store](/docs/how-tos/open-attestation/verifiable-documents/dns-txt/deploying-document-store/document-store-cli) guide. | ||
| - `--hash` is the value of `targetHash` field of one of the [previously wrapped documents](/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli) (open one of the file, head to the bottom and check for the `targetHash` in the `signature` object. | ||
| > **Note**: The hash used for revocation is the `targetHash` field from the wrapped document (found in the `signature` object at the bottom of the file). You can revoke using either the `targetHash` (revokes single document) or `merkleRoot` (revokes entire batch). |
There was a problem hiding this comment.
Explain how batch revocation selects merkleRoot.
Line 24 says the CLI auto-extracts targetHash from the wrapped document, but Line 37 tells readers they can revoke a whole batch with merkleRoot. The prompt flow shown here never documents a flag or prompt that overrides the extracted hash, so the later multi-document path is not reproducible from this page.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-cli.mdx`
around lines 24 - 37, The docs mention both targetHash and merkleRoot but don't
explain how to choose batch revocation; update the CLI flow for the "trustvc
document-store revoke" command to show how to override the extracted targetHash
and select merkleRoot (either by documenting the interactive prompt choice
"Revoke type: [single|batch]" and instructing the user to paste the merkleRoot
when "batch" is chosen, or by documenting the CLI flag that accepts a merkle
root such as --merkle-root/--hash-type). Reference the existing "Document path"
prompt (which auto-extracts targetHash) and explicitly state the new step or
flag that lets users select "merkleRoot" to revoke an entire batch.
Comment on lines
+31
to
+54
| The TrustVC library provides a `documentStoreRevoke` function that supports both ethers v5 and v6, and automatically detects the document store type (standard, transferable, or legacy TT document store). | ||
|
|
||
| ```ts | ||
| import { DocumentStoreFactory } from "@tradetrust-tt/document-store"; | ||
| import { documentStoreRevoke } from "@trustvc/trustvc"; | ||
| import { Wallet, ethers } from "ethers"; | ||
|
|
||
| const unconnectedWallet = new Wallet("privateKey"); | ||
| const provider = new ethers.providers.JsonRpcProvider("http://127.0.0.1:8545"); // Local network | ||
| const wallet = unconnectedWallet.connect(provider); | ||
| // Setup wallet and provider | ||
| const wallet = new Wallet("privateKey"); | ||
| const provider = new ethers.JsonRpcProvider("https://sepolia.infura.io/v3/YOUR_INFURA_KEY"); | ||
| const signer = wallet.connect(provider); | ||
|
|
||
| // Revoke a document hash from the document store | ||
| const tx = await documentStoreRevoke( | ||
| "0x63A223E025256790E88778a01f480eBA77731D04", // Document store address | ||
| "0x8dcf358a9436bca6654f565e3c5843d91c0052d3a2eff37bbd380038e8a1fa39", // Document hash (targetHash) | ||
| signer, | ||
| { | ||
| maxFeePerGas: "50000000000", // Optional: EIP-1559 gas settings | ||
| maxPriorityFeePerGas: "2000000000", | ||
| }, | ||
| ); | ||
|
|
||
| const documentStore = DocumentStoreFactory.connect("0x63A223E025256790E88778a01f480eBA77731D04", wallet); | ||
| console.log(`Document Store Name: ${await documentStore.name()}`); // Document Store Name: DemoDocumentStore | ||
| const receipt = await tx.wait(); | ||
| console.log(`Document revoked in transaction: ${receipt.hash}`); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
TrustVC documentStoreRevoke return type transaction
💡 Result:
In TrustVC (@trustvc/trustvc), documentStoreRevoke(...) returns a transaction hash, not an ethers TransactionResponse / TransactionReceipt.
- Return type:
Promise<string> - Returned value: the revocation transaction hash (e.g.
"0x...") (github.com)
Citations:
🏁 Script executed:
# Check the full file to see all code examples and context
fd "revoking-document-code.mdx" --type fRepository: TradeTrust/documentation
Length of output: 297
🌐 Web query:
ethers.js v5 v6 JsonRpcProvider constructor differences
💡 Result:
Constructor signature
-
v5
new ethers.providers.JsonRpcProvider(urlOrConnectionInfo?, networkish?)
urlOrConnectionInfocan be a URL string or aConnectionInfo; if omitted defaults tohttp://localhost:8545. Network is auto-detected if omitted. [1]
-
v6
new ethers.JsonRpcProvider(url?: string | FetchRequest, network?: Networkish, options?: JsonRpcApiProviderOptions)
- Moved from
ethers.providers.*toethers.* urlcan be a string orFetchRequest- New third param:
options(batching, polling, cache, etc.), includingstaticNetwork. [2][3]
- Moved from
Static network / StaticJsonRpcProvider
- v5: separate class
StaticJsonRpcProvider(url, network)(caches chainId / avoids repeated network checks). [1] - v6: integrated into
JsonRpcProviderviaoptions.staticNetwork:- If you know the network:
new JsonRpcProvider(url, network, { staticNetwork: network })
- If you want auto-detect once:
new JsonRpcProvider(url, undefined, { staticNetwork: true })
{ staticNetwork: network }.) [4] - If you know the network:
🏁 Script executed:
# Read the file to see the exact code at lines 31-54 and check the "Also applies to: 65-67" reference
head -n 70 "docs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-code.mdx" | tail -n 40Repository: TradeTrust/documentation
Length of output: 1551
🏁 Script executed:
# Also check the versioned docs file to see if it has the same issue
head -n 70 "versioned_docs/version-4.x/tutorial/verifiable-documents/advanced/document-store/revoking-document/revoking-document-code.mdx" | tail -n 40Repository: TradeTrust/documentation
Length of output: 2307
Fix the documentStoreRevoke call—it returns a transaction hash string, not a transaction response.
documentStoreRevoke returns Promise<string> (the revocation transaction hash), not a transaction response, so tx.wait() will throw a TypeError. Store the result as txHash and log it directly.
Also note: the example uses ethers v6 syntax (ethers.JsonRpcProvider). If v5 support is intended, show the v5 equivalent (ethers.providers.JsonRpcProvider).
Suggested fix
-const tx = await documentStoreRevoke(
+const txHash = await documentStoreRevoke(
"0x63A223E025256790E88778a01f480eBA77731D04", // Document store address
"0x8dcf358a9436bca6654f565e3c5843d91c0052d3a2eff37bbd380038e8a1fa39", // Document hash (targetHash)
signer,
{
maxFeePerGas: "50000000000", // Optional: EIP-1559 gas settings
maxPriorityFeePerGas: "2000000000",
},
);
-const receipt = await tx.wait();
-console.log(`Document revoked in transaction: ${receipt.hash}`);
+console.log(`Document revoked in transaction: ${txHash}`);📝 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.
Suggested change
| The TrustVC library provides a `documentStoreRevoke` function that supports both ethers v5 and v6, and automatically detects the document store type (standard, transferable, or legacy TT document store). | |
| ```ts | |
| import { DocumentStoreFactory } from "@tradetrust-tt/document-store"; | |
| import { documentStoreRevoke } from "@trustvc/trustvc"; | |
| import { Wallet, ethers } from "ethers"; | |
| const unconnectedWallet = new Wallet("privateKey"); | |
| const provider = new ethers.providers.JsonRpcProvider("http://127.0.0.1:8545"); // Local network | |
| const wallet = unconnectedWallet.connect(provider); | |
| // Setup wallet and provider | |
| const wallet = new Wallet("privateKey"); | |
| const provider = new ethers.JsonRpcProvider("https://sepolia.infura.io/v3/YOUR_INFURA_KEY"); | |
| const signer = wallet.connect(provider); | |
| // Revoke a document hash from the document store | |
| const tx = await documentStoreRevoke( | |
| "0x63A223E025256790E88778a01f480eBA77731D04", // Document store address | |
| "0x8dcf358a9436bca6654f565e3c5843d91c0052d3a2eff37bbd380038e8a1fa39", // Document hash (targetHash) | |
| signer, | |
| { | |
| maxFeePerGas: "50000000000", // Optional: EIP-1559 gas settings | |
| maxPriorityFeePerGas: "2000000000", | |
| }, | |
| ); | |
| const documentStore = DocumentStoreFactory.connect("0x63A223E025256790E88778a01f480eBA77731D04", wallet); | |
| console.log(`Document Store Name: ${await documentStore.name()}`); // Document Store Name: DemoDocumentStore | |
| const receipt = await tx.wait(); | |
| console.log(`Document revoked in transaction: ${receipt.hash}`); | |
| The TrustVC library provides a `documentStoreRevoke` function that supports both ethers v5 and v6, and automatically detects the document store type (standard, transferable, or legacy TT document store). | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/how-tos/open-attestation/verifiable-documents/dns-txt/revoking-document/revoking-document-code.mdx`
around lines 31 - 54, The example incorrectly treats documentStoreRevoke as
returning a TransactionResponse; update the call to capture the returned
transaction hash (e.g., const txHash = await documentStoreRevoke(...)) and
remove the tx.wait() call, then log the txHash directly; additionally clarify
the provider syntax by showing the ethers v6 provider (ethers.JsonRpcProvider)
used in the snippet and, if v5 compatibility is desired, show the v5 equivalent
(ethers.providers.JsonRpcProvider) as an alternative so readers know which
constructor to use.
Comment on lines
+251
to
264
| trustvc title-escrow nominate-transfer-owner | ||
|
|
||
| ? Enter the path to the wrapped document: ./wrapped-documents/document-1.json | ||
| ℹ info Document signature verified successfully | ||
| ? Enter the beneficiary address: <ALICE_ADDRESS> | ||
| ? Select wallet type: Encrypted Wallet JSON | ||
| ? Enter the path to your encrypted wallet JSON file: ./wallet.json | ||
| ? Enter your wallet password: [hidden] | ||
| ? Enter a remark (optional): <REMARK_STRING> | ||
|
|
||
| ℹ info Connecting to the registry and attempting to nominate the change of owner... | ||
| ⠋ awaiting Waiting for transaction 0x... to be mined | ||
| ✔ success Transferable record's holder has been successfully nominated to new owner with address <ALICE_ADDRESS> | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
`For the latest TrustVC CLI documentation, what are the exact success/output messages for:
trustvc title-escrow nominate-transfer-ownertrustvc title-escrow endorse-transfer-owner
Do these commands report owner changes, holder changes, or both?`
💡 Result:
1) trustvc title-escrow nominate-transfer-owner — success/output message
I couldn’t find any published TrustVC CLI docs that contain the nominate-transfer-owner command string. The closest “latest” public CLI docs in the TrustVC/TradeTrust ecosystem document the same action under nominate-change-owner, with this exact success line:
✔ success Transferable record with hash <TOKEN_ID>'s holder has been successfully nominated to new owner with address: <NEW_OWNER_ADDRESS> [1][2]
Does it report owner changes, holder changes, or both?
- It reports an owner nomination (i.e., a proposed/new owner), and does not report a holder change (the on-chain holder/owner state does not change just from nomination). [2]
2) trustvc title-escrow endorse-transfer-owner — success/output message
The publicly documented exact success line (same action name: endorse-transfer-owner) is:
✔ success Transferable record with hash <TOKEN_ID>'s holder has been successfully endorsed to approved beneficiary at <NEW_BENEFICIARY_ADDRESS> [1][2]
Does it report owner changes, holder changes, or both?
- It reports an ownership/beneficiary (owner) transfer endorsement, and does not report a holder change. Despite the message wording (“holder has been…”), this command is documented as endorsing the approved beneficiary/owner. [1][2]
Sources: OpenAttestation CLI docs (archived but still published) [1]; TradeTrust CLI docs (also published, positioned as developer tooling around TrustVC) [2].
🏁 Script executed:
# First, find the file in the repository
find . -type f -name "title-transfer-example.md" | head -5Repository: TradeTrust/documentation
Length of output: 254
🏁 Script executed:
# Once found, read the specific lines mentioned in the review
wc -l ./docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.mdRepository: TradeTrust/documentation
Length of output: 162
🏁 Script executed:
# Read lines 251-264 to see the exact content
sed -n '251,264p' ./docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.mdRepository: TradeTrust/documentation
Length of output: 757
🏁 Script executed:
# Read lines 295-308 to see the second location mentioned
sed -n '295,308p' ./docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.mdRepository: TradeTrust/documentation
Length of output: 759
🏁 Script executed:
# Get more context around these lines to understand the structure
sed -n '240,320p' ./docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.mdRepository: TradeTrust/documentation
Length of output: 2767
The success message terminology is confusing and should be clarified or corrected.
Both nominate-transfer-owner (line 257) and endorse-transfer-owner (line 303) show success messages that reference "holder," but the surrounding documentation correctly describes these as owner/ownership changes. The commands nominate and endorse changes to the owner, not the token holder. The success text should either:
- Use "owner" instead of "holder" for consistency with the operation being performed, or
- Add a clarifying note that "holder" in the CLI output refers to the ownership relationship being transferred.
This terminology mismatch creates confusion about what state is actually changing during these operations.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/introduction/key-components-of-tradetrust/transferability/title-transfer-example.md`
around lines 251 - 264, Update the CLI success output for the title-escrow
transfer commands to use "owner" (not "holder") or add an explicit clarifying
note; specifically modify the success message emitted by the
nominate-transfer-owner command and the endorse-transfer-owner command (the
strings that currently read "Transferable record's holder has been successfully
nominated to new owner..." and similar) so they reference "owner" consistently
with the documented operation, or append a short parenthetical clarifier that
"holder" in this output refers to ownership, then run the CLI to verify both
commands' success messages match the docs.
Comment on lines
+59
to
76
| The TrustVC CLI uses an interactive prompt system: | ||
|
|
||
| ```bash | ||
| trustvc title-escrow transfer-owner-holder | ||
|
|
||
| ? Enter the path to the wrapped document: ./wrapped-documents/document-1.json | ||
| ℹ info Document signature verified successfully | ||
| ? Enter the new owner address: <CHARLIE_ADDRESS> | ||
| ? Enter the new holder address: <CHARLIE_ADDRESS> | ||
| ? Select wallet type: Encrypted Wallet JSON | ||
| ? Enter the path to your encrypted wallet JSON file: ./wallet.json | ||
| ? Enter your wallet password: [hidden] | ||
| ? Enter a remark (optional): <REMARK_STRING> | ||
|
|
||
| ℹ info Connecting to the registry and attempting to endorse the change of owner... | ||
| ⠋ awaiting Waiting for transaction 0x... to be mined | ||
| ✔ success Transferable record's holder has been successfully endorsed to new owner and holder | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
`What is the latest TrustVC CLI version, and are these subcommands still valid in that version:
- trustvc title-escrow transfer-owner-holder
- trustvc title-escrow reject-transfer-owner-holder
- trustvc title-escrow transfer-holder
- trustvc title-escrow reject-transfer-holder
- trustvc title-escrow nominate-transfer-owner
- trustvc title-escrow endorse-transfer-owner
- trustvc title-escrow reject-transfer-owner
- trustvc title-escrow return-to-issuer
- trustvc title-escrow accept-return-to-issuer
- trustvc title-escrow reject-return-to-issuer`
💡 Result:
Latest TrustVC CLI version
The latest published TrustVC CLI package is @trustvc/w3c-cli v1.2.18. [1]
That CLI is the w3c-cli command, and its own README explicitly marks it as deprecated and documents only these commands: key-pair, did, sign, verify, credential-status create|update—no title-escrow commands. [2]
Are your trustvc title-escrow ... subcommands still valid in that version?
No. In @trustvc/w3c-cli v1.2.18, none of the listed title-escrow subcommands are valid, because that CLI does not include a title-escrow command at all. [2]
What to use instead (TradeTrust CLI equivalents)
If what you want is Title Escrow / Token Registry operations, the current docs show these under the TradeTrust CLI (tradetrust title-escrow ...). The closest equivalents to your list are: [3]
trustvc title-escrow transfer-owner-holder→tradetrust title-escrow endorse-change-owner[3]trustvc title-escrow reject-transfer-owner-holder→tradetrust title-escrow reject-transfer-owner-holder[3]trustvc title-escrow transfer-holder→tradetrust title-escrow change-holder[3]trustvc title-escrow reject-transfer-holder→tradetrust title-escrow reject-transfer-holder[3]trustvc title-escrow nominate-transfer-owner→tradetrust title-escrow nominate-change-owner[3]trustvc title-escrow endorse-transfer-owner→tradetrust title-escrow endorse-transfer-owner[3]trustvc title-escrow reject-transfer-owner→tradetrust title-escrow reject-transfer-owner[3]trustvc title-escrow return-to-issuer→tradetrust title-escrow return-to-issuer[3]trustvc title-escrow accept-return-to-issuer→tradetrust title-escrow accept-returned[3]trustvc title-escrow reject-return-to-issuer→tradetrust title-escrow reject-returned[3]
Sources: TrustVC W3C CLI on npm (version) [1], TrustVC/w3c-cli README (deprecated + command list) [2], TradeTrust “Perform Transactions” docs (title-escrow commands) [3].
🏁 Script executed:
# Check the actual file content to see which CLI tool names are used
file_path="docs/introduction/key-components-of-tradetrust/transferability/transactions.md"
# Check if file exists and read sections around the mentioned line ranges
echo "=== Checking lines 59-76 ==="
sed -n '59,76p' "$file_path"
echo -e "\n=== Checking lines 106-121 ==="
sed -n '106,121p' "$file_path"
echo -e "\n=== Checking lines 1-30 for overall context ==="
sed -n '1,30p' "$file_path"
# Count occurrences of trustvc vs tradetrust in the file
echo -e "\n=== CLI tool name occurrences ==="
echo "trustvc occurrences:"
rg "trustvc" "$file_path" | wc -l
echo "tradetrust occurrences:"
rg "tradetrust" "$file_path" | wc -lRepository: TradeTrust/documentation
Length of output: 2934
Replace trustvc CLI with tradetrust CLI throughout the file.
The documented commands use trustvc title-escrow ..., but the TrustVC CLI (v1.2.18, the latest published version) is deprecated and does not include a title-escrow command. These commands exist in the TradeTrust CLI instead, under tradetrust title-escrow .... Change all 17 instances of trustvc in this file to tradetrust to match the correct CLI tool.
This affects all line ranges mentioned (59-76, 106-121, 154-170, 200-215, 248-264, 292-308, 332-347, 371-387, 408-581).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/introduction/key-components-of-tradetrust/transferability/transactions.md`
around lines 59 - 76, This file documents CLI commands using the deprecated
"trustvc" binary; replace every occurrence of the CLI token "trustvc" (e.g., the
command string "trustvc title-escrow transfer-owner-holder" and other "trustvc
..." examples) with "tradetrust" so the examples become "tradetrust title-escrow
...". Update all 17 instances in the document, ensuring interactive examples,
help/usage snippets and any inline command references consistently use
"tradetrust" instead of "trustvc".
|
|
||
| ```bash | ||
| w3c-cli sign | ||
| trustvc w3c w3c-sign |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Search for other occurrences of trustvc CLI commands in the docs to verify naming pattern consistency.
# Check for patterns of trustvc commands across the documentation
rg -n "trustvc w3c" --type md --type mdx -g "*.mdx" | head -30Repository: TradeTrust/documentation
Length of output: 95
🏁 Script executed:
#!/bin/bash
# Read the specific file and show context around line 35
echo "=== File content around line 35 ==="
sed -n '30,40p' docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdx
echo ""
echo "=== Searching for trustvc commands in mdx files ==="
# Search for trustvc commands in all mdx files
rg -n "trustvc" docs/ -g "*.mdx" | grep -E "(trustvc\s+\w+\s+\w+)" | head -20Repository: TradeTrust/documentation
Length of output: 1497
🏁 Script executed:
#!/bin/bash
# Search for CLI package or command definitions
echo "=== Looking for CLI package or implementation ==="
find docs -name "*README*" -o -name "*cli*" | grep -i readme | head -10
echo ""
echo "=== Searching for `@trustvc/trustvc-cli` references ==="
rg "@trustvc/trustvc-cli" docs/ -g "*.mdx" -B2 -A2
echo ""
echo "=== Check if there's a commands reference or CLI help documentation ==="
rg "w3c-sign|key-pair-generation" docs/ -g "*.mdx" -B1 -A1Repository: TradeTrust/documentation
Length of output: 2235
🏁 Script executed:
#!/bin/bash
# Search for package.json or CLI package references
echo "=== Looking for package.json files ==="
find . -name "package.json" -type f | head -10
echo ""
echo "=== Search for all w3c subcommands in documentation ==="
rg "trustvc w3c" docs/ -g "*.mdx" --no-heading
echo ""
echo "=== Look for any upstream trustvc references or URLs ==="
rg "trustvc.io|github.com.*trustvc" docs/ -g "*.mdx" | head -10Repository: TradeTrust/documentation
Length of output: 2242
🌐 Web query:
trustvc-cli w3c w3c-sign command documentation github
💡 Result:
w3c-sign doesn’t appear to be the actual command name in TrustVC’s CLI docs; the documented W3C VC signing command is:
- Install:
npm install -g@trustvc/w3c-cli`` - Sign:
w3c-cli sign(it interactively asks for your key-pair JSON, VC JSON, and an output directory, then writes something likesigned_vc.json). [1]
Reference docs:
- TradeTrust “Signing Documents (CLI)” (covers install +
w3c-cli signwalkthrough). [1] - npm package page for
@trustvc/w3c-cli(describes the CLI and that it signs VCs usingsignCredential). [2]
GitHub (related implementation/library):
TrustVC/trustvcrepository (wrapper library; includes thesignW3Cfunction for W3C VC signing in code). [3]
Sources: [1] [2] [3]
🏁 Script executed:
#!/bin/bash
# Read broader context from the file to see all mentions
sed -n '20,65p' docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdxRepository: TradeTrust/documentation
Length of output: 1755
Correct the package name and CLI command syntax.
Line 26 should install @trustvc/w3c-cli (not @trustvc/trustvc-cli), and line 35 should use the command w3c-cli sign (not trustvc w3c w3c-sign). The referenced command on line 54 also needs correction to align with the correct CLI structure. Additionally, on line 60, wrap signW3C and @trustvc/trustvc in inline code formatting for consistency.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/introduction/key-components-of-tradetrust/w3c-vc/signing-documents/signing-document-cli.mdx`
at line 35, Replace the incorrect package and CLI command names: change the
install package from `@trustvc/trustvc-cli` to `@trustvc/w3c-cli`, replace
occurrences of the command trustvc w3c w3c-sign with the correct CLI invocation
w3c-cli sign (also update the other referenced command to use w3c-cli sign), and
wrap the identifiers signW3C and `@trustvc/trustvc` in inline code formatting for
consistency.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix: Update with TrustVC Commands
Description
This PR updates the documentation to use TrustVC CLI commands across various guides and tutorials. The changes ensure consistency in command references and improve clarity for users working with both W3C Verifiable Credentials and OpenAttestation documents.
Changes Made
Files Modified
Key areas updated:
Summary by CodeRabbit
Documentation