Add ERC: Oracle-Permissioned ERC-20 with ZK-Verified ISO 20022 Payment Instructions #1062
Conversation
…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.
|
🛑 |
chadxeth
force-pushed
the
master
branch
2 times, most recently
from
cdc1f35 to
6cb4710
Compare
…s and enhance validation requirements. Added details on approval consumption behavior, amount range design, and best-match selection for overlapping approvals.
| @@ -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?
| 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.
| + **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.
|
The commit fcf7cbb (as a parent of e7a70d4) contains errors. |
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.