feat(contract-dev): edit jetton processing guide to fit style guide.#2125
Open
feat(contract-dev): edit jetton processing guide to fit style guide.#2125
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughReframes the on-chain jetton processing doc around verification of Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@contract-dev/techniques/on-chain-jetton-processing.mdx`:
- Line 12: The sentence contains a typo "a contracts must verify" in the
JettonNotify warning; update the wording to be grammatically correct and clear
(e.g., change to "a contract must verify" or "contracts must verify") so the
security note about verifying that a JettonNotify comes from the correct jetton
wallet address reads cleanly; ensure the terms JettonNotify and jetton wallet
address remain unchanged.
- Line 101: The phrase saying a jetton wallet "shares an owner" with the
receiving contract is inaccurate; update the wording around
SetTrustedJettonWallet to state that the trusted jetton wallet must be the
jetton wallet derived for the receiving contract's address (i.e., the jetton
wallet whose owner is the receiving contract address), not the contract's
admin/owner, and replace the ambiguous language with this precise explanation
and a link/reference to the TON Docs find jetton wallet procedure.
- Around line 223-224: The wording is inaccurate: TEP-89 defines internal
messages named provide_wallet_address and take_wallet_address (not get-methods),
so update the sentence to say "TEP-89 defines the internal messages
provide_wallet_address and take_wallet_address" and change any "get-methods"
reference to "internal messages"; also correct agreement from "platform such as
DeDust only allows them" to plural "platforms such as DeDust only allow them" to
match plural "platforms".
- Around line 119-121: The InitContract flow must attach enough TON to fund the
TEP-89 response so the minter can call take_wallet_address; update the
docs/examples around InitContract and the ProvideWalletAddress call (which uses
SEND_MODE_CARRY_ALL_REMAINING_MESSAGE_VALUE) to explicitly state and show that
sufficient value is included, otherwise take_wallet_address will fail and
jettonWalletAddress remains unset; reference InitContract, ProvideWalletAddress,
take_wallet_address, jettonWalletAddress and TEP-89 in the clarification so
readers know where to add the funds.
- Around line 22-29: The table row labeled "TEP-89 compatibility" should be
renamed to something like "TEP-89 required" or "Requires TEP-89" to avoid
implying incompatibility, and update the three column values so they indicate
whether the approach requires TEP-89 (e.g., Manual management: No, Automatic
discovery: Yes, Get-method emulation: No); update any adjacent explanatory text
in the sections "Manual management", "Automatic discovery", and "Get-method
emulation" to clarify that TEP-89-compatible jettons can still be used with the
first and third approaches even though they don’t require TEP-89.
- Around line 279-288: Update the wording around validating StateInit in the
JettonNotify flow to clarify that hashing a supplied StateInit only proves the
initial state (not necessarily the current code/data used by
get_wallet_address/calculateJettonWallet) and therefore this low-trust path must
require a current-state proof (or on-chain proof of code/data) unless the guide
explicitly states the minter is immutable; mention JettonNotify, StateInit,
jettonMinter, get_wallet_address and calculateJettonWallet by name and add a
short note linking to TON upgrade/address derivation concepts so readers know to
require a current state proof when they don’t control the minter.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 7aa9e7a2-bad2-490c-8389-cdd2cdbfcc95
📒 Files selected for processing (1)
contract-dev/techniques/on-chain-jetton-processing.mdx
There was a problem hiding this comment.
Pull request overview
Updates the “On-chain jetton processing” technique doc to better match the documentation style guide (closes #2117), including callout formatting, restructured sections, and refreshed diagrams.
Changes:
- Standardizes callouts using
<Aside type="...">and rewrites the intro for clearer guidance. - Reorganizes the content into three verification approaches with a comparison table.
- Replaces/updates diagrams and code block titles to improve readability.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This comment was marked as off-topic.
This comment was marked as off-topic.
aigerimu
reviewed
Apr 30, 2026
aigerimu
reviewed
Apr 30, 2026
aigerimu
reviewed
Apr 30, 2026
Contributor
|
imho, making the headings more accessible for a broader audience is a good idea, but they become too broad and lose important specificity |
Collaborator
Author
@aigerimu Fair. I added a comparison table with section links at the beginning to account for specificity. |
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
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.
Closes #2117.
Summary by CodeRabbit