2026-02-08 02:00:17
Rust has long had an inconsistency with C regarding the alignment of 128-bit integers on the x86-32 and x86-64 architectures. This problem has recently been resolved, but the fix comes with some effects that are worth being aware of.
\ As a user, you most likely do not need to worry about these changes unless you are:
i128/u128 rather than using align_of
improper_ctypes* lints and using these types in FFI\ There are also no changes to architectures other than x86-32 and x86-64. If your code makes heavy use of 128-bit integers, you may notice runtime performance increases at a possible cost of additional memory use.
\ This post documents what the problem was, what changed to fix it, and what to expect with the changes. If you are already familiar with the problem and only looking for a compatibility matrix, jump to the Compatibility section.
Data types have two intrinsic values that relate to how they can be arranged in memory; size and alignment. A type's size is the amount of space it takes up in memory, and its alignment specifies which addresses it is allowed to be placed at.
\
The size of simple types like primitives is usually unambiguous, being the exact size of the data they represent with no padding (unused space). For example, an i64 always has a size of 64 bits or 8 bytes.
\ Alignment, however, can vary. An 8-byte integer could be stored at any memory address (1-byte aligned), but most 64-bit computers will get the best performance if it is instead stored at a multiple of 8 (8-byte aligned). So, like in other languages, primitives in Rust have this most efficient alignment by default. The effects of this can be seen when creating composite types (playground link):
use core::mem::{align_of, offset_of};
#[repr(C)]
struct Foo {
a: u8, // 1-byte aligned
b: u16, // 2-byte aligned
}
#[repr(C)]
struct Bar {
a: u8, // 1-byte aligned
b: u64, // 8-byte aligned
}
println!("Offset of b (u16) in Foo: {}", offset_of!(Foo, b));
println!("Alignment of Foo: {}", align_of::<Foo>());
println!("Offset of b (u64) in Bar: {}", offset_of!(Bar, b));
println!("Alignment of Bar: {}", align_of::<Bar>());
\ Output:
Offset of b (u16) in Foo: 2
Alignment of Foo: 2
Offset of b (u64) in Bar: 8
Alignment of Bar: 8
\
We see that within a struct, a type will always be placed such that its offset is a multiple of its alignment - even if this means unused space (Rust minimizes this by default when repr(C) is not used).
\ These numbers are not arbitrary; the application binary interface (ABI) says what they should be. In the x86-64 psABI (processor-specific ABI) for System V (Unix & Linux), Figure 3.1: Scalar Types tells us exactly how primitives should be represented:
| C type | Rust equivalent | sizeof | Alignment (bytes) |
|----|----|----|----|
| char | i8 | 1 | 1 |
| unsigned char | u8 | 1 | 1 |
| short | i16 | 2 | 2 |
| unsigned short | u16 | 2 | 2 |
| long | i64 | 8 | 8 |
| unsigned long | u64 | 8 | 8 |
\n The ABI only specifies C types, but Rust follows the same definitions both for compatibility and for the performance benefits.
If two implementations disagree on the alignment of a data type, they cannot reliably share data containing that type. Rust had inconsistent alignment for 128-bit types:
println!("alignment of i128: {}", align_of::<i128>());
// rustc 1.76.0
alignment of i128: 8
printf("alignment of __int128: %zu\n", _Alignof(__int128));
// gcc 13.2
alignment of __int128: 16
// clang 17.0.1
alignment of __int128: 16
(Godbolt link) Looking back at the psABI, we can see that Rust has the wrong alignment here:
| C type | Rust equivalent | sizeof | Alignment (bytes) |
|----|----|----|----|
| __int128 | i128 | 16 | 16 |
| unsigned __int128 | u128 | 16 | 16 |
\n It turns out this isn't because of something that Rust is actively doing incorrectly: layout of primitives comes from the LLVM codegen backend used by both Rust and Clang, among other languages, and it has the alignment for i128 hardcoded to 8 bytes.
\ Clang uses the correct alignment only because of a workaround, where the alignment is manually set to 16 bytes before handing the type to LLVM. This fixes the layout issue but has been the source of some other minor problems.12 Rust does no such manual adjustment, hence the issue reported at https://github.com/rust-lang/rust/issues/54341.
There is an additional problem: LLVM does not always do the correct thing when passing 128-bit integers as function arguments. This was a known issue in LLVM, before its relevance to Rust was discovered.
\ When calling a function, the arguments get passed in registers (special storage locations within the CPU) until there are no more slots, then they get "spilled" to the stack (the program's memory). The ABI tells us what to do here as well, in the section 3.2.3 Parameter Passing:
Arguments of type
__int128offer the same operations as INTEGERs, yet they do not fit into one general purpose register but require two registers. For classification purposes__int128is treated as if it were implemented as:typedef struct { long low, high; } __int128;with the exception that arguments of type
__int128that are stored in memory must be aligned on a 16-byte boundary.
\
We can try this out by implementing the calling convention manually. In the below C example, inline assembly is used to call foo(0xaf, val, val, val) with val as 0x11223344556677889900aabbccddeeff.
\
x86-64 uses the registers rdi, rsi, rdx, rcx, r8, and r9 to pass function arguments, in that order (you guessed it, this is also in the ABI). Each register fits a word (64 bits), and anything that doesn't fit gets pushed to the stack.
/* full example at <https://godbolt.org/z/5c8cb5cxs> */
/* to see the issue, we need a padding value to "mess up" argument alignment */
void foo(char pad, __int128 a, __int128 b, __int128 c) {
printf("%#x\n", pad & 0xff);
print_i128(a);
print_i128(b);
print_i128(c);
}
int main() {
asm(
/* load arguments that fit in registers */
"movl $0xaf, %edi \n\t" /* 1st slot (edi): padding char (`edi` is the
* same as `rdi`, just a smaller access size) */
"movq $0x9900aabbccddeeff, %rsi \n\t" /* 2nd slot (rsi): lower half of `a` */
"movq $0x1122334455667788, %rdx \n\t" /* 3rd slot (rdx): upper half of `a` */
"movq $0x9900aabbccddeeff, %rcx \n\t" /* 4th slot (rcx): lower half of `b` */
"movq $0x1122334455667788, %r8 \n\t" /* 5th slot (r8): upper half of `b` */
"movq $0xdeadbeef4c0ffee0, %r9 \n\t" /* 6th slot (r9): should be unused, but
* let's trick clang! */
/* reuse our stored registers to load the stack */
"pushq %rdx \n\t" /* upper half of `c` gets passed on the stack */
"pushq %rsi \n\t" /* lower half of `c` gets passed on the stack */
"call foo \n\t" /* call the function */
"addq $16, %rsp \n\t" /* reset the stack */
);
}
\ Running the above with GCC prints the following expected output:
0xaf
0x11223344556677889900aabbccddeeff
0x11223344556677889900aabbccddeeff
0x11223344556677889900aabbccddeeff
\ But running with Clang 17 prints:
0xaf
0x11223344556677889900aabbccddeeff
0x11223344556677889900aabbccddeeff
0x9900aabbccddeeffdeadbeef4c0ffee0
//^^^^^^^^^^^^^^^^ this should be the lower half
// ^^^^^^^^^^^^^^^^ look familiar?
\ Surprise!
\
This illustrates the second problem: LLVM expects an i128 to be passed half in a register and half on the stack when possible, but this is not allowed by the ABI.
\ Since the behavior comes from LLVM and has no reasonable workaround, this is a problem in both Clang and Rust.
Getting these problems resolved was a lengthy effort by many people, starting with a patch by compiler team member Simonas Kazlauskas in 2017: D28990. Unfortunately, this wound up reverted. It was later attempted again in D86310 by LLVM contributor Harald van Dijk, which is the version that finally landed in October 2023.
\ Around the same time, Nikita Popov fixed the calling convention issue with D158169. Both of these changes made it into LLVM 18, meaning all relevant ABI issues will be resolved in both Clang and Rust that use this version (Clang 18 and Rust 1.78 when using the bundled LLVM).
\
However, rustc can also use the version of LLVM installed on the system rather than a bundled version, which may be older. To mitigate the chance of problems from differing alignment with the same rustc version, a proposal was introduced to manually correct the alignment like Clang has been doing. This was implemented by Matthew Maurer in #116672.
\ Since these changes, Rust now produces the correct alignment:
println!("alignment of i128: {}", align_of::<i128>());
// rustc 1.77.0
alignment of i128: 16
\ As mentioned above, part of the reason for an ABI to specify the alignment of a datatype is because it is more efficient on that architecture. We actually got to see that firsthand: the initial performance run with the manual alignment change showed nontrivial improvements to compiler performance (which relies heavily on 128-bit integers to work with integer literals). The downside of increasing alignment is that composite types do not always fit together as nicely in memory, leading to an increase in usage. Unfortunately this meant some of the performance wins needed to be sacrificed to avoid an increased memory footprint.
The most important question is how compatibility changed as a result of these fixes. In short, i128 and u128 with Rust using LLVM 18 (the default version starting with 1.78) will be completely compatible with any version of GCC, as well as Clang 18 and above (released March 2024). All other combinations have some incompatible cases, which are summarized in the table below:
| Compiler 1 | Compiler 2 | status | |----|----|----| | Rust ≥ 1.78 with bundled LLVM (18) | GCC (any version) | Fully compatible | | Rust ≥ 1.78 with bundled LLVM (18) | Clang ≥ 18 | Fully compatible | | Rust ≥ 1.77 with LLVM ≥ 18 | GCC (any version) | Fully compatible | | Rust ≥ 1.77 with LLVM ≥ 18 | Clang ≥ 18 | Fully compatible | | Rust ≥ 1.77 with LLVM ≥ 18 | Clang < 18 | Storage compatible, has calling bug | | Rust ≥ 1.77 with LLVM < 18 | GCC (any version) | Storage compatible, has calling bug | | Rust ≥ 1.77 with LLVM < 18 | Clang (any version) | Storage compatible, has calling bug | | Rust < 1.773 | GCC (any version) | Incompatible | | Rust < 1.773 | Clang (any version) | Incompatible | | GCC (any version) | Clang ≥ 18 | Fully compatible | | GCC (any version) | Clang < 18 | Storage compatible with calling bug |
\
As mentioned in the introduction, most users will notice no effects of this change unless you are already doing something questionable with these types.
\ Starting with Rust 1.77, it will be reasonably safe to start experimenting with 128-bit integers in FFI, with some more certainty coming with the LLVM update in 1.78. There is ongoing discussion about lifting the lint in an upcoming version, but we want to be cautious and avoid introducing silent breakage for users whose Rust compiler may be built with an older LLVM.
Trevor Gross on behalf of The Rust Lang Team
\ Also published here
\ Photo by Suzanne D. Williams on Unsplash
\
2026-02-08 02:00:02
What’s up, world? It’s Ese.
\ I take the subway here in New York City quite often: It’s my shuttle to and from uptown visits with family, downtown museum trips and dinners with friends, and cross-borough appointments and shopping trips.
\ Very fortunately, I’ve never been a victim of a violent crime while traveling underground, a bit of anecdata that probably means little to anyone who has been following the news about our subways lately. In the past month alone, the subways have been host to a wild rush-hour shooting, multiple stabbing incidents, and other random assaults.
\ These scary incidents have prompted dramatic official reactions: Early last month, Governor Kathy Hochul ordered 750 National Guard soldiers into the subway to scan bags at high-volume stations. Mayor Eric Adams also added an additional 800 police officers to the system.
\ Of course, it’s critical to say here that while perceptions of safety are important, the subway system is relatively safe, based on the available evidence. More than three million riders take the train each day, and the vast majority do so without incident. According to a recent New York Times analysis of data from mid-2022, there was around one violent crime per one million rides on the subway. Since then, the Times reported that “the overall crime rate has fallen and ridership has increased, making the likelihood of being a victim of a violent crime even more remote.”
\ Even Mayor Adams and the NYPD report that the subway system is getting safer. On Wednesday, the NYPD announced a reduction in subway crimes, saying overall transit crime fell almost 24 percent in the first quarter of 2024. Officials credited the reduction in reported incidents to additional officers working in the transit system.
\ “It is highly encouraging to see the tangible results of our hard work—the investment we are making is clearly paying dividends,” said NYPD commissioner Edwin Caban in the announcement. “We vow to maintain our tight focus on the drivers of crime in order to improve transportation safety—and perceptions of safety—at every station, on every train, at all hours of the day and night. That is what New Yorkers expect and deserve.”
\ Part of that investment includes Adams’ embrace of crime-fighting tech. Last week, Adams announced the city would pilot gun detectors—yes, a lot like metal detectors but for guns—in the subway. The trial is the latest in a series of tech solutions that Adams, a former cop, is exploring for subway safety: Last September, Adams announced a pilot program with Knightscope, a company that makes autonomous security robots, at Times Square, the busiest of the subway’s 472 stations. The robot, which weighs more than 400 pounds, is equipped with a camera to record images and videos. It also has a call button to report incidents.
\ Crime-fighting tech like robots and gun detectors aside, there is one technology I do think would make the subways a lot safer: barriers at the edges of the platforms.
\ Just last week, a man was pushed onto the tracks in front of an oncoming 4 train in Harlem. Police say the deadly attack was unprovoked. And this week, I heard from a colleague that ANOTHER person was struck by a train earlier in the day.’
\ I thought: In 2024, why aren’t officials investing in technology that makes it difficult to push someone in front of a train or prevents deaths by suicide on the tracks?
\ To its credit, the MTA, which is controlled by New York State, published a sprawling, 3,920-page report on its yearslong feasibility study for platform screen doors in February 2020. Turns out station platform widths, space for accessibility clearance, multiple train car types, limited height, and structural integrity of platform edges are among the factors complicating a full rollout of platform screen doors in such an old system. The agency estimated that system-wide feasibility for a platform screen door program is 27%, or 128 of the 472 stations.
\ Price is a challenge, too. The total cost for installing full-height gates in just those 128 stations would be over $7 billion, the agency found, and half-height gates would cost $6.53 billion. Once installed, the agency would have to spend more than $119 million each year to maintain the doors.
\ The closest thing we have to subway gates in the city right now are metal screens, installed earlier this year in one station in Manhattan. These barriers, which are bolted to the ground, aren’t mechanically operated: they don’t slide open or closed, so one can still fall or be pushed through the open space at the platform edge. Sadly, in a timeline where we may one day have gun detectors and massive robots patrolling underground, these steel fences appear to be the best tool we have to curb preventable subway deaths.
\ Thanks for reading! As always, you can reach me with thoughts at [email protected].
\ Ese Olumhense
Investigative Reporter
The Markup
Credits
\ Also published here
\ Photo by Eddi Aguirre on Unsplash
2026-02-08 01:00:04
With this post we aim to address the community’s questions about the lack of official console ports through the Godot Foundation. Unfortunately, there has been a lot of mixed messaging on this topic in the past. The truth is that a lot of important information is locked behind vendor-specific NDAs, so even those in the know are often unable to fully explain the situation. Nonetheless, here we attempt to describe the current blockers to the best of our ability, and detail what that means for you as developers looking to port to console.
First and foremost, with the situation being as it is, the Godot Foundation does not have active plans to work on console platform ports.
\ This may change in the future, especially if it becomes possible to share console ports that are truly Free and Open Source (i.e. not locked behind any NDAs or paywalls).
\ However, this does not mean you cannot bring your game to these platforms, see here for a list of unofficial vendors providing porting services.
We wrote a blog post a few years ago explaining the barriers to providing console ports: https://godotengine.org/article/godot-consoles-all-you-need-know/. We want to expand on that post and include more detail about what led to our decision not to produce console ports through our non-profit organization.
\ From a high level, here are three barriers we are facing:
\ Of these three issues, only the inability to license ports as open source is a deal breaker for the Godot Foundation. The other two simply make it very expensive and undesirable for us to consider providing ports officially. Let’s look at these issues one by one.
Broadly speaking, there are two types of console ports:
\ Using approved middleware is ideal for game developers as they can trust that the game they develop will work on the target platform. A crucial part of approved middleware is that the engine provider accepts liability for any problems with the port. In other words: if there is a problem with the engine itself in regards to security, licensing, etc. then the middleware provider takes the liability and the game developer is safe.
\ The Godot Foundation is not able to take such liability, as it does not provide commercial support for any of its projects. In fact, this refusal to accept liability is core to the MIT license that Godot uses (more on licensing later).
\ From a liability perspective alone, anyone could provide source code for console ports in a closed environment only available to NDA holders that fully disclaims all sources of liability. The great news is that the first ports of this sort are surfacing already! They are difficult to find as you often need to have the relevant NDAs to discover them. In the case of a Nintendo Switch port, RAWRLAB Games was able to publicly announce their open-source Nintendo Switch port for Godot Engine users. This sort of community effort is amazing and is something that the Godot Foundation heavily encourages!
\ While we are very excited about this progress, we aren’t going to put our limited Godot Foundation resources behind developing such ports either, for the following reasons.
The Godot Foundation as an entity receives donations from the community to spend on the development of the Godot Engine as a project. That being said, these resources — which currently pay for about 10 people to work on anything from release management to writing code to organizational tasks — are nothing in comparison to the amount of voluntary time that you as a community invest in making the Godot Engine as successful as it has become in the recent years. At the time of writing, 2,634 volunteer contributors are listed as authors of the project!
\ We are gifted with a huge community of such passionate contributors, and put a lot of weight on enabling and encouraging new people to join into the process. Sadly, the number of potential contributors with console experience, access to console vendor NDAs, and devkits is very small in comparison.
\ This would flip our current situation on its head. With console ports, nearly all the work would have to be done by the Godot Foundation, which means the cost per platform would be disproportionately higher than for all other platforms we officially maintain (i.e. Windows/Linux/Mac, web and mobile). Even more so if we want the console ports to be the same quality as the rest of our code base, including maintenance and catering to new hardware.
\ This is both inefficient, and unfair to community members who don’t plan to release on consoles. A significant portion of their donation would go towards maintaining platform ports for closed systems which they don’t have access to (and can’t have access to without spending a significant amount of money).
\ It is also worth keeping in mind that Godot is a very large and fully featured game engine compared to other open source game engines out there. We have extensive third party libraries, dedicated 2D and 3D renderers, networking, multiple scripting language support, external plugins, etc. It would be an undertaking of immense effort and time to create a console port that fully supports all Godot has to offer.
\ Finally, because we do have limited resources, diverting any resources away from the core product to work on consoles would require slowing down development of Godot itself to create and maintain the console ports.
The board of the Foundation strongly feels that we should only be using funds to develop Free and Open Source Software (FOSS). We are committed to being a fully FOSS project. Further, we credit our FOSS stance with a lot of our success. When you contribute to Godot, you become a part owner of the project and you don’t sign away your rights to your code in a CLA (contributor license agreement). This way, every contributor has assurance that they have worked to benefit all users, and that their contribution won’t be yanked away from them by the entity controlling development.
\ In short, we want to develop Godot in a way that ensures that anyone who downloads Godot can be assured that they own the copy of Godot that they are using. We do that by remaining dedicated to two things:
We use the MIT license to distribute Godot. Unfortunately, the MIT license is incompatible with providing official middleware because it very clearly states that we won’t take on liability for the code (i.e. you can’t sue us if it turns out that Godot doesn’t work for you, or has a bug that costs you money — which is important since we only operate on your donations to begin with). Further it is incompatible with non-middleware ports as well because such ports would have to be limited in their distribution to authorized console developers only.
\ Accordingly, any console port would have to be distributed under a modified MIT license or another license that allowed us to limit who the code could be distributed to (and potentially limit the distribution in other ways). In either case, we would have to compromise our FOSS ideals, which we feel are our strength.
Further, and more importantly, we do all of our development in the open. Everything is on GitHub or our developer chat (chat.godotengine.org, which is open to all who want to discuss development of the project or just listen in). We don’t want to put ourselves in a situation where our development has to happen behind closed doors and away from the eyes of the community, and this is exactly what would be required by the console vendors.
\ Right now, anyone can see the volume of work that is happening on Godot by visiting Godot’s GitHub page. They can also hang out on the chat and get a feel for the process of development or ask questions directly to the developers. If we shift our development behind closed doors, then you have to take our word that things are progressing and that the donations are being put to good use (unless you have the relevant NDAs).
\ Finally, we want to assure every contributor and every donor that their contribution benefits all Godot users. If we put donations towards a console port that is hidden behind closed doors, then we are taking resources away from everyone and putting them into something that only benefits a select few and that isn’t something we want to do.
For the above reasons, the Foundation has decided not to provide console ports for now. Not because we categorically do not want to, quite the opposite actually, but because it currently is not feasible for us and would require to compromise the things that make Godot great. In the future, if console manufacturers become more open about the licensing of console ports in particular, and maybe even agree to support that endeavor financially, then we will happily reconsider. We would love to have official console ports alongside the existing ones from third-party vendors for all of our community to use.
By Emi
\ Also published here
\ Photo by Kamil Switalski on Unsplash
\
2026-02-08 00:02:44
How are you, hacker?
🪐 What’s happening in tech today, February 7, 2026?
The HackerNoon Newsletter brings the HackerNoon homepage straight to your inbox. On this day, we present you with these top quality stories. From Everyone Says AI Is Insecure, So I Measured It to HackerNoon Projects of the Week: Pantry Pilot, RecomendeMe Charmpay, let’s dive right in.
By @christiaanb33k [ 10 Min read ] The uncomfortable but ultimately empowering truth is that a significant number of so-called AI risks are, in fact, old security problems wearing new language. Read More.
By @proofofusefulness [ 3 Min read ] Three startups—Pantry Pilot, RecomendeMe, and Charmpay—featured in HackerNoon Projects of the Week for proving real-world usefulness. Read More.
🧑💻 What happened in your world this week?
It's been said that writing can help consolidate technical knowledge, establish credibility, and contribute to emerging community standards. Feeling stuck? We got you covered ⬇️⬇️⬇️
ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME
We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.See you on Planet Internet! With love, The HackerNoon Team ✌️
2026-02-07 21:59:59
Firefox Managed Session Controller is an open-source Ubuntu tool that scored 36 on HackerNoon’s Proof of Usefulness scale, aiming to help parents create healthier internet boundaries for children.
2026-02-07 21:53:57
\
What happens when the person who onboarded 150 million people into crypto decides the next frontier is autonomous AI?
That is the question the tech and AI industry now faces as Kris Marszalek, the co-founder and CEO of Crypto.com, formally announced the launch of ai.com as a consumer-facing autonomous AI agent platform, set to go live on February 8, 2026 with a Super Bowl LX commercial on NBC.
\ This is not another chatbot. This is not another wrapper on GPT. And this is not a product aimed at developers or enterprises. ai.com is positioning itself as the first platform to give everyday consumers access to AI agents that do not just respond, but act.
\
Marszalek acquired the ai.com domain in April 2025 in what the Financial Times reported as a $70 million transaction, believed to be the single largest domain purchase in recorded history. The deal, brokered by Larry Fischer of GetYourDomain.com, was paid entirely in digital assets to an undisclosed seller. For context, the previous publicly known domain sale record was nearly $50 million for CarInsurance.com, and the ai.com domain itself had last changed hands in 2023 for $11 million.
\ Since the purchase, Marszalek has been assembling a dedicated AI team and building out the platform's infrastructure. The timing of the launch, paired with a Super Bowl commercial slot that typically costs upwards of $7 million for 30 seconds of airtime, suggests this is not a soft launch. This is a consumer acquisition play designed for mass scale, mirroring the strategy Marszalek used when Crypto.com secured naming rights to the Los Angeles arena in a 20-year deal valued at $700 million and ran Super Bowl ads in previous years.
\
The platform allows users to generate a personal AI agent in roughly 60 seconds. The agent operates autonomously on behalf of the user, performing tasks like trading stocks, managing calendars, sending messages, automating workflows, and even updating online dating profiles. All of this runs within a secure environment where data is encrypted with user-specific keys and agents are restricted to user-defined permission limits.
\ The differentiator, according to the company, is self-improvement at network scale. When one agent builds a missing feature or capability to complete a task, that improvement gets shared across millions of agents on the platform.
\ Kris Marszalek, Founder and CEO of ai.com, explains,
\
"We are at a fundamental shift in AI's evolution as we rapidly move beyond basic chats to AI agents actually getting things done for humans. Our vision is a decentralized network of billions of agents who self-improve and share these improvements with each other, vastly and rapidly expanding agentic capabilities and accelerating the advent of AGI."
\ The free tier gives users basic access, with paid subscriptions unlocking enhanced capabilities and increased input tokens. The company is also exploring financial services integrations, agent marketplaces, and what it describes as "human and agency co-social networks."
\
The agentic AI space has been heating up throughout 2025 and into 2026. OpenAI has been pushing its own agent capabilities. Google DeepMind has expanded Gemini's autonomous functions. Anthropic, Microsoft, and a growing number of startups are all racing to define what consumer-facing AI agents look like. But most of these efforts remain tethered to technical users, API integrations, or enterprise deployments.
\ ai.com is making a bet that the gap in the market is not capability, but accessibility. The pitch is zero technical knowledge required. No hardware. No complex setup. Just a handle, an agent name, and you are live.
\ Whether this simplicity holds up under real-world usage remains to be seen. The promise of agents that autonomously trade stocks or manage financial workflows carries regulatory weight. The platform will need to navigate securities regulations, data privacy frameworks across jurisdictions, and the fundamental trust problem that comes with giving an AI agent permission to act on your behalf.
\
Marszalek is running a familiar playbook. Crypto.com grew through aggressive consumer marketing, stadium naming rights, celebrity endorsements, and regulatory compliance across multiple jurisdictions. The company holds licenses and registrations in markets globally and processes transactions for over 150 million users.
\ Applying that same infrastructure and strategy to AI agents is a calculated move. The Super Bowl ad is not just marketing. It is a statement that ai.com intends to compete for mainstream consumer attention against the largest AI companies in the world, from a standing start.
\
The ambition here is clear and the execution timeline is aggressive. Launching a consumer AI agent platform with a Super Bowl commercial is the kind of move that either defines a new category or becomes a cautionary tale. Given Marszalek's track record of scaling Crypto.com to 150 million users and securing regulatory approvals across dozens of markets, the operational credibility is there.
\ The real test will be whether ai.com can deliver on the promise of genuinely autonomous agents that work reliably across financial services, productivity tools, and daily life, while maintaining the security and privacy standards consumers will demand. If it works, this could be the platform that makes AI agents as commonplace as mobile apps. The race just got significantly more interesting.
\ Don’t forget to like and share the story!
:::tip This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYO
:::
\
