Sabitlenmiş Tweet
In light of recent events, I want to highlight a few key principles about how we think about smart contract development in Move.
First, it’s important to reiterate that this was not an issue with Move itself but rather a domain-specific bug. These types of bugs can exist in any language and is why exhaustive test coverage, audits, and tools like @AsymptoticTech’s Move prover are so important.
In fact, one of the most slept-on features of Move 2024 was the addition of macros. Macros have completely revolutionized the ease of writing tests in Move. If you don’t believe me, take a look at any of @themoveguy‘s Move tests.
New tools like this are great but are only impactful if you incorporate them into your Sui smart contracts – for this reason I have personally dedicated a lot of time to revamping our internal Move testing infrastructure using these newer tools.
Now let’s get in to the purpose of this post. How you design your smart contracts should not be taken lightly – real people's money is at play. The way Move was designed (object model, type system, ability modifiers, ownership model, … the list goes on) helps alleviate certain bugs but no one language is free of bugs altogether. You must spend a lot of time and consideration on every aspect of your smart contract to make sure it remains as secure as possible.
During the designing phase of every product, we always discuss the many ways to design a product [on-chain] and the different trade-offs each design has in terms of security vs other factors. As I’ve mentioned in one of my medium posts: At @AftermathFi, our users’ security is always the foremost priority throughout the design, development, and rollout of all of our products. Below I’ve listed a few design considerations we had and the choices we made that focused on the safety of our users’ funds.
Afterburner Vaults. One of the most requested features we’ve received since the launch of our original Afterburner Vaults was auto-relocking of user positions. This is a tremendous UX improvement over requiring users to relock themselves at set intervals so why haven’t we provided this: we simply can’t.
With the design of our Afterburner Vaults, we favored security of user funds above all else. Because of this, when you deposit funds into our Afterburner Vault, your funds are wrapped by a custom object and transferred directly back to you. This means that you, and only you, have access to your liquidity (should it be any other way?) – the Afterburner Vault does not pool together liquidity nor can any other address, ourselves included, interact with your deposited funds.
This is very important as now it means only you can invoke transactions that interact with this object. In the case that you want to extend your position’s lock, only you can initiate a transaction to do so.
This all comes down to Sui’s unique object-centric data model and the ownership properties associated with objects. In the case of our Afterburner Vaults, there existed a spectrum of implementations with competing security vs convenience properties. We’ve chosen the implementation that best favors security of funds as that is what matters most.
With all of this said, we have been able to replicate auto-relocking on the newest version of our Afterburner Vaults while still preserving the same design and safety I just mentioned. This way you get the best of both worlds!
Shared Custody Pattern. I’ve already dedicated an entire medium post to this pattern but it is too important to not mention here. There are a few domains wherein a user requests that an action be performed on their behalf with their own funds. In our case, these domains are dollar-cost averaging (DCA) and limit orders (LO).
The way that you implement a shared custody model has a large impact on the accessibility of your funds and thus their security. We’ve utilized a 1-of-2 multisig, adding complexity on our part not yours, to provide the most strict level of security around your funds.
At any moment, the number of actors that can interact with your funds is deterministic; for example, your orders are soulbound to the multisig address until either the order is executed–at which point the resulting funds are sent to your address–or the order is canceled–at which point the underlying funds are returned to your address. What is important is that:
i. At no point can a third-party access the order that holds your funds, and
ii. The exact action set that can be performed on your order is static.
Again, we were faced with a spectrum of implementations that contrast security vs convenience and we picked the implementation that provided the highest level of security for you, our user.
Hot Potato Pattern. With any DeFi aggregator, you are composing transactions across a series of third-party contracts. In our DEX aggregator’s case, we are chaining together swaps from many spot-trading venues to perform an asset -> asset swap. The number of integrated protocols in unbounded, as a new AMM can always be released tomorrow, and we must be able to support it while maintaining the intra-route safety of our user’s funds.
There are a few ways you can manage this every growing number of integrations, again creating a spectrum but this time of security vs package maintenance. The design we went with was to whitelist the third-party integrations we have, thus removing the ability to inject a malicious spot-trading venue.
At the start of a route, we wrap user funds into a custom hot potato object and use it during the route to enforce a safe flow of funds through our whitelisted venues. Not only does this provide safety on the routed funds but it also assures legitimacy on all volumes we report; event output is obtained from this hot potato and can only be obtained through a direct route of funds through the trusted, whitelisted trading venues.
The above are only a few examples of the design considerations we faced with our products; it's not even the full list for each product mentioned. When designing any smart contract, you are constantly faced with different design questions that can affect the safety of your product. It is always important to put in the effort to ensure you are always doing best for your users.
English
