Page 1Chintai (EOS resource exchange) low severity issue.

Original article by Dexaran posted on Medium on November 8, 2018.

Description.

Chintai is a EOS smart-contract. It is a kind of exchange where users can lend or lease EOS.

If a user wishes to lease the resources (CPU or NET) provided by his EOS, he must send his EOS to the Chintai contract where it will be stored in an order.

If a user wants to rent resources, he must complete the execute order or group of orders. To do this, he must send the rental fee to the contract, after which the rented EOS will be staked for the leaser’s CPU or NET depending on his(her) choice. Contract does not allow leaser to receive “EOS”. Contract only allows leaser to get CPU or NET provided by someone else’s EOS.

Discovered issue.

When users place orders at the same price, orders are grouped in the same way as orders on any exchange are grouped. In some situations, in order to rent an EOS, a leaser needs to execute several orders within a transaction.

Each transaction in the EOS runs for a certain time. There is a maximum amount of time that a transaction can run for. If the maximum amount of transaction time is exceeded then transaction is not guaranteed to execute.

It is possible to spam Chintai with large quantities of small orders. This will lead to the impossibility to borrow/lend significant amount of EOS and hurt the operability of the contract.

Example.

User1 submits 100 “lend” orders of 10 EOS each at 0.20%/week.

User2 wants to lease 1000 EOS. In this case, user2 can not invoke the contract and get 1000 EOS leased because it needs to execute 100 small orders and it is above the max transaction time limit.

User2 can execute orders one by one, however he will run out of resources quickly.

User2 cannot access orders above the “lowest ask” price because he need to execute lowest ask orders from stack first.