Conversation
WalkthroughAdded new vendor documentation page for Hinkal, a ZK-enabled smart-contract system enabling private stablecoin settlements across multiple blockchains. The page outlines architecture patterns, privacy mechanisms, use cases, technical specifications, and associated risks. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 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)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hinkal`:
- Around line 11-12: The paragraph starting "Hinkal is a smart contract..."
contains grammatical errors: change the phrase "enables to send, receive and
operate in stablecoins" to "enables users to send, receive, and operate in
stablecoins" (or similar correct phrasing), and correct typos elsewhere such as
"remmitances" → "remittances" and "paymenents" → "payments"; scan the rest of
the document for similar spelling/grammar issues and apply consistent
punctuation (e.g., Oxford comma) and capitalization fixes to ensure the text
reads cleanly.
- Around line 7-13: Replace promotional claims in the Hinkal README (phrases
like "complete confidentiality", "under 3 seconds", "6 independent security
audits + 3yr uptime") with neutral, source-backed language: either add inline
citations to verifiable sources for each factual claim or reword to a factual,
non-marketing statement (e.g., describe the feature or measured performance
without superlatives or exact numbers unless sourced). Apply the same treatment
to the other promotional lines noted (lines referenced as 61-67) and ensure each
replaced phrase references a source or is phrased as a neutral
capability/feature description.
- Around line 1-5: The vendor page titled "Vendor: Hinkal" is not being picked
up by validation because validateAllVendors() only scans .md files under the
vendors directory; move/rename this document into the vendors directory as
hinkal.md so it becomes a .md file under vendors/ and is included by
validateAllVendors(), then update any internal links/references to the new
location and ensure frontmatter remains intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| --- | ||
| title: "Vendor: Hinkal" | ||
| status: draft | ||
| maturity: production | ||
| --- |
There was a problem hiding this comment.
Move this document to vendors/hinkal.md so it is actually validated.
validateAllVendors() only scans .md files in vendors/. In the current location/name, this page is skipped by vendor validation automation.
Suggested fix
- hinkal
+ vendors/hinkal.md🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@hinkal` around lines 1 - 5, The vendor page titled "Vendor: Hinkal" is not
being picked up by validation because validateAllVendors() only scans .md files
under the vendors directory; move/rename this document into the vendors
directory as hinkal.md so it becomes a .md file under vendors/ and is included
by validateAllVendors(), then update any internal links/references to the new
location and ensure frontmatter remains intact.
| # Hinkal - ZK-powered smart contract for private stablecoin settlements on EVM, Solana and Tron | ||
|
|
||
| ## What it is | ||
|
|
||
| Hinkal is a smart contract on public chains that lets users hold private balances controlled through their existing wallet keys. This enables to send, receive and operate in stablecoins with complete confidentiality, | ||
| without changing chains or custody. Through zero-knowledge proofs, every transaction is proven valid and verifiable on public chains, while participants and amounts stay private. Via viewing keys, users can selectively | ||
| disclose transaction history to preserve auditability. And for compliance, Chainalysis KYT screens wallet addresses before execution to prevent high-risk funds from entering the smart contract. |
There was a problem hiding this comment.
Replace promotional claims with neutral, source-backed wording.
Several lines read as marketing copy (e.g., “complete confidentiality”, “under 3 seconds”, “6 independent security audits + 3yr uptime”). In this KB, these should be either sourced inline or rewritten to neutral factual language.
Example neutral rewrite
- # Hinkal - ZK-powered smart contract for private stablecoin settlements on EVM, Solana and Tron
+ # Hinkal - ZK-enabled private settlement system for stablecoins on EVM, Solana, and Tron
- This enables to send, receive and operate in stablecoins with complete confidentiality,
+ This enables sending, receiving, and operating in stablecoins with confidentiality properties defined by its protocol design,
- - Instant processing. Confidential transactions are executed in under 3 seconds
- - 6 independent security audits + 3yr uptime.
+ - Processing latency and throughput depend on chain conditions and relayer/prover setup.
+ - Security posture is documented via published audits and operational history.Also applies to: 61-67
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@hinkal` around lines 7 - 13, Replace promotional claims in the Hinkal README
(phrases like "complete confidentiality", "under 3 seconds", "6 independent
security audits + 3yr uptime") with neutral, source-backed language: either add
inline citations to verifiable sources for each factual claim or reword to a
factual, non-marketing statement (e.g., describe the feature or measured
performance without superlatives or exact numbers unless sourced). Apply the
same treatment to the other promotional lines noted (lines referenced as 61-67)
and ensure each replaced phrase references a source or is phrased as a neutral
capability/feature description.
| Hinkal is a smart contract on public chains that lets users hold private balances controlled through their existing wallet keys. This enables to send, receive and operate in stablecoins with complete confidentiality, | ||
| without changing chains or custody. Through zero-knowledge proofs, every transaction is proven valid and verifiable on public chains, while participants and amounts stay private. Via viewing keys, users can selectively |
There was a problem hiding this comment.
Fix grammar and spelling errors before merge.
Line 11 uses incorrect phrasing (“enables to send”), and Line 48 has typos (“remmitances”, “paymenents”).
Suggested edits
- This enables to send, receive and operate in stablecoins with complete confidentiality,
+ This enables users to send, receive, and operate in stablecoins with confidentiality,
- - **Payroll, remmitances and invoicing**: private salary, contractor and vendor paymenents.
+ - **Payroll, remittances, and invoicing**: private salary, contractor, and vendor payments.Also applies to: 48-48
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@hinkal` around lines 11 - 12, The paragraph starting "Hinkal is a smart
contract..." contains grammatical errors: change the phrase "enables to send,
receive and operate in stablecoins" to "enables users to send, receive, and
operate in stablecoins" (or similar correct phrasing), and correct typos
elsewhere such as "remmitances" → "remittances" and "paymenents" → "payments";
scan the rest of the document for similar spelling/grammar issues and apply
consistent punctuation (e.g., Oxford comma) and capitalization fixes to ensure
the text reads cleanly.
There was a problem hiding this comment.
♻️ Duplicate comments (3)
hinkal.md (3)
61-67:⚠️ Potential issue | 🟠 MajorRemove unsourced performance/security marketing claims in strengths.
“Instant processing… under 3 seconds” and “Mature and audited” are promotional unless backed by verifiable references and scope (network, conditions, audit links/dates). Reword neutrally or add citations.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hinkal.md` around lines 61 - 67, Remove or neutralize unsourced marketing claims "Instant processing. Confidential transactions are executed in under 3 seconds" and "Mature and audited" in the strengths list; either delete those lines or reword them to a verifiable, conditional statement (e.g., "Low-latency processing under certain conditions" and "Underwent security audits" ) and, if keeping a claim, add precise citations (audit reports, dates, scope, or benchmark sources) next to the corresponding phrases to substantiate them.
1-5:⚠️ Potential issue | 🟠 MajorMove this page to
vendors/hinkal.mdso vendor validation picks it up.This file is still outside the vendor docs directory used by the validation pipeline, so schema/section checks can be skipped.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hinkal.md` around lines 1 - 5, The file hinkal.md containing the frontmatter title "Vendor: Hinkal" must be relocated into the vendor docs directory so the validation pipeline picks it up; move the Markdown file into the vendors/ directory (rename/move hinkal.md to vendors/hinkal.md), and after moving, update any internal references or links that pointed to the old location so schema/section checks will run against the moved file.
7-13:⚠️ Potential issue | 🟠 MajorReplace promotional/absolute claims with neutral, source-backed wording.
Phrases like “ZK-powered,” privacy guarantees stated as absolute outcomes, and the KYT/compliance statement should be either cited inline or rewritten as neutral capability statements. Also fix grammar at Line 11 (“This enables to send…”).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hinkal.md` around lines 7 - 13, Replace promotional/absolute wording in the Hinkal description: change "ZK-powered" to a neutral phrase like "uses zero-knowledge proofs" (or similar), rephrase absolute privacy claims into conditional/caveated capabilities (e.g., "enables confidential transactions when proofs are used" or "aims to preserve privacy subject to protocol limits"), and rewrite the KYT/compliance line to indicate optional/integrated screening (e.g., "can integrate Chainalysis KYT to screen addresses" or "may screen addresses for compliance") with an inline citation placeholder; also fix the grammar in "This enables to send, receive and operate in stablecoins" to "This enables users to send, receive, and operate in stablecoins." Target the phrases "ZK-powered", "This enables to send, receive and operate in stablecoins confidentially", and the KYT sentence for these edits and add citation markers where claims are retained.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@hinkal.md`:
- Around line 61-67: Remove or neutralize unsourced marketing claims "Instant
processing. Confidential transactions are executed in under 3 seconds" and
"Mature and audited" in the strengths list; either delete those lines or reword
them to a verifiable, conditional statement (e.g., "Low-latency processing under
certain conditions" and "Underwent security audits" ) and, if keeping a claim,
add precise citations (audit reports, dates, scope, or benchmark sources) next
to the corresponding phrases to substantiate them.
- Around line 1-5: The file hinkal.md containing the frontmatter title "Vendor:
Hinkal" must be relocated into the vendor docs directory so the validation
pipeline picks it up; move the Markdown file into the vendors/ directory
(rename/move hinkal.md to vendors/hinkal.md), and after moving, update any
internal references or links that pointed to the old location so schema/section
checks will run against the moved file.
- Around line 7-13: Replace promotional/absolute wording in the Hinkal
description: change "ZK-powered" to a neutral phrase like "uses zero-knowledge
proofs" (or similar), rephrase absolute privacy claims into conditional/caveated
capabilities (e.g., "enables confidential transactions when proofs are used" or
"aims to preserve privacy subject to protocol limits"), and rewrite the
KYT/compliance line to indicate optional/integrated screening (e.g., "can
integrate Chainalysis KYT to screen addresses" or "may screen addresses for
compliance") with an inline citation placeholder; also fix the grammar in "This
enables to send, receive and operate in stablecoins" to "This enables users to
send, receive, and operate in stablecoins." Target the phrases "ZK-powered",
"This enables to send, receive and operate in stablecoins confidentially", and
the KYT sentence for these edits and add citation markers where claims are
retained.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 97790d92-4511-4e34-ab2d-f7e30f2e84a2
📒 Files selected for processing (1)
hinkal.md
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@vendors/hinkal.md`:
- Line 35: The text contains promotional wording—replace marketing claims with
neutral, verifiable descriptions: change phrases like "Simple SDK integration,"
"High transaction processing speed," and "No migration required" to fact-based
statements (e.g., describe supported SDKs/APIs, typical throughput with measured
metrics or caveats, and any compatibility constraints or required steps). Update
the sentence in vendors/hinkal.md that currently reads "Simple SDK integration
for wallets, payment processors, treasury systems, payout flows and more" and
the similar copy at the later occurrence to list specific features, supported
integrations, or documented requirements, and remove superlatives or unqualified
claims.
- Around line 59-67: Add a missing "## CROPS profile" section to
vendors/hinkal.md: create the header "## CROPS profile" and add a Markdown table
with the exact columns "Product | CR | OS | Privacy | Security | Context", and
include at least one product row (e.g., "Hinkal Mainnet | Low/Med/High |
EVM/Solana/Tron | ... | ... | ...") providing concise values for CR, OS,
Privacy, Security, and Context so the vendor card conforms to the CROPS
requirement.
- Around line 1-5: Add an entry for the new vendor file to CHANGELOG.md under
the [Unreleased] section: open CHANGELOG.md and under the "## [Unreleased]"
heading add a "### Added" subsection (or append to it) with a bullet like "-
**Vendor:** [vendors/hinkal.md](vendors/hinkal.md) (`#129`)" so the new
vendors/hinkal.md file is documented per CONTRIBUTING.md; ensure formatting and
PR reference match existing changelog style.
- Around line 7-8: Update the Hinkal vendor card header/description that
currently reads "Hinkal - ZK-enabled smart contract for private stablecoin
settlements on EVM, Solana and Tron" to explicitly state Ethereum alignment:
mention Ethereum mainnet or specific production L2 deployments and any
Ethereum-specific integrations (e.g., ERC standards supported, EIP
compatibility, tooling/wallets, or bridges to mainnet/L2). Edit the description
and the corresponding paragraph(s) referencing "EVM, Solana and Tron" to include
concrete details such as "deployed on Ethereum mainnet and X L2(s)", supported
ERC token standards, and any mainnet-compatible bridges or integrations so the
entry meets IPTF Ethereum-aligned criteria.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 893a4d1e-8402-47be-b9ab-109971a539f7
📒 Files selected for processing (1)
vendors/hinkal.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
vendors/**/*.md
⚙️ CodeRabbit configuration file
vendors/**/*.md: This is a vendor card.Structure & frontmatter: Validate against the template at
vendors/_template.md.Ethereum alignment (CRITICAL):
Pervendors/README.md, IPTF only lists vendors whose products are Ethereum-aligned.
Check that the product is built for or deployed on Ethereum mainnet or production L2s,
or is a multichain solution that benefits the Ethereum ecosystem (supports EIPs/ERCs,
advances shared privacy patterns, or brings institutional adoption to Ethereum).
Flag products that primarily serve non-Ethereum L1s without meaningful Ethereum integration.CROPS evaluation (CRITICAL):
Vendor cards MUST include a## CROPS profilesection with a table evaluating each product.
Table columns: Product | CR | OS | Privacy | Security | Context.
Validate scores against the rubrics inCONTRIBUTING.md § CROPS Evaluation.
CROPS is assessed per product, not per vendor — a single vendor may have products with different profiles.
For vendors, the Security score should also consider: audit status, upgrade key controls, admin key scope, incident history, and bug bounty program.Tone (CRITICAL): Must be neutral and factual per
vendors/README.mdhouse style.
Vendor cards describe capabilities objectively — they do not endorse products.
Flag any promotional language, superlatives, or marketing copy.Word limits: warn > 1000, error > 1800.
Files:
vendors/hinkal.md
| --- | ||
| title: "Vendor: Hinkal" | ||
| status: draft | ||
| maturity: production | ||
| --- |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Checking CHANGELOG.md presence:"
fd -i '^CHANGELOG\.md$' .
echo
echo "Searching for PR reference and vendor link under Unreleased:"
rg -n -C3 '\[Unreleased\]|#129|vendors/hinkal\.md|hinkal' CHANGELOG.mdRepository: ethereum/iptf-map
Length of output: 606
Add CHANGELOG.md entry for this vendor addition under [Unreleased].
The CHANGELOG.md file exists but lacks an entry for this vendor file. Per CONTRIBUTING.md, significant changes (including new vendor files) must be documented under [Unreleased] with a PR reference. Add an entry like:
## [Unreleased]
### Added
- **Vendor:** [vendors/hinkal.md](vendors/hinkal.md) (`#129`)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@vendors/hinkal.md` around lines 1 - 5, Add an entry for the new vendor file
to CHANGELOG.md under the [Unreleased] section: open CHANGELOG.md and under the
"## [Unreleased]" heading add a "### Added" subsection (or append to it) with a
bullet like "- **Vendor:** [vendors/hinkal.md](vendors/hinkal.md) (`#129`)" so the
new vendors/hinkal.md file is documented per CONTRIBUTING.md; ensure formatting
and PR reference match existing changelog style.
| # Hinkal - ZK-enabled smart contract for private stablecoin settlements on EVM, Solana and Tron | ||
|
|
There was a problem hiding this comment.
Ethereum alignment is not explicit enough for IPTF inclusion criteria.
The card says “EVM, Solana and Tron” but does not explicitly state Ethereum mainnet/production L2 deployment or concrete Ethereum-specific integration (e.g., ERC/EIP support). Please add explicit Ethereum alignment details.
As per coding guidelines, “IPTF only lists vendors whose products are Ethereum-aligned… built for or deployed on Ethereum mainnet or production L2s, or multichain with meaningful Ethereum integration.”
Also applies to: 56-57
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@vendors/hinkal.md` around lines 7 - 8, Update the Hinkal vendor card
header/description that currently reads "Hinkal - ZK-enabled smart contract for
private stablecoin settlements on EVM, Solana and Tron" to explicitly state
Ethereum alignment: mention Ethereum mainnet or specific production L2
deployments and any Ethereum-specific integrations (e.g., ERC standards
supported, EIP compatibility, tooling/wallets, or bridges to mainnet/L2). Edit
the description and the corresponding paragraph(s) referencing "EVM, Solana and
Tron" to include concrete details such as "deployed on Ethereum mainnet and X
L2(s)", supported ERC token standards, and any mainnet-compatible bridges or
integrations so the entry meets IPTF Ethereum-aligned criteria.
| ## Strengths | ||
|
|
||
| - Multichain. Available on EVM, Solana and Tron | ||
| - High transaction processing speed | ||
| - No migration required. Works with existing wallets, custody setups, stablecoins, and payment infrastructure. | ||
| - Preserves recipient privacy without CEX routing | ||
| - Built-in compliance controls - viewing keys and KYT | ||
|
|
||
| ## Risks and open questions |
There was a problem hiding this comment.
Missing required ## CROPS profile section and table.
This vendor card omits the mandatory CROPS evaluation block. Add ## CROPS profile with the required columns and at least one product row.
Proposed patch
## Strengths
- Multichain. Available on EVM, Solana and Tron
- High transaction processing speed
- No migration required. Works with existing wallets, custody setups, stablecoins, and payment infrastructure.
- Preserves recipient privacy without CEX routing
- Built-in compliance controls - viewing keys and KYT
+## CROPS profile
+
+| Product | CR | OS | Privacy | Security | Context |
+|---------|----|----|---------|----------|---------|
+| Hinkal private settlement | medium | partial | high | medium | both |
+
## Risks and open questionsAs per coding guidelines, “Vendor cards MUST include a ## CROPS profile section with a table evaluating each product. Table columns: Product | CR | OS | Privacy | Security | Context.”
📝 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.
| ## Strengths | |
| - Multichain. Available on EVM, Solana and Tron | |
| - High transaction processing speed | |
| - No migration required. Works with existing wallets, custody setups, stablecoins, and payment infrastructure. | |
| - Preserves recipient privacy without CEX routing | |
| - Built-in compliance controls - viewing keys and KYT | |
| ## Risks and open questions | |
| ## Strengths | |
| - Multichain. Available on EVM, Solana and Tron | |
| - High transaction processing speed | |
| - No migration required. Works with existing wallets, custody setups, stablecoins, and payment infrastructure. | |
| - Preserves recipient privacy without CEX routing | |
| - Built-in compliance controls - viewing keys and KYT | |
| ## CROPS profile | |
| | Product | CR | OS | Privacy | Security | Context | | |
| |---------|----|----|---------|----------|---------| | |
| | Hinkal private settlement | medium | partial | high | medium | both | | |
| ## Risks and open questions |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@vendors/hinkal.md` around lines 59 - 67, Add a missing "## CROPS profile"
section to vendors/hinkal.md: create the header "## CROPS profile" and add a
Markdown table with the exact columns "Product | CR | OS | Privacy | Security |
Context", and include at least one product row (e.g., "Hinkal Mainnet |
Low/Med/High | EVM/Solana/Tron | ... | ... | ...") providing concise values for
CR, OS, Privacy, Security, and Context so the vendor card conforms to the CROPS
requirement.
1 participant
What are you adding?
Description
Detailed overview of hinkal to be added to the vendor map
Checklist
Summary by CodeRabbit