# a protocol for ETH transfers, even more simpler and with error-handling The reason this protocol is so simple is because the transfers are tracked in the ShardState. These are the `CrossStateCall` objects - they're not receipts because they're in the state. (I know we've been trying to avoid putting things in the state, but as long as the bloat is controlled it won't kill us, will it? I'm assuming these CrossStateCall objects can't be created unless either the sending contract or the objects themselves have some minimum amount of ETH - "deposit as rent"). Because each `CrossStateCall` object in the state represents an isolated transfer, transfers can be individually tracked, and it's easy for the protocol to change a transfer's status (In contrast, a transfer object can't be changed if it is netted with another balance in a balance map. Or pushed out into a block receipt/log where it will forever exist as an immutable record in the historical chain data). Being able to change the transfer object makes it easy to do error-handling and reverts of cross-shard transfers, which the other proposals can't do (I guess they would need additional bitfield/receipt/accumulator constructs added to them, to track if an ETH transfer receipt has been reverted rather than deposited, and so on). With a mechanism that can handle errors, now the protocol can execute contract code when processing the transfer (I guess the other proposals could also run code, but what's the point in running the code if a contract has no choice but to accept a transfer). Like the other proposals, it takes two txn's to complete a transfer. [](https://storage.googleapis.com/ethereum-hackmd/upload_156912f402fdaef8f47ceafe7f03221a.png) It does take two more txn's to do garbage collection on the receipt objects (note that if the sender does go into a state where she waits for a confirmation or revert, then the third txn is not strictly garbage collection). The key thing about all the mechanisms is how they do replay protection. This one achieves replay protection by requiring that the transfer object on Alice's account be deleted before Bob can delete the object on his account. So the object on Alice's account is deleted first (by passing a proof that the object is on Bob's account, which shows that the transfer was completed). And the object on Bob's account is deleted second (by passing a proof of deletion / exclusion on Alice's account). Arguably these garbage collection steps shouldn't be counted as necessary to "complete" a transfer, since the ETH can be used by the recipient immediately after step 2. And the garbage collection can be batched with other sends that come later, or other txn's, so it doesn't seem like significant overhead. [](https://storage.googleapis.com/ethereum-hackmd/upload_9cedb9be3e71184d7c41246c2313f914.png) Please ignore the `CrossStateSlot` and "cross_state" stuff, that's a separate thing; the cross-shard transfer protocol can stand alone. (I just didn't feel like making new diagrams. These go with a [collection of others](https://notes.ethereum.org/SCxJs3mISOG0zRDKD_hXxw) that are about "cross-contract state", an idea for tokens that I've been sketching out separately).