-
Project Name & Description
Aconcagua Finance, through its product Boveda.ai, is building institutional-grade infrastructure for BTCFi on Rootstock. Bóveda vaults are non-custodial, multisignature smart contracts based on Safe (Gnosis), offering secure and flexible self-custody tailored for individuals, companies, and asset managers.Safe is already deployed on Rootstock (via safe.rootstock.io), however, the current Safe Apps ecosystem is limited, restricting the ability of users to interact with native DeFi protocols from within their vaults. With this grant, we aim to fill that gap by integrating key Rootstock-native protocols — eg Tropykus, Boltz, Sovryn — directly into the Safe interface.
This will enable everybody to bridge, lend on Tropykus, and interact with Sovryn directly from their secure multisig vaults, with added features like timelocks, whitelisting, and role-based access. By embedding these DeFi integrations as Safe Apps, we transform Rootstock into a viable platform for institutional BTCFi — combining custody-grade security with seamless protocol access. Access will be allowed from the same safe.rootstock.io.
Our goal is to unlock a full institutional experience on Rootstock, helping attract capital and adoption through a transparent, and secure interface tailored for serious crypto users.
-
Team Background
Manuel Rico Molina (Founder, COO, CTO): https://www.linkedin.com/in/manuel-rico-molina/
X: @mricomolina
Github: Aconcagua-CTO · GitHubSantiago Lacasia (Cofounder, CEO): https://www.linkedin.com/in/santiago-lacasia/
-
Total Grant Amount
$14.000 total; requesting $8.000 for Milestone 1 -
Milestone 1 – Deploy First Safe App on Staging ideally via IPFS
Grant Request: $8,000 – Timeline: 8 weeks
Main Deliverable: One Safe App fully integrated and deployed to the Safe staging environment with IPFS hosting and manifest compliance. -
Milestones 2, 3, and 4
Milestone 2 – Add Additional Safe Apps to Staging + Submit First for Listing
Grant Request: $2,000 – Timeline: 4 weeks
Main Deliverable: Additional Safe Apps deployed to staging + first app submitted for official Safe listing.Milestone 3 – Submit Remaining Apps + Execute Bootstrap Phase
Grant Request: $1,000 – Timeline: 4 weeks
Main Deliverable: Remaining Safe Apps submitted for listing + Bootstrap Phase of go-to-market strategy completed. (See go to market strategy below)Milestone 4 – Complete Traction & Growth Phases with Adoption KPIs
Grant Request: $3,000 – Timeline: 3 months
Main Deliverable: Achieve 10 BTC used on Safe Apps. -
Technical Specs
-
Safe App Architecture
Each Safe App is built as a client-side React application using the cra-template-safe-app provided by Safe. It runs as an iframe inside the Safe{Wallet} and communicates with the user’s Safe via the @safe-global/safe-apps-sdk. -
Development Tooling and SDKs
safe-apps-sdk Base JS SDK for Safe communication
safe-apps-react-sdk React hooks for easier integration
safe-apps-provider Generic Web3 provider for Safe-based apps
safe-apps-wagmi Integration for apps using WAGMI hooks
cra-template-safe-app Create React App template with Safe boilerplate -
IPFS & Staging Deployment
Each Safe App will be deployed on:IPFS using web3.storage or nft.storage
Optionally mirrored on HTTPS with SSL for testing and debugging
Test environments will be accessible via Safe’s “Add Custom App” feature
For production, each app will be submitted for listing in the official Safe App registry, following Safe’s process (submission form, QA review, optional walkthrough)
-
-
**Value Prop for Rootstock
**
This project enhances the utility and institutional appeal of the Rootstock network by expanding the Safe ecosystem with direct integrations to important native DeFi protocols.While Safe is already deployed on Rootstock, the current set of Safe Apps is minimal, limiting the ability for users — especially institutions — to engage with the broader BTCFi ecosystem. By adding these integrations, we transform Safe on Rootstock into a powerful gateway for secure, compliant, and flexible financial activity, all within the network.
With Boveda.ai, institutions can bridge BTC, deploy capital into DeFi, and manage roles, whitelists, and governance securely through multisignature vaults. This increases Rootstock’s competitiveness as a Bitcoin Layer 2, unlocks new use cases for BTC, and lays the groundwork for onboarding DAOs, OTC desks, family offices, and businesses holding digital assets — all while driving protocol-level adoption across the network.
-
**Demo and GitHub repo
Demo**
Our tesnet environment is open at https://catedral-boveda.web.app/
It is currently limited because vaults can’t be created, so you can register and create your user, but will be initially without vaults. But we’ll deploy as we develop. Feel free to ask for credential to sample vaults.GitHub repo
GitHub - aconcagua-finance/Aconcagua-API-CONTRACTS-POLYGON -
Video Pitch:
Here it is. I’m a tech guy, don’t judge me too hard
https://drive.google.com/file/d/1aubWzzOLzGOGzJ78Nlka2tdSaLQ2SBne/view?usp=sharing -
Go - To - Market Strategy
-
Phase 1: Bootstrap (16 weeks – Already Started)
Target Audience: Crypto-native users (DeFi participants, OTC traders, DAOs, family offices)
Actions:Participated as speakers at Bitcoin Pizza Day Argentina
https://x.com/BitcoinAR/status/1925338681209929834
https://x.com/BitcoinAR/status/1925338696271663178
Published testnet and invited early users to test vault functionality
Featured in the “Charlas con Sato” podcast (includes information on unrelated product from our company)
https://www.youtube.com/live/VimFn8LfQTY?si=CShNd7rQ4C3wm3m1Delivered 1:1 onboarding sessions to early adopters
-
Phase 2: Traction (3 months)
Target Audience: Wider geographical user base, academic and educational reach
Actions:Confirmed participation in Descentralizar.org
Launch of self-custody educational content series (already prepared)
Contenidos Web - Google Drive -
Phase 3: Growth (3 months)
Target Audience: Institutional users — small asset managers, companies, HNW individuals
Actions:Perform digital campaigs
-
-
Sustainability.
The safe apps will be open and available for everyone on safe.rootstock.io with no connection or relation required with boveda.ai.
We offer concierce setup and custody of keys at a price for open source products to our customers
Hi Delegates! I would love to hear your feedback before the onchain vote @Kaf_Anode @Avantgarde @Curia . Thanks in advance!
Manuel
Thank you @Ikabott for the revised proposal, the added go-to-market strategy, and the clearer articulation of your value proposition to the Rootstock ecosystem.
Could you consider including in this revised version the adoption metrics you previously shared in response to our rationale? That would help make the proposal more complete and transparent regarding how success will be measured. Specifically, you mentioned
We also have a follow-up question regarding how adoption will be evaluated going forward. The final milestone’s target of 10 BTC deployed across vaults still feels quite low, given the scope and funding requested. Could you provide more ambitious or multidimensional KPIs, for example, the number of unique users or institutions onboarded, vaults created, or transactions executed through the integrated Safe Apps?
Thanks for the feedback!
We just finished discussingthis, and we believe we found a way to incorporate it:
We start our marketing efforts earlier, with the first milestone, and we add the initial traction also earlier. We add a new milestone (5) to complete the growth phase of the go-to-market strategy with a more ambitious goal. As a comparison, 20 BTC (our new goal of all apps) is 2.3M USD (with today valuation) is more than half of what tropykus has borrowed today. We increase our budget slightly to accommodate additional marketing efforts from (from 14k to 16k).
Let us know!
Regards
-
Milestone 1 – Deploy First Safe App on Staging ideally via IPFS
Grant Request: $10,000 – Timeline: 8 weeks
Deliverables:
One Safe App fully integrated and deployed to the Safe staging environment with IPFS hosting and manifest compliance.
Bootstrap phase of the go-to-market complete (See go to market strategy below) -
Milestones 2, 3, 4, and 5
Milestone 2 – Add Additional Safe Apps to Staging + Submit First for Listing
Grant Request: $2,000 – Timeline: 4 weeks
Main Deliverables:
Additional Safe Apps deployed to staging + first app submitted for official Safe listing.Milestone 3 – Submit Remaining Apps + execute traction phase
Grant Request: $1,000 – Timeline: 4 weeks
Deliverables:
Remaining Safe Apps submitted for listing
Traction Phase of go-to-market strategy completed. (See go to market strategy below)Milestone 4 – Complete listing process of all candidate apps and start Growth Phase with Adoption KPIs
Grant Request: $1,000 – Timeline: 2 months
Deliverables:
Get 0.1 BTC bridged from Bitcoin network to a vault
Get 2 vaults above 0.1 BTC on tropykus investmentMilestone 5 - Complete growth phase Grant Request: $2,000 – Timeline: 6 months
Achieve 20 BTC used on Safe Apps.
Onboard 100 users
We are LIVE for voting!
Hi community, I want to share with anyone that is project is currently paused for reasons external to the project.
As a summary the goal of this project is to enable rootstock core dapps (moneyonchain, tropykus, boltz) to be apps in safe, thus allowing all the benefits of this technology (multisig, whitelists, spending limits, etc).
Now, working with tropykys during our first implementation we discovered a problem using safe.
From the rootstock team:
”What the Tropykus team found is a possible incorrect implementation of an opcode in the Rootstock node that affects how Safe works when the party interacting is a contract; it’s not an issue with Safe itself. This is currently being analyzed by Rootstock’s Core team.”
In more detail, it return wrong balances when interacting with contracts.
Now, this is important, we are looking for ways around it, but for the time being, we are dependant on the rootstock core team to fix it.
I will keep this post update with news.
Last is, as of Jan29, this fix is in rootstocks core backlog.
Any feedback is welcome.
Regards
Manuel
Seems like this was poised to be found, eventually.
So it may be a good opportunity to fix now by Rootstock, sonner rather than later.
Hello @Ikabott , thank you for updated post on Jan 29th regarding that this grant is on hold until the Rootstock core/dev team fixing the issue of the opcode in the RT node. Have you received any updates from the Rootstock team on timeline or if they have resolved this issue? Tks!
Hi @DAOstar_gov
Latest I have is from 2 days ago.
Rootstock team was able to reproduce the error, but only on tenderly, not on the node.
Topykys sent a new onchain test to the core team to continue investigation.
I’ll share more news when they are available.
Regards!
Thanks so much for the update, let us know once you have more info. Thks!
Hi team. Keeping you updated.
The problem remains, the good news is that we find a workaround if the problem arises.
We compiled all the information and sent it to rootstock
We’ll keep you updated
The transaction that worked:
https://explorer.rootstock.io/tx/0x50fad10444065f7558af41108b552eb0568ca171191646f190b96ff9291d1e27
The analysis we did is that Rootstock’s .send method sends a fixed 2300 gas because it uses .send, and the Safe contract consumes more than that just to forward the transaction to its implementation. Taking advantage of the fact that it’s a proxy, in the context of the transaction we changed the implementation to a practically empty contract, which cost only ~20 gas to receive the transaction instead of the ~800 gas that the Safe one costs for an SLOAD.We asked the AI to write it more clearly 
Why it fails
The Safe proxy v1.3.0 does not have its own receive() function. When it receives RBTC, all the logic goes through fallback(), which does the following:
-
SLOAD(slot 0) to read the singleton address — 800 gas on RSK
-
Auxiliary assembly operations (AND, CALLDATALOAD, CALLDATACOPY, etc.) — ~183 gas
-
DELEGATECALL to the singleton — ~700 gas base
-
The singleton executes receive(), which emits the SafeReceived event (LOG2) — ~1,381 gas
Total required: ~3,064 gas. Available: 2,300 gas. After the proxy overhead (~983 gas), only ~1,317 gas remain for the singleton. The LOG2 event needs 1,381 gas. Short by 64 gas.
Why it works on Ethereum but not on Rootstock
In Ethereum (post-Berlin / EIP-2929), storage accesses and contract address accesses distinguish between “cold” (first time) and “warm” (subsequent) accesses. Within the same transaction, the proxy’s slot 0 and the singleton address have already been accessed earlier, so:
| Operation | RSK (RSKIP-239, no EIP-2929) | Ethereum (post-Berlin) |
|---|---|---|
| SLOAD(slot 0) | 800 gas (always flat) | 100 gas (warm) |
| DELEGATECALL to singleton | ~700 gas | ~100 gas (warm address) |
| Proxy overhead | ~983 gas | ~383 gas |
| Gas remaining for impl | 1,317 gas | ~1,917 gas |
| LOG2 (SafeReceived event) | 1,381 gas > 1,317 → FAIL | 1,381 gas < 1,917 → OK |
Rootstock implemented the Istanbul repricing via RSKIP-239 (raising SLOAD from 200 to 800 gas), but never implemented EIP-2929 (warm/cold storage access discounts). Without the “warm” discount, SLOAD always costs 800 gas, and the proxy overhead exceeds the 2,300 gas stipend provided by .send.
Scope of the issue
This affects any Safe multisig on Rootstock that is the recipient of a transfer via .send() or .transfer(). It is not specific to one contract or use case — any protocol, DAO, or contract that uses these methods to send RBTC to a Safe will either fail silently (.send() returns false) or revert (.transfer() reverts).
Hello team.
Small update to keep the thread alive. There is consensus that rootstock needs EIP-2929 applied in order to make safe work. It’s been discussed between the rootstock and the tropykus team. Nothing we can do from the project at the moment.
It’s unfortunate we can’t move forward. We’ll keep you updated.
Regards
Manuel
Hello @Ikabott , thank you so much for this incredibly detailed technical breakdown and all the updates, as we’re sure that it’s been frustrating for you right now with this roadblock. It’s also clear you’ve done the heavy lifting to identify the root cause. Since you mentioned this affects Safe v1.3.0, have you explored if using a different version of Safe (or a modified Rootstock-optimized singleton) could bypass the LOG2 gas requirement? Or is the proxy overhead (SLOAD at 800 gas) an insurmountable barrier for any Safe-based architecture on the current RSKIP-239 parameters? Do you have any “plan b” options to overcome this issue that uses a different solution? We would like see the grant project move forward to a succesful completion, and realize that it’s in limbo.