Derivative Asset Icons

[smbdy]

Derivative Asset Icons

This proposal is submitted on behalf of BGD Labs.

Background

The Aave ecosystem has several types of derivative tokens (aTokens, wrapped aTokens, umbrella tokens, etc.) that could use clearer visual identities.
Right now, most interfaces just show the underlying asset's icon with some extra context, which works okay in many situations. But as Aave keeps growing and expanding, there are more and more scenarios where this basic approach falls short.
The problem is there's no standard way to visually represent these derivative assets when the surrounding context isn't enough to make it clear what type of token you're looking at.

Use Cases Requiring Distinct Iconography

Here are the main situations where we might need standalone icons for Aave's derivative tokens:

Reward Interfaces

When displaying potential or earned rewards that mix underlying assets and derivatives (aTokens), users need clear visual distinction to understand what they're earning.

Token Selection & Portfolio Views

In token selection dropdowns and portfolio displays where space is limited, distinct iconography helps users quickly identify specific token types without relying on additional text.

Explorers & Wallets

Block explorers and wallet interfaces typically show minimal context around tokens. Distinctive icons would help users immediately understand what type of token they're viewing or transacting with.

In all these cases, we need to communicate token type through the icon alone, without depending on surrounding contextual elements.

Additional Considerations

Multi-Chain Compatibility

With Aave being multi-chain, we need to consider how derivative token icons will interact with network indicators that are commonly placed in corners of token icons. Any solution must account for this potential visual conflict.

Version Differentiation

As Aave evolves from v3 to v4 (which may not have native tokenization of deposits), we need to consider whether and how to visually differentiate tokens from different protocol versions. We might need to decide whether to represent all versions of aUSDC with the same icon or differentiate them based on version.

Possible Solutions

After evaluating several approaches, we've identified the most practical options for implementation:

Icon Frames (Recommended)

Implementing unified frame designs for different types of derivative assets creates a consistent visual language. This approach is currently being used in some interfaces, though without standardization across the ecosystem.

Pros:

• Preserves the original token's visual identity
• Easily distinguishable across the ecosystem
• Compatible with monochromatic icon implementations
• Provides clear categorization of derivative types

Cons:

• Introduces additional visual complexity
• Could reduce legibility when scaled down
• May clash with established asset brand color palettes
• Less effective for assets with non-circular icon shapes
• Current implementations can look unbalanced when placed together

Note: We've developed a solution that allows for automatic generation of token variations using the frames approach. The current frame designs shown are for illustrative purposes only and can be adjusted and improved to address visual balance and other concerns. Additionally, using frames won't be obligatory - when interfaces have other means to clearly convey the token type (such as labels or contextual information), the underlying asset icon can still be used directly.

Continuous Purple Wrapper with Modifiers

A standardized purple wrapper (consistent with Aave branding) combined with distinct modifiers for different token types.

Pros:

• Creates strong brand consistency with Aave's visual identity
• Provides a unified system that can accommodate different token types
• Instantly recognizable as part of the Aave ecosystem

Cons:

• Would still face challenges with network indicators and other modifiers
• May not work well at smaller sizes where modifiers become illegible
• Reduces visibility of the underlying asset's identity

Other Approaches Considered

Badge or Corner Indicators

We could add small badges or corner indicators to the original token icons.

Pros:

• Maintains the original token's visual identity
• With appropriate iconography, can effectively communicate the specific token role
• Creates a scalable system that can accommodate future derivative types
• Follows established UI patterns that users may already be familiar with

Cons:

• May not work effectively at smaller icon sizes where badges become illegible
• Clashes with industry convention of using corner indicators to mark an asset's blockchain/network
• Could create visual confusion when multiple badges are needed (e.g., chain indicator + token type)
• Requires careful placement to avoid interfering with the original icon's key visual elements

Proposed Implementation

Based on the analysis of different approaches and practical considerations, we recommend standardizing the Icon Frames approach with the following improvements:

1. Create a balanced, consistent frame design that works harmoniously across different token icons
2. Develop a clear visual language for different derivative types (aTokens, wrapped aTokens, etc.)
3. Ensure compatibility with network indicators for multi-chain implementations
4. Consider how to handle version differences (v3/v4) in a visually coherent way

Discussion

We believe the Icon Frames approach represents the best solution at this time, balancing visual clarity with practical implementation concerns. However, we welcome community feedback on this proposal to ensure it meets the needs of all ecosystem participants and to further refine the approach before final implementation.

[g-a-v-i-n]

Hey! Gavin from the Aave Labs design team here. Thank you for this proposal.

We've found that visual decorators on token icons, like network badges, borders, or other distinguishing marks, don't scale particularly well. There are an unbounded number of current and future token use cases (e.g., staking, wrapping, lending, and transaction events) that might seem to warrant decoration, but applying multiple layers of signifiers reduces legibility and clarity, especially given the ubiquity and small size of token icons in most interfaces.

For this reason, we believe the decision to visually distinguish modified tokens is best left to app developers, who can account for context-specific needs. Similarly, we don't include suggestions for network badges or transaction event badges in the brand kit. We don't believe it's something that should be treated as a brand-wide responsibility or suggested for use at a brand level.

[eboadom]

No matter the solution, the problem at the moment is very real: if there are no guidelines in a centralized place of the DAO on how to tackle the visual representation of tokens (with/without modifiers), nobody knows, and results in the following outcomes.

• Some teams will care and each one will make their representation, which is maybe (very debatable I would say and contradictory with the concept of centralising Aave's brand) a positive outcome, but removes any brand recognition of the tokens being "official" of the Aave ecosystem. So for example, we BGD will do the wrapper approach in the case of the Umbrella interface, Aave Labs will do labeling, some DEX aggregator will do their own thing, etc. Very frequently this will degenerate into people copying each other, no matter what is formally better.
• Some teams will not want to spend any resources thinking about it, and representation will be, or generic, or misleading.
• Some other teams when they reach out (to multiple contributors, that is how it works) for some guidelines and the answer is "there is no official guideline, is up to each integrator to decide", will get lost in internal bureaucracy and put less integration priority. Or as previously mentioned, maybe go to Etherscan, copy/paste the icon (if it is there, highly frequently not the case) and call it a day.

Maybe the solution is to simply state on the brand guide that to refer to any Aave-product token it should be done via underlying + text reference, and some examples. And then each integrator can handle visuals however they deem better.

But from our side, mainly we wanted to raise awareness of this, because even if not a blocker for the interface we have at hand with Umbrella, it really is a problem not to have guidelines, no matter if those would be "up to each integrator to decide"

[g-a-v-i-n]

Hey Ernesto, good to hear from you. This makes sense - we could offer more direction or perspective on a few common UI patterns we like to use. So maybe to start we'll add a set of simple UI guidelines that can grow over time.

From my point of view I think we'd want to preserve the following general values.

• Integrators and service providers should have the flexibility to design their interfaces in the way they think is best. We don't claim to have perfect ideas or solutions to the many complex UI questions that define this domain. Keeping a light touch on UI guidelines can foster innovation as well.

• Ensure the core brand is consistently applied, especially the logo as it's what users recognize first and most frequently. I think this alignment benefits every contributor in the ecosystem, even when execution details differ across apps. This is the intent of the brand guidelines as they stand now.