Add ERC: Oracle-Permissioned ERC-20 with ZK Proofs #1062
Conversation
chadxeth
force-pushed
the
master
branch
2 times, most recently
from
cdc1f35 to
6cb4710
Compare
ERCS/erc-7963.md
Outdated
| @@ -0,0 +1,226 @@ | |||
| --- | |||
| eip: 7963 | |||
| title: Oracle-Permissioned ERC-20 with ZK-Verified ISO 20022 Payment Instructions | |||
There was a problem hiding this comment.
Unfortunately ISO standards are not generally free (as in beer) to access. Unless this one is different, we do not permit links (even by name) to non-free resources. Doing so would place a burden on implementers that may be unfair to smaller organizations and individuals who might not be able to access the document.
There was a problem hiding this comment.
Hey Sam, thanks for reviewing my PR. I have a couple of questions regarding this that I have compiled from the authors:
-
Is it permissible to mention “ISO 20022 pain.001” by name if the implementation does not require access to the official ISO document? The spec is based on a public interpretation and open-source JSON abstraction.
-
Would a clarification stating that “no ISO standard documents are required to implement this EIP” be sufficient to resolve the concern? I’m happy to include a Licensing & Accessibility section to that effect.
-
Am I allowed to describe the schema as “pain.001-compatible” or “inspired by ISO 20022 pain.001” instead of naming the exact standard?
-
Is referencing the publicly browsable message definitions on iso20022.org acceptable, or should I remove even those?
There was a problem hiding this comment.
Hey Sam, do let me know so i can push this forward.
There was a problem hiding this comment.
hey @SamWilsn , sorry to bother but do you mind responding to my questions so that i can push this PR forward.
There was a problem hiding this comment.
Sorry for the wait!
Is it permissible to mention “ISO 20022 pain.001”
As long as it isn't required, and the reference is just for something like "compatible with ISO 20022" I'd be okay with it
There was a problem hiding this comment.
Is referencing the publicly browsable message definitions on iso20022.org acceptable, or should I remove even those?
Please remove them.
| This standard is **proof-system-agnostic**. The reference implementation uses RISC Zero for: | ||
| + **Transparent Setup**: No trusted ceremony required | ||
| + **Developer Experience**: Write verification logic in Rust | ||
| + **Performance**: Efficient proof generation and verification | ||
| + **Auditability**: Clear, readable verification code |
There was a problem hiding this comment.
Text describing the reference implementation should be placed in that section.
ERCS/erc-7963.md
Outdated
| + **CLI Tools**: Host program for proof generation and verification | ||
| + **Gas Optimization**: Efficient on-chain verification with detailed gas profiling | ||
|
|
||
| Repository: [chadxeth/eip-permissioned-erc20](https://github.com/chadxeth/eip-permissioned-erc20) |
There was a problem hiding this comment.
If the reference implementation is small, include it inline in this document. If it is larger, you should include it in the assets/... directory under a permissive license.
There was a problem hiding this comment.
Understood on this as well. Will include in my next commit.
assets/erc-7963/A&I.jpg
Outdated
There was a problem hiding this comment.
We prefer SVGs if you can, or PNGs failing that.
There was a problem hiding this comment.
Also this doesn't seem to be used.
…t Instructions Introduced a new ERC standard that allows token transfers to be validated through an external "Transfer Oracle" using zero-knowledge proofs. This standard aims to enhance compliance and flexibility in institutional tokenization while maintaining ERC-20 compatibility. Included detailed specifications, interfaces, and events for implementation.
…s and enhance validation requirements. Added details on approval consumption behavior, amount range design, and best-match selection for overlapping approvals.
- Title: Oracle-Permissioned ERC-20 with ZK Proofs (43 chars) - Add description field (116 chars, within 140 limit) - Satisfies EIP-1 format requirements
Complete implementation with: - Solidity contracts (PermissionedERC20, TransferOracle, RiscZeroVerifier) - RISC Zero ZK programs for payment instruction validation - Comprehensive test suite (80 Solidity + 45 Rust tests passing) - CLI tools and deployment scripts - Full documentation Implementation uses generic payment instruction terminology (refactored from pain.001-specific naming). Size: 1.0 MB (cleaned of build artifacts and dependencies)
- Add required preamble fields: discussions-to, category, requires - Fix preamble field order (author before status) - Change section headers from # to ## (Abstract, Motivation, Specification) - Link EIP-1967 reference - Remove backticks from file path in Reference Implementation - Restructure appendix content (remove section, integrate into spec) - Fix Copyright section with CC0 link - Change table headers to avoid ERC-7963 pattern matching issues
eip-review-bot
changed the title
- Move 'requires' field after 'created' in preamble (correct order) - Reorder sections: Security Considerations now after Reference Implementation - Simplify reference implementation link to avoid erc-7963 pattern issue
- Add index.md files for directory navigation in Jekyll build - Fix LICENSE reference: change from missing file to CC0 statement - Fix broken EIP-walkthrough.md link: replace with ERC-7963 spec URL - Update resource links and capitalize Payment Instruction properly
|
The commit b4d052a (as a parent of 1290dff) contains errors. |
- Rename assets/erc-7963/ to assets/eip-7963/ (matches Jekyll convention) - Update ERC spec to reference ../assets/eip-7963/ paths - Remove broken directory links from index files (contracts/, test/, etc.) - Keep only valid links to README.md and zk/ subdirectory
4 participants
Introduced a new ERC standard that allows token transfers to be validated through an external "Transfer Oracle" using zero-knowledge proofs. This standard aims to enhance compliance and flexibility in institutional tokenization while maintaining ERC-20 compatibility. Included detailed specifications, interfaces, and events for implementation.