Protecting Your Identity and Money on Tula
Attackers don't earn your trust — they borrow trust someone else built. Why signing in, trusting a device and moving money are three different things.
A familiar account sends you a message.
It has the same name, the same phone number and the same profile people have known for years. Nothing immediately looks unusual.
Then the message arrives:
“I have an emergency. Can you send me some money?”
For messaging platforms, this has become one of the hardest forms of fraud to deal with. The attacker does not need to convince you to trust a stranger. They borrow trust that somebody else has already spent years building.
For Tula, where conversations and payments can exist in the same application, we believe that requires a different approach to account security.
The Problem Is Bigger Than a Stolen Password
Account takeover is often described as a password problem.
In reality, an attacker may obtain several pieces of legitimate information at once.
They might know a password. They might obtain an SMS verification code. They might even learn a user's Security PIN.
The dangerous assumption is that enough correct credentials must mean the person entering them is the account owner.
That is not always true.
Imagine an account that has been used on the same phone for months. That established device is still online and communicating normally.
Suddenly, another phone appears.
The new phone has never been associated with the account before, but whoever is operating it knows the phone verification code and the user's Security PIN.
There are two ways a system could interpret that.
The first is:
“Excellent. They passed additional authentication. Give them more access.”
The second is:
“Why does an entirely new device know credentials belonging to an account whose existing device is still active?”
Tula is being designed around the second question.
Knowing the Phone Number Isn't the Same as Being the Person
Phone numbers remain useful. They help people find each other and provide one method of account verification.
But we do not believe a phone number should represent a person's entire digital identity.
A legitimate account may already have an established history of trusted devices and cryptographic identities.
When another device suddenly appears, that continuity matters.
A person buying a new phone and deliberately transferring their account is different from an unknown new device unexpectedly appearing while their original phone remains active.
Our security architecture is designed to recognise that difference.
More Correct Credentials Can Sometimes Mean More Danger
This sounds counter-intuitive.
Normally, entering the correct PIN after entering the correct SMS verification code should make a system more confident.
But security depends on context.
Suppose the established device is still active. No phone transfer was initiated. Then a completely new device appears and successfully presents both the account's phone verification and Security PIN.
At that point, the correct response may not be to trust the new device.
It may be to assume that the credentials themselves have been compromised.
That distinction is particularly important in a financial application.
Conversations and Money Should Have Different Security Boundaries
One of the principles behind Tula is simple:
The ability to communicate should not automatically provide the authority to move money.
A device involved in account recovery or a serious security conflict may still be able to use appropriate non-financial parts of Tula while outgoing financial activity remains protected.
That separation gives the legitimate user time to regain control without giving somebody who has acquired account credentials an immediate path to cash out the wallet.
It also means that entering a Security PIN and one-time code is not considered in isolation. Device trust and the wider security state of the account matter too.
The Payment Destination Matters Too
There is another protection built into the way Tula approaches in-chat payments.
When you initiate an integrated payment from a one-to-one conversation, Tula resolves the beneficiary from the registered account participating in that conversation.
The person you are talking to cannot silently replace the integrated payment destination with a different phone number.
This removes one common scam pattern from the built-in payment experience.
It does not eliminate social engineering. A compromised account can still type:
“Don't send it through Tula. Send it to this other number instead.”
That is why device-security warnings and user awareness still matter.
If somebody unexpectedly asks you to abandon the normal payment flow, that should make you stop and verify what is happening.
Account Takeover Can Attack Both Sides of a Conversation
There are two financial threats we think about.
The first is straightforward:
An attacker takes over your account and tries to steal the money already in your wallet.
The second is more subtle:
An attacker takes over your identity, asks your friends for money, receives those payments into your legitimate account and then tries to move the money out.
The second attack is especially powerful because the scammer is exploiting your reputation rather than simply attacking your balance.
This is why Tula treats receiving money and moving money as different authorities.
Even where funds can enter an account, a device that is not sufficiently trusted should not automatically have the ability to move those funds elsewhere.
Your Contacts Deserve Security Information Too
If someone you have known for years suddenly starts communicating from a newly introduced device, that information can matter — particularly when money enters the conversation.
Tula is developing ways to make meaningful security changes visible without overwhelming users with technical terminology.
That could mean informing a recipient that a contact has recently started using an unverified device or that an account is undergoing security protection.
The objective is not to label legitimate people as criminals.
The objective is to give users information they did not previously have when deciding whether an unusual request is trustworthy.
Encryption Still Matters — But It Solves a Different Problem
Tula uses end-to-end encryption for private messaging, using Signal Protocol-based technology for one-to-one conversations and Messaging Layer Security for groups.
Encryption is essential because it protects the confidentiality of conversations.
But encryption cannot answer every security question.
If malware controls an unlocked phone, or if an attacker successfully becomes an authorised endpoint, encrypted messages still eventually have to be displayed to somebody.
That is why messaging security must also include device trust, recovery protection and account-security controls.
Recovery Shouldn't Be the Weakest Door
Strong authentication is pointless if an attacker can simply click Forgot PIN and bypass it.
Tula's approach is therefore being designed so that account recovery does not automatically create financial trust.
In higher-risk circumstances, recovering an identity may require additional verification, including identity re-verification for users whose financial identity has already been established.
And even successful identity recovery should not necessarily mean unrestricted financial access in the same second.
The objective is to make legitimate recovery possible while making rapid account theft difficult.
What This Means for Tula Users
Security should not require people to understand cryptography.
Users should be able to rely on a few straightforward principles:
Never share your Tula Security PIN or one-time verification code with another person.
Do not install applications sent through suspicious links.
Treat requests to send money outside the normal Tula payment experience with additional caution.
Pay attention when Tula tells you that a contact's device or account security status has changed.
And remember that Tula support will never ask you to disclose your full Security PIN or verification code in a chat.
Building for When Prevention Fails
No responsible security system should assume that phishing, malware, stolen credentials or social engineering will never succeed.
Eventually, somebody will click the wrong link.
Somebody will reveal a code.
A phone will be lost.
A credential will be compromised.
Our job is therefore not only to prevent those events.
It is also to make sure that one mistake does not automatically become complete control over a person's conversations, identity and money.
That is the security philosophy behind Tula:
verify the person, recognise the device, protect the conversation and independently protect the money.

