> For the complete documentation index, see [llms.txt](https://postica.gitbook.io/binding-system-3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://postica.gitbook.io/binding-system-3/overview/proxy-bindings.md). # Proxy Bindings Bind any serialized field, on anything, without writing code. Proxy bindings are the **no-code half** of the system. `Bind` needs the field to be yours and a line of code to declare it. `Rigidbody.mass` is not yours. Neither is `Light.intensity`, a shader property on a material, or anything in a package or an Asset Store plugin. {% hint style="success" %} **Learn by doing:** [A Health Bar with No Driver Class](/binding-system-3/tutorials/health-bar.md) builds one from scratch, including where it is stored and why it needs an update point. [Binding an Asset You Cannot Edit](/binding-system-3/tutorials/binding-assets.md) walks the storage rule below, one branch at a time. {% endhint %} A **proxy binding** solves that by storing the binding *beside* the object instead of inside it. Nothing is written, nothing is recompiled, and the bound component never learns that it happened. For a project, that means the whole wiring layer can be built and rewired by people who do not open source files, and third-party components are bindable out of the box. See [Two Ways to Bind](/binding-system-3/overview/two-ways-to-bind.md) for the comparison with `Bind`, including the one behaviour that genuinely differs: update points. ## How to make one Right click the field's label in the Inspector and choose **Enable Binding**. It works the same whether you are looking at a component in a scene, a prefab, or an asset selected in the Project window, and in a floating Properties window as well as in the Inspector. With several objects selected, **Enable Binding** binds the field on every one of them, and **Disable Binding** removes it from every one that has it. A path picked afterwards reaches the others too. See [Editing several bindings at once](/binding-system-3/overview/binding.md#several-selected-objects-with-a-proxy-binding).

This does not bind the field. It makes the field bindable, and a **hexagon toggle** appears beside its label. Click that, and the field is replaced by the same bind row you get on a `Bind` field, with the same source modes, the same menu, the same converters and modifiers, the same Live Debug. Everything in the rest of this documentation applies unchanged. It is the same hexagon a `Bind` field has. **Enable Binding** gives an ordinary field the toggle a bind field is born with. With [Micro UI](/binding-system-3/overview/micro-ui.md) on, the field keeps its own control once bound, and the hexagon opens the binding in a popup. ### The toggle and Disable Binding are different actions

Action	What it does
The hexagon toggle	Switches between bound and unbound and keeps the setup. Off, the field is a plain value you can type into. On, the binding is back exactly as you left it: source, path, converters, modifiers. Per instance, so the same component can be bound in one scene and not in another.
Disable Binding	Removes the binding entirely. The setup is discarded and the hexagon disappears, leaving the original field with its value.

That distinction is the point of having two states. Dropping to a hand-typed value to test something, then restoring a fully configured binding, costs two clicks and loses nothing. ## What can be bound

Target	What you can bind
Serialized fields	Any serialized field on any component, including private ones with `[SerializeField]`.
Project assets	The same, on an asset rather than a scene object: `ScriptableObject`s, materials, physics materials, presets, anything with a serialized field in its Inspector. Select it in the Project window and right click the field.
Material properties	Shader properties in the material Inspector, including Tiling and Offset on a texture, which bind as `Vector2`.
UnityEvent slots	The target of a `UnityEvent` entry, so an event can drive a bound value.

{% hint style="success" %} The asset case is worth calling out, because it is the one people do not expect. A `ScriptableObject` holding your game's tuning data can have its own fields bound to other assets, and those bindings travel with the asset rather than with any scene. {% endhint %} {% hint style="info" %} Non-serialized properties, such as `Transform.position`, are not proxy-bindable targets, because there is nothing serialized to attach the binding to. They are perfectly bindable as **sources**, which is the far more common need. {% endhint %} ## Where they are stored This is the part worth understanding, because it decides what version control sees. The rule is that a binding is stored **as close to the bound object as that object allows**.

The bound object lives in	Where the binding is stored
A scene	A hidden `ProxyBindings` component on the same GameObject, saved in the scene.
A prefab	The same hidden component, saved in the prefab. It travels with every instance.
A `ScriptableObject`	A hidden `Bindings` sub-asset of that asset. It moves, copies and deletes with its owner, and shows up in that asset's own diff.
Any other project asset	The shared `global-bindings` asset in the Bindings folder. Materials and textures are the usual examples.

The scene component is hidden from the Add Component menu and runs at execution order **-320000**, so bindings are in place before anything else in the frame. The sub-asset is hidden too, unless you turn on [Visualization ▸ Proxy Bindings](/binding-system-3/reference/settings.md#visualization), which reveals both. Whether the sub-asset is visible is saved in its asset's file, because that is where the Project window reads it from. Switching the option therefore rewrites and reimports every asset that holds proxy bindings, so expect those files in your next diff. {% hint style="info" %} The sub-asset branch is specifically `ScriptableObject`, not "assets that can hold sub-assets". A material could hold one and does not get one. It is created lazily and removed again when the last binding on that asset is disabled, so an asset you experimented with does not keep an empty companion object. {% endhint %} {% hint style="danger" %} Do not delete the `global-bindings` asset in the Bindings folder. It is the fallback store for every bound object that cannot carry a sub-asset of its own, and deleting it removes all of those bindings at once. Scenes, prefabs and sub-asset-capable assets are unaffected, because their bindings are embedded. {% endhint %} ## Seeing what an object drives Turn on [Visualization ▸ Proxy Bindings](/binding-system-3/reference/settings.md#visualization) and any GameObject that owns proxy bindings shows them as a read-only list in its Inspector. A `ScriptableObject` shows its **Bindings** sub-asset under it in the Project window. It is the quickest way to answer "what is this object wired to?" without opening a diagnostics window.

The proxy binding list on an inspected object

For the same question at project scale, use [Bindings Dependencies](/binding-system-3/project-tools/diagnostics/dependencies.md). ## Update points, and why only this mode has them A `Bind` field is resolved lazily: your code reads it, and that read *is* the update. A proxy binding has no such moment, because nothing in the target component knows the binding exists. So the engine moves the value instead, and you say when. That is why **Update Points** appears in the bind menu here and nowhere else, and why the full set is available: **EDITOR**, **UPDATE**, **LATE UPDATE**, **FIXED UPDATE**, **RENDER** and the lifecycle points, each with an optional interval. It is more control than a `Bind` field is ever offered, and it is the reason this mode can drive things at edit time and follow animation precisely. {% hint style="warning" %} A new proxy binding starts with **UPDATE** and **Optimized Update** already on, so it works as soon as it has a source and a path. A proxy binding with **no** update point does nothing on its own. That is a fault when it was not intended, and a [deliberate configuration](/binding-system-3/overview/modes-and-updates.md#no-update-point-on-purpose) when the binding is driven from code with `UpdateBind`, or by a `UnityEvent`. {% endhint %} ## Performance notes Being engine-driven has two consequences worth planning around. 1. **The binding runs whether or not anyone needs the value.** Choose the cheapest stage that works, and consider an [interval](/binding-system-3/overview/modes-and-updates.md#intervals) and [Optimized Update](/binding-system-3/overview/modes-and-updates.md#optimized-update), which together close most of the gap to a lazy `Bind`. 2. **They use** [**phased bindings**](/binding-system-3/project-tools/performance/phased-bindings.md) when that setting is on, which it is by default. On an update where the source value has not changed, that skips the converter and the modifiers outright and leaves only the source read. An Inspector with a great many proxy bindings takes longer to draw, since each one is a full bind row. If that becomes noticeable, [Performance Mode](/binding-system-3/project-tools/performance/performance-mode.md) drops the decorative parts, and it can engage automatically above a threshold you set. ## When to reach for which

Situation	What to use
You are not sure	Proxy binding. Being wrong costs one click.
The field is in a package, in Unity, or in a plugin	Proxy binding, the only option.
A shader property, or a field on an asset	Proxy binding, the only option.
A designer has to be able to change the wiring	Proxy binding. No source file, no recompile, no programmer.
You want to see the connection work while authoring	Proxy binding, with the EDITOR update point.
Your own code already reads the value every frame	`Bind<T>`. The read is the update, so it is free.
The value has to be exact at a precise moment in your code	`Bind<T>`, read at that moment.
Hundreds of bind rows on one object	Either, and read Performance Mode.

## Related pages * [Two Ways to Bind](/binding-system-3/overview/two-ways-to-bind.md): this mode next to the code one. * [The Bind Field](/binding-system-3/overview/binding.md): every control on the row, which is the same row here. * [Bindings Monitor](/binding-system-3/project-tools/diagnostics/bindings-monitor.md): what all these proxies cost at runtime. * [Settings](/binding-system-3/reference/settings.md): the Bindings folder location, and the visualization toggles.