Compare commits
1 Commits
lash/exten
...
lash/reser
| Author | SHA1 | Date | |
|---|---|---|---|
|
0b8040adcd
|
103
spec/011_Reserve_Proof_Spec.md
Normal file
103
spec/011_Reserve_Proof_Spec.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# PROOF FORMAT FOR REAL-WORLD RESERVE ASSETS
|
||||
|
||||
This is draft status
|
||||
|
||||
|
||||
A collection of proofs represents contracts describing real and virtual assets posted as reserve for a specific token issuance.
|
||||
|
||||
The underlying resources for the proofs may be documents, recordings, photos, crypto transactions.
|
||||
|
||||
sha256sum is calculated on files. crypto transaction hashes are used as-is. All data is is left-padded to 512 bit vectors.
|
||||
|
||||
The hashes are ordered in sequence of their big-endian numerical value and sha256sum is calculated on the sequence. This is the collateral proof.
|
||||
|
||||
--
|
||||
|
||||
The proof should be signed by the key performing the initial reserve transaction and made available. The following options should be considered:
|
||||
|
||||
- A secp256k1 ECC signature on the proof
|
||||
- A ethereum blockchain transaction to a well-known address, with the proof in the data field
|
||||
- An ENS record
|
||||
|
||||
Additional signatures may optionally be added.
|
||||
|
||||
|
||||
---
|
||||
|
||||
The proof, signature and underlyding digital resources must be disseminated to a selection of storers whose role is to provide data availability on demand.
|
||||
|
||||
With the eventual maturity of decentralized storage, additional data availability guarantees can come from these.
|
||||
|
||||
---
|
||||
|
||||
metadata structures can be added to provide metadata and context for the digial resources in the proof.
|
||||
|
||||
This structure can also allow alternate hash representations of the data, aswell as additional signatures.
|
||||
|
||||
Lastly it can include a list of locations where the resources can be obtained. The resources should be available on querying the proof hash, responding with the resources in a well-known achive format, and optionally providing a human readable index of the files (the client can choose using the 'Accept' HTTP header)
|
||||
|
||||
---
|
||||
|
||||
example:
|
||||
|
||||
A contract for a token reserve consists of a written document A, a video recording B and a crypto transaction C.
|
||||
|
||||
sha256(A), sha256(B) are calculated. They result in Ah = 0x56.., Bh = 0x12. C = 0x34..
|
||||
|
||||
sha256 is calculated on the ordered sequence to obtain the proof; sha256(Bh, C, Ah) = Ph
|
||||
|
||||
Token T is minted by sending reserve from account K. Ph is signed by the same key; secp256k1.ec_sign(K, Ph) = Ks
|
||||
|
||||
The proof is encapsulated by metadata:
|
||||
|
||||
```
|
||||
{
|
||||
'version': 0,
|
||||
'token': <token address>,
|
||||
'proofs': {
|
||||
'default': {
|
||||
'digest': <Ph>,
|
||||
'signatures': [
|
||||
<Ks>,
|
||||
],
|
||||
},
|
||||
'foo-algo': [
|
||||
'digest': <Ph2>,
|
||||
'signatures': [
|
||||
...,
|
||||
],
|
||||
],
|
||||
},
|
||||
'resources': [
|
||||
{
|
||||
'type': 'file',
|
||||
'proof': {
|
||||
'default': {
|
||||
'digest': <...>,
|
||||
}
|
||||
},
|
||||
'metadata': {
|
||||
'mime-type': 'application/pdf',
|
||||
'filename': 'foo.pdf',
|
||||
},
|
||||
},
|
||||
{
|
||||
'type': 'ethereum-transaction',
|
||||
'proof': {
|
||||
'default': {
|
||||
'digest': <...>,
|
||||
}
|
||||
},
|
||||
},
|
||||
],
|
||||
'locations': [
|
||||
'ftp://ftp.grassrootseconomics.org/reserve-resources',
|
||||
'https://redcross.com/grassrootseconomics/reserve-resources',
|
||||
...
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Another possiblity is to host the proofs on DNS TXT records by well-known actors. This means, for example, if _<Ph>_resource_proofs.grassrootsconomics.org could returns the token address (or the other way around), that means GE considers the proof valid for the token. A list of DNS hosts can be established to decentralize this certification.
|
||||
@@ -1,70 +0,0 @@
|
||||
# API EXTENSIONS FOR EXTERNALLY CREATED BLOCKCHAIN RESOURCES
|
||||
|
||||
At time of writing, apis are registered under `/api/v2`. This will change.
|
||||
|
||||
## NOMENCLATURE
|
||||
|
||||
Values enclosed with `<>` are _required_.
|
||||
|
||||
Values enclosed with `[]` means _optional_.
|
||||
|
||||
No enclosure means _literal_.
|
||||
|
||||
## CHANGED METHODS
|
||||
|
||||
Endpoints _modified_ are found under /api/v1/
|
||||
|
||||
Changes will be submitted upstream.
|
||||
|
||||
### `/api/v1/organisation`
|
||||
|
||||
### **POST**
|
||||
|
||||
One item is added to data payload:
|
||||
|
||||
```
|
||||
{
|
||||
account_address: [address],
|
||||
}
|
||||
```
|
||||
|
||||
If specified, the organisation will be bound to the specified blockchain account, and _will not_ create a new account on instantiation.
|
||||
|
||||
## ADDED METHODS
|
||||
|
||||
Endpoints _added_ are found under /api/ext/
|
||||
|
||||
### `/api/ext/exchange/register`
|
||||
|
||||
#### **POST**
|
||||
|
||||
Creates a new entry in `exchange_contract` table in database.
|
||||
|
||||
Requires token addresses to be registered in advance on `/api/v1/token/`
|
||||
|
||||
Request payload:
|
||||
```
|
||||
{
|
||||
reserve_address: <address>,
|
||||
token_address: <address>,
|
||||
converter_address: <address>,
|
||||
registry_address: <address>,
|
||||
connector_weight: <uint>,
|
||||
}
|
||||
```
|
||||
|
||||
Response payload on success:
|
||||
```
|
||||
{
|
||||
message: 'Exchange added',
|
||||
data: {
|
||||
exchange: (exchange schema dump, TODO specify)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Returns:
|
||||
```
|
||||
201 - exchange record created
|
||||
400 - token addresses not known to platform
|
||||
```
|
||||
@@ -1,102 +0,0 @@
|
||||
# API EXTENSIONS FOR MANIPULATING LOCATIONS RECORDS
|
||||
|
||||
## NOMENCLATURE
|
||||
|
||||
Values enclosed with `<>` are _required_.
|
||||
|
||||
Values enclosed with `[]` means _optional_.
|
||||
|
||||
No enclosure means _literal_.
|
||||
|
||||
## ADDED METHODS
|
||||
|
||||
Endpoints _added_ are found under /api/ext/
|
||||
|
||||
### `/api/ext/geolocation/`
|
||||
|
||||
#### **POST**
|
||||
|
||||
Adds a location entry to the database
|
||||
|
||||
Request payload:
|
||||
```
|
||||
{
|
||||
common_name: <string>,
|
||||
latitude: <float>,
|
||||
longitude: <float>,
|
||||
parent_id: [uint],
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
`parent_id` is the location table id of the location record for the greater area encapsulating the location being registered.
|
||||
|
||||
### `/api/ext/geolocation/<path_string>/`
|
||||
|
||||
#### **GET**
|
||||
|
||||
Retrieves a location record based on the given `path_string`. Every part of the given path string must match the value in the location hierarchy. A path string must have minimum one part.
|
||||
|
||||
Example, given database has `foo/bar` and `foo/baz`: A search of `foo/bar` will only match `foo/bar`. A search of `foo` will match both `foo/bar` and `foo/baz`.
|
||||
|
||||
Response payload:
|
||||
|
||||
```
|
||||
{
|
||||
id: <uint>,
|
||||
common_name: <string>,
|
||||
path: <string>,
|
||||
latitude: <float>,
|
||||
longitude: <float>,
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
`common_name` is the location leaf name.
|
||||
|
||||
`path` is the full hierarchical path string.
|
||||
|
||||
### `/api/ext/geolocation/<ext_type>/<ext_id>/`
|
||||
|
||||
|
||||
#### **GET**
|
||||
|
||||
Queries the `location_external` table for a matching value, and returns the `location` object associated with it.
|
||||
|
||||
Currently only `OSM` is supported as `ext_type`. The value given matches a `place_id` entry in the external table.
|
||||
|
||||
Data format returned the same as `GET /api/ext/geolocation/<path_string>/`
|
||||
|
||||
### `/api/ext/user/<user_id>/geolocation/`
|
||||
|
||||
#### **PUT**
|
||||
|
||||
Sets the location of the affected user
|
||||
|
||||
Data payload:
|
||||
|
||||
```
|
||||
{
|
||||
location_id: <uint>
|
||||
}
|
||||
```
|
||||
|
||||
#### **GET**
|
||||
|
||||
Retrieves full objects for the hierarchical path of the user location.
|
||||
|
||||
Response payload:
|
||||
|
||||
```
|
||||
{
|
||||
user_id: user_id,
|
||||
location: [
|
||||
{
|
||||
common_name: <string>,
|
||||
longitude: <float>,
|
||||
latitude: <float>,
|
||||
},
|
||||
...
|
||||
],
|
||||
}
|
||||
```
|
||||
@@ -1,41 +0,0 @@
|
||||
# API EXTENSIONS FOR VIEWING NOTIFICATION DATABASE
|
||||
|
||||
|
||||
## NOMENCLATURE
|
||||
|
||||
Values enclosed with `<>` are _required_.
|
||||
|
||||
Values enclosed with `[]` means _optional_.
|
||||
|
||||
No enclosure means _literal_.
|
||||
|
||||
## ADDED METHODS
|
||||
|
||||
Endpoints _added_ are found under /api/ext/
|
||||
|
||||
### `/api/ext/sms/` `/api/ext/sms/user/<user_id>/` `/api/ext/sms/<phone_number>/`
|
||||
|
||||
#### **GET**
|
||||
|
||||
Returns a list of latest sms notifications sent by the platform.
|
||||
|
||||
If `user_id` or `phone_number` is given, only entries for the affected user will be returned.
|
||||
|
||||
Accepts one query string:
|
||||
|
||||
```
|
||||
limit: [uint] - maximum items to return (default: 100)
|
||||
```
|
||||
|
||||
Response payload:
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
datetime: <string>,
|
||||
number: <string>,
|
||||
message: <string>,
|
||||
},
|
||||
...
|
||||
]
|
||||
```
|
||||
@@ -1,80 +0,0 @@
|
||||
# API EXTENSIONS FOR INDEPENDENT TRANSFER ACCOUNTS
|
||||
|
||||
At time of writing, apis are registered under `/api/v2`. This will change.
|
||||
|
||||
## NOMENCLATURE
|
||||
|
||||
Values enclosed with `<>` are _required_.
|
||||
|
||||
Values enclosed with `[]` means _optional_.
|
||||
|
||||
No enclosure means _literal_.
|
||||
|
||||
## ADDED METHODS
|
||||
|
||||
Endpoints _added_ are found under /api/ext/
|
||||
|
||||
### `/api/ext/transfer_account/register/`
|
||||
|
||||
#### **POST**
|
||||
|
||||
Create a new transfer_account bound to an organisation.
|
||||
|
||||
Request payload:
|
||||
```
|
||||
{
|
||||
address: <address>,
|
||||
organisation_id: <uint>,
|
||||
}
|
||||
```
|
||||
|
||||
Response payload on success:
|
||||
```
|
||||
{
|
||||
message: 'Created',
|
||||
data: {
|
||||
id: <uint>
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
`id` is the id of the newly created transfer account
|
||||
|
||||
Returns:
|
||||
```
|
||||
201 - transfer account is added
|
||||
400 - address or organisation data invalid
|
||||
404 - organisation not found
|
||||
```
|
||||
|
||||
### `/api/ext/user/`
|
||||
|
||||
#### **POST**
|
||||
|
||||
Add a new user without transfer account. The user will be associated with the organisation in the API session context.
|
||||
|
||||
Request payload:
|
||||
```
|
||||
{
|
||||
phone: <string>,
|
||||
first_name: <string>,
|
||||
last_name: <string>,
|
||||
}
|
||||
```
|
||||
|
||||
Response payload on success:
|
||||
```
|
||||
{
|
||||
data: {
|
||||
id: <uint>
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
`id` is the id of the newly created user.
|
||||
|
||||
Returns:
|
||||
```
|
||||
201 - user created
|
||||
400 - organisation context missing
|
||||
```
|
||||
Reference in New Issue
Block a user