Ang pagpapatupad ng isang loan request sa isang karaniwang chain ay maaaring magrequire ng tatlong hiwalay na token. Ang native asset para sa gas. Ikalawa para sa pagbabayad sa relay service na kumukuha ng credit data ng borrower. Ikatlo para sa kompensasyon sa keeper network na nagpapagana ang callback pagkatapos bumalik ang data. Ang halimbawang ito ay galing sa sariling async execution documentation ng Rialo, at ito ay naglalarawan sa tunay na operasyonal na gastos ng isang bagay na tinatawag ng maraming tao bilang isang solong transaction. Tatlong asset na kailangang kunin, panatilihin, monitor, at i-top up. Tatlong balance na kailangang pamahalaan. Tatlong lugar kung saan humihinto ang workflow kung isa sa mga ito ay mawawala sa maling oras. Ang multi-token tax na ito ay kung saan-kailan ay lumalabas dahil hindi ito isang protocol fee na ipinapataw ng sinoman. Ito ay isang emergent na gastos mula sa paglabas ng capability sa hiwalay na network na bawat isa ay nangangailangan ng sariling ekonomiya upang mabuhay. Walang sinuman ang disenyo nito. Ito ay nagkumpok, isa sa isang middleware layer. Sa @RialoHQ, ang parehong workflow ay tumatakbo bilang isang solong async transaction. Ang mga validator ay nagmamaneho ng external API sa pamamagitan ng native web calls. Ang execution ay humihinto at nagpapatuloy nang walang keeper na magpapagana nito. Isang token, isang balance, isang bagay na dapat panatilihin na may sapat na pondo. Ang mga diskusyon tungkol sa token design ay karaniwang nakatuon sa supply schedules at distribution curves. Ang mas kapaki-pakinabang na tanong ay ilang iba’t ibang token ang kailangan hawakan ng isang developer bago gumana ang kanilang produkto. Para sa karamihan ng industriyang ito, ang patotoo ay tatlo, at hindi kailanman isinama ang bilang na ito sa anumang pitch deck.