We recently introduced our new Notify API for programmable real-time transaction notifications. This new API represents an exciting step forward for Blocknative's cycle of ideate, build, test, learn, and refine. And one thing I've learned in two decades of founding and running startups is that successful organizations are constantly searching for customers to say three magical words:

We want that!

This new development was only possible because we worked with a great partner — Pillar Wallet — who said those three magical words. Read on to learn how we identified the opportunity, what it took to build the API, and why it might matter to your blockchain-based business.

Imagine my excitement after our first call with Drew Harding, the Chief Product Officer at Pillar. During the call, I ran through an end-to-end demo of our framework for Dapp developers — showcasing at least two dozen unique features... but Drew focused on one feature in particular: transaction notifications. 

So when Drew shared that real-time transaction notifications were an area where he thought we could integrate with Pillar Wallet, I realized that this was a great opportunity and that the team had a lot of work to do. Why? 

1. Integrating with a Wallet is an entirely different process than integrating with a Dapp.

2. Because Pillar is a multi-asset wallet, we needed to detect transactions involving ERC-20 and ERC-721 tokens in addition to ETH – with more contracts, such as swaps, to follow.

3. As strong proponents of great wallet UX, Pillar needed the ability to notify the user of both outbound and inbound transactions. So we needed to extend our node monitors to track specific addresses in addition to transaction hashes.

4. Pillar was already hard at work building their next-generation wallet platform, which involves a transition to a smart contract wallet architecture. So, in addition to their current installed base of non-custodial private-key wallets, we needed to add support for smart contract wallets.

5. As part of their next-generation platform, Pillar is also incorporating payment channels via the Abridged SDK. We needed to add support for state channels in general and payment channels specifically. 

6. Because Pillar is a native smartphone app, they control the entire UX. So everything above needed to be provided via a lightweight API whereby they let us know what they care about and we emit events describing every state change for every transaction related to everything they care about.

7. Because Pillar serves a global user base, our API needs to be highly available. This requires new levels of operational redundancy, which increases technical complexity.

8. Due to the inherent vagaries and inconsistencies of the global mempool (another topic we plan to cover in a future post), we needed to ensure that our mempools were configured to accept and retain as many transactions as possible. We also needed to diversify our node peering relationships as well as develop a roadmap for further geographically distributing our node monitors

9. And a lot more that’s not worth mentioning here

See that list? This is the hard part. 

This is also why the best product ideas often require someone from the outside to spot the obvious opportunity. Drew noticed one of our many features and said: “We want that.” We assumed he had no way of knowing that this would cascade into this laundry list of features and infrastructure enhancements.  

But the team certainly did. Which is why we hadn’t seriously considered building this capability. We were too close to the problem. All of that would be too time-consuming to build on a speculative basis. Except this wasn’t speculative. We had a real partner who wanted this functionality.

After determining that we might have an opportunity to integrate, Drew introduced us to Vitor Py, Pillar’s CTO. Early in the conversation, Vitor told us that he and his team had already built a system to handle real-time notifications. 

😳

We were more than a little surprised.

But Vitor went on to tell us:

At first glance, this seems like a straightforward problem. But the infrastructure required to capture the data is complex and expensive to operate. And we had multiple engineers involved in building and maintaining it. There aren't any shortcuts. Doing it reliably, at scale, was becoming a huge distraction to my team.

Based on his experience,  Vitor came to appreciate that notifications are too big of a problem to tackle as a side project. Instead, they require the dedicated attention of a focused, full-time development team. 

When we showed Vitor what we had already built, he lit up. He was excited about the prospect of outsourcing this functionality. From there we dove into Pillar’s technical requirements and how they wanted to consume the event stream from our API. Over several weeks our teams collaborated to extend the Blocknative API to meet the needs of Pillar and other Wallets. 

Blocknative now offers our Notify API, a production-ready service built specifically for Wallet providers and sophisticated Dapps who want to deploy real-time blockchain notifications.

You and your team can benefit from all of the investment we put in to satisfy Pillar's requirements. We've been fortunate to find a partner to help us find this next step in our product development. 

To see our notifications in action, download Pillar's iOS or Android app and send some Mainnet transactions. 

Wallet providers and sophisticated Dapps can now leverage this infrastructure to power real-time notifications. Those  who are interested in learning more about Blocknative can visit our Wallet page or click on the button below to book a demo: 

We recently introduced our new Notify API for programmable real-time transaction notifications. This new API represents an exciting step forward for Blocknative's cycle of ideate, build, test, learn, and refine. And one thing I've learned in two decades of founding and running startups is that successful organizations are constantly searching for customers to say three magical words:

We want that!

This new development was only possible because we worked with a great partner — Pillar Wallet — who said those three magical words. Read on to learn how we identified the opportunity, what it took to build the API, and why it might matter to your blockchain-based business.

Imagine my excitement after our first call with Drew Harding, the Chief Product Officer at Pillar. During the call, I ran through an end-to-end demo of our framework for Dapp developers — showcasing at least two dozen unique features... but Drew focused on one feature in particular: transaction notifications. 

So when Drew shared that real-time transaction notifications were an area where he thought we could integrate with Pillar Wallet, I realized that this was a great opportunity and that the team had a lot of work to do. Why? 

1. Integrating with a Wallet is an entirely different process than integrating with a Dapp.

2. Because Pillar is a multi-asset wallet, we needed to detect transactions involving ERC-20 and ERC-721 tokens in addition to ETH – with more contracts, such as swaps, to follow.

3. As strong proponents of great wallet UX, Pillar needed the ability to notify the user of both outbound and inbound transactions. So we needed to extend our node monitors to track specific addresses in addition to transaction hashes.

4. Pillar was already hard at work building their next-generation wallet platform, which involves a transition to a smart contract wallet architecture. So, in addition to their current installed base of non-custodial private-key wallets, we needed to add support for smart contract wallets.

5. As part of their next-generation platform, Pillar is also incorporating payment channels via the Abridged SDK. We needed to add support for state channels in general and payment channels specifically. 

6. Because Pillar is a native smartphone app, they control the entire UX. So everything above needed to be provided via a lightweight API whereby they let us know what they care about and we emit events describing every state change for every transaction related to everything they care about.

7. Because Pillar serves a global user base, our API needs to be highly available. This requires new levels of operational redundancy, which increases technical complexity.

8. Due to the inherent vagaries and inconsistencies of the global mempool (another topic we plan to cover in a future post), we needed to ensure that our mempools were configured to accept and retain as many transactions as possible. We also needed to diversify our node peering relationships as well as develop a roadmap for further geographically distributing our node monitors

9. And a lot more that’s not worth mentioning here

See that list? This is the hard part. 

This is also why the best product ideas often require someone from the outside to spot the obvious opportunity. Drew noticed one of our many features and said: “We want that.” We assumed he had no way of knowing that this would cascade into this laundry list of features and infrastructure enhancements.  

But the team certainly did. Which is why we hadn’t seriously considered building this capability. We were too close to the problem. All of that would be too time-consuming to build on a speculative basis. Except this wasn’t speculative. We had a real partner who wanted this functionality.

After determining that we might have an opportunity to integrate, Drew introduced us to Vitor Py, Pillar’s CTO. Early in the conversation, Vitor told us that he and his team had already built a system to handle real-time notifications. 

😳

We were more than a little surprised.

But Vitor went on to tell us:

At first glance, this seems like a straightforward problem. But the infrastructure required to capture the data is complex and expensive to operate. And we had multiple engineers involved in building and maintaining it. There aren't any shortcuts. Doing it reliably, at scale, was becoming a huge distraction to my team.

Based on his experience,  Vitor came to appreciate that notifications are too big of a problem to tackle as a side project. Instead, they require the dedicated attention of a focused, full-time development team. 

When we showed Vitor what we had already built, he lit up. He was excited about the prospect of outsourcing this functionality. From there we dove into Pillar’s technical requirements and how they wanted to consume the event stream from our API. Over several weeks our teams collaborated to extend the Blocknative API to meet the needs of Pillar and other Wallets. 

Blocknative now offers our Notify API, a production-ready service built specifically for Wallet providers and sophisticated Dapps who want to deploy real-time blockchain notifications.

You and your team can benefit from all of the investment we put in to satisfy Pillar's requirements. We've been fortunate to find a partner to help us find this next step in our product development. 

To see our notifications in action, download Pillar's iOS or Android app and send some Mainnet transactions. 

Wallet providers and sophisticated Dapps can now leverage this infrastructure to power real-time notifications. Those  who are interested in learning more about Blocknative can visit our Wallet page or click on the button below to book a demo: