# Pin high usage Code IDs on Osmosis

**URL:** <https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394>\
**Category:** Proposal Discussion\
**Tags:** passed\
**Created:** [February 9, 2024, 8:55am UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394 "2024-02-09T08:55:17Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![JohnnyWyles](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/johnnywyles/32/3114_2.png) [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)\
**Post date:** [February 9, 2024, 8:55am UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/1 "2024-02-09T08:55:17Z")

</div>

This proposal would pin the code IDs underlying the contracts with the most executions and calls on Osmosis, resulting in lower gas costs per transaction interacting with them.

This will be a routine proposal that maintains the list of pinned contracts by pinning and unpinning specific Code IDs based on contract usage, as the Code IDs in use by a contract may change over time.

## Proposed Code IDs:

| Code ID | Project | Contract | Executes |
| --- | --- | --- | --- |
| 400 | Levana | Markets | 2m+ |
| 162 | CALC | DCA | 1.3m+ |
| 216 | Mars | Red Bank | 140k+ |
| 308 | Mars | Credit Manager | 78k+ |
| 326 | Skip | Skip Swap Entry Point | 59k |
| 429 | Skip | Skip Swap Entry Point2 | 31k |
| 41 | TFM | Router | 50k |
| 6 | Osmosis | Rate Limiter | 0 (Calls not visible but incur gas with every transfer) |
| 148 | Osmosis | Transmuter v1 | 0 (Calls not visible but every transmuter swap incurs gas) |
| 254 | Osmosis | Transmuter v2 | 0 (Calls not visible but every transmuter swap incurs gas) |

**Target On-Chain Date** : 12th February 2024

---

<div class="post-metadata">

**Author:** ![LeonoorsCryptoman](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/leonoorscryptoman/32/208_2.png) [@LeonoorsCryptoman](https://forum.osmosis.zone/u/LeonoorsCryptoman)\
**Post date:** [February 9, 2024, 7:49pm UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/2 "2024-02-09T19:49:09Z")

</div>

Is there an explanation of what pinning exactly does?

---

<div class="post-metadata">

**Author:** ![JohnnyWyles](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/johnnywyles/32/3114_2.png) [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)\
**Post date:** [February 10, 2024, 2:32pm UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/3 "2024-02-10T14:32:06Z")

</div>

It causes those contracts to be held in the wasm cache so they can be accessed more quickly.

I’m unsure of the specification implications for validators, but as these are all frequently used contracts, they will often be loaded for each block anyway so they should be minimal.

Oddly, there doesn’t seem to be any documentation on this on the cosmwasm documentation, and this is the only information I can find on Git Hub.

---

<div class="post-metadata">

**Author:** ![JohnnyWyles](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/johnnywyles/32/3114_2.png) [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)\
**Post date:** [February 12, 2024, 11:07am UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/4 "2024-02-12T11:07:25Z")

</div>

When going to load this proposal, it turns out that any Code ID uploaded by Governance gets auto-pinned!

This means that I am dropping the two Swaprouter codes and the Pyth code from this list as they are already pinned.

It also confirms that we shouldn’t see significant performance impact for validators in other areas since we already have 31 contracts pinned.

When we next do a routine pinning proposal (since at least one of these is getting an update in the next few weeks!) then we should propose unpinning some of the obsolete contracts too.

---

<div class="post-metadata">

**Author:** ![Winfred](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/winfred/32/3074_2.png) [@Winfred](https://forum.osmosis.zone/u/Winfred)\
**Post date:** [February 13, 2024, 12:11am UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/5 "2024-02-13T00:11:30Z")

</div>

> [@JohnnyWyles](#):
>
> I’m unsure of the specification implications for validators, but as these are all frequently used contracts, they will often be loaded for each block anyway so they should be minimal.
> 
> Oddly, there doesn’t seem to be any documentation on this on the cosmwasm documentation, and this is the only information I can find on Git Hub.

Hmmm does it make sense to put forth a prop then?

---

<div class="post-metadata">

**Author:** ![JohnnyWyles](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/johnnywyles/32/3114_2.png) [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)\
**Post date:** [February 13, 2024, 10:07am UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/6 "2024-02-13T10:07:35Z")

</div>

Yes - it preloads these contracts and should reduce the costs.

I tested this on Testnet before loading with a couple of contracts and saw about a 25% gas reduction there.

---

<div class="post-metadata">

**Author:** ![LeonoorsCryptoman](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/leonoorscryptoman/32/208_2.png) [@LeonoorsCryptoman](https://forum.osmosis.zone/u/LeonoorsCryptoman)\
**Post date:** [February 13, 2024, 1:07pm UTC](https://forum.osmosis.zone/t/pin-high-usage-code-ids-on-osmosis/2394/7 "2024-02-13T13:07:00Z")

</div>

> [@JohnnyWyles](#):
>
> I tested this on Testnet before loading with a couple of contracts and saw about a 25% gas reduction there.

That is quite a lot and only improves UX.

> [@JohnnyWyles](#):
>
> When going to load this proposal, it turns out that any Code ID uploaded by Governance gets auto-pinned!

If I understand this correctly this means that every contract with an ID uploaded through governance (so not the contracts uploaded at a later moment through a whitelisted address) are automatically pinned?

Upside, we should indeed not expend weird behaviour on the validator nodes since it is already a common practice. That is quite the relief imo, since it means we are not experimenting on the chain ^^
