Over the past few months, the Chintai core team has been busy debating a multitude of features the Chintai platform will need to address in order to create a robust token leasing marketplace. We are encouraged by the progress that the team has made so far, but there are still topics up for debate that we touch on in this update.

Discussion has been increasingly active in the Telegram group with invaluable input continuously being made by the community. The contribution by the community has been vital to the core team discussions behind the scenes. We are incredibly appreciative of the community support, and welcome your review and opinions about these proposals.

I. Chintai Functionality Overview

II. Chintai Private API & Lease Engine Update

III. Front End User Interface/Back End Interaction

IV. Governance Board Proposal

V. Current Functionality Considerations

VI. New BP Sponsors Announcement

I. Chintai Functionality Overview

The majority of the discussion over the past few months has focused on the core functionality that Chintai will need for launch. To date, we have come up with the following order-execution functionality breakdown:

Submitting Lease Offers/Lease Bids

User Submits order, inputs APR, Quantity and Lease Address (Lease Address only required for dApp accounts attempting to rent EOS tokens)

Order gets submitted to Chintai leasing engine, where it is validated and a contract is created.

Scatter-Chintai Interaction

Chintai will use Scatter to enable secure user-wallet access. In order to create a Chintai account users will log on to Chintai through Scatter. If a user does not yet have a Scatter account, one can be created directly through Chintai’s API.

A Scatter request is then returned informing the user to move the token fee (if leasing) or the tokens at stake (if delegating for leasing) to the designated contract address.

A user can cancel the order at any time before it has been filled, any part of the order has been filled, the order is locked in (subject to change).

Leasing Engine

The Chintai leasing engine takes that order into consideration and attempts to match it. For launch this is unlikely to be sophisticated. Manual matching by the dApp holder selecting available leases to fill is the default functionality. Once a match has been discovered, the order (or the partially filled portion) is closed and submitted to the contract engine.

The contract engine then pays the required interest (EOS token payment for the contract as a deferred transaction) upfront to the lessor, and delegates the bandwidth/CPU to the lessee (dApp holder) address of the matched order.

Each order will have three possible default periods of time set by Chintai for launch: 1 month, 3 months and 6 months. Advanced lease term functionality will be built out further in future iterations.

The created contract will then exist on a contracts page, initially this will display contract information, but in the future Chianti will provide the ability to extend, shorten or cancel contracts, assuming all parties agree.

Additional Points

Price discovery will occur through manual supply bids and demand acceptance on launch. A future Chintai token pricing mechanism will automate the current spot price and leasing futures definition thereafter.

Consideration needs to be given to cancellation of orders — to discourage cancellation of orders a time delay is one option to enable ample time for an alternative fill, with a zero (or full) payment as a penalty depending on the party breaking contract (lessor or lessee).

II. Chintai Private API & Lease Engine Update

The initial private API for Chintai is now complete. This will allow for interaction with the different Chintai front end and back end processes. The lease engine code to create the supply and demand market as well as the order matching process has also been created. The private API provides Chintai with the ability to create orders, cancel orders and create new accounts among other core functionality. This API can be called to link with Scatter, as well as the front end UX interface, back end functionality, and the leasing engine. In order to expedite development, we have also brought on other core developers to tie the different code bases together and build out the Chintai platform.

III. Front End User Interface

The user interface design is being worked on by the Chintai interface development team. An initial screenshot can be seen below displaying our initial vision for parts of the user personal profile order page, as well as market visualization and order history.

User Page

IV. Governance Board Proposal

As Chintai will be a community dApp, consideration needs to be made toward dApp governance. Chintai will have a core team that continues to work on the project, and implement updates and features suggested by the community going forward.

It is important that the community gives continual input and enhancement direction to ensure the platform serves EOS.IO optimally. We propose a governance board structure, whereby Chintai community members are nominated to represent and provide input into the decisions made by the Chintai core team. We propose that the board includes members of the Chintai core team, along with board seats occupied by a community nomination system. The community board seats could operate based on a voter proposal system, whereby all proposed updates are voted on by the community and that result reflects the community board vote. Possibility, for community members highly invested in the success of Chintai can also be contemplated as an additional board seat.

This is one of the most important topics that needs to be considered, as allocation of BP funds and Chintai community work proposals (if selected) must be discussed. We believe the pay of the Chintai core team should be transparent and agreed upon. This should not be a sum of money allocated without purpose, but one fairly allocated to adequately address operating and development costs. We urge the community to continue to propose ideas surrounding governance structures, and how this can be best implemented by the Chintai platform. We also ask that anybody interested globally in being part of the Board to volunteer.

V. Current Functionality Considerations

We would like to continue to ask for input from the community on:

Order Cancellation — we have discussed bad actor scenarios that could potentially occur if Chintai allows for order cancellation without appropriate design controls. For example, a user could cancel a lease before expiration and not pay the contract after accessing the CPU/Bandwidth provided for the elapsed period of the contract. This could be solved with a deferred payment at the beginning of the contract, and in theory 100% penalties for cancellation by a given party. Paying upfront with a deferred payment ensures that both sides will not be financially worse off from one another by breaking contract. There are potential implementations to offset both sides such as penalties, bans, etc. that the core team has contemplated, but as of right now, it seems the best route will be to force contracts to be non-cancellable on launch.

VI. New Block Producer Sponsorship Announcements

The Chintai core team is excited to announce a number of new block producer sponsors. These BP candidates, if voted in, have committed to supporting the ongoing operational costs of Chintai through a percentage of their received block rewards. The new BP candidates who have committed to support the platform if voted in are as follows: EOS Cannon, EOS Dublin, EOS Nation, EOS WTZ, Oracle Chain and Worbli. We would like to again thank each of these BP candidates for their support, and we are excited to see what happens upon EOS launch!

Conclusion

We are excited for what the coming months hold and will continue to update the community as progress continues. Thank you for your continued support, and as always, we urge all community to members to contribute to the discussion and help continue to build out the advanced, fee-less leasing application that EOS needs and deserves for the future.