# Virtual Baker TZIP

**URL:** https://forum.tezosagora.org/t/virtual-baker-tzip/2551
**Category:** TZIP
**Created:** [December 29, 2020, 2:53am UTC](https://forum.tezosagora.org/t/virtual-baker-tzip/2551 "2020-12-29T02:53:08Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![mantiss3](https://forum.tezosagora.org/letter_avatar_proxy/v4/letter/m/e5b9ba/32.png) [@mantiss3](https://forum.tezosagora.org/u/mantiss3)
#### Post date: [December 29, 2020, 4:44pm UTC](https://forum.tezosagora.org/t/virtual-baker-tzip/2551/2 "2020-12-29T16:44:35Z")

</div>

For the sake of completeness this post is related to [Virtual Baker](https://forum.tezosagora.org/t/virtual-baker/1793/)

Regarding the TZIP itself i think one should lift the ambiguity in the description whether the chosen model for this Virtual Baker is custodial or non-custodial with regard to the XTZ.

_If_ non-custodial (as is the case for regular/real/physical bakers which are non-custodial) then we should refrain from adopting “deposit” in the naming of the api methods. It is quite ambiguous to speak of a “deposit” which usually implies physical transfer and counterparty risk if it is not what is happening under the hood. I am not good with names but i think things along the line of “delegate” or “lock” or “allocate” or w/e seem better instead.

_If_ it is custodial then there’s a problem imho.

---

_[View the full topic](https://forum.tezosagora.org/t/virtual-baker-tzip/2551)._