Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
@GaryD Sounds awesome to me. We go once a year to Orlando for the Gymnastics national.
We will meet up for sure!
Matt
Trading futures and options involves substantial risk of loss and is not suitable for all investors. Past performance is not necessarily indicative of future results. You may lose more than your initial investment. All posts are opinions and do not claim to be facts. Please conduct your own due diligence. Use only Risk capital when trading Futures.
1 800 771 6748 local 561 367 8686 email [email protected]
@glennts we have cleared Vision from day one and our customers survived Refco, MF Global and PFG.
Any FCM with over 20 years has to endure a lot of regulation and fines.
Our customers at Optimus experienced no drama. Thank you you for your due diligence and reporting.
Matt
Trading futures and options involves substantial risk of loss and is not suitable for all investors. Past performance is not necessarily indicative of future results. You may lose more than your initial investment. All posts are opinions and do not claim to be facts. Please conduct your own due diligence. Use only Risk capital when trading Futures.
1 800 771 6748 local 561 367 8686 email [email protected]
what are your opening account balance requirements?
what are your daytrade margins on the popular emini contracts?
(ES, EMD, YM, NQ, QM, CL, TF/AB/ER2, 6A, 6B, 6C, 6E, 6S)
what are your platform choices, and associated fees monthly, if any?
what or which data vendors and fees are available, for say the Ninja platform?
sure would be nice to know those essentials, perhaps even pick up a few converts along the way
If safety was priority number one, I sure as hell would not be trading futures... lol!
I am not all in. But you never know until you know. In my mind, at least they are heavily watched.
I looked into everything that worked with Sierra. I called him, not the other way around. So I am either good to go, or on my own, which is nearly the same thing.
We are working on our calculated market statistics, like NYSE TICK. These are intended to be of very good quality and accuracy. We plan to release these in February.
In regards to Zen-Fire and Sierra Chart, if you have a look around at the postings about what is currently going on, at the time of this posting, with Zen-Fire now that it no longer utilizes Rithmic technology, it would not even matter whether we supported their API component or not. There are numerous technical problems being reported on this forum, ninja trader forum, and Mirus has acknowledged this. It would only makes sense that we stay clear of this until these problems are worked out and resolved. Zen-Fire users were always a small percentage of our user base.
We do not work with in process API components. We thought we would make an exception to the new Zen-Fire API, but after working through it, we decided not to continue because of the problems and confusion. It was a mistake for us to even consider this API or any other API for that matter going forward. This comment in no way should be taken negatively towards Mirus or the API developer. These are our own personal views based on decades of experience. We believe in quality and logical engineering and working with a neutral communications protocol between the client and the server.
We believe that when it comes to communicating orders between the client and the server and all of the trading related data, this must be done in a very well understood, clear and structured format. The best protocol is FIX and the best implementation we have seen is TT.
Edit: Also the DTC protocol that we are working to establish, is a good protocol as well. It is efficient with market data. And there is one clearing firm that has adopted it.
We work at the protocol level. We have also started an initiative in this industry to a develop a plug-and-play communications protocol between trading program/applications and the backend trading services and data feeds. This allows complete interoperability between the clients and the servers. If you have a look at the Sierra Chart website, you can learn about the DTC protocol initiative.
We hope Zen-Fire and others will join us in this effort.
However, we do not limit ourselves to DTC. We can work with any protocol, as long as it is logical and clearly documented. We also need sufficient time to be able to interface to a service. With Zen-Fire, there was not sufficient time. The whole thing happened too quickly.
If we have said things, that are not considered appropriate here, then the administrator can delete them. I just wanted to get some thoughts out there to bring an understanding among our Zen-Fire users. If you currently have a Sierra Chart account with paid usage time and cannot use it because you do not have access to Zen-Fire and were previously using Zen-Fire, please get in touch with us about this.
Rithmic has discontinued their contract with ZenFire. It means ZenFire is no longer available through the Ritmic API that is used in 3rd party platforms like MultiCharts and others. We were provided with a new ZenFire API but as it was developed by ZenFire in short terms, it is not stable enough. We're developing the broker and data feed connections to ZenFire and manage intensive testing to make it work as it should in MultiCharts. Our development team are doing their best to complete the connection development in the shortest possible time. We're sorry for the inconveniences.
We'll be sending the e-mails and posting all the necessary updaters on our Forum for a new API once they are ready. Unfortunately there is no ETA at the moment. Thank you for understanding.
There needs to be more attention brought to this concept of API components. These components are developed for amateur/beginner programmers. Professional programmers do not need to mess around with API components. They only cause us unnecessary trouble and complications.
The idea that a protocol cannot be open, and needs to be private and confidential, is complete nonsense. We have had enough of this nonsense. And Mirus and others should learn something from this.
None of us should be supporting the in process API component concept any longer. This is the source of so many problems for programmers and the end-users. A lot of problems you face with connectivity and stability in the programs that use them are due to API components.
None of us should be using API components any longer and insist upon a change. We have already made that decision and Ninja trader and Multicharts should do the same.
Edit: For those of you who do not fully understand this discussion, I guess a simple way of explaining it is that every programmer has their own way of doing things. It does not make sense to mix with one programmers code into another programmers code base. Inevitably they will conflict with each other and there will be problems. You as an end user have no idea where the source of the problem is.
Each program (the client-side trading program, and the server side market data and trading server) should implement their programs using their own methods and ideas and then use a neutral communications layer between them. This neutral communications layer is going to be a protocol like FIX or DTC. Or some other proprietary protocol.
Obviously, we all have to still deal with the underlying operating systems which computer programs are built on. But the core functions of underlying operating systems, are generally well-designed and well-documented. Critical functions like network sockets and files are very thoroughly designed and provide a proper API. Although the code below a computer program should be as minimal as possible. This is why the fastest, most efficient, and the most reliable programs are ones which are built on top of as little code as possible. This is one reason we do not use .NET. Sierra Chart is built directly on top of the Windows API, at the present time.
