rpc = RippleNetwork(app.config['RIPPLE_SERVER'])
poll = RippleNetwork(app.config['RIPPLE_SERVER'])
last_ledger = Variables.get('ripple_last_ledger')

while True:
    trans = []
        rst = rpc.account_tx(account=withdraw_wallet, ledger_index_min=last_ledger, limit=1000)
        while rst.get('marker') is not None:
            rst = rpc.account_tx(account=withdraw_wallet, ledger_index_min=last_ledger, marker=rst['marker'], limit=1000)

    except RippleException as e:
        if e.resp['error'] == 'lgrIdxsInvalid':
            log.debug('ledger_index_min too new, sleeping for 10s')


    for rec in trans:
        tx = rec['tx']
        log.debug('Got tx %s', tx['hash'])

        if tx['TransactionType'] != 'Payment':

        if tx['Destination'] != withdraw_wallet:

        log.info('Queue tx %s', tx['hash'])

    last_ledger = rst['ledger_index_max'] + 1
    Variables.set('ripple_last_ledger', last_ledger)
    # Wait for next(or several) ledger close here.

Code above is my current implementation, but this method does not scale to thousands of accounts.

Is there any 'best practice'?

  • First, unless you're catching up on past transactions use subscribe instead of repeated account_tx calls. Second, for a large number of accounts it can be more efficient to just subscribe to the the full transaction stream and filter it down to the transactions you care about.
    – dchapes
    Apr 6 '14 at 8:54
  • dchapes: why don't you add that as an answer? I agree that if you're monitoring a significant number of accounts, it's best to get the full stream and filter.
    – Eric S
    Apr 6 '14 at 10:28

I'm not sure a large code paste is the best way to get your example across (I'm unfamiliar with the library/API you're using for example). Assuming it's correct to summarize that you are looping, repeatedly doing account_tx RPC calls with at most a ten second delay; then that's not efficient even for a small number of accounts.

For a small-ish number of accounts, I'd recommend doing something like your loop only on restart to catchup from a last known ledger you've processed. (For example, after restarting your monitoring after an outage or disconnect). Once caught up it's better to use the subscribe RPC with the set of Ripple accounts you're interested in. The server will send you a notification anytime any transaction touches any of the accounts you list. This avoids polling and is far more efficient, especially during periods where the accounts are idle. (I'm only familar with using subscribe over a websocket, and it works very well for this even over days; I don't know what library support for this is like).

Once you go beyond a certain threshold of accounts you are trying to watch, especially if they are very active accounts, it may be easier to use the subscribe RPC to subscribe to all transactions and filter those for just the ones effecting the accounts you're interested in. Also, at that point it may become a good idea to do such queries against your own locally running rippled rather than rely on a public Ripple server.

The point at which it's best to switch from subscribing to a list of accounts versus subscribing to all transactions is unclear to me. For starters, there may be a limit to the number of accounts you can specify in a subscribe call; if so perhaps modify a locally running rippled to remove any such limit and have it do the filtering may be appropriate.

  • Thanks for replying. The RippleNetwork thing is just a thin wrapper around rippled websocket API. I aware the subscribe method, but how do you recover to the point where the monitor daemon fails? Repeated transactions are acceptable, while missing several is not.
    – Proton
    Apr 7 '14 at 7:12
  • Subscribing all transactions and do filtering is also acceptable. But there is no "ledger_index_min" like account_tx provided, only live transaction streams.
    – Proton
    Apr 7 '14 at 7:18
  • @Proton "but how do you recover to the point where the monitor daemon fails". I covered that in the second paragraph. That's where it would make sense to do a loop like the one you gave. You'd keep track of the highest ledger number you've synced with (either via the ledger field of each tx or if you happen to also want/need the ledger close stream you could use that). On restart you'd do the account_tx from that ledger forward, and once caught up with the current ledger you'd switch over to the subscribe stream for efficiency and lower latency rather than needing to poll for changes.
    – dchapes
    Apr 7 '14 at 14:06
  • At least that's how I'd approach it, there are probably other ways.
    – dchapes
    Apr 7 '14 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.