# WIP: Design of a transparent/local AVM

**URL:** <https://forum.anoma.net/t/wip-design-of-a-transparent-local-avm/2119>\
**Category:** Protocol Design\
**Tags:** avm\
**Created:** [August 10, 2025, 5:58pm UTC](https://forum.anoma.net/t/wip-design-of-a-transparent-local-avm/2119 "2025-08-10T17:58:58Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\
**Post date:** [September 1, 2025, 6:00am UTC](https://forum.anoma.net/t/wip-design-of-a-transparent-local-avm/2119/4 "2025-09-01T06:00:20Z")

</div>

> [@mariari](#):
>
> However if we zoom out, we provided the context `whatever` to `foo`. Now imagine if `whatever` is an object not a module… then the semantics are the same.

The difference between objects and functions in my model here is that objects have a _history_ and functions do not. Modeling a pure function as an object which has a history doesn’t really make sense. However, the _frontend syntax_ you describe here is totally compatible with a fundamental model which does make a distinction between objects and functions – it is still the case that you can send a message to a function (and get back the result of computing the function), functions just do _not_ have an identity or a history (whereas objects _do_).

> [@mariari](#):
>
> The base layer should be able to have all of these powers as it’s harder to get it later.

OK, noted.

> [@mariari](#):
>
> You are basically making the argument that the object that everything inherits from (proto object) basically has an identity API that gets constructed.

I’m not familiar with what you’re referencing here (“proto object”, “identity API”), do you have a link?

In general, I’m trying to construct something similar to process isolation, such that multiple users can use the VM, create their own objects, etc. while still guaranteeing that objects will behave as expected. More specifically, this ownership restriction provides for _hierarchical transactional objects_, where the objects created by an object can always be “folded into” it (or modeled as within it), since they cannot be called from elsewhere. It is probably possible to relax the restriction somewhat while preserving that, e.g. allow children to call parents, but this introduces some complexities in modeling (would the child-parent call be part of the history, or not? if the former, _where is it_ in history, since the triggering call has not been responded to yet? if the latter, what exactly is this? etc.).

However, it would be easy to drop this restriction and leave the rest of the construction the same, we’d just lose these guarantees. I suppose that this ownership check could even be implemented in the object code (program), and perhaps that would be preferable to putting it in the base model.

> [@mariari](#):
>
> For this instruction why can it not be caught?

I suppose that it could be (some sort of handler when you call an object). This instruction is intended to revert any state changes (“as if the transaction never happened”), so we’d need to think about how that works with catch/handle semantics, but I can imagine a basic first pass (it is as if the call in question never happened, and you have to handle the error) would be reasonable enough, and possible to build on top of.

---

_[View the full topic](https://forum.anoma.net/t/wip-design-of-a-transparent-local-avm/2119)._