Saline Intents: Fixing Crypto

Saline Intents: Fixing Crypto

Why and How we made Intents first class in our platform

In our introduction blog post, we described the Saline Network and its main components without entering into too much detail. Saline Intents are the core of our design and platform, and thus merits some more attention.

In this blog post, we focus our attention on how and where our intents play their role and why they are so much better than “the normal way”.

Let’s dive in💧.

Everybody is Talking About Intents

We’re sure you noticed, but everyone is talking about “intents” in one way or another. Everybody is working hard on trying to integrate them as they come to realise how powerful they are.

We have an edge, though: we don’t have to integrate, we’re baking them in to the core of our platform.

Forget “Intent-Centric”, We Are Intent-Driven

Contrary to the competition trying to build around intents, everything on Saline is an intent. Everything. From simple “transfer X funds from A to B” to more complex in-wallet-defined-AMMs, every single thing happening on the Saline chain is bound to an intent.

While others are attacking some small part of the realm of intents, we’ve made them the DNA of Saline. Every action, from basic transactions to sophisticated in-wallet operations like AMMs, is governed by intent. This is not just a feature, it's the whole platform.

Saline intents has the potential to revolutionise how we view the universe of on-chain possibilities; it’s like the paradigm shift from peer-to-peer payments to a smart-contract world computer.

Understanding Intents

In order to really understand intents and how they compare with the current way of validating transactions, we need to go back to the basics of transaction validation in a typical blockchain (we’ll keep it short, pinky promise! ).

A typical (PoS) blockchain has validators, they are the ones actually running the chain. They are connected to each other, and their job is to take transactions that have been submitted to a mempool, aggregate them in a block, and publish then vote on that block. The actual details vary from one chain to another of course, but typically one of the validators is elected block proposer for that time slot, that validator aggregates a certain number of transactions together into a block, signs it and sends it to the other validator nodes for approval. When enough validators vote that they accept this new block, it then becomes the chain’s head.

So a block is made of several transactions, right? What work do the validators do on a transaction, then? A transaction is typically submitted by a user, and represents a state change that they wish to happen. Anybody can submit any kind of transaction, so it comes down to the validators to, well, validate them; that is to say, determine whether this transaction is allowed or not.

What makes a transaction valid depends on the chain, of course, but there are a few common predicates:

  • The number 1, “universal” check that is made is that the transaction is indeed signed by the originating wallet (that check is almost universal): if a transaction on the chain spends funds from wallet W, we have to be sure that W’s owner agrees with that, otherwise anybody could spend anybody else’s funds, and we don’t want that! (Or… do we? 🤔)
    The way validators know that “W’s owner agrees” is that the transaction has been signed by W’s private key. Since the private key is (hopefully) an absolute secret that is kept and only W’s owner must know about it, if the signature verification passes, then we are as sure as we can be that W’s owner originates the transaction.

  • If the transaction is a transfer of assets (“transfer 10ETH token from wallet 0xA to wallet 0xB”), one of the other universal, basic checks to be made is that there are enough tokens (>= 10ETH) in wallet 0xA, right? If somebody wants to spend 10ETH, they must have at least 10ETH

  • If the transaction is a Smart Contract call, then some additional checks are performed as well, such as:

    • Is the format correct, i.e., are the arguments given the ones expected by the Smart Contract’s functions

    • Did the user include enough fees,

    • Etc.

The rest is pretty much chain-dependent, but that is the gist of it.

So… Intents?

Yes, yes we’re coming to it 😁!

In our case, we’re going to focus on the first point: since anybody can submit transactions to the mempool, one of the first, most logical checks that must be made is to make sure that the wallet whose assets / funds are originating from has granted the permission to do so. In the real world, it’s akin to a point-of-sale terminal asking your credit card’s pin code before granting the payment: this prevents someone who got their hands on your card to spend your money.

So for years and years now, the (only) way blockchain validators made sure that a transaction was deemed valid, was to check the transaction’s signature against the originating wallet’s public key. This is a pretty obvious choice: only the owner of the wallet could sign with the private key, and thus it provided a guarantee.

Can We Do Better?

Of course we can, let’s see how 🧐.

When we think about it, what do we want to check, really? 🤔

When we check that a transaction was signed by the wallet owner’s private key, that’s not what we are really after, are we?

The fact that it is signed is just a way for us to be sure that the wallet owner agrees with the transaction: since they signed it, they have to have agreed with it, right (otherwise, they would not have)?

But actually, the fact that the transaction was signed by them gives us more than just “they agree with that transaction”, it also gives us “they issued the transaction”. The “agree” part is but a side-effect.

So really, when you think about it this way, a normal blockchain’s validators check that the person who issued the transaction is the wallet owner; with the logic that if they issued the transaction, well, they must agree with it.

And this works well: you can’t really cheat the system and it can’t get it wrong (unless someone steals your private key of course). But it is very limiting. Because what we really want to check is that the owner of the wallet agrees with the transaction, we don’t really care if they issued it or not.

A real-life analogy would be if you were giving your bank card to a friend for him to withdraw $135 from an ATM to go buy you something nice, and if you could call your bank and pre-authorise the transaction (“If you see a $135 withdrawal request, please allow it, I’m aware”). Then your friend could go withdraw the cash, with your card, without your PIN, and bring you the item he bought (and hopefully your change).

How convenient would that be?

The key point here is that you meant to allow this $135 transaction, even though you did not do it yourself. And that is all that mattered: even though you were not playing a part in it, what happened is what you wanted to happen.

👉That is what Saline intents allow. 👈

So we just dropped the word: basically, what we have been building is just that: a way for people to broadcast what they want instead of focusing on how to get it. We basically allow users to broadcast their desires, their intentions, their … intents 🤔, and then anything, any transaction that fulfills their wish will be deemed valid.

You can think of it like people automatically pre-approving transactions, but it’s actually (much) more powerful than that.

By the way, did you catch the juicy part?

Let’s bring that last sentence to the front again: “[...] and then anything, any transaction that fulfills their wish will be deemed valid”. That last part is really the gist, the magic of intents: remember how we said earlier that in “traditional blockchains”, a transaction was deemed valid if it was signed by the owner of the Wallet whose funds are being spent? Well here, that’s not a requirement!

With Saline intents, people, anyone can actually submit a transaction that uses your assets, spends your funds, trades, swaps with your account, without necessarily requiring you to either initiate or even sign the transaction !

Why? How?

Well: those transactions will be validated (by validators) if and only if they respect your intents. So e.g. if you installed an intent that allows people to take some of your BTC as long as they give you X ETH or Y SOL for it, well they will be able to do it without your intervention.

Neat!

Saline Intents & The Saline Blockchain

Time to give a tiny bit more information about the system supporting this. We will not dive too deep into the details of the chain (for the sake of keeping this post short), but we will give you a peak. But a later blog post will cover more details, of course ! 😉

Sadly, a platform that makes use of the kind of supercharged intents we just described doesn’t really exist. It’s okay though: we are building it 🛠️ !

At the heart of it all, is a blockchain. A fairly classic-looking PoS blockchain with validator nodes, “just like any ol’ blockchain out there”. Then on this chain, instead of having normal (dumb) wallets, you’re going to have what we call Intentional Wallets. Those wallets -as their name suggests- are crypto wallets on which you can install intents, as many as you want. Those intents are going to be published and recorded on-chain, and they will serve, as we saw before, as the validation model. Any transaction involving your wallet will need to satisfy intents in order to be considered valid: that is, Validators will check that this transaction satisfies an intent on your wallet in order to proceed with it.

You can, at any point, uninstall intents of course: this is meant to be dynamic. You can also limit intents’ effect in frequency (“allow Alice to spend up to 0.05 ETH once a day”) or in time (“accept payment in BTC up to March, 15”).

intents can target both outgoing transactions (restricting who can use your funds and how) and incoming transactions (limit currency for payment, whitelist or blacklist accounts, etc. - no more account dusting!).

You can bundle transactions together so that they happen in a batch or not at all (atomic bundle), you can trigger transactions based on events or data provided on-chain.

You can of course involve signatures if you want to: we said it was not a necessity that transactions were signed thanks to this powerful system, but it doesn’t mean they can’t. It’s trivial to set up signature rules to share spending on an account (“allow Alice to spend up to 0.1 ETH without requiring additional signature, but any amount above needs her signature and mine”), or to involve multi persons: (“to spend from this wallet, at least 2 people from [Alice, Bob, Charly, Dave] must approve (sign)”).

And just to reiterate once-more: this kind of intent behaviour is not an add-on, it’s not a “compatibility layer”, it’s not “an alternative”, like other chains are trying to do. This is not only the default but the only way: everything is intent.


There is another unique aspect of the Saline network which is… pretty cool. So far we have covered the chain, validator nodes, the intent system that drives everything and transactions. As it is classic in PoS chains, validator nodes are going to be rewarded for the work they do: when they validate transactions, they are going to earn reward (money 💵).

Classic.

But there is an extra opportunity here… the whole point of intents, is that you express what you, as a user, want. Not what to do to get it. But someone has to, right? As we said, anyone that looks at the pool of intents can spot two (or more) broadcasted intents and realise they match: so they can submit a transaction that matches them.

Why, though? Because it’s profitable. They have two opportunities to earn something there:

  1. You can “take a fee”. For instance, suppose Alice spots a person that has published an intent saying “anyone can take up to 10BTC from my wallet, as long as they give me at least 19ETH per BTC”. Another person has published an intent stating “anyone can give me BTC and I’m ready to pay up to 19.1ETH per BTC.

    Alice sees that person 2 has, let’s say 200ETH in their wallet. They then submit a batch transaction that says:
    - take 191ETH from Person 2
    - Send 190ETH to Person 1
    - Send 1ETH to Alice
    - Take 10BTC from Person 1
    - Send 10BTC to Person 2
    By doing this, this person just earned 1ETH for themselves by essentially being a market maker.

  2. Even for other-looking transactions where it is not directly possible to take such a fee, we have included in our platform what is called Matcher Reward. Basically, in the same spirit that a validator node is rewarded for doing work (validating), someone who submits transactions matching intents are going to be rewarded a Matcher Reward.

💡
In other words, we believe to be the first platform where submitting transactions can earn you money 🔥.

Conclusion

There is still so much to cover, but we wanted to focus our attention on intents as the Saline platform sees and implements them, because it is crucial to understanding the rest.

We believe that intents are what is going to fix crypto and we are excited to be part of it! As for Saline, it does use intents at its core, but that is not all there is to it! We don’t want to be simply an intent marketplace: we want to unify the users’ experience and Make Crypto Simple. One way is to bring other chains into the equation and this is why the Saline Network is inherently cross-chain (but not only: we are also off-chain) !

This is another aspect we are pretty excited to talk about, so expect a blog post about that soon!

As usual, reach out to us on X, on LinkedIn :)