MINA Staking

GROOT StakeService

The Best MINA


Guaranteed 24% rewards for unlocked and 12% for locked!
Performance focused - GROOT - Mina Staking-as-a-Service



"We are Groot" & a handsome chef with a bias towards pressing buttons - Cristian.
Also we know "stuff" about horoscope, critical infrastructure & MINA Staking Nodes.

Like the beloved GROOT...we do!
We can do it better together.


Staking Mina
Planting Trees

Some Stake Nodes
Some Trees

A tree for all the epochs that GROOT staking node is running.
+1 tree/epoch>0 minted blocks, +2/epoch>20


Resilience & Speed
Performance & No SPoF

3+ Worldwide Relays
Zero downtime

GROOT Staking as a Service is a resilient set of nodes for Mina blockchain.


Mina To The Moon!
1st Forest by Staking

MINA Mass Adoption
GROOT Staking Greets You!

Staking-as-a-Service GROOT is performance oriented staking node for the Mina project. Having a bigger or smaller forest planted solely from nodes profit will be a great gift.

Driven by Performance Mina Staking Node

3+ Worldwide Spread Nodes

i9-12900K@DDR5 / Ryzen 5950X / i9-11900K

Q & A

Couple of answer to potential questions

This website is still under construction

What rewards do I offer? The highest potential rewards and guaranteed!
If you took part on Mina ICO or you've bought a number of coins via Kraken, OKEx, Gate.io or Coinlist feel free to delegate as I will pay 24% guaranteed for the first 4 months if your token are unlocked. 12% for locked ones.
I don't use fair share system or canonical related blocks distribution. That means: no matter who win the block, if is canonical or not, or any other aspects/variables. You know exactly how much you'll get before the delegation.
You'll get the rewards every month (or epoch) based on your initial stake.
Simple formula 2% (1% for locked) every month for your initial delegated stake, paid monthly or if there are any trust issues I'll pay after every epoch which is two times per month.

  • Delegate 100 MINA unlocked = 2 MINA each month
  • Delegate 2000 MINA unlocked = 40 MINA each month
  • Delegate 66000 MINA locked = 660 MINA each month

I'll use rounded numbers as I like their beauty: as an example; when you delegate 14758.35 MINA, your rewards will be 295.167 per month, you'll receive first month 296 MINA followed by 3 months of 295 MINA.
An answer to a question that one can rise is about getting the rewards only for Initial Stake vs rewards for Initial + Subsequent Rewards. I won't take into consideration your rewards! This is the reason why I establish very clear, fixed, easy to know, calculate and the highest numbers at start.
*At 1st of October 2021 the rewards will be decreased for unlocked token to 18% guaranteed for the next 4 months, for locked ones will stay the same 12%.
NOTE: The strategy from October onwards is yet to be decided! (Update 25Nov: We are still on 24% / 12%)

Feel free to use the contact form below for any information or ideas.

What hardware am I using? i9 & Ryzen
At least three physically dedicated servers covering Europe and North America with a good combination of Tier1 and T2 peering/routes. I had servers also in Asia (SG, JP, HK) but were proven to underperform due to global distribution of nodes.
The specs are: 6 to 32 cores and 32 to 128 GB RAM. The "newest-november" acquisition is an Intel Core i9-12900K with DDR5.
Running SNARKS.
I will avoid the use of AWS, GC and Azure infrastructure for Mina network. In fact I avoid these three in all of the crypto projects in which I'm involved, in my opinion is ethically wrong to provide a decentralization service using a...monopolistic centralized system.
Also, from time to time I use various low and high end specs for testing purposes.

Means of communications Via this website contact form. There will be an email subscription for any Staking-as-a-Service related queries.

Small stake welcome! Guaranteed rewards.

Best Mina Staking Nodes

Zero Single Point of Failure

Useful resources for Delegators and Mina Node Operators

Metrics and Informations about Mina Blockchain & Stake Nodes

Websites & Telegram channels Mina related

Mina delegators and Staking-as-a-Service Operators may need to use some of the below resources at one point. All the websites whoing metrics displays informations taken from Mina blockchain explorer however there can differences between the information format. Check and use the one you like.

Useful metrics about Mina staking nodes for delegators and node operators in MINA Network

Mina blockchain technically related content

  • minaprotocol.org Official documentation for setting up a node and additional information.

Telegram channels for Mina Blockchain, Nodes Operator and Mina Developers

Short Answers to Some of the Mina Protocol FAQ

1. What about decentralization? There are over 650 Genesis Founding Members and any of them can run nodes. Nodes can be any or all of these: Block Producers, SNARK-ers, Archive. Over 500 Validators are active on the network at 12th of June 2021, I have a positive feeling about decentralization considering the mainnet launch on March.

2. Mina depends and use Google Cloud for Archive nodes? It doesn't depends or rely on GC, they use it as well as using AWS. GC & AWS are easy to manage and scale, personally I don't use the big three, but if I was O1 Labs creating such a wonderful blockchain I would like to spend as less time as possible on settings servers but focus on the protocol development.

3. Why TPS is low? Is common sense and a logical decision to focus on what's important and what makes the protocol great instead of what's important for mythology. TPS can be increased fairly easy but it won't benefit the chain yet.

4. Transaction procesing time? A transaction average processing time is not more than 4 minutes. A block is created at approximately every 3 minutes, if you've made a transaction 30 seconds before the block production time, 30 seconds will be the processing time. However, when using exchanges we can wait for about 1 hour to deposit. Kraken as an example needs 15 confirmations for deposit, that mean 15 blocks which takes around 50 minutes, withdrawals are done in about 5 minutes from my experience.

medium.com/minaprotocol A great explanation to most common questions and what's next, published on 12th of June 2021

CO2/Running Cost settled 2025/2022

Optimizations and Settings for Mina Stake Nodes servers

SSH, Sysctl, Chrony, Firewall, for Mina Staking-as-a-Service Nodes

Essential Settings

For any cold operations use a computer which was not, and will never be connected to the internet.
That's your effort but keys and funds remain secure.

Note: Have Money - Love Story! No Money - I'm Sorry!

When we install any server: Dedicated, VPS or a Raspberry PI in the bedroom don’t let him running around before securing it as fast as possible after installation/deployment. Turn it off if in a rush but don't let it naked.


If SSH is not in place, we need to either create a new pair on the new computer. Or copy them via rsync, ssh-copy-id, WinSCP or whatever you like.

Test the keys are working: without closing the current session, open a new SSH, if not successful take another try as something is missing.

# 1. Permissions when you copy
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

# 2. SSHD restart for Debian/Ubuntu
systemctl restart ssh.service
# 3. SSHD edit
nano /etc/ssh/sshd_config

# 4. Port, X11 and Pwd Auth Changes
# Check through the entire page
# duplicate lines can be at the bottom
Port 836
PasswordAuthentication no
	#no for bellow if you don't use root
PermitRootLogin prohibit-password
X11Forwarding no

# 5. 1000 most scanned ports

If you can’t choose what port to use, check over this list with the most scanned 1000 ports and avoid them. Also, on iana.org you may find a detailed description of the chosen port, if in use by someone.
SSHD restart and confirm the changes.

Upgrades & Updates & Restart

Before the upgrade we can set the time zone and language. Can save you time on some future updates. If you do it, when generating the en_US language or something you prefer, check it! As some of the providers only use en_GB or some substitute, change the 2nd line accordingly. Set the time zone to UTC.

When doing the updates you can be asked to keep some currently installed configuration files or replace them, one can be sshd_config, keep current version if you don’t know what are the changes. Implicitly, new configuration is required when replaced.

# 6. Before the upgrade
dpkg-reconfigure tzdata
locale-gen en_US.UTF-8
update-locale LANG=en_US.UTF-8

# 7. Updates and housekeeping
apt-get update -y
apt-get upgrade -y
apt-get autoremove
apt-get autoclean
apt-get install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

After the updates reboot! This reboot is mandatory and most of the times is recommended to re-run the upgrades again as some packages might be pretty ancient, skipping this step can affect the performance of the system. The unattended updates package consist of stable versions only but if you don't trust it just drop it.

Firewall UFW

The following part can be ignored but I think limiting the connections to your server is beneficial. Limits per Mina node port and the number of global in-connections. For this we have to add the rules on before.rules configuration UFW file, as it is before rules (before the user rules) your whitelisted IP should also be present here. Using before rules in order to also have a summary look inside the rules and we don't want to add rules that will be subsequently ignored.

Two important facts are: 1.if we write a rule in to the UFW rules configuration files and we mess something the UFW will become and stay disabled when reloading, with a message about which line is broken or some error. 2. the rules are read in order.
If first rule is to allow on port 8302 after that a denied IP, it won’t block the IP access if is connecting to port 8302. In order to deny an IP you have to use ufw insert 2 deny from, use insert 2 or 3 (assuming you have at least 2 or 3 rules) for easy remove/check after, avoid position 1 as you may want to use it for critical allows.

We’ll use the masking, basic masking is very easy to understand for UFW allow/block IPv4, advanced masking might be a bit confusing.
The basics are like that: 8>.16>.24>.32=

  • 8 is referring to all of the IPs ranged after the first set of digits
  • 16 after the second set
  • 24 after the third, and
  • 32 mask mean the entire IP address.
  • means the IP itself
  • (can be written also like means all the IPs ranged where the star is: 129.134.29.*
  • ( means 129.134.*.*
  • ( means 129.*.*.*

Allowing or denying with mask 8: for the above example is any IP starting with 129 will be allowed/denied.

# 8. UFW install
apt-get install ufw

# 9. Add your IP, node port and enable
ufw allow from xxx.xx.xx.xxx
ufw allow 8302/tcp
ufw enable

#10. Add your IP in before.rules
# Limit connections coming in 
nano /etc/ufw/before.rules

-I ufw-before-input -s -j ACCEPT
-A ufw-before-input -p tcp --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
-A ufw-before-input -p tcp --syn --dport 8302 -m connlimit --connlimit-above 100 -j DROP
-A ufw-before-input -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 24 -j DROP
-A ufw-before-input -p tcp --syn -m connlimit --connlimit-above 400 --connlimit-mask 0 -j DROP

1st rule is to allow our IP.
Maximum 3 connections per IP, whatever the port. The node needs only one per IP, let’s say two if other parties have difficulties connecting and their server is initiating a new connection without firstly closing this one. So, I set 3 because I feel cute.
Maximum 100 connection coming via port 8302, the Mina node port. This is the third rule (or 2nd for block category) to avoid the probable unintended mess that can be caused by a legit but in trouble node who's trying to connect chaotically. We have first rule no more than 3 connections and then if is Mina node related is free for 100. Having this rule after the one with 400 global could make our node useless for Mina related new connections, in the face of a concerted random attack. We don't forget the main scope why we are here: To run the MINA.
Maximum 50 out of 255 potential IPs with 24 mask, note that the number of computers behind those 254 can be larger.
Maximum 500 TCP IN total connections to our node by using mask 0, we don’t need 500 but let's be selfish.

Considering the above rules the maximum needed is 300 for the node to be operative and some more if we update or we watch a movie in the same time. This type of configuration is some sort of protection in case something hard to anticipate is occuring and we still want to remain useful as a Mina Staking-as-a-Service, keep the protocol running but in the same time don't get punched out.

Keep an eye on the Mina updates and protocol needs. Feel free to adjust the numbers however you want or you consider reasonable. No mask 16 and 8 used as the IP distribution around the world is not even. There are no benefits in configuring useless rules, in order to really have useful rules in here there's some work to do and the efficacy will still remain questionable.
After you add any rules straight to *.rules make sure ufw reload.

Extra settings to before.rules & UFW

When on before.rules you can check and alter for your needs: the 5th set of rules is relating to your server ping response, we can DROP it from here or from sysctl. This one is better as you and the allowed IPs above will be able to ping the node for various monitoring/checks but nobody else can. On the sysctl variant is disabled for everyone.

UFW also provide us with maximum initiated attempts limit in a defined period. The default is 6times/30seconds when enabled, the command is:
ufw limit 836/tcp this will deny any IP who tried more than 6times/30sec/port836.

All of the rules that you input by command are added for IPv4 and IPv6. If you have to actively use the UFW adding/removing rules features and only need the IPv4 ones, changing the IPv6 to no in the first row on rules here nano /etc/default/ufw will block all the IPv6 connections and only allow the loopback communication, also no new rules for IPv6 will be added and the rules/status will be easier to read.

Dynamic IP’s & UFW

When no static IP and your ISP can’t hand you over one the simplest and safest way is to add the entire IP range. With mask 8 allowed we are roughly 200 times less exposed without locking ourselves out.

#11. Extra UFW before.rules checks
#DROP ping reply from UFW firewall not sysctl

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP

#12. UFW allow class for dynamic IPs
# if you want to use UFW ALLOW user rules
ufw insert 1 allow from
# have the same effect

Allowing 10-20 IPs with mask 8 rather than allowing the SSH port is still around 200 times less exposure, so don’t lock yourself out, use whichever mask you are positive about meeting your needs. If definitely know that only the last set of digits from your IP will be changed use mask 24. This rule should be the first one added (see above UFW discussion) in the before.rules right after the "End of required lines" or ufw insert 1 allow from if you use command line for user.rules

Port knocking. Connecting when we move along or no fixed IP involved.

If there is no fixed IP, class of IPs or we have to connect from an unknown location we can use simple port knocking, you can go for advanced ones but they can be more annoying.

#13. Port knocking
nano /etc/ufw/before.rules
-A ufw-before-input -m state --state NEW -m tcp -p tcp --dport 836 -m recent --rcheck --name SSH -j ACCEPT
-A ufw-before-input -m state --state NEW -m tcp -p tcp --dport 31747 -m recent --name SSH --remove -j DROP
-A ufw-before-input -m state --state NEW -m tcp -p tcp --dport 31748 -m recent --name SSH --set -j DROP
-A ufw-before-input -m state --state NEW -m tcp -p tcp --dport 31749 -m recent --name SSH --remove -j DROP

The knocking looks like that: before being able to connect to our SSH port 836 we need to first initiate any connection (can use Putty and change port, or any mean of sending a packet of data) to port 31748 in our example; nothing happens as the packet is dropped but our needed port 836 will be opened for us now, so we can use SSH and do the spring ploughing, after we finished we need to initiate a connection to 31747 or 31749 to close the listening on SSH. *7 and *9 are used to avoid our port opening without closing it straight away by random port scanners.

Chrony fundamental settings

Very important 7: do not use NTP servers from Ubuntu, Fedora and Google; they aren't accurate! Google was good some time ago, currently is at best a non-sense with low Stratum and excellent latency but ridiculous time. Note: time.nist.gov is a reliable source in many US locations.
Very important 9: use minsources 3 (as global setting), it compares the time of minimum 3 different sources before deciding, it automatically reject the bad one time. Without this enabled the accuracy can get affected if there are NTP's very close but inaccurate and some other far away. Chrony will synchronize with the closest as it considers the other affected by latency.

The easy way to configure is to use pools from ntp.org, choose 3/2/1.country.pool.ntp.org and 2/1/0.continent.pool.ntp.org or whatever you’d like, iburst need to be present on all of the servers and pools, for the pools I go with maxsources between 4 and 8.

#14. Chrony fundamental settings
apt-get install chrony
nano /etc/chrony/chrony.conf

pool 1.sg.pool.ntp.org iburst	maxsources 7 maxpoll 8
pool 1.asia.pool.ntp.org iburst	maxsources 7 maxpoll 8
server ntp.xtom.com.hk iburst maxpoll 8
maxupdateskew 5.0
makestep 0.1 -1
leapsectz right/UTC
local stratum 10
minsources 3

We don’t use minpoll and the maxpoll is 8, not less than 6 anyway. Poll 8 means that at maximum 256 seconds we'll ask for new synch with the NTP servers. Poll 7 means 128 seconds, poll 6 is 64 and so on. There are some compulsive disordered myths about using maxpoll 2, 3 or even 0 or below.
If we find ourselves in a position of asking more than 1 time per minute that mean something else in our structure is really unfit for purpose. You may use it when you own a set of 3 NTP servers.
Couple of reasons why it doesn't make sense:

  • clock will be never independently synchronized and won’t be able to self-sustain not even for a very short time period
  • can get banned from NTP servers, when banned you may still get the time but from the service door, which sometimes is dirty

The recommended way is to look for Stratum 1 & 2 servers near Mina node location and use it. If your Google search is currently broken there's another solution:

  • set your maxsources to 8/pool
  • add the NTP pools (4) from the country where the node reside
  • check chrony sources
  • write down the fastest and reputable ones
  • restart chrony service and wait for 4-5 minutes then write again
  • if needed, do it again until you are happy with the results
  • change to the collected servers instead of pools.
6-9 servers should be enough, after you’ve put the servers in place monitor them for couple of days and replace the bad performing.
Monitoring is like that, chronyc sources: when the difference between sample and last is too large or zero those need be replaced. The zero one are either offline or restricted. Large difference is an evasive term that looks like: when most of your servers have none or small difference between sample and last but some of them have a big one, the some need replacement.
When all of the sources have large differences most of the time: reinstall OS, check the network connectivity, change provider, etc.
#15. Start Chrony with IPv4 only (add -4)
nano  /etc/systemd/system/chronyd.service
ExecStart= /usr/lib/systemd/scripts/chronyd-starter.sh -4

Familiar issues: giving IPv6 or listening on but IPv6 disabled, edit chronyd service and start with -4 option, IPv4 only; none of the servers are working, check the firewall and then with your provider to see if they use their own servers.

Sysctl settings

For improved security and performance, I’ve crafted a set of rules that can be added to any Mina node. Look at the last part if using multiple virtual nodes on one host as some of the marked settings can interfere with the virtualized hosts, however running a single instance of Linux all of the settings should be copy/paste.

#16. Sysctl configuration
nano /etc/sysctl.conf
	#add following lines

	# Ratio tcp/app
net.ipv4.tcp_adv_win_scale = 2	
	# Latency vs Throughput
net.ipv4.tcp_low_latency = 1	
	# Long live the King
net.ipv4.tcp_slow_start_after_idle = 0	
	# No route saving
net.ipv4.tcp_no_metrics_save = 1	
	# Send with first packet
net.ipv4.tcp_fastopen = 1	
	# IPv6 disabling
net.ipv6.conf.all.disable_ipv6 = 1	
net.ipv6.conf.default.disable_ipv6 = 1	
net.ipv6.conf.lo.disable_ipv6 = 1	
	# BBR
net.core.default_qdisc = fq	
net.ipv4.tcp_congestion_control = bbr	
	# Gretel and Hansel
net.ipv4.conf.all.rp_filter = 1	
net.ipv4.conf.default.rp_filter = 1	
kernel.randomize_va_space = 1	
	# SYN attacks
net.ipv4.tcp_max_syn_backlog = 4096	
net.ipv4.tcp_syn_retries = 4	
net.ipv4.tcp_synack_retries = 2	
net.ipv4.tcp_syncookies = 1	
	# Ignore ICMP broadcast request and bogus response
net.ipv4.icmp_echo_ignore_broadcasts = 1	
net.ipv4.icmp_ignore_bogus_error_responses = 1	
	# Reboot 10 seconds after Kernel mortality, avoid downtime
kernel.panic = 10	
vm.panic_on_oom = 1	
	# Using swap
vm.swappiness = 10
	# Check the below set when running multiple machines on one host
	# No routing and redirects
net.ipv4.ip_forward = 0	
net.ipv4.conf.all.accept_redirects = 0	
net.ipv4.conf.all.accept_source_route = 0	
net.ipv4.conf.all.secure_redirects = 0	
net.ipv4.conf.all.send_redirects = 0	
net.ipv4.conf.default.accept_redirects = 0	
net.ipv4.conf.default.accept_source_route = 0	
net.ipv4.conf.default.secure_redirects = 0	
net.ipv4.conf.default.send_redirects = 0	
net.ipv6.conf.all.accept_redirects = 0	
net.ipv6.conf.all.accept_source_route = 0	
net.ipv6.conf.default.accept_redirects = 0	
net.ipv6.conf.default.accept_source_route = 0	
	# Martians (If you are interested to look on the logs)
net.ipv4.conf.all.log_martians = 1	
net.ipv4.conf.default.log_martians = 1	
	# No pongs to pings, don't enable if you use ping
net.ipv4.icmp_echo_ignore_all = 1
net.ipv6.icmp.echo_ignore_all = 1

Will be counterproductive for all of us to describe each of the rules but there is a small description before them, feel free to search for if interested.
The response to ping is the last rule, as we previously added our IP to before.rules and set the others requests to DROP is not necessary to activate this option as this will stop any reply. However if not needed go for it.

IPv6 is faster and better than v4 mostly because lacking in NAT and gateway. In 1-2 years when providers will be more prepared, we’ll have a noticeable improvement in latencies, however at the moment we keep it disabled when running only the Mina node.
Regarding the security, there are some flying poetries around narrating the flaws and other epic fails, my suggestion is to make your research and don't forget that both IPv4 & IPv6 are transport protocols and both need to be protected.

Crontab for sysctl & chrony & Mina node

Sysctl might not be fully executed if some of the modules are not loaded at the time of sysctl launching. In this case an easy option is to add a cronjob 33 seconds after restart, you can tweak the time as not more than 5 seconds are needed in 99% of the situations.

#17. Delays and synchronizations
	#Delay the mina-node service with 60 seconds
nano /etc/systemd/system/mina.service
	#add the below line before ExecStart
ExecStartPre	= /bin/sleep 60
	#Edit crontab and add these lines
sudo crontab -e
@reboot sleep 33; /sbin/sysctl --load=/etc/sysctl.conf
@reboot sleep 35; chronyc -a 'burst 4/4'
@reboot sleep 53; chronyc -a makestep
@reboot sleep 55; /sbin/hwclock --utc –systohc
Also on crontab we add an iburst for Chrony in order to have the time synchronized when our Mina node is starting. Now, if you follow these settings make sure the node is starting after everything we have here is executed. You have to edit the mina service, is located at nano /etc/systemd/system/mina.service

  • 33 seconds we load our sysctl
  • 35 we burst a Chrony sync which takes 8-10 seconds
  • 53 make the chronyc step
  • 55 we instruct our hardware clock with new time
  • 60 seconds the mina node can start.

Securing shared memory & Swap file creation

These two are together as we need to edit the same file fstab in order to add both of the entries. A swap file is better to be there even when the amount of usable memory is more than enough. Securing the shared memory means that no programs can be executed from there.

#18.	Swap file creation and shared memory security
	#Check if swap is on and happy with size
swapon -s
	#Disable if not happy
sudo swapoff -a
	#Set size (8G=8GB)
sudo fallocate -l 8G /swapfile
	#Secure the swap
sudo chown root:root /swapfile
sudo chmod 0600 /swapfile
	#Make it
sudo mkswap /swapfile
	#Enable it
sudo swapon /swapfile
	#Make sure is there
swapon -s
	#Add the following lines in fstab
sudo nano /etc/fstab
	#1st is swap, 2nd is shared memory security
/swapfile	none	swap	sw	0 0
tmpfs /run/shm tmpfs defaults,noexec,nosuid 0 0
There are some theories about why all of the operating systems need a smaller of bigger swap file but I tend to believe that is nothing technical but has more to do with feelings and probably tenderness, same like tractors. In this config the swap file is 8 GB, for Mina node I'll go with 8-16 GB.

Download all of the snippets in one TXT file.

Observation when grafting the quince

With these settings our server is ready to run a Mina Staking-as-a-Service node secure and very efficiently.

In regards to security there are two valid statements:

  • 2. No security is enough security.
  • 2. Too much security is as bad as too little security.

In regards to resiliency and life in general there is one simple thing, is not about IF but WHEN. Don’t keep all your eggs in one basket and be prepared to lose the battle but win the war...IF is worthy!

Your server, cold wallet, EEPROMs, biometrics, etc. can be stolen, hacked, destroyed at any point. Facts like some mofos having five factors authentication, guesting themselves on their servers to protect some imaginary roots and using some quantum-photonic encryption in order to be imba are mostly BS.
Any layer is prone to failure or penetration, is a matter of time and/or who's on the other side. Assuming that one of the distinctive advantage of the other side is not bending knees backwards but they're passionate about hacking into 100 dollars servers.

Each layer adds complexity to a system, which doesn't automatically convert to security. The weakest link and human factor will remain as it is but the easiness of restoring/replacing a simple system won't. Focus and achieve the right balance for you.

My suggestion is to never use more layers than you can handle and if you believe that something is not safe it isn't. Take it easy, get more knowledge, understand what's happening and if your time, effort or investment for those specific circumstances have logic. If in doubt don't do it!

Keep your bloody cold keys always COLD and have backups.
Copy/paste those lines of code, talk with Jesus, use some sorceries but keep them fucking COLD.

Those keys are everything that matters on our case here; everything else like losing a server or all of them; your nodes hacked by some IRC fans, another set of lunatics sending some PayPal phishing from your SNARK-er…trivial details.

We Are GROOT! Mina Staking-as-a-Service


Feel free to ask everything about anything.
I'll get back to you not later than 5 days!