There is a need for a source of truth as to what can be trusted in SEP. The registries broadly cover the areas of:
For initial development phase of SEP, addresses will require whitelisting so that they may register a service provider with smart-contract enforced sunset clause for the whitelisting of 180 days (ie. after which anyone may register).
Reputation based scoring / assessment is OUTSIDE OF SCOPE for the initial development phase of SEP. During this phase, the SEP will NOT support terms that allow for the transfer of funds to service providers without intervention / consent of the consumer. Reputation base scoring / dispute settlement is targetted to be implemented after the cessation of the whitelist timeframe.
This registry provides a canonical source for line-specific state transition contracts that allow for the issuance of
stubs, and subsequent state changes.
The registry shall contain a bytes32 to address mapping for the industry-specific code (eg. “movi”) to the implementing contract. The registry shall also contain a mapping of industry to service provider to uint256. This is to be interpreted as a
can, essentially indcating that the service provider providers a service in the specific industry, and the industry-specific terms they agree to are governed by the implementation.
Protocol fees for the specific industry are stored within this contract.
It is a requirement that the service provider has agreed to the industry-specific terms / life-cycle. If they cease to agree, and exit the industry, no NEW stub issuance may take place, but old stubs and their terms remain effective.
The above method opens up the possibility to have sub-industry, or locale specific industry implementations, such as
movi-JP for accommodation providers in Japan.
The service provider registry allows consumers to:
- Find where to get industry-specific information about the service provider.
- Determine who is authorised to act in what role on behalf of the service provider.
- Determine when an authorised party was authorised, and if their authorisation is revoked, when it was revoked.
Service providers store their information offline, saving on costly gas and allowing the system to remain storage system agnostic. In doing so, there is a need to determine the time at which a specific document was published.
The document timestamp registry allows actors on the protocol to:
- Determine the time at which a document was created.
Proof of ownership of the document is outside the scope of the timestamp registry.
Accounting of funds is handled by a centralised accounting contract, similar to the
vat system as used in MakerDAO. The actual funds are held by joiner contracts. This allows for the system to limit the types of collateral / tokens that may be used to pay for stubs. There are three types of accounts that may own collateral managed within the
- Service Providers (
- Stubs (
- Ethereum addresses (
Funds are specified in mappings such that:
mapping (bytes32 => mapping (address => uint256))
mapping (address => mapping (address => uint256))
The zero address
token MAY be implemented and represent the deployment chain’s native unit of account.
As stubs may be resold on secondary markets, any collateral attached to them should move simultaneously, therefore the stub represents an account itself.
Ownership of stubs is handled through a
mapping (bytes32 => address)
Similar to MakerDAO’s
vat, root administrative contracts can be attached to the
vat to allow custom movement of funds / stub ownership. This allows for future use cases such as a ProxyContract that implements zk ownership of a stub.
Industrial lines (such as
stays) will have an account within the
vat. This account will be an ethereum address corresponding to the contract’s deployment address. This allows for the system to accrue protocol fees, and to account for these fees on a per industry basis, allowing the case of different protocol fees depending on an industry.
When a service provider and consumer come to an agreement, they make a
deal. The result of this
deal is a stub (voucher) that represents a future service to be delivered by the service provider to the consumer. This future service (items) is subject to terms and carries a specified cost. It is the role of the line (industry) contract to implement rules defining the lifecycle of their issued stubs.
item array, in the primitive sense.
term is a business logic primitive for Videre, and may be called by either party, depending on the
term. For example there may be a
NO_REFUND_AFTER_CHECKIN term where upon the
consumer checks into the accommodation facility, the
service provider may call the term to have the whole balance of funds transferred to themselves.
Another example may be a
48HR_RAINCHECK by which the stub may be fully refundable. The
consumer could then call the
term which would refund their payment provided the conditions were met.
Careful consideration should be given to terms and the privacy implications that they may have.
These are contracts that help with usability / specific cases.
stub holder can transfer their
stub to the NFTWrapper which then subsequently becomes the owner of the
stub in the
vat, though the respective NFT
tokenId that is issued is minted to the stub holder.
The wrapper would contain a
stub mapping, and
owner mapping. This wrapper should also proxy the
ILifeCycle interface so that calls can just be forwarded directly from the token owner to the industry-specific life-cycle implementation.