A Smaller Core. A Wallet That Can Do More.

This article explains how Powerups let Salmon add useful capabilities while keeping the wallet core focused and the user in control.

Every wallet can add another button.

The harder task is explaining what enters the picture when the user presses it.

A swap depends on a route. A card purchase involves a provider that collects personal information. A portfolio service may receive a wallet address and read everything associated with it.

Those services do different jobs and expose the user to different risks. Most wallets present them as if they were simply part of the interface.

Powerups are Salmon’s model for making the distinction visible.

The core handles what must always work

The most sensitive parts of a wallet should also be the most predictable.

Salmon Core is responsible for creating and recovering accounts, protecting keys, reading balances, building transactions, explaining proposed actions, requesting approval, signing, and broadcasting.

That foundation is always present. It does not depend on which additional capabilities a user chooses.

Powerups sit outside that foundation. They help with specific outcomes such as swapping, staking, or moving between fiat and crypto. They can be useful without receiving the wallet’s full authority.

This produces a simple division of responsibility:

Powerups propose actions. Salmon Core validates, explains, requests approval, signs, and broadcasts.

The boundary matters even when Salmon writes both sides. Internal code can contain a mistake. A dependency can behave unexpectedly. A route can return an unsafe result. Limiting what a component can do reduces the damage any one failure can cause.

Optional means optional

The base wallet should not force every workflow onto every user.

A trader, a validator participant, an NFT collector, and someone who mainly uses stablecoins do not need the same wallet. A fixed super-app gives all of them the combined complexity of every possible use case.

Powerups let users choose the capabilities relevant to them.

Swap ships as part of the current wallet experience and can be disabled. Stake is the next planned Powerup, followed by On/Off Ramp; development of those two has not started. Other ideas remain candidates rather than commitments.

The catalogue should grow because a capability solves a clear problem, not because an empty slot needs another icon.

The provider should not disappear

Convenience often depends on making infrastructure invisible. That can improve an interface, but it can also hide information the user needs.

Before a sensitive Powerup is used, Salmon should answer four questions:

• Who provides the service?
• What funds or information does that provider receive?
• How long does the exposure last?
• How does the user exit or recover?

The answers vary sharply.

An onchain swap may settle as one transaction or fail without completing. A card provider may connect identity documents to a wallet address. A portfolio service may never touch an asset while still learning a detailed financial history.

These differences cannot be represented honestly by one generic safety badge.

Naming the provider and explaining the exposure does not guarantee a good outcome. It prevents the interface from disguising a business relationship as a neutral wallet function.

Permissions should describe a job

Most software permissions are broad enough to become meaningless.

A wallet needs a stricter standard because a vague permission can become a financial risk.

Each Powerup should receive only the access required for its stated job. A portfolio capability can read balances and activity. A swap capability can request quotes and prepare a proposed exchange. A news capability has no reason to approach signing.

If a capability needs more access, the user should see the request when it changes. If the Powerup is disabled, its access should end.

Disabling a Powerup does not change what the user owns. Balances and positions exist onchain, independently of a local setting. Salmon Core continues to read those positions and can direct the user back to the relevant capability when management is required.

The setting controls the interface and its access. It does not control the asset.

Clear approval is part of the product

A confirmation button is not enough.

Before the wallet asks for authority, it should explain what the user gives, what the user receives, which provider or protocol is involved, what fees apply, and what could fail.

The numbers shown in that confirmation should come from the core’s interpretation of the transaction, not from the Powerup asking to be trusted. Where possible, the core should simulate the outcome and compare it with the action the Powerup declared.

This is the practical meaning of keeping intelligence and authority separate. A capability can help the user find a route. It cannot approve its own work.

A product model, not a feature gallery

Powerups are not a race to publish the largest catalogue.

The foundation comes first: restricted interfaces, readable permissions, provider disclosure, transaction interpretation, and a reliable path back to Salmon Core for approval.

Success should be measured by what happens after a capability ships. Do users complete the action they came for? Do they understand the tradeoff? Do they return because the workflow remains useful? Does the integration justify the cost and risk of maintaining it?

Those questions keep modularity from becoming another word for feature accumulation.

A smaller core gives Salmon a stable center. Powerups let the product expand around it without treating every integration as equally trusted or every feature as permanently necessary.

The result should feel simple to the user for the right reason: not because dependencies are hidden, but because their boundaries are clear.