https://github.com/expede/validated-token
ERC902 implementation
https://github.com/expede/validated-token
erc1066 erc20 erc902
Last synced: about 1 year ago
JSON representation
ERC902 implementation
- Host: GitHub
- URL: https://github.com/expede/validated-token
- Owner: expede
- License: apache-2.0
- Created: 2018-10-21T02:29:57.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2018-10-21T04:03:52.000Z (over 7 years ago)
- Last Synced: 2025-02-02T10:43:13.166Z (over 1 year ago)
- Topics: erc1066, erc20, erc902
- Language: JavaScript
- Homepage: https://eips.ethereum.org/EIPS/eip-902
- Size: 802 KB
- Stars: 2
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
Awesome Lists containing this project
README
# Validated Token Example Contracts
[](https://travis-ci.org/expede/validated-token)
[](https://codeclimate.com/github/expede/validated-token/maintainability)
[](https://eips.ethereum.org/EIPS/eip-902)
[](https://eips.ethereum.org/EIPS/eip-1066)
## Architecture
The basic relationship of this protocol is very simple: there are validators that expose two `check` functions:
```solidity
check(address token, address user) returns (byte status)
check(address token, address to, address from, uint256 amout) returns (byte status)
```
Why list this as a `Caller` and not `Token`? Because validators may be arranged into a DAG of validation dependencies. They may check `any` and `all` of their dependencies, or have more complex logic, change which dependencies are required based on who they're validating, and so on.
# Interface
```solidity
interface TokenValidator {
function check(
address _token,
address _subject
) public returns(byte statusCode)
function check(
address _token,
address _from,
address _to,
uint256 _amount
) public returns (byte statusCode)
}
```
# Architecture
## Isolated
```
+--------+
│ Caller |
+--------+
│ ↑
check(...) │ │ statusCode
↓ │
+-----------+
| Validator |
+-----------+
```
Here `Caller` may be a token, another `Validator`, an exchange (directly checking), or a user verifying that they will be authorized to perform some action.
## Stacked
(With example ERC1066 status codes for flavour)
```
+-------+
│ Token |
+-------+
│ ↑
check(...) │ │ 0x11
↓ │ check(...)
+------------+ -------------> +------------+
| ValidatorA | | ValidatorC |
+------------+ <------------- +------------+
│ ↑ 0x21 │ ↑
check(...) │ │ 0x11 check(...) │ │ 0x31
↓ │ ↓ │
+------------+ +------------+
| ValidatorB | | ValidatorD |
+------------+ +------------+
```
# Example Diagram
A somewhat contrived example is for purchasing a holiday via the blockchain. Here, we have `TravelToken`, which is your travel package (flight & hotel details, &c). In order to purchase such a token, you need to be able to have a valid travel visa, have all of your immunizations up to date, and prove that you are who you say you are. In turn, the travel visa requires that you're not a crminal on a government watch list.
Each of these validation services may be operated variously by the travel agency, governments, and identity services. By implementing the `TokenValidator` interface, these validation services can interact with other validators to check information that they don't own.
## Links
* [EIP](https://eips.ethereum.org/EIPS/eip-902)